[Bug c/63625] New: -flto breaks optimization during link phase on arm-none-eabi without -O on linker (!) command line

[anpaza at mail dot ru]

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

Bug ID: 63625
   Summary: -flto breaks optimization during link phase on
arm-none-eabi without -O on linker (!) command line
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anpaza at mail dot ru

Created attachment 33790
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33790action=edit
A test source file  build shell script demonstrating the bug

I use arm-none-eabi-gcc (Fedora 2013.11.24-2.fc19) 4.8.1.

When compiling and linking as usual with the -flto switch the resulting
executable is not optimized.

It looks like the code gets recompiled again somehow if -flto was specified on
linker command line (I'm not sure how exactly -flto works but I suppose it
relinks the whole code again somewhat like -fwhole-program but from GIMPLE
opcodes).

Since it recompiles everything again, the optimization options have effect on
the result. If you don't specify -O on linker command line (which is useless in
the traditional usage mode), you'll get an absolutely unoptimized executable.

I think the optimization options should be either stored into the object files,
or maybe at least WRITE A BIG RED WARNING in the manual about it. I'm doing
embedded code and was shocked of the quality of the code... then I objdump'ed
the object file and have seen a totally different code - clean and optimized. I
almost pulled all my hair off till I realized it was the -flto switch that I
monkey-copied from someone else's makefile and after reading the description in
the manual I decided it is a good thing.

The attached scripts demonstrate the bug. Comment out the -flto LDFLAGS switch
and the .s output gets optimized, uncomment and it gets unoptimized.

[Bug c/63625] -flto breaks optimization during link phase on arm-none-eabi without -O on linker (!) command line

[anpaza at mail dot ru]

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

Andrew Zabolotny anpaza at mail dot ru changed:

   What|Removed |Added

Version|unknown |4.8.1
 Resolution|FIXED   |INVALID

--- Comment #2 from Andrew Zabolotny anpaza at mail dot ru ---
Indeed, you are right.
Glad it's solved in 4.9.
Closing the bug, then.

[Bug c/41138] New: Inconsistent (incorrect?) overflow in implicit constant conversion warning

[anpaza at mail dot ru]

Given the following testcase:

-
unsigned char foo;

void test ()
{
foo = 65280;
foo = 65280L;
foo = 65280U;

foo = 0xff00;
foo = 0xff00L;
foo = 0xff00U;
}
-

when compiling (gcc -c test.c) there will be warnings emited at first, second,
fourth and fifth expressions but ont at the third and sixth:

test3.c: In function 'test':
test3.c:5: warning: overflow in implicit constant conversion
test3.c:6: warning: overflow in implicit constant conversion
test3.c:9: warning: overflow in implicit constant conversion
test3.c:10: warning: overflow in implicit constant conversion

In my opinion, it should either warn everywhere (overflow because rvalue has
bits set outside of the range of a 'char'), or emit a different warning with
something aboud rvalue signedness.

Also, if you increment all constants by one (e.g. 65281 and 0xff01) all
warnings will disappear. So the warning emited before is either incorrect and
should be never emited in such cases, or should be emited always, but not just
sometimes.


-- 
   Summary: Inconsistent (incorrect?) overflow in implicit constant
conversion warning
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: anpaza at mail dot ru


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