LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 24214 - Clang crashes with the regparam function attribute when targeting AArch64
Summary: Clang crashes with the regparam function attribute when targeting AArch64
Status: RESOLVED FIXED
Alias: None
Product: clang
Classification: Unclassified
Component: Frontend (show other bugs)
Version: trunk
Hardware: PC FreeBSD
: P normal
Assignee: Unassigned Clang Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-22 11:26 PDT by andrew
Modified: 2015-07-28 09:32 PDT (History)
6 users (show)

See Also:
Fixed By Commit(s):


Attachments
Example showing the assert (45 bytes, text/x-csrc)
2015-07-22 11:26 PDT, andrew
Details

Note You need to log in before you can comment on or make changes to this bug.
Description andrew 2015-07-22 11:26:56 PDT
Created attachment 14626 [details]
Example showing the assert

The AArch64TargetInfo class sets RegParmMax to 8, however in include/clang/Basic/TargetInfo.h there is an assert that RegParmMax < 7.

The attached file shows the issue when built with:
clang -cc1 -triple aarch64-unknown-freebsd11.0 regparam_test.c

Building this with clang 3.6 from FreeBSD and clang 3.8 I get the following:

Assertion failed: (RegParmMax < 7 && "RegParmMax value is larger than AST can handle"), function getRegParmMax, file /home/andrew/freebsd/repo/llvm/tools/clang/include/clang/Basic/TargetInfo.h, line 824.
Comment 1 Kristof Beyls 2015-07-24 04:15:48 PDT
IIUC, the expected behaviour is to produce an error on the attached file, just like clang does for other non-x86 backends?

$ clang -target armv7 t.c
t.c:1:32: error: 'regparm' is not valid on this platform
void foo(void) __attribute__ ((regparm(3)));
                               ^       ~
1 error generated.
Comment 2 emaste 2015-07-24 08:15:56 PDT
(In reply to comment #1)
> IIUC, the expected behaviour is to produce an error on the attached file,
> just like clang does for other non-x86 backends?

That seems correct to me. It looks like the port failures we're encountering are  caused by using regparm unconditionally, rather than in some x86 #ifdef - e.g., http://www.ohse.de/uwe/ftpcopy/ has

> #if GNUC_MINIMUM(2,7) /* doesn't work reliable before, IIRC */
> # define attribute_regparm(x) __attribute__((__regparm__((x))))
> #else
> # define attribute_regparm(x)
> #endif

> static void attribute_regparm(2)
> outplus(uogetopt_env *e, const char *s)
> { ...

So there are likely bugs for us to file for each of these ports, although the compiler should also behave as you suggest.
Comment 3 Kristof Beyls 2015-07-28 09:32:22 PDT
This is fixed by r243417.