[Bug middle-end/89998] [7/8 regression] ICE: verify_gimple failed in printf-return-value

2019-04-09 Thread gandalf at winds dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89998

--- Comment #10 from gandalf at winds dot org ---
(In reply to Jakub Jelinek from comment #9)
> Fixed for trunk.  As a workaround I'd suggest using a correct prototype or
> -fno-builtin-sprintf if you intentionally use a different one.

Thanks. Using the correct prototype (dropping the 'unsigned') indeed works as a
workaround.

[Bug middle-end/89270] [9 regression] AVR ICE: verify_gimple failed

2019-04-07 Thread gandalf at winds dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270

--- Comment #3 from gandalf at winds dot org ---
(In reply to Georg-Johann Lay from comment #2)
> For the time being, you can work around this by a macro from AVR-LibC or
> some equivalent inline asm

Thanks, that workaround does indeed work (and with slightly smaller code
generated as well).

[Bug middle-end/89998] New: [9 regression] AVR ICE: verify_gimple failed in printf-return-value

2019-04-07 Thread gandalf at winds dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89998

Bug ID: 89998
   Summary: [9 regression] AVR ICE: verify_gimple failed in
printf-return-value
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gandalf at winds dot org
  Target Milestone: ---

I get an ICE on the following code with GCC 9.0.1 20190407 (experimental)
compiled for AVR. Works in GCC 8.x. If the __flash keyword is taken out before
_str[]=("xx"), then it compiles OK.


unsigned short sprintf(char *str, const char __flash *fmt, ...)
{
  __builtin_va_list args;

  __builtin_va_start(args, fmt);
  __builtin_va_end(args);
  return 0;
}

extern char *s;

int main()
{
  s+=sprintf(s, ({ static const char __flash _str[]=("xx"); _str; }));
}


# avr-gcc -v -O -mmcu=atmega1284p -c test3.c -o test3.o
Using built-in specs.
Reading specs from
/usr/local/avr/lib/gcc/avr/9.0.1/device-specs/specs-atmega1284p
COLLECT_GCC=avr-gcc
Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr
--disable-nls --enable-languages=c --disable-bootstrap --disable-libssp
Thread model: single
gcc version 9.0.1 20190407 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O'  '-c' '-o' 'test3.o'
'-specs=device-specs/specs-atmega1284p' '-mmcu=avr51'
 /usr/local/avr/libexec/gcc/avr/9.0.1/cc1 -quiet -v -imultilib avr51
-D__AVR_ATmega1284P__ -D__AVR_DEVICE_NAME__=atmega1284p test3.c -mn-flash=2
-mno-skip-bug -quiet -dumpbase test3.c -mmcu=avr51 -auxbase-strip test3.o -O
-version -o /tmp/ccm4oBir.s
GNU C17 (GCC) version 9.0.1 20190407 (experimental) (avr)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/usr/local/avr/lib/gcc/avr/9.0.1/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/avr/lib/gcc/avr/9.0.1/include
 /usr/local/avr/lib/gcc/avr/9.0.1/include-fixed
 /usr/local/avr/lib/gcc/avr/9.0.1/../../../../avr/include
End of search list.
GNU C17 (GCC) version 9.0.1 20190407 (experimental) (avr)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 082ea327cdf9723cb24010e987b4f891
test3.c: In function 'main':
test3.c:12:5: error: non-trivial conversion at assignment
   12 | int main()
  | ^~~~
short unsigned int
int
_6 = 2;
during GIMPLE pass: printf-return-value
test3.c:12:5: internal compiler error: verify_gimple failed
0xc51c8b verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5386
0xb5ff2f execute_function_todo
../../gcc/passes.c:1977
0xb60e6e execute_todo
../../gcc/passes.c:2031
Please submit a full bug report.

[Bug middle-end/89996] New: [avr] ICE in expand_expr_real_2 with -O3

2019-04-06 Thread gandalf at winds dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89996

Bug ID: 89996
   Summary: [avr] ICE in expand_expr_real_2 with -O3
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gandalf at winds dot org
  Target Milestone: ---

The following fails with GCC 8.2 and 8.3 on AVR. The below output is from 8.3:

# avr-gcc -v -O3 -mmcu=atmega1284p -c test2.c -o test2.o
Using built-in specs.
Reading specs from
/usr/local/avr/lib/gcc/avr/8.3.0/device-specs/specs-atmega1284p
COLLECT_GCC=avr-gcc
Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr
--disable-nls --enable-languages=c --disable-bootstrap --disable-libssp
Thread model: single
gcc version 8.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-O3'  '-c' '-o' 'test2.o'
'-specs=device-specs/specs-atmega1284p' '-mmcu=avr51'
 /usr/local/avr/libexec/gcc/avr/8.3.0/cc1 -quiet -v -imultilib avr51
-D__AVR_ATmega1284P__ -D__AVR_DEVICE_NAME__=atmega1284p test2.c -mn-flash=2
-mno-skip-bug -quiet -dumpbase test2.c -mmcu=avr51 -auxbase-strip test2.o -O3
-version -o /tmp/ccYds885.s
GNU C17 (GCC) version 8.3.0 (avr)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/avr/lib/gcc/avr/8.3.0/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/avr/lib/gcc/avr/8.3.0/include
 /usr/local/avr/lib/gcc/avr/8.3.0/include-fixed
 /usr/local/avr/lib/gcc/avr/8.3.0/../../../../avr/include
End of search list.
GNU C17 (GCC) version 8.3.0 (avr)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e17ca263eb8b0996b4ab7dcf63f27ece
during RTL pass: expand
test2.c: In function 'send_document.isra.0.constprop':
test2.c:33:11: internal compiler error: in expand_expr_real_2, at expr.c:8573
0x51269b expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:8573
0x70e9a0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9968
0x71c001 expand_expr
../../gcc/expr.h:280
0x71c001 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:8575
0x70e9a0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9968
0x6195f1 expand_normal
../../gcc/expr.h:286
0x6195f1 precompute_register_parameters
../../gcc/calls.c:989
0x6195f1 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:4127
0x70e2e6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11050
0x71734b store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc/expr.c:5651
0x718189 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5419
0x718189 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:4954
0x626e38 expand_call_stmt
../../gcc/cfgexpand.c:2702
0x626e38 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3638
0x626e38 expand_gimple_stmt
../../gcc/cfgexpand.c:3804
0x628c4f expand_gimple_basic_block
../../gcc/cfgexpand.c:5833
0x62dcc6 execute
../../gcc/cfgexpand.c:6439
Please submit a full bug report.



Code to reproduce:

extern char *strrchr(const char *, int) __attribute__((__pure__));
extern int strcasecmp_P(const char *, const char *) __attribute__((__pure__));

static const struct {
  char ext[5];
  const char __flash *desc;
  _Bool subst;
} __flash mime_types[]={
  {"txt", ((const char __flash []){("text/plain; charset=utf-8")}), 1},
  {"html", ((const char __flash []){("text/html; charset=utf-8")}), 1},
  {"htm", ((const char __flash []){("text/html; charset=utf-8")}), 1},
};

struct http {
  char uri[128];
  _Bool sendfile_subst;
};

typedef struct {
  unsigned char user[sizeof(struct http)];
} DESC;

static void send_document(DESC *d, short err, const char __flash *err_string,
  const char *file, _Bool conn_close)
{
  struct http *hd=(void *)d->user;
  const char *ext;
  unsigned char i;
  _Bool subst=0;

  if((ext=strrchr(file, '.'))) {
for(i=0;i < (int)(sizeof(mime_types)/sizeof(mime_types[0]));i++)
  if(!strcasecmp_P(ext, mime_types[i].ext)) {
subst=mime_types[i].subst;
break;
  }
  }

  hd->sendfile_subst=subst;
}

static void http_do_uri_request(DESC *d)
{
  struct http *hd=(void

[Bug c/89270] New: [9 regression] AVR ICE: verify_gimple failed

2019-02-09 Thread gandalf at winds dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89270

Bug ID: 89270
   Summary: [9 regression] AVR ICE: verify_gimple failed
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gandalf at winds dot org
  Target Milestone: ---

I get an ICE on the following code with GCC 9.0.1 20190209 (experimental)
compiled for AVR. Works in GCC 8.x.

void test()
{
  extern const unsigned char __memx __data_load_end;
  __uint24 top=(__uint24)&__data_load_end;
}

# avr-gcc -v -save-temps -mmcu=atmega1284p -c test2.c -o test.o
Using built-in specs.
Reading specs from
/usr/local/avr/lib/gcc/avr/9.0.1/device-specs/specs-atmega1284p
COLLECT_GCC=avr-gcc
Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr
--disable-nls --enable-languages=c --disable-bootstrap --disable-libssp
Thread model: single
gcc version 9.0.1 20190209 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps'  '-c' '-o' 'test.o'
'-specs=device-specs/specs-atmega1284p' '-mmcu=avr51'
 /usr/local/avr/libexec/gcc/avr/9.0.1/cc1 -E -quiet -v -imultilib avr51
-D__AVR_ATmega1284P__ -D__AVR_DEVICE_NAME__=atmega1284p test2.c -mn-flash=2
-mno-skip-bug -mmcu=avr51 -fpch-preprocess -o test2.i
ignoring nonexistent directory
"/usr/local/avr/lib/gcc/avr/9.0.1/../../../../avr/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/avr/lib/gcc/avr/9.0.1/include
 /usr/local/avr/lib/gcc/avr/9.0.1/include-fixed
 /usr/local/avr/lib/gcc/avr/9.0.1/../../../../avr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps'  '-c' '-o' 'test.o'
'-specs=device-specs/specs-atmega1284p' '-mmcu=avr51'
 /usr/local/avr/libexec/gcc/avr/9.0.1/cc1 -fpreprocessed test2.i -mn-flash=2
-mno-skip-bug -quiet -dumpbase test2.c -mmcu=avr51 -auxbase-strip test.o
-version -o test2.s
GNU C17 (GCC) version 9.0.1 20190209 (experimental) (avr)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C17 (GCC) version 9.0.1 20190209 (experimental) (avr)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 7a3227a0716f5444cb50a3b2fc4e4212
test2.c: In function 'test':
test2.c:1:6: error: invalid types in nop conversion
1 | void test()
  |  ^~~~
long int
const  unsigned char *
_1 = (long int) &__data_load_end;
test2.c:1:6: internal compiler error: verify_gimple failed
0xc5df1d verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5094
0x9f42f5 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:13701
0x9f44e4 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:13791
0x86ac77 cgraph_node::analyze()
../../gcc/cgraphunit.c:667
0x86d803 analyze_functions
../../gcc/cgraphunit.c:1126
0x86e4e2 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2834

[Bug c/85623] New: strncmp() warns about attribute 'nonstring' incorrectly in -Wstringop-overflow

2018-05-02 Thread gandalf at winds dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85623

Bug ID: 85623
   Summary: strncmp() warns about attribute 'nonstring'
incorrectly in -Wstringop-overflow
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gandalf at winds dot org
  Target Milestone: ---

The following code emits a warning when using strncmp() to compare a small
quoted string with a "char data[4]" array declared __attribute__((nonstring)).

The warning only appears if the quoted string is smaller than the size of the
data[] array. My use of the data[] array is intended to act like a
NUL-terminated string unless it is 4 bytes long, at which point it is
non-NUL-terminated. This is the expected behavior when using strncpy() to fill
(and truncate) arbitrary strings into a fixed-sized char[] array. I understand
I can let GCC know of this intent by marking the array with
__attribute__((nonstring)).

My anticipated fix for GCC is that this warning should only appear with
strcmp() and not strncmp().


extern char *strncpy (char *, const char *, long);
extern int strncmp (const char *, const char *, long);

extern __attribute__((nonstring)) char data[4];

void test(char *string)
{
  if(strncmp(data, "??", sizeof(data)))
strncpy(data, string, sizeof(data));
}

# gcc -O3 test.c -c -Wall
test.c: In function ‘test’:
test.c:8:6: warning: ‘__builtin_strcmp’ argument 1 declared attribute
‘nonstring’ [-Wstringop-overflow=]
   if(strncmp(data, "??", sizeof(data)))
  ^
test.c:4:40: note: argument ‘data’ declared here


Incidentally, changing the "??" to "" or to a variable of type char* does
not cause the warning.

In my understanding, strncmp() is the correct function to use here because the
size (3rd arg) does not overflow the length of data[4]. Nothing has overflowed
here to warrant a stringop-overflow warning.

I'm also unsure why the warning says '__builtin_strcmp' when strncmp() instead
of strcmp() is being used.

Removing the __attribute__((nonstring)) causes strncpy() to warn instead:


extern char *strncpy (char *, const char *, long);
extern int strncmp (const char *, const char *, long);

extern char data[4];

void test(char *string)
{
  if(strncmp(data, "??", sizeof(data)))
strncpy(data, string, sizeof(data));
}

# gcc -O3 test.c -c -Wall
test.c: In function ‘test’:
test.c:9:5: warning: ‘strncpy’ specified bound 4 equals destination size
[-Wstringop-truncation]
 strncpy(data, string, sizeof(data));
 ^~~


Conclusion: If GCC 8+ intends that we mark non-NUL-terminated strings with
__attribute__((nonstring)) going forward, then there needs to be a way to
cleanly use strncmp() to compare strings saved with strncpy() without any
warnings.

[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem

2018-01-12 Thread gandalf at winds dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801

--- Comment #10 from gandalf at winds dot org ---
This fix resolves the issues for me. Thank you!

[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem

2018-01-11 Thread gandalf at winds dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801

--- Comment #6 from gandalf at winds dot org ---
(In reply to Georg-Johann Lay from comment #1)
> Old v7.2 does it correctly: one string in flash, one in RAM.

My more specific testcase (comment #3 in PR83729) references a 32-byte string
in a function that is only called once in my program, in a slow code path (e.g.
initialization). I understand there is a slowdown incurred by LPM instructions
when using __flash, hence the compiler may want to optimize this condition. But
since RAM is more limited than Flash on AVR (and I know my use of memory vs.
large strings), I specifically use __flash to specify I want certain strings
like this one located in flash memory instead of RAM.

Is that not the purpose of __flash? Why would the compiler duplicate this
string in RAM? What if my string happened to be larger than the total RAM
available?

[Bug middle-end/83729] [8 Regression] AVR ICE on convert_memory_address_addr_space_1 at explow.c:300

2018-01-09 Thread gandalf at winds dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83729

--- Comment #3 from gandalf at winds dot org ---
Another regression test case (compile with -O):

void code_to_ascii(char buf[1], unsigned int code)
{
  __attribute__((used))
  static const char __flash test[5]="ABCDE";

  static const char __flash code_tab[32]="0123456789ABCDEFGHJKLMNPRSTUWXYZ";

  buf[0]=code_tab[code];
}

Variable "test" is correctly placed in section .progmem.data.

Variable "code_tab" is incorrectly placed in section .rodata.

This causes a problem for programs that are larger than 64KB in size. In my
case, "code_to_ascii" is one of the last functions in my .c file, and therefore
it is at the very end of the executable. Since "code_tab" appears next to
"code_to_ascii" after the 64KB boundary, __flash no longer references the
correct area in program memory.

GCC 7.2 correctly places both variables in .progmem.data.

[Bug middle-end/83729] New: AVR ICE on convert_memory_address_addr_space_1 at explow.c:300

2018-01-07 Thread gandalf at winds dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83729

Bug ID: 83729
   Summary: AVR ICE on convert_memory_address_addr_space_1 at
explow.c:300
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gandalf at winds dot org
  Target Milestone: ---

Created attachment 43054
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43054=edit
Preprocessed file

gcc version 8.0.0 20180107 (experimental) (GCC) 
gcc svn r256323
Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr
--disable-nls --enable-languages=c --disable-bootstrap --disable-libssp
Cross compiled on host using x86_64-pc-linux-gnu v7.2.0

ICE while compiling avr-libc svn r2546

Command:

avr-gcc -save-temps -DHAVE_CONFIG_H -I. -I../../..  -I../../../common
-I../../../include -I../../../include  -Wall -W -Wstrict-prototypes -mmcu=avr2
-D__COMPILING_AVR_LIBC__ -mcall-prologues -Os  -MT asctime_r.o -MD -MP -MF
.deps/asctime_r.Tpo -c -o asctime_r.o ../../../libc/time/asctime_r.c -Wextra

during RTL pass: expand
../../../libc/time/asctime_r.c: In function 'asctime_r':
../../../libc/time/asctime_r.c:57:16: internal compiler error: in
convert_memory_address_addr_space_1, at explow.c:300
  buffer[i] = ascdays[d++];
  ~~^~
0x51b973 convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*,
unsigned char, bool, bool)
../../gcc/explow.c:300
0x7ab83a convert_memory_address_addr_space_1(scalar_int_mode, rtx_def*,
unsigned char, bool, bool)
../../gcc/explow.c:474
0x7ab83a convert_memory_address_addr_space(scalar_int_mode, rtx_def*, unsigned
char)
../../gcc/explow.c:402
0x7ab83a memory_address_addr_space(machine_mode, rtx_def*, unsigned char)
../../gcc/explow.c:416
0x791824 change_address_1
../../gcc/emit-rtl.c:2288
0x7c200f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10185
0x7c1a6c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:10586
0x7c492f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9923
0x7cf6d3 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc/expr.c:5632
0x7d0f87 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5400
0x6ad998 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3692
0x6ad998 expand_gimple_stmt
../../gcc/cfgexpand.c:3790
0x6afdf7 expand_gimple_basic_block
../../gcc/cfgexpand.c:5810
0x6b52ae execute
../../gcc/cfgexpand.c:6416

[Bug c/49487] New: Internal compiler error in AVR code

2011-06-21 Thread gandalf at winds dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49487

   Summary: Internal compiler error in AVR code
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gand...@winds.org
CC: eric.wedding...@atmel.com
  Host: x86_64-unknown-linux-gnu
Target: avr-unknown-none
 Build: x86_64-unknown-linux-gnu


Compiling the following function triggers an internal compiler error in (at
least) GCC versions 4.2, 4.3, 4.5 and the latest 4.7.0-20110620:

unsigned int test(unsigned int *ptr, unsigned int len)
{
  unsigned int sum=0, *p=ptr;

  while(p  ptr+len)
sum += ({ unsigned int _x=(*p++); (_x  8) | (_x  8); });

  if(__builtin_expect(len  1, 0))
sum += *p;

  return ~sum;
}

Compiler command and resulting output:

avr-gcc -O3 -Wall -mmcu=atmega644   -c -o test3.o test3.c
test3.c: In function 'test':
test3.c:12:1: error: could not split insn
(insn 40 38 41 (parallel [
(set (reg:HI 20 r20 [92])
(rotate:HI (reg/v:HI 20 r20 [orig:67 _x ] [67])
(const_int 8 [0x8])))
(clobber (mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [4 %sfp+1 S1 A8]))
]) test3.c:6 64 {*rotbhi}
 (nil))
test3.c:12:1: internal compiler error: in final_scan_insn, at final.c:2724

This was compiled using a cross-compiler on an x86_64 system as outlined below:

Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr
--disable-nls --enable-languages=c --disable-bootstrap --disable-libssp
Thread model: single
gcc version 4.7.0 20110620 (experimental) (GCC)


[Bug target/49487] Internal compiler error in AVR code

2011-06-21 Thread gandalf at winds dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49487

--- Comment #3 from gandalf at winds dot org 2011-06-21 17:17:20 UTC ---
(In reply to comment #1)
 (In reply to comment #0)
  Compiling the following function triggers an internal compiler error in (at
  least) GCC versions 4.2, 4.3, 4.5 and the latest 4.7.0-20110620:
 
 Could you be a bit more specific on the version numbers for 4.2, 4.3, and 4.5?
 
 I've just tried building on 4.3.3 (WinAVR 20100110) and it compiled
 successfully for -O[0123s].
 
 snip 
  This was compiled using a cross-compiler on an x86_64 system as outlined 
  below:
 
 Could you try using a 32-bit host?

Sorry about being vague on the previous GCC versions--I didn't think it
mattered that much. I very well could have been using patches from Atmel back
then (it was a while ago). I cannot reproduce the problem today on vanilla GCC
4.3.5 and 4.4.6.

However I am able to reproduce the problem on 4.5.3 right now too (on a 64-bit
host).


[Bug middle-end/42898] [4.3/4.4/4.5 Regression] volatile structures and compound literal initializers

2010-01-30 Thread gandalf at winds dot org


--- Comment #6 from gandalf at winds dot org  2010-01-30 20:56 ---
The patch provided fixes this issue and brings the original GCC 4.2.2 behavior
back.

Thanks so much for your quick response!


-- 


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



[Bug c/42898] New: Problem initializing volatile structures

2010-01-29 Thread gandalf at winds dot org
I've recently upgraded to GCC 4.3.2 from 4.2.2, and I noticed a strange
change in how volatile bitmask structures are optimized.

Consider the following code (compiled using just the -O3 option):


/* 32-bit MMIO */
struct hardware {
  int parm1:8;
  int :4;
  int parm2:4;
  int parm3:15;
  int parm4:1;
};

void f1()
{
  volatile struct hardware *ptr=(void *)0x11223344;

  *ptr=(struct hardware) {
.parm1=42,
.parm2=13,
.parm3=11850,
.parm4=1,
  };
}

void f2()
{
  volatile struct hardware *ptr=(void *)0x11223344;

  struct hardware set={
.parm1=42,
.parm2=13,
.parm3=11850,
.parm4=1,
  };

  *ptr=set;
}


In GCC 4.3.2, this produces the following assembly:

f1:
movl$0, 287454020
movb$42, 287454020
movl287454020, %eax
andb$15, %ah
orb $208, %ah
movl%eax, 287454020
movl287454020, %eax
andl$-2147418113, %eax
orl $776601600, %eax
movl%eax, 287454020
movl287454020, %eax
orl $-2147483648, %eax
movl%eax, 287454020
ret

f2:
movl$-1370828758, 287454020
ret

Aren't both functions syntactically the same, and shouldn't they produce the
same optimized code as in f2 above? This used to be the case in GCC 4.2.2.

The problem I'm seeing, apart from the lack of optimization, is that f1
causes 5 separate writes to a single MMIO register, instead of 1. This
particular hardware register is only expecting one write to this location, and
when multiple writes are received it causes the hardware to fail.

If this new behavior is intended, is there some sort of attribute I can add to
the code to get the original 4.2.2 behavior back?

Thanks,
 -Byron


-- 
   Summary: Problem initializing volatile structures
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gandalf at winds dot org
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


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