[Bug c/38767] [avr] Complex equations evaluate wrong

[daniel at rozsnyo dot com]

--- Comment #1 from daniel at rozsnyo dot com  2009-01-08 16:51 ---
The 01 should be 0x1, my bad. Lost a day working out this :/


-- 

daniel at rozsnyo dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38767

[Bug c/38767] New: [avr] Complex equations evaluate wrong

[daniel at rozsnyo dot com]

Tried with:
 avr-gcc (GCC) 3.4.6 (Gentoo 3.4.6-r2 p1.5, ssp-3.4.6-1.0, pie-8.7.10)
 avr-gcc (GCC) 4.2.4 (Gentoo 4.2.4 p1.0)
 avr-gcc (Gentoo 4.3.2-r2 p1.5, pie-10.1.5) 4.3.2

Both -Os and -O0 behave the same, the -mmcu=atmega1281 and -mmcu=atmega128 too
(however the later was not tested on all 6 combinations)

When the complex statement is replaced with the commented out equivalent, the
result is right. It fails on stated magic numbers - the code is basically a
test if a write to external memory crosses the 64KB chip boundary or not.

Complete source code:

#define F_CPU 1600UL
#include 

uint8_t _eeprom_cross16bit( uint32_t a, uint16_t c ) {

/*
uint32_t s = a & 0x1;
uint32_t e = (a + c -1) & 0x1;
return s != e;
*/

return (a & 01) != ( (a + c -1) & 01 );

}

// main code
int main(void) {

// init LEDS
PORTC = 0;
DDRC  = 0xFF;

// comparison result:
if (_eeprom_cross16bit( 4075 , 43 )) {
// wrong
PORTC = 0x55;
} else {
// good
PORTC = 0x0F;
}

while(1);

return 0;
}


-- 
   Summary: [avr] Complex equations evaluate wrong
   Product: gcc
   Version: 3.4.6
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daniel at rozsnyo dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38767

[Bug rtl-optimization/110220] New: ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega

[daniel at rozsnyo dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110220

Bug ID: 110220
   Summary: ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel at rozsnyo dot com
  Target Milestone: ---

Created attachment 55308
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55308&action=edit
Code that fails to compile

After I migrated from gcc-4.8/4.9 to recent versions, both the gcc-14.0.0 and
gcc-13.1.1 fail to compile my pretty large avr-mcu project at one specific
function/construct. While I have found a solution with making the code
differently constructed to not trigger the ICE, now that I found time, I did
reduce the output of the  -save-temps into a single function that triggers the
assertion.


during RTL pass: jump
insn-bug-minimal.c: In function ‘cmd_parse’:
insn-bug-minimal.c:184:1: internal compiler error: in patch_jump_insn, at
cfgrtl.cc:1295
  184 | }
  | ^
0x90de427 internal_error(char const*, ...)
???:0
0x820f6af fancy_abort(char const*, int, char const*)
???:0
0x835a3be redirect_edge_and_branch(edge_def*, basic_block_def*)
???:0
0x8dc2b15 cleanup_cfg(int)
???:0


The way to avoid this ICE is to comment out one of the switch(state) cases, or
move one of them before the switch into an if-statement (my current function
equivalent workaround).

My cross-compile toolchain is made by gentoo crossdev package.

The ICE seems to be present only at -Os for the attached minimal source:
avr-gcc -g -Os -Wall -mmcu=atxmega128a4u -std=gnu99 -c insn-bug-minimal.c -o
bug.o

[Bug rtl-optimization/110220] [13/14 Regression] ICE in patch_jump_insn, at cfgrtl.cc:1295 - avr/xmega

[daniel at rozsnyo dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110220

--- Comment #3 from Daniel Rozsnyo  ---
The ICE is triggered in gcc 13 and 14 versions only.

Added gcc 11 and 12 to my gentoo crossdev - it compiles without ICE assertion
on those.