[Bug middle-end/34109] Incorrect code for tail calls with a structure as 4th argument

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2009-03-20 11:08 ---
(In reply to comment #3)
 No feedback in over a year.  Presumed fixed in 4.3.0.

I can confirm that this test case works when compiled with a vanilla gcc-4.3.3
built for armv5tel eabi.


-- 


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

[Bug target/31938] Wrong code on int to short cast on armeb

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2007-05-31 19:48 ---
I cannot reproduce this on an armv5b-softvfp-linux machine, with either
gcc-3.3.6, gcc-4.0.4, gcc-4.1.2, or gcc-4.2.0 (all bootstrapped natively on the
arm machine).

However, I suspect your test case is wrong. Unpatched versions of gcc default
to little-endian mode on arm, even if you configure with
--target=arm${foo}b-${bar}.
Since you didn't pass -mbig-endian when compiling the test case, gcc will
generate code assuming little-endian data representation. The assembly code you
listed is actually correct for little-endian.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2007-05-31 20:01 ---
I can confirm this broken behaviour, including that it disappears if the 'c'
variable is renamed to 'xxc', with gcc-3.3.6, 4.0.4, 4.1.2, and 4.2.0, all
running natively on an armv5b-softvfp-linux machine.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/26463] -O2, -O3, -Os segment fault due to bad array index on ARM

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2007-05-31 20:35 ---
I cannot reproduce this bug with gcc-4.0.4, 4.1.2, or 4.2.0 on an
armv5b-softvfp-linux machine.


-- 


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

[Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-04-12 09:11 ---
(In reply to comment #1)
 There is no undefined behavior here (increment of a short value converts 
 to int, increments then converts back to short, none of which are 
 undefined), so at least the wrong code issue would be the same as bug 
 35634.

It's not undefined, but the conversion from int back to short provokes
implementation-defined behaviour when the int value doesn't fit in a short.
That makes this test program not strictly conforming.

The lack of a compile-time warning is unfortunate, but I don't think this is a
case of wrong-code.


-- 


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

[Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2009-04-12 21:33 ---
(In reply to comment #3)
 (In reply to comment #2)
  (In reply to comment #1)
   There is no undefined behavior here (increment of a short value converts 
   to int, increments then converts back to short, none of which are 
   undefined), so at least the wrong code issue would be the same as bug 
   35634.
  
  It's not undefined, but the conversion from int back to short provokes
  implementation-defined behaviour when the int value doesn't fit in a short.
  That makes this test program not strictly conforming.
 
 But converting from short to int for the argument to printf should behave as 
 if
 a short value was converted to int, i.e. the int value should be in range
 -32768 to 32767, right?

Usually but not here. Since you compiled with -fstrict-overflow (implicitly via
-O2) the compiler can assume your short variables will have proper short
values. As an optimisation the compiler could decide to store short variables
in wider int variables and to perform short arithmetic using int arithmetic.
Since you promised not to cause signed overflow those int variables would
always be the proper sign-extension of the corresponding short variables.

But your test program does cause signed overflow, so this optimisation changes
behaviour. It's still not the compiler's fault. If you deliberately cause
signed overflow, do not compile with -fstrict-overflow.


-- 


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

[Bug c/39843] -funsigned-bitfields discards aligned attribute

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2009-04-22 08:05 ---
(In reply to comment #0)
 % gcc-snapshot -funsigned-bitfields testsuite/gcc.dg/bitfld-3.c
 % ./a.out
 Abort

Confirmed with gcc-4.3-20090419 on i686-pc-linux-gnu.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/39975] Support big endian ARM by default.

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2009-05-03 19:39 ---
(In reply to comment #0)
 Create a default configuration that honours big endian ARM by default. PR31938
 refers to this.

Looks like a dupe of PR16350. And most of the de-facto standard patch people
have been applying to get this support is in gcc-4.3. But see comment #22 in
PR16350 for a missing hunk (MULTILIB_DEFAULTS should also use
TARGET_ENDIAN_OPTION and not hard-code mlittle-endian).


-- 


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

[Bug target/10242] [ARM] subsequent use of plus and minus operators could be improved

[mikpe at it dot uu dot se]

--- Comment #7 from mikpe at it dot uu dot se  2009-05-03 19:53 ---
(In reply to comment #6)
 Created an attachment (id=17475)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17475action=view) [edit]
 Proposed fix -- will commit after trunk reopens

Ping, trunk is open now, no? I've been using this proposed fix in my gcc-4.3.4
based compiler for more than a month now without ill effects.


-- 


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

[Bug target/26463] -O2, -O3, -Os segment fault due to bad array index on ARM

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2009-05-03 20:05 ---
(In reply to comment #3)
 Comment #2 indicates that there isn't a problem with a 4.x series compiler .
 I'd like some feedback if this problem exists today with a more recent version
 of the compiler.

I can't reproduce the problem with either gcc-4.3.4 20090405 or gcc-4.4.1
20090428 on an armv5tel-unknown-linux-gnueabi system.


-- 


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

[Bug libstdc++/40178] New: libstdc++ fails to detect atomic builtins for EABI ARM/Linux

[mikpe at it dot uu dot se]

EABI ARM/Linux supports atomic builtins in gcc, but they are implemented as
calls to libgcc helper procedures with names like __sync_fetch_and_add_4() etc
rather than being expanded inline.

libstdc++v3/acinclude.m4 tests for atomic builtins by compiling source files
with calls to __sync_fetch_and_add() etc, and then checking if the resulting
assembly files contain the string __sync__. If they do then acinclude.m4
assumes that atomic builtins are not supported. This presumably works for archs
that inline expand the atomic builtins, but it gives false negatives on EABI
ARM/Linux.

Building gcc-4.4-20090512 for armv5tel-unknown-linux-gnueabi shows:

...
Configuring in armv5tel-unknown-linux-gnueabi/libstdc++-v3
...
checking for thread model used by GCC... posix
checking for atomic builtins for bool... no
checking for atomic builtins for short... no
checking for atomic builtins for int... no
checking for atomic builtins for long long... no
configure: WARNING: No native atomic operations are provided for this platform.
configure: WARNING: They will be faked using a mutex.
configure: WARNING: Performance of certain classes will degrade as a result.

hppa-linux-gnu implements atomic builtins similarly to EABI ARM/Linux, so it
may also be affected by this problem.


-- 
   Summary: libstdc++ fails to detect atomic builtins for EABI
ARM/Linux
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: armv5tel-unknown-linux-gnueabi


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

[Bug libstdc++/40178] libstdc++ fails to detect atomic builtins for EABI ARM/Linux

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-05-17 18:01 ---
(In reply to comment #1)
 This is essentially the same as PR40133, which is blocked by PR40134.

Agreed. The underlying issue appears to be the static libgcc only symbols. One
wonders why they did things that way.


-- 


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

[Bug target/35623] RTL check failure in arm_const_double_rtx

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2009-05-19 08:24 ---
(In reply to comment #1)
 I've been bootstrapping trunk pretty regularly for arm-linux-gnueabi on the
 compile farm (though not building with latest libc) and haven't seen such a
 problem .

Note that the bug report is for OABI. I cannot reproduce it with EABI gcc-4.2.4
or gcc-4.3.4-20090517 on the preprocessed test case.


-- 


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

[Bug libstdc++/40133] exception propagation support not enabled in libstdc++ 4.4 on {armeabi,hppa}-linux

[mikpe at it dot uu dot se]

--- Comment #8 from mikpe at it dot uu dot se  2009-05-22 19:18 ---
Created an attachment (id=17902)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17902action=view)
always pass -lgcc to linker

The link error reported by Matthias Klose is caused by the following:
1. g++ links shared libraries with -shared-libgcc, which apparently is
important  whenever exceptions are possible.
2. -shared-libgcc by definition excludes the static libgcc from the link
command.
3. Since the __sync__ procedures are only present in the static libgcc, it
follows that they cannot be used by -shared-libgcc objects like libstdc++.so.

One way around this is to redefine -shared-libgcc to actually link against the
static libgcc, contrary to its intention. Both mingw32 and cygwin do this, so
it's not unheard of. The attached patch updates ARM EABI to do just that.
Passes a bootstrap and light testing here.

However, I would strongly prefer to just move the __sync__ procedures to the
shared libgcc (with symbol versions of course).


-- 


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

[Bug bootstrap/40268] New: continued build failures from PR39791 and PR40061 fixes

[mikpe at it dot uu dot se]

gcc-4.3-20090524 fails to build for target=alpha-unknown-linux:

/tmp/gcc-4.3-20090524/gcc/dwarf2out.c: In function 'add_subscript_info':
/tmp/gcc-4.3-20090524/gcc/dwarf2out.c:11328: error: break statement not within
loop or switch

gcc-4.3.3 and earlier build fine so this is a regression.

The problem is that the PR39791 fix put a break statement in a block which is a
loop body only when !MIPS_DEBUGGING_INFO. This and an undeclared variable issue
were reported as PR40061, but the fix for PR40061 only fixed the undeclared
variable issue, not the invalid break statement issue.

The break issue could be fixed by turning this block into a loop body also in
the !MIPS_DEBUGGING_INFO case, but that looks like it will require more #ifdefs
and local variables. So I suggest to just #ifdef the break statement. I'm
attaching patch which does just that.


-- 
   Summary: continued build failures from PR39791 and PR40061 fixes
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC target triplet: alpha-unknown-linux


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

[Bug bootstrap/40268] continued build failures from PR39791 and PR40061 fixes

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2009-05-27 08:26 ---
Created an attachment (id=17921)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17921action=view)
fix alpha compile failure in dwarf2out.c


-- 


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

[Bug target/35079] [arm] ICE (segfault) with gfortran -O3 -funroll-loops

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2009-05-28 08:40 ---
(In reply to comment #3)
 I just tried this with gfortran 4.3.3 that I have on my ubuntu box. I don't 
 get
 a failure with arm-linux-gnueabi. Can you verify that this still exists with
 arm-linux configurations ?

This problem looks like a dupe of PR35964 and PR39076. If so then it's probably
fixed in current 4.3 branch, and Debian used to backport the fix to their 4.3
compilers which may be why it appears fixed on Ubuntu.


-- 


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

[Bug c/40312] Compiling with O2 flag lead to wrong binary code (X86 system 32bit)

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-05-31 08:10 ---
(In reply to comment #1)
 The one compiled with O2 has wrong binary code.
 
 The problem occurs when GCC compiles the following lines with O2 flag.
 
 
 if (pdw  memcmp(a1, a2, pdw  2))
 return 0;
 
 
 In the binary code, pdw is not shifted left by 2, which leads to wrong result.

I can confirm the test case breakage with gcc-4.1.2 on i686-pc-linux-gnu,
however gcc-4.2.4 and gcc-4.3-20090524 work. Since both gcc-4.1 and gcc-4.2 are
obsoleted and unsupported, you should consider upgrading to gcc-4.3 or gcc-4.4.


-- 


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

[Bug c/39843] -funsigned-bitfields discards aligned attribute

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-06-04 09:22 ---
(In reply to comment #0)
 % gcc-snapshot -funsigned-bitfields testsuite/gcc.dg/bitfld-3.c
 % ./a.out
 Abort

Confirmed with gcc-4.4-20090602 and gcc-4.3-20090531 on i686-pc-linux-gnu. I
haven't been able to reproduce the problem on x86_64.


-- 


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

[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc gcc-4.2.x

[mikpe at it dot uu dot se]

--- Comment #13 from mikpe at it dot uu dot se  2009-06-11 00:01 ---
(In reply to comment #11)
 Fixed.

Not quite. I'm trying to build gcc-4.4-20090609 on powerpc64-unknown-linux-gnu,
with binutils 2.17.50.0.6-6, configured with --enable-languages=c,ada
--with-cpu=default32 --disable-shared, and the first attempt to link gnat1
fails with R_PPC_REL24 errors similar to those shown earlier in this PR entry.

A look in the build log shows that the host C compiler is invoked with -O1
while building the C parts of stage1, but the host gnat is invoked with no
optimisation flags at all. It seems that the workaround to pass -O1 when
--relax is missing isn't propagated into the Ada parts.

If I set CC='gcc -O2' during the initial configure step the build succeeds.


-- 


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

[Bug c++/32534] gcc fails to initialize template's static data members before their use in some cases

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-06-11 20:03 ---
(In reply to comment #1)
 I've been bitten by this bug, which is almost 2 years old. I haven't tested it
 with gcc 4.4 though, but I confirm that it happens with gcc-4.3.3. Is there
 anyone willing to correct this?

gcc-4.4.1 20090609 also prints 0 (has the bug).


-- 


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

[Bug c/40404] Comparison involving unsigned int:17 bitfield seems wrong

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2009-06-12 20:41 ---
(In reply to comment #3)
 Can someone identify the patch that fixed that on the trunk?

I've identified r139702, the fix for PR37005, as the revision which fixed this
test case on gcc-4.4. That change applies easily to current gcc-4.3, so I tried
it and it did fix this test case also for gcc-4.3.


-- 


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

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-06-14 10:24 ---
(In reply to comment #1)
 With 4.5 I see
 With 4.5.0 I see:
 
 push{lr}
 sub sp, sp, #12
 ldr r2, [r0]
 ldr r1, [r0, #4]
 mov r0, sp
 str r2, [sp, #4]
 bl  func
 add sp, sp, #12
 pop {pc}

However, gcc-4.5-20090611 generates the longer 10-instruction code:

push{lr}
ldr r2, [r0]
sub sp, sp, #20
add r3, sp, #4
ldr r1, [r0, #4]
str r2, [r3, #4]
mov r0, r3
bl  func
add sp, sp, #20
pop {pc}


-- 


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

[Bug rtl-optimization/39871] [4.3/4.4/4.5 regression] Code size increase on ARM due to inferior CSE

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2009-06-14 14:06 ---
(In reply to comment #1)
 With 4.5 I see
 With 4.5.0 I see:
 
 push{lr}
 sub sp, sp, #12
 ldr r2, [r0]
 ldr r1, [r0, #4]
 mov r0, sp
 str r2, [sp, #4]
 bl  func
 add sp, sp, #12
 pop {pc}

I've tested every weekly gcc-4.5 snapshot and they all generate one instruction
more than this code.

How did you configure and invoke gcc-4.5 to get this 9-instruction code?


-- 


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

[Bug tree-optimization/40087] [4.3 Regression] Number of iterations analysis wrong

[mikpe at it dot uu dot se]

--- Comment #15 from mikpe at it dot uu dot se  2009-06-15 14:24 ---
(In reply to comment #14)
 ping 4.3.4...

The PR40087 fix depends on changes from the PR39455 fix. Both of them are 4.3
regressions, and I've used both fixes in my 4.3 tree for a while now without
issues.


-- 


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

[Bug target/30064] ICE in reload_cse_simplify_operands, at postreload.c:393

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-06-16 15:17 ---
(In reply to comment #0)
 gcc-m68k-ice.c:28: internal compiler error: in reload_cse_simplify_operands, 
 at
 postreload.c:393
 
 If any of the options -m5307, -msep-data, or -O1 is removed, the problem goes
 away.
 
 Reproduced on 4.1.1, 4.1-20061124, 4.2-20061128, 4.3-20061202. Couldn't
 reproduce ICE on 3.4.6, but it could be generating incorrect code (no solid
 evidence of that though).

Using my m68k-unknown-linux cross environment I can reproduce the ICE with
gcc-4.2.[0-4], but not with gcc-4.3.[0-3] or with the latest weekly gcc-4.3 and
gcc-4.4 snapshots. Since 4.3.0 and above work I didn't bother trying to
identify the exact revision that fixed it.


-- 


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

[Bug target/34439] ICE in reload_cse_simplify_operands for Coldfire

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2009-06-16 16:29 ---
(In reply to comment #4)
 Works with 4.3.1.  Should this be closed if someone can confirm it is fixed on
 the trunk?

This is a generic m68k issue as I can easily reproduce the ICE using a
gcc-4.2.4 based cross-compiler to m68k-unknown-linux. The current latest
gcc-4.4 and gcc-4.3 weekly snapshots do not exhibit the ICE however.


-- 


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

[Bug middle-end/39227] ICE with -fstack-protector in add_stack_var_conflict, at cfgexpand.c:269

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-06-17 14:08 ---
(In reply to comment #1)
 Works for 4.4.1 and 4.5.0

ICEs for me with today's 4.4 branch on i686-linux. The -O0 -fstack-protector
combination is key, with -O1 and above it works, ditto without
-fstack-protector.


-- 


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

[Bug bootstrap/40477] [4.3 regression] build failure on alpha-linux-gnu mips-linux-gnu

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2009-06-17 18:51 ---
Dupe of PR40268/PR40061.


-- 


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

[Bug middle-end/40547] New: comparison in lhs of ?: incorrectly converted to unsigned min

[mikpe at it dot uu dot se]

Compiling this test program with gcc-4.4-20090623 fails with a linker error:

 cat pr39867-redux.c
int main (void)
{
  int exp = -1;
  /* Wrong folding of the LHS to an unsigned MIN leads to 2 != 4294967295. */
  if ((exp  2 ? (unsigned int) exp : 2U) != -1U)
link_error ();
  return 0;
}
 gcc -O2 pr39867-redux.c
/tmp/ccwtpmSD.o: In function `main':
pr39867-redux.c:(.text+0x7): undefined reference to `link_error'
collect2: ld returned 1 exit status

This is a regression from gcc-4.3.3 and earlier releases.

The test case is a variant of PR39867, which got fixed. That bug report was
about fold-const.c turning a ?: into MAX and wrongly changing a signed compare
to an unsigned compare in the process. There are additional cases that turn ?:
into MIN, but they weren't considered or fixed.

I'll attach the test case and a proposed fix.


-- 
   Summary: comparison in lhs of ?: incorrectly converted to
unsigned min
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
  GCC host triplet: i686-pc-linux-gnu


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

[Bug middle-end/40547] comparison in lhs of ?: incorrectly converted to unsigned min

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2009-06-24 22:25 ---
Created an attachment (id=18063)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18063action=view)
test case

test case illustrating the bug


-- 


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

[Bug middle-end/40547] comparison in lhs of ?: incorrectly converted to unsigned min

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-06-24 22:29 ---
Created an attachment (id=18064)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18064action=view)
proposed patch fixing this error

This patch adapts Paolo Bonzini's patch for PR39867 to handle the remaining two
cases in fold_cond_expr_with_comparison that produce MIN rather than MAX.
Bootstrapped on i686-pc-linux-gnu and verified to fix the test case.


-- 


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

[Bug c/32041] [4.3 Regression] offsetof buglet

[mikpe at it dot uu dot se]

--- Comment #10 from mikpe at it dot uu dot se  2009-06-25 12:12 ---
(In reply to comment #9)
 Fixed.

The gcc-4.3 backport or PR32041 to c-parser.c adds an assignment to `loc'. The
mainline version needed that for build_array_ref, but in 4.3 build_array_ref
does not take a loc parameter so the assignment is redundant. Suggested fixup:

--- gcc-4.3-pr32041/gcc/c-parser.c.~1~  2009-06-25 14:01:22.0 +0200
+++ gcc-4.3-pr32041/gcc/c-parser.c  2009-06-25 14:06:20.0 +0200
@@ -5353,7 +5353,6 @@ c_parser_postfix_expression (c_parser *p
  {
if (c_parser_next_token_is (parser, CPP_DEREF))
  {
-   loc = c_parser_peek_token (parser)-location;
offsetof_ref = build_array_ref (offsetof_ref,
integer_zero_node);
goto do_dot;


-- 


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

[Bug target/38886] [4.3 Regression] ICE move_insn, at haifa-sched.c:1786

[mikpe at it dot uu dot se]

--- Comment #9 from mikpe at it dot uu dot se  2009-06-26 19:49 ---
I believe this is the same issue as in PR39254.


-- 


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

[Bug c++/40595] [C++0x] ICE trying to use sfinae with variadic template pack expansion

[mikpe at it dot uu dot se]

--- Comment #7 from mikpe at it dot uu dot se  2009-07-01 10:53 ---
(In reply to comment #6)
 Fixed for 4.4.1.

This test case causes the same ICE in tsubst also with gcc-4.3.4.

After packporting the ICE fix, 4.3.4 instead fails with:

variadic94.C: In function 'int main()':
variadic94.C:32: sorry, unimplemented: call_expr cannot be mangled due to a
defect in the C++ ABI

Is this an inherent limitation in 4.3 or just another unfixed bug?


-- 


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

[Bug c/40635] New: bogus name and location in 'may be used uninitialized' warning

[mikpe at it dot uu dot se]

The following test case produces a 'may be used uninitialized' warning that
refers to a variable that isn't in scope at the point of the warning:

 cat nntpinit.c
struct hostent {
char **h_addr_list;
};
struct hostent *gethostbyname(const char*);
int socket(void);
int close(int);
int connect(int, const char*);
void foo(void);

static int get_tcp_socket(const char *machine)
{
struct hostent *hp;
int s42, x;
char **addr;

hp = gethostbyname(machine);
x = 0;
for (addr = hp-h_addr_list; *addr; addr++) {
s42 = socket();
if (s42  0)
return -1;
x = connect(s42, *addr);
if (x == 0)
break;
close(s42);
}
if (x  0)
return -1;
return s42;
}

int server_init(const char *machine)
{
int sockt_rd;

sockt_rd = get_tcp_socket(machine);
foo();
if (sockt_rd  0)
return -1;
return 0;
}
 gcc -O2 -Wall -c nntpinit.c
nntpinit.c: In function 'server_init':
nntpinit.c:38: warning: 's42' may be used uninitialized in this function

There is indeed a 'may be used uninitialized' issue in this code, but it's
actually in get_tcp_socket(), not in server_init() because there every use is
trivially preceeded by a def.

I guess that automatic inlining is messing up name and context information.

The test case is distilled down from some ancient nntp client code I'm tidying
up, and the bogus data in the warning did cause some headscratching before the
warning could be analysed and fixed (set x = -1 in get_tcp_socket()).


-- 
   Summary: bogus name and location in 'may be used uninitialized'
warning
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
  GCC host triplet: i686-pc-linux-gnu


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

[Bug c++/40658] spurious warning array subscript is below array bounds

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2009-07-06 09:32 ---
Ditto here on powerpc64-unknown-linux-gnu. -m32 gives the warning, -m64 does
not.


-- 


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

[Bug c/40602] crti.o: No such file

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-07-07 10:18 ---
(In reply to comment #1)
 Now I'm trying to compile gcc-4.4.0 configured as follows:
 
 ../gcc-4.4.0/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
 --target=x86_64-pc-linux-gnu --enable-languages=c --disable-multilib
 
 make fails with the same error message.
 
 crti.o is located at /usr/lib64/crti.o
 
 this is the output of cat LOG | grep crti.o | grep ENOENT | grep lib64 after
 having issued strace -f make 2 LOG:
 
 [pid 32046]
 access(/sources/gcc-build/gcc/../lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../x86_64-pc-linux-gnu/lib/../lib64/crti.o,
 R_OK) = -1 ENOENT (No such file or directory)
 [pid 32046]
 access(/sources/gcc-build/gcc/../lib/gcc/x86_64-pc-linux-gnu/4.4.0/../../../../lib64/crti.o,
 R_OK) = -1 ENOENT (No such file or directory)
 [pid 32046] access(/lib/../lib64/crti.o, R_OK) = -1 ENOENT (No such file or
 directory)
 [pid 32046] access(/usr/lib/../lib64/crti.o, R_OK) = -1 ENOENT (No such file
 or directory)
 
 As you can see it tries to access /usr/lib64/crti.o, but inexplicably it can't
 find it.

Check that /usr/lib/ exists. If it doesn't then /usr/lib/../lib64/ will ENOENT
rather than resolve to /usr/lib64/. Also check that /usr/lib isn't a symlink,
in which case /usr/lib/.. may not be /usr .


-- 


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

[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2009-07-07 11:35 ---
Confirmed, with gcc-4.3-20090705 it works, with gcc-4.4-20090630 it fails.
Compiling with -S and comparing the .s files it looks like 4.4 completely
mis-schedules the code for put_uint32:

put_uint32:
.register   %g2, #scratch
.register   %g3, #scratch
ldub[%sp+2175], %g1
ldub[%sp+2176], %g3
ldub[%sp+2177], %g2
ldub[%sp+2178], %g4
st  %o0, [%sp+2175]
stb %g4, [%o1+3]
stb %g1, [%o1]
stb %g3, [%o1+1]
jmp %o7+8
 stb%g2, [%o1+2]

Notice how the store of %o0 to the four bytes at %sp+2175 comes after the
corresponding byte loads, so %g1 to %g4 are loaded with garbage, likely zeroes.

In contrast, gcc-4.3 generates the store before the loads:

put_uint32:
.register   %g2, #scratch
.register   %g3, #scratch
st  %o0, [%sp+2175]
ldub[%sp+2176], %g3
ldub[%sp+2177], %g4
ldub[%sp+2178], %g2
ldub[%sp+2175], %g1
stb %g2, [%o1+3]
stb %g1, [%o1]
stb %g3, [%o1+1]
jmp %o7+8
 stb%g4, [%o1+2]


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2009-07-07 16:28 ---
A reghunt identified Jakub's (added to cc: list) r142481 (PR38367 fix) as the
source of this regression.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu dot org


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

[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch

[mikpe at it dot uu dot se]

--- Comment #6 from mikpe at it dot uu dot se  2009-07-07 23:10 ---
(In reply to comment #5)
 Created an attachment (id=18151)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18151action=view) [edit]
 gcc44-pr40668.patch
 
 Untested patch that fixes this testcase.

Thanks. This fixes the issue in a cross-compiler to sparc64-linux. I'm
currently bootstrapping 4.4-20090630 plus this patch on an Ultra5, I'll follow
up once that's complete (it will take quite a while).


-- 


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

[Bug tree-optimization/40679] Optimizer handles loops with volatiles and post-incr. wrong

[mikpe at it dot uu dot se]

--- Comment #6 from mikpe at it dot uu dot se  2009-07-08 09:59 ---
(In reply to comment #2)
 Replacing *tbl++ by tbl[i] gives this ARM code:
 .L2:
 mov r3, #10
 str r3, [r2], #4
 cmp r2, #0
 bne .L2
 bx  lr
 
 See, gcc knows about the wrapping but still the *tbl++ version misses the
 end-condition which is the bug.

The difference is that in the tbl[i] version there will not be a wraparound at
runtime because tbl[i] for i == 64 is never computed, while in the *tbl++
version the iteration with i == 63 will do tbl++ moving tbl from -4U to 0
before the loop termination test, which triggers undefined behaviour.

And the issue is not ARM, the same infinite loop occurs for e.g. target i686.


-- 


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

[Bug target/40668] 64-bit sparc miscompiles memcpy of argument inside switch

[mikpe at it dot uu dot se]

--- Comment #7 from mikpe at it dot uu dot se  2009-07-08 16:43 ---
4.4-20090630 plus this fix bootstrapped fine, fixed the test case, built a
working 2.6.31-rc2 Linux kernel, and built a working Erlang VM.


-- 


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

[Bug tree-optimization/38369] [4.3 regression] ICE (SIGSEGV in number_of_iterations_exit)

[mikpe at it dot uu dot se]

--- Comment #10 from mikpe at it dot uu dot se  2009-07-09 14:45 ---
I've identified Jakub's r140177 (PR37356) as the point where these test cases
were fixed in 4.4.0. A backport doesn't look easy (to me anyway).


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/40523] GCC generates invalid instructions when building for Thumb-2 on armel

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-07-09 19:03 ---
This was fixed for 4.4.0 by Richard's r143339.

I backported that to 4.3.4 and it built ok and fixed this test case. My boxes
are ARMv5TE so I cannot run the generated thumb2 code however.


-- 


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

[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2009-10-17 22:08 ---
I just had a look at some gcc-4.4.2 testsuite failure on arm-linux-gnueabi, and
came across the uninit-13.c one and this PR.

The error is not that uninit-13.c triggers an is used uninitialized warning,
it's supposed to do that, but that on ARM the line number for the warning is
off-by-one.

On armv5tel-linux-gnueabi:
uninit-13.c: In function 'foo':
uninit-13.c:7: warning: '__real__ f' is used uninitialized in this function

On i686-pc-linux-gnu:
uninit-13.c: In function 'foo':
uninit-13.c:8: warning: '__real__ f' is used uninitialized in this function

Apparently x86-64 is also off-by-one, while my powerpc64 box agrees with i686.

If I replace the _Complex float with a struct of two floats like this:

typedef struct { float x; float y; } C;
C foo()
{
float x; float y;
x = 0;
return (C){x, y};
}

then my i686 and ARM compilers emit identical warnings.

Something strange is happening with _Complex on ARM (and x86-64).


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2009-10-18 12:55 ---
On ARM, gcc generates assembly code for the bb-reorg.c test case that gas fails
to assemble. The pr34999.c test case fails for the same reason. The following 
reduced assembly snippet illustrates it:

 cat bb-reorg.s
.text
.align  2
.global main
main:
ldr r0, .L30
mov pc, lr
.section.text.unlikely
.align  2
.L30:   .word   1819043176
 as bb-reorg.s
bb-reorg.s: Assembler messages:
bb-reorg.s:5: Error: internal_relocation (type: OFFSET_IMM) not fixed up

This still occurs with the recently released binutils-2.20.

Does gcc generate invalid assembly code, or is the assembly code valid and gas
is in error for failing to handle it?

Should the bb-reorg and pr34999 test cases be XFAILed on arm until this is
resolved?


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug c++/37204] [c++0x] reinterpret_castT(v) incorrectly yields an lvalue

[mikpe at it dot uu dot se]

--- Comment #6 from mikpe at it dot uu dot se  2009-10-18 17:58 ---
Revision 152966 on 4.4 branch causes a testsuite regression for me on
i686-linux:

Running /mnt/builds/gcc-4.4-r152966/gcc/testsuite/g++.dg/dg.exp ...
FAIL: g++.dg/cpp0x/rv-reinterpret.C execution test

Reverting just the PR37204 bits eliminates that regression.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[mikpe at it dot uu dot se]

--- Comment #23 from mikpe at it dot uu dot se  2009-10-21 10:48 ---
(In reply to comment #8)
 (In reply to comment #7)
  With binutils from the 2.20 branch, and gcc from the 4.4 branch, including
  Jakub's patch, and excluding the current workaround from Ramana, I get:
  
 
 IIUC and to make things explicit, the work-around is needed for any binutils
 prior to the 2.20 branch until the backport is done. If the backport is
 committed we should pull out my work around as well. 

The backport has been committed now, so your PR41533 workaround should not be
needed any more.


-- 


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

[Bug middle-end/40747] [4.4/4.5 Regression] wrong code for int-is-in-range test at -O1 and above

[mikpe at it dot uu dot se]

--- Comment #11 from mikpe at it dot uu dot se  2009-10-21 10:51 ---
*** Bug 40547 has been marked as a duplicate of this bug. ***


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug middle-end/40547] comparison in lhs of ?: incorrectly converted to unsigned min

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2009-10-21 10:51 ---


*** This bug has been marked as a duplicate of 40747 ***


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application

[mikpe at it dot uu dot se]

--- Comment #8 from mikpe at it dot uu dot se  2009-10-21 12:19 ---
I can reproduce the misalignment exceptions on armv5tel-linux-gnueabi with
gcc-4.3.4 at -O0 but not with gcc-4.4.2.  The loop in main() which iterates
over the packed array creates a misaligned pointer from which it performs
word-sized loads, which causes misalignment exceptions.  gcc-4.4.2 generates
very different code which doesn't make assumptions about alignment.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application

[mikpe at it dot uu dot se]

--- Comment #10 from mikpe at it dot uu dot se  2009-10-21 19:47 ---
(In reply to comment #9)
 My version is:
 [r...@ build]# ccmips -V
 ccmips: `-V' option must have argument
 [r...@pace build]# ccmips --version
 ccmips (GCC) 3.3.2 20030904 (Wind River vxworks61) (built 20050516)
 Copyright (C) 2003 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

That's an old vendor-modified compiler based on an ancient and no longer
supported gcc version. Please direct your questions about that compiler to the
vendor, Wind River.

If you can reproduce your MIPS alignment problem using gcc-4.3 or newer, then
that's something you should report here in a new bugzilla entry (so as to not
confuse this ARM problem with a possibly unrelated MIPS problem).


-- 


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

[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application

[mikpe at it dot uu dot se]

--- Comment #11 from mikpe at it dot uu dot se  2009-10-22 17:55 ---
Created an attachment (id=18869)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18869action=view)
reduced test case in plain C


-- 


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

[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application

[mikpe at it dot uu dot se]

--- Comment #12 from mikpe at it dot uu dot se  2009-10-23 00:29 ---
The ARM misalignment bug in this PR was fixed for gcc-4.4 by r141742, an
apparently ia64- and Ada-motivated generic patch.


-- 


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

[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application

[mikpe at it dot uu dot se]

--- Comment #13 from mikpe at it dot uu dot se  2009-10-23 12:49 ---
Created an attachment (id=18879)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18879action=view)
backport of r141742 to gcc-4.3.4 that I'm testing


-- 


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

[Bug other/41809] New: escaping address of packed field should trigger warning

[mikpe at it dot uu dot se]

A field in a packed struct will often not have the normal alignment for its
type.  So taking the address of such a field may yield a misaligned pointer,
but gcc does not warn about that.  This is similar to casting a pointer from a
less aligned type to a more aligned type, which does give a warning (with
-Wcast-align).

Example:
 cat aopf.c
#include stdio.h

void __attribute__((noinline)) f(int *p)
{
printf(%p\n, p);
}

struct s {
int x;
char c;
} __attribute__((__packed__));

struct s A[10];

int main(void)
{
unsigned int i;

for (i = 0; i  sizeof(A)/sizeof(A[0]); ++i) {
f(A[i].x);
f((int*)(char*)A[i].x);
}
return 0;
}
 gcc -Wall -Wextra -Wcast-align -O aopf.c
aopf.c: In function 'main':
aopf.c:21:4: warning: cast increases required alignment of target type

Ideally both calls to f() should trigger alignment warnings.


-- 
   Summary: escaping address of packed field should trigger warning
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se


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

[Bug c/41895] New: _Complex return type changes line numbers in diagnostics

[mikpe at it dot uu dot se]

 cat uninit-13b.c
float
foo(void)
{
_Complex float f;
__imag__ f = 0;
return f;
}
 gcc -O -Wuninitialized -S uninit-13b.c
uninit-13b.c: In function 'foo':
uninit-13b.c:4:20: warning: 'REALPART_EXPR f' is used uninitialized in this
function

This is as expected, and occurs consistently for all(?) targets (I've checked
i686, x86_64, sparc64, ppc64, alpha, and armv5tel Linux).

Changing the return type to '_Complex float', without changing anything else,
including the line numbers for the function body declarations and statements,
causes the diagnostic to refer to a different line:

 sed 's/^float/_Complex float/'  uninit-13b.c  uninit-13.c
 gcc -O -Wuninitialized -S uninit-13.c
uninit-13.c: In function 'foo':
uninit-13.c:5:16: warning: 'REALPART_EXPR f' is used uninitialized in this
function

This difference occurs on the i686, x86_64, sparc64, ppc64, and alpha targets,
but not the armv5tel target which continues to refer to line 4.

These inconsistencies are seen with gcc-4.5-20091029, 4.4.2, and 4.3.4.


-- 
   Summary: _Complex return type changes line numbers in diagnostics
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
  GCC host triplet: i686-pc-linux-gnu


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

[Bug c++/41941] bad stack allocation using inline asm

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2009-11-04 15:47 ---
On x86_64 there's a 128 byte area below %rsp which is free to use without first
setting up a stack frame. This is described in the x86_64 ABI document. The
Linux kernel skips this area before pushing signal handler stack frames.

Do you have a concrete example of this not working?


-- 


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

[Bug middle-end/42044] [4.4/4.5 Regression] gcc.c-torture/compile/930117-1.c

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2009-11-14 16:09 ---
Presumably fixed for 4.5 by revision 154178.


-- 


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

[Bug rtl-optimization/41917] Strange athrithmetic result with -O3

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2009-11-14 16:32 ---
This wrong-code bug also occurs with 4.3.4 on i686-linux, but not with 4.2.4 or
4.1.2, making it a regression. The patch for 4.4 applies cleanly to 4.3 and
fixes the bug there with no new regressions (I tested i686, powerpc64, and
arm).


-- 


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

[Bug tree-optimization/41035] AIX cexp builtin underflow

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2009-12-09 16:07 ---
(In reply to comment #2)
 libmpfr must be a shared object because libmpc relies on hidden, global state
 in libmpfr.  If libmpfr is linked statically with libmpc and with GCC, each
 receives different instances of the global variables.

If that's true then that's a horrible horrible bug in libmpc!

I generally build private static-only gmp and mpfr libs for gcc-4.3 and above
to avoid any interaction with whatever libs the rest of the system may or may
not have.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug tree-optimization/42337] GCC ICE in compute_antic, at tree-ssa-pre.c:2534

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2009-12-14 12:57 ---
This bug is also present in gcc-4.4-20091208 but not in gcc-4.3-20091206. The
two fixes listed here apply Ok to 4.4 and solve the problem there w/o
regressions (tested on i686, powerpc64, and arm).


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug middle-end/42372] [4.5 regression] Regrename reuses non-dead register

[mikpe at it dot uu dot se]

--- Comment #7 from mikpe at it dot uu dot se  2009-12-16 21:27 ---
I've done a binary search which identified 154688 as the revision which caused
the problem to appear.

To answer Bernd's question, I used an arm cross configured with:
--target=armv5tel-unknown-linux-gnueabi
--with-gmp=/home/mikpe/pkgs/linux-x86/gmp-4.3.1
--with-mpfr=/home/mikpe/pkgs/linux-x86/mpfr-2.4.2 --with-arch=armv5te
--with-tune=xscale --prefix=/mnt/work/cross-armv5tel --disable-nls
--enable-shared --disable-libmudflap --disable-multilib --enable-threads=posix
--enable-checking=release --enable-languages=c


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/41196] The use of ARM NEON vshll_n_u8 intrinsic results in compile error on valid code [4.4 only]

[mikpe at it dot uu dot se]

--- Comment #11 from mikpe at it dot uu dot se  2009-12-21 11:55 ---
(In reply to comment #10)
 Fixed.

You forgot to add the test case in the 4.4 backport.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/42503] New: gcc-4.4-20091215 broke libjava on ARM

[mikpe at it dot uu dot se]

Building gcc-4.4-20091215 on arm with java enabled fails with a linkage error:

libtool: link: ( cd .libs  rm -f libgcj_bc.la  ln -s ../libgcj_bc.la
libgcj_bc.la )
/bin/sh ./libtool --tag=GCJ --mode=link /home/mikpe/objdir44/gcc/gcj
-B/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/
-B/home/mikpe/objdir44/gcc/
-L/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava -g -O2  -o
jv-convert --main=gnu.gcj.convert.Convert -rpath /home/mikpe/crap/lib
-shared-libgcc 
-L/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/../libstdc++-v3/src/.libs
-lstdc++  -L/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/.libs
libgcj.la 
libtool: link: /home/mikpe/objdir44/gcc/gcj
-B/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/
-B/home/mikpe/objdir44/gcc/ -g -O2 -o .libs/jv-convert
--main=gnu.gcj.convert.Convert -shared-libgcc 
-L/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/.libs
-L/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava
-L/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/../libstdc++-v3/src/.libs
/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava/../libstdc++-v3/src/.libs/libstdc++.so
./.libs/libgcj.so
/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libstdc++-v3/src/.libs/libstdc++.so
-lm -lpthread -lrt -ldl -lz -Wl,-rpath -Wl,/home/mikpe/crap/lib
/usr/bin/ld: .libs/jv-convert: hidden symbol `__sync_synchronize' in
/home/mikpe/objdir44/gcc/libgcc.a(linux-atomic.o) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[3]: *** [jv-convert] Error 1
make[3]: Leaving directory
`/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/mikpe/objdir44/armv5tel-brewer-linux-gnueabi/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/home/mikpe/objdir44'
make: *** [bootstrap] Error 2

4.4 snapshots up to and including 20091208 build fine, so this is a recent
regression.


-- 
   Summary: gcc-4.4-20091215 broke libjava on ARM
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
 GCC build triplet: armv5tel-unknown-linux-gnueabi
  GCC host triplet: armv5tel-unknown-linux-gnueabi
GCC target triplet: armv5tel-unknown-linux-gnueabi


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

[Bug target/42503] gcc-4.4-20091215 broke libjava on ARM

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2009-12-26 14:59 ---
Reverting r155171 allows gcc-4.4-20091215 to build a working libjava again.

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155171
Log:
2009-12-11  Ramana Radhakrishnan  ramana.radhakrish...@arm.com

PR target/42263
2009-08-11  Andrew Haley  a...@redhat.com
* config/arm/arm.c (arm_init_libfuncs): Add __sync_synchronize.

I suspect ARM's static libgcc has more symbols than the shared one bug is
involved here (see PR40133 and PR40134).


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||ramana dot radhakrishnan at
   ||arm dot com


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

[Bug target/42503] gcc-4.4-20091215 broke libjava on ARM

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2009-12-27 13:59 ---
(In reply to comment #4)
 Note, however, that something is definitely wrong in the analysis: PR40133 and
 PR40134 have been fixed **only in mainline**, thus per se those changes cannot
 be involved in a breakage involving 4_4-branch.

I believe it's the *absence* of the PR40134 fix on 4_4-branch that's causing
the backport of __sync_synchronize() support to regress. I'm currently testing
4.4-20091215 with relevant bits of PR40134 backported (r151568 + r152975): that
cured the build failure, but the testsuite run is not yet finished.


-- 


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

[Bug target/42503] [4.4 Regression] gcc-4.4-20091215 broke libjava on ARM

[mikpe at it dot uu dot se]

--- Comment #7 from mikpe at it dot uu dot se  2009-12-28 00:46 ---
(In reply to comment #5)
 I believe it's the *absence* of the PR40134 fix on 4_4-branch that's causing
 the backport of __sync_synchronize() support to regress. I'm currently testing
 4.4-20091215 with relevant bits of PR40134 backported (r151568 + r152975): 
 that
 cured the build failure, but the testsuite run is not yet finished.

The testsuite run now finished with no regressions compared to 4.4 snapshots
from before this regression.


-- 


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

[Bug target/42503] [4.4 Regression] gcc-4.4-20091215 broke libjava on ARM

[mikpe at it dot uu dot se]

--- Comment #10 from mikpe at it dot uu dot se  2009-12-28 12:11 ---
Matthias, your Debian patch includes the following, which is not part of the
trunk fix for PR40134 but instead appears to be a fragment from an early
version of the PR41175/PR40677 fix (which seems to depend on PR40134):

--- a/src/gcc/config/rs6000/rs6000.c(revision 151558)
+++ b/src/gcc/config/rs6000/rs6000.c(working copy)
@@ -15869,7 +15869,7 @@
 no_global_regs_above (int first, bool gpr)
 {
   int i;
-  for (i = first; i  gpr ? 32 : 64 ; i++)
+  for (i = first; i  (gpr ? 32 : 64) ; i++)
 if (global_regs[i])
   return false;
   return true;


-- 


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

[Bug target/42503] [4.4 Regression] gcc-4.4-20091215 broke libjava on ARM

[mikpe at it dot uu dot se]

--- Comment #12 from mikpe at it dot uu dot se  2009-12-29 13:05 ---
Created an attachment (id=19413)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19413action=view)
pr40134 generic + arm bits

This is the version of the PR40134 patch I intend to submit, unless Matthias
wants to submit his version. This version only adds t-slibgcc-libgcc support
and enables it for arm-linux-gnueabi. Mainline and debian also enables it for
some powerpc and hppa targets, I'm excluding those bits to avoid involving
other targets than arm at this point. (It's easy to enable other targets later
on.)


-- 


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

[Bug target/42503] [4.4 Regression] gcc-4.4-20091215 broke libjava on ARM

[mikpe at it dot uu dot se]

--- Comment #14 from mikpe at it dot uu dot se  2009-12-29 23:15 ---
Patch submitted:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01192.html


-- 


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

[Bug middle-end/42099] Error in 64-bit division for 32-bit target

[mikpe at it dot uu dot se]

--- Comment #7 from mikpe at it dot uu dot se  2009-12-30 16:45 ---
FWIW, Ian's fix backports trivially to 4.4 and 4.3 and fixes this test case
there with no test suite regressions (all default languages) on i686-linux.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug c/42557] gcc no compile for m68k(coff/elf)

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2009-12-30 22:40 ---
(In reply to comment #0)
 I tried to compile gcc (4.4.1 and 4.4.2) for m68k-coff for Linux. I'm
 using Ubuntu 9.10 AMD64. However, I get an error stating that gas is not
 supported for the version of binutils (2.20) used:
 
 ...
 Configuring in ./gas
...
 This target is no longer supported in gas
 make[1]: *** [configure-gas] Error 1
 make[1]: Leaving directory `/home/miltoncsl/Documents/coldfire/binutils-2.20'
 make: *** [all] Error 2

Confirmed, but this is a binutils problem so you should report it to them not
us. binutils-2.16.1 does build for m68k-unknown-coff.


-- 


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

[Bug c/42557] gcc no compile for m68k(coff/elf)

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2009-12-31 00:53 ---
(In reply to comment #0)
 When compiling m68k-elf the process went
 smoothly and I can install (m68k-elf-as, m68k-elf-ar, etc.). But this
 time I can not compile gcc 4.4.1 or 4.4.2 (m68k-elf-gcc) because I
 get an error stating problems with libgcc.mvars:
...
 Makefile:143: ../.././gcc/libgcc.mvars: No such file or directory
 make[2]: *** No rule to make target `../.././gcc/libgcc.mvars'.  Stop.
 make[2]: Leaving directory
 `/home/miltoncsl/Documents/coldfire/gcc-4.4-4.4.1.orig/gcc-4.4.1/m68k-elf/libgcc'
 make[1]: *** [all-target-libgcc] Error 2
 make[1]: Leaving directory
 `/home/miltoncsl/Documents/coldfire/gcc-4.4-4.4.1.orig/gcc-4.4.1'
 make: *** [all] Error 2

I can reproduce this, but only by doing the build in the source directory
itself. Never ever do that with gcc. Doing the build in a separate object
directory and configuring with --target=m68k-unknown-elf --disable-libssp I'm
easily able to build gcc-4.4.2 as cross-compiler to m68k-unknown-elf on
i686-linux.

This PR should be closed as invalid.


-- 


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

[Bug c/42522] [m68k] Wrong code generated with -O2/-O3

[mikpe at it dot uu dot se]

--- Comment #10 from mikpe at it dot uu dot se  2009-12-31 17:01 ---
Created an attachment (id=19431)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19431action=view)
simpler test case

I'm attaching a reduced test case that triggers wrong-code for m68k-elf with
gcc-4.5-20091224, every 4.x release, and 3.4.6 (didn't check older releases).

To trigger, compile with -O2 (or higher) and -m68020 (or higher), and observe
how bar() skips all tests and just returns zero.

Any of the following actions mask the bug:
1. reduce optimization level to -O1
2. reduce target cpu type to -m68010 or -m68000
3. remove the __attribute__((packed)) from union foo
4. in bar(), replace p-d[0] with p-d[1] so that the first and second
memory accesses don't have the same base address

-fno-strict-aliasing makes no difference


-- 


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

[Bug c/42571] internal compiler error: Illegal instruction when handling moon.c file

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2010-01-01 17:37 ---
Created an attachment (id=19437)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19437action=view)
fix arm eabi default cpu type

Try this patch, from debian. It corrects arm-eabi to choose an
armv4t-compatible arm9tdmi as the default cpu type. Otherwise it may generate
armv5t code, which is consistent with your illegal instruction problem.

Oh, and please update the reported against field: you selected 4.2.2 but
clearly you used 4.4.2 (4.2.x is no longer supported).


-- 


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

[Bug c/42571] internal compiler error: Illegal instruction when handling moon.c file

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2010-01-01 19:48 ---
(In reply to comment #3)
 Try this patch, from debian. It corrects arm-eabi to choose an
 armv4t-compatible arm9tdmi as the default cpu type. Otherwise it may generate
 armv5t code, which is consistent with your illegal instruction problem.
 
 Thanks, but seeing as this is my first time patching what I can assume to be
 the gcc binary file, how do I actually *do* it (i.e. which commands)?

The patch is for the gcc source code, to be applied with the `patch' utility.
If you're uncomfortable patching the gcc source code, you can instead try
adding --with-arch=armv4t when configuring gcc before you build it.


-- 


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

[Bug c/42557] gcc no compile for m68k(coff/elf)

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2010-01-02 14:21 ---
(In reply to comment #3)
 However, the goal is to compile gcc for the coff format and
 I'm having it difficulties.

Consider the following two facts:
1. binutils-2.17 removed m68k-coff support, that was 3.5 years ago
2. gcc-4.4's NEWS file lists m68k-coff as unmaintained and scheduled for
removal

 I'm sure that problem has easy solution, but I'm starting now. What books can
 help in this process?

Your best option is to target m68k-elf instead, as that's still supported.

If you absolutely must use coff, it's probably best to use older versions of
binutils and gcc from the time when it was still supported. binutils-2.16.1 and
gcc-3.4.6 might be a good starting point. You can't expect any upstream support
for these old versions, however.


-- 


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

[Bug c++/40561] [4.3 Regression] code does not compile -- compiles fine when replacing != with !(==)

[mikpe at it dot uu dot se]

--- Comment #10 from mikpe at it dot uu dot se  2010-01-03 23:15 ---
(In reply to comment #9)
 Fascinating indeed.  If someone can bisect where during 4.4 development we
 fixed this again or where during 4.3 development we broke it that would be
 nice.

This test case was fixed for 4.4 by r142961, the fix for PR38564.

This test case fails with a recent 4.3, but r142961 applies cleanly and fixes
the test case. I haven't done any testsuite runs on that combo yet, however.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/42503] [4.4 Regression] gcc-4.4-20091215 broke libjava on ARM

[mikpe at it dot uu dot se]

--- Comment #17 from mikpe at it dot uu dot se  2010-01-05 15:41 ---
Fixed now, closing.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug target/32332] [4.3 only ] libobjc build failure on arm-unknown-eabi (__gnu_objc_personality_v0)

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2010-01-10 22:05 ---
(In reply to comment #3)
 Works for me with current 4.4 branch and trunk. 
 
 I think this patch fixed it - 
 
 http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00303.html - 
 http://gcc.gnu.org/viewcvs?view=revisionrevision=136215
 
 
 I don't think this is fixed in the 4.3 branch because I can't see the bits in
 the relevant files. 

It's not fixed in current 4.3 branch. The patch quoted above is included in
Debian's gcc-4.3 (and in my private 4.3 tree), and with it objc works fine.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug c/42721] possible integer wrong code bug

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2010-01-13 12:14 ---
With a recent gcc-4.4 I see this -O1/-O2 difference on i686 but not powerpc64.
On i686 gcc-4.3 also seems affected (-O0 vs -O1), but 4.2 and 4.1 seem Ok.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug c/37768] New: bogus warnings on x86_64-mingw32 due to attribute((format(printf))) breakage

[mikpe at it dot uu dot se]

When gcc is configured to generate code for x86_64-pc-mingw32, that is MinGW
for 64-bit Windows, attribute((format(printf))) is redefined by the backend to
be compatible with MSVC's runtime library, which differs significantly from
C99.

This is fine for calls that link to MSVC's library, but it breaks code that
uses private implementations of C99-compliant formatting routines, because the
backend redefines ALL uses of attribute((format(printf))) to mean MSVC's printf
not C99. The result is that C99-compliant code gets stray warnings and
inadequate printf format checking on x86_64-pc-mingw32.

The program below illustrates the issue. It declares a private C99-compliant
snprintf() implementation and invokes it with %zu and %llx formats. This
triggers the following bogus warnings on x86_64-pc-mingw32:

 x86_64-pc-mingw32-gcc -std=c99 -O -Wall -c badwarning.c
badwarning.c: In function 'main':
badwarning.c:16: warning: unknown conversion type character 'z' in format
badwarning.c:16: warning: unknown conversion type character 'l' in format
badwarning.c:16: warning: too many arguments for format

What I think the backend should do is to implement an msprintf format type,
and then Mingw-w64 should declare printf() et al using that not plain printf.

/* badwarning.c */
#include stddef.h
#include stdarg.h

int  __attribute__((format(printf, 3, 4)))
my_snprintf(char *buf, size_t n, const char *fmt, ...)
{
/* invoke C99 compliant private vsnprintf() here */
return 0;
}

int main(void)
{
char buf[64];
return my_snprintf(buf, sizeof buf, %zu %llx,
   sizeof buf, 0ULL);
}


-- 
   Summary: bogus warnings on x86_64-mingw32 due to
attribute((format(printf))) breakage
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC target triplet: x86_64-pc-mingw32


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

[Bug c/37768] bogus warnings on x86_64-mingw32 due to attribute((format(printf))) breakage

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2008-10-09 07:04 ---
  The program below illustrates the issue. It declares a private C99-compliant
  snprintf() implementation and invokes it with %zu and %llx formats. This
  triggers the following bogus warnings on x86_64-pc-mingw32:
 
 Use gnu_printf for such an implementation.

Thanks. Using gnu_printf (new in 4.4) solves the issues I had.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/37915] bootstrap broken for cygwin

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2008-10-25 20:55 ---
Same here. gcc-4.4-20081024 configured with --enable-languages=c,c++ and built
using gcc-4.3.2/binutils-2.18.93 on cygwin (XP 64 Pro) ICEs when compiling
type_traits.h. It also ICEs in the same place when configured for
x64_64-pc-mingw32.

The following is a minimized test case that triggers the ICE:

templatebool, typename
  struct __enable_if 
  { };

templatetypename _Tp
  struct __enable_iftrue, _Tp
  { typedef _Tp __type; };


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug bootstrap/37915] bootstrap broken for cygwin

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2008-10-31 10:03 ---
(In reply to comment #1)

I rebuilt my toolchains with binutils-2.19 + three fixes and now
gcc-4.4-20081024 builds fine for me with --enable-languages=c,c++.

The three addon fixes in my binutils-2.19 are:
1. http://sourceware.org/ml/binutils-cvs/2008-10/msg00050.html
   Backport pointers aren't long on Win64 fix from upstream.
2. http://sourceware.org/ml/binutils-cvs/2008-10/msg00112.html
   Backport ld -r bug on Win64 (PR6945) fix from upstream.
3. Local multilib patches so i686-{cygwin,mingw32} binutils can process 64-bit 
  object files, and x86_64-mingw32 binutils can process 32-bit object files.


-- 


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

[Bug c/37989] New: PR37528 fix broke --disable-shared on mingw32

[mikpe at it dot uu dot se]

gcc-4.4-20081003 and later configured with --disable-shared for mingw32 attempt
to link with libgcc_eh.a even though it never built libgcc_eh.a (those object
files are included in libgcc.a):

/home/mikpe/gcc-4.4-20081031/configure --target=x86_64-pc-mingw32
--prefix=/tmp/cross-mingw64 --disable-nls --disable-shared
--enable-threads=win32 --enable-languages=c --with-gmp=/opt/local/gmp-4.2.4
--with-mpfr=/opt/local/mpfr-2.3.2 --disable-win32-registry
--enable-sjlj-exceptions
make
make install
echo int main(void) { return 0; }  trivial.c
/tmp/cross-mingw64/bin/x86_64-pc-mingw32-gcc trivial.c
/tmp/cross-mingw64/lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/bin/ld:
cannot find -lgcc_eh
collect2: ld returned 1 exit status

The fix for PR37528 changed mingw32.h to #define REAL_LIBGCC_SPEC, and it also
changed it to unconditionally link with -lgcc_eh for !shared-libgcc.
That only works if libgcc_eh.a actually was built, which isn't the case when
gcc was configured with --disable-shared.


-- 
   Summary: PR37528 fix broke --disable-shared on mingw32
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: x86_64-pc-mingw32


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

[Bug c/37989] PR37528 fix broke --disable-shared on mingw32

[mikpe at it dot uu dot se]

--- Comment #1 from mikpe at it dot uu dot se  2008-11-01 18:10 ---
Created an attachment (id=16610)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16610action=view)
patch to unbreak --disable-shared on mingw32

Proposed patch to unbreak --disable-shared on mingw32. When PR37528 changed
mingw32.h to #define REAL_LIBGCC_SPEC it also bypassed gcc/gcc.c's logic to
only link with -lgcc_eh when ENABLE_SHARED_LIBGCC is defined. So my proposed
fix adds that logic to mingw32.h's definition of REAL_LIBGCC_SPEC.

Tested on WinXP64 under cygwin both with and without --disable-shared.


-- 


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

[Bug target/37989] PR37528 fix broke --disable-shared on mingw32

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2008-11-03 13:49 ---
(In reply to comment #2)
Danny, I've tested the revised patch both with and without --disable-shared,
and both configs build and work fine.


-- 


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

[Bug target/34652] arm-only miscompilation of alloca code

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2008-03-16 16:49 ---
(In reply to comment #1)
 This happens with 4.1, 4.2 and trunk on old ABI.  Apparently it doesn't
 happen with EABI.
 

I see the problem too, on Linux/ARM/OABI with gcc-4.1.2.

However, the problem is in the test case itself. Specifically the attempt to
align _b:

 if (((unsigned long)_b)sizeof(_b)) _b++;

_b is void*, so this is if (_b  4) _b += 1; at the machine level, which is
totally bogus. Om my machine alloca() returned 0xbea1d97c (a multiple of 4 but
not of 8), which this code changed to 0xbea1d97d. The following uses of _b as a
pointer caused numerous alignment exceptions (logged by the kernel).

On the other machines I tested this on (sparc, powerpc, x86), alloca() returned
an address that was a multiple of 8, so the bogus alignment code didn't
trigger.

If you want to align _b to a multiple of 2*sizeof(void*), do something like:
_b = (void*)(((unsigned long)_b + 2*sizeof(void*)-1)  ~(2*sizeof(void*)-1));

Not a gcc bug, IMO.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug rtl-optimization/35812] New: redundant range check in trivial switch statements

[mikpe at it dot uu dot se]

The code generated for switch (n  7) which has all possible cases (0-7)
includes a redundant range check.

To illustrate, this source code:

void foo(unsigned int *d, const unsigned int *s, unsigned int n)
{
switch (n  7) {
  case 7:
d[7] = s[7];
break;
  case 6:
d[6] = s[6];
break;
  case 5:
d[5] = s[5];
break;
  case 4:
d[4] = s[4];
break;
  case 3:
d[3] = s[3];
break;
  case 2:
d[2] = s[2];
break;
  case 1:
d[1] = s[1];
break;
  case 0:
d[0] = s[0];
break;
}
}

compiles (gcc-4.2.3 -O2 -fomit-frame-pointer -S) to:

.text
.p2align 4,,15
.globl foo
.type   foo, @function
foo:
movl12(%esp), %eax
andl$7, %eax
cmpl$7, %eax
ja  .L12
jmp *.L11(,%eax,4)
.section.rodata
.align 4
.align 4
.L11:
.long   .L3
.long   .L4
.long   .L5
.long   .L6
.long   .L7
.long   .L8
.long   .L9
.long   .L10
(the rest omitted)

In the sequence:
andl$7, %eax
cmpl$7, %eax
ja  .L12
the compare-and-jump can never trigger.


-- 
   Summary: redundant range check in trivial switch statements
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
  GCC host triplet: i686-pc-linux-gnu


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

[Bug tree-optimization/36339] [4.3/4.4 Regression] not call clobbering variable for non common offset

[mikpe at it dot uu dot se]

--- Comment #7 from mikpe at it dot uu dot se  2008-05-27 20:48 ---
(In reply to comment #6)
 Fixed.
 

I added the fix to the latest gcc-4.3 snapshot and bootstrapped it.
I then tested both the original application that failed (Erlang)
as well as the latest Linux kernel. Both built and worked fine.

Thank you for fixing this so quickly.


-- 


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

[Bug bootstrap/36356] New: gcc-4.2.4 bootstrap failure on Solaris/x86 caused by PR31868 fix

[mikpe at it dot uu dot se]

gcc-4.2.4 fails to bootstrap on Solaris10/x86 as follows:

env CONFIG_SHELL=/usr/bin/bash /home/mikpe/gcc-4.2.4/configure
--prefix=/opt/local/gcc-4.2.4 --with-gnu-as
--with-as=/opt/local/binutils-2.18/bin/as --without-gnu-ld
--with-ld=/usr/ccs/bin/ld --enable-threads=posix --disable-shared
--enable-multilib --enable-nls --with-included-gettext
--with-libiconv-prefix=/opt/csw --enable-java-awt=xlib --with-system-zlib
--enable-languages=c,c++ --with-mpfr=/opt/csw
make bootstrap
...
checking sys/sem.h presence... yes
checking for sys/sem.h... yes
checking for sin in -lm... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/home/mikpe/objdir-4.2.4-static'
make: *** [bootstrap] Error 2

I have previously built gcc-4.1.2 and gcc-4.2.3 successfully on this
system, so this failure is an obvious regression.

Testing older 4.2 snapshots showed that 4.2-20080206 was the last
snapshot that built ok, and 4.2-20080213 is the first one that fails.

Inspecting the diff between 20080206 and 20080213 and testing parts
of it separately has identified H.J. Lu's fix for PR31868 as the
culprit. Specifically, after that change crtstuff.c is compiled with
-fno-asynchronous-unwind-tables which it wasn't before the change.
20080213 minus the -fno-asynchronous-unwind-tables change builds fine.

I haven't yet checked if gcc-4.3 is similarly affected because I needed
to resolve a generic 4.3 problem first (PR36339).


-- 
   Summary: gcc-4.2.4 bootstrap failure on Solaris/x86 caused by
PR31868 fix
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
  GCC host triplet: i386-pc-solaris2.10


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

[Bug bootstrap/36330] i386-pc-solaris2.10 configure: error: C compiler cannot create executables

[mikpe at it dot uu dot se]

--- Comment #6 from mikpe at it dot uu dot se  2008-05-28 13:20 ---
(In reply to comment #5)
 checking for C compiler default output file name... configure: error: C
 compiler cannot create executables
 See `config.log' for more details.
 make[1]: *** [configure-target-libgomp] Error 1
 
 Can you attach the config.log  then?
 

I get the exact same failure trying to bootstrap 4.3-20080522 + PR36339
fix on Solaris10/x86. The config.log entry says this:

configure:2540: checking for C compiler default output file name
configure:2543: /home/mikpe/objdir-4.3-20080522-static/./gcc/xgcc
-B/home/mikpe/objdir-4.3-20080522-stat
ic/./gcc/ -B/opt/local/gcc-4.3-20080522/i386-pc-solaris2.10/bin/
-B/opt/local/gcc-4.3-20080522/i386-pc-s
olaris2.10/lib/ -isystem
/opt/local/gcc-4.3-20080522/i386-pc-solaris2.10/include -isystem /opt/local/gcc
-4.3-20080522/i386-pc-solaris2.10/sys-include  -m64 -O2 -g -O2   -pthread  
conftest.c  5
ld: fatal: unwind table: file
/home/mikpe/objdir-4.3-20080522-static/./gcc/amd64/crtend.o: section .eh_f
rame: bad cie version 0: offset 0x7ff84680

collect2: ld returned 1 exit status

gcc is configured to use GNU as but Sun ld, as seems to be standard.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/38642] [4.3/4.4/4.5 Regression] Code with -fPIC results in segfault on ARM (old ABI)

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2009-07-11 15:23 ---
The bug occurs on OABI with gcc-4.3-20090705 but not with gcc-4.4-20090707.


-- 


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

[Bug tree-optimization/38072] [4.3 Regression] ICE during inlining of valid code

[mikpe at it dot uu dot se]

--- Comment #13 from mikpe at it dot uu dot se  2009-07-11 15:34 ---
(In reply to comment #12)
 would be interesting to know what fixed this on the trunk.

A binary search on trunk identified revision 138207 as the point that fixed
this ICE. That revision is a large merge from gimple-tuples-branch.


-- 


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

[Bug target/39429] compiler create bad asm codes.

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2009-07-11 20:20 ---
It seems that cpu type and tuning options make a difference here. If I compile
with -mcpu and -mtune referring to a cpu that does not imply FL_LDSCHED, such
as arm740t, then I get the broken code that clobbers r0 before loading r3.
Changing cpu and tune types to a cpu that does imply FL_LDSCHED, such as arm8
or xscale, then r3 is loaded before r0 is clobbered and the sub becomes an rsb.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||mikpe at it dot uu dot se


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

[Bug target/39429] compiler create bad asm codes.

[mikpe at it dot uu dot se]

--- Comment #4 from mikpe at it dot uu dot se  2009-07-12 11:29 ---
Created an attachment (id=18179)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18179action=view)
reduced test case in plain C


-- 


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

[Bug target/39429] compiler create bad asm codes.

[mikpe at it dot uu dot se]

--- Comment #6 from mikpe at it dot uu dot se  2009-07-12 21:21 ---
(In reply to comment #5)
 What options did you use  ?  Did you use -O2 , -O3 or -Os  with the testcase
 you've added here ? I don't see the problem with 4.5.0 trunk 149479 with 
 either
 -mcpu=arm740t or with arm7tdmi.

Either -O2 or -Os plus -mcpu=arm740t will trigger it in gcc-4.3.4 and
gcc-4.4.1. After prepping a patch for 4.4.1 I noticed that I couldn't trigger
it in 4.5; I'm currently bisecting 4.5 to identify what changed it there.


-- 


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