[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1063882: gcc: Internal error from ternary cond as inline asm parameter



Control: tags -1 + moreinfo

On 14.02.24 02:10, VictorBW wrote:
Package: gcc
Version: 4:12.2.0-3
Severity: normal
X-Debbugs-Cc: knodewaeee+debbugs@gmail.com

Dear Maintainer,

I wanted to dynamically select registers for use in an inline assembly statement, so I tried the questionmark conditional operator, as in this minimal example:

	namespace gpr {
	    volatile register int64_t r12 asm("r12");
	    volatile register int64_t r13 asm("r13");
	...
	asm volatile ("mov %0, blah" : "+r"((reg) ? gpr::r13 : gpr::r12));


please post the complete code example.

please also recheck with newer GCC versions (GCC 13, GCC 14) in newer Debian development versions.

This generates an internal error:
	$ g++ bug.cpp
	during RTL pass: expand
	bug.cpp: In function ‘void move(uint8_t, int64_t)’:
	bug.cpp:11:47: internal compiler error: in expand_expr_addr_expr_1, at expr.cc:8435
	   11 |     asm volatile ("mov %0, blah" : "+r"((reg) ? gpr::r13 : gpr::r12));
	      |                                         ~~~~~~^~~~~~~~~~~~~~~~~~~~~

g++ -freport-bug did not deem the bug reproducible, but godbolt.org produces the following backtrace
	0x264bdbc internal_error(char const*, ...)
		???:0
	0xa523e3 fancy_abort(char const*, int, char const*)
		???:0
	0xf62e6e expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool)
		???:0
	0xf703ae store_expr(tree_node*, rtx_def*, int, bool, bool)
		???:0

I expected:
	Realistically, a proper compiler error
	Optimistically, generation of appropriate branches

I will apply an alternative solution in the meantime, but the latter behaviour would be very nice to have.

Perhaps other builtins also generate improper errors when used with a conditional operator? (I have not tried)

First time Debian/GCC bugreport, please forgive any relevant blunders :)

-- System Information:
Debian Release: 12.5
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64


Reply to: