[Bug tree-optimization/41339] Variables can occur multiple times in cfun->local_decls

[baldrick at free dot fr]

--- Comment #4 from baldrick at free dot fr  2009-09-13 07:43 ---
Created an attachment (id=18577)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18577&action=view)
New checking patch; frees memory allocated by the checking code


-- 

baldrick at free dot fr changed:

   What|Removed |Added

  Attachment #18566|0   |1
is obsolete||


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

[Bug fortran/40812] Files > 2GB are incorrectly handled on mingw

[ktietz at gcc dot gnu dot org]

--- Comment #13 from ktietz at gcc dot gnu dot org  2009-09-13 08:19 ---
(In reply to comment #12)
> > > Well, in fact it is MS here. But we on mingw-w64 think at the moment 
> > > about 
> > > to add an override option for this by defining _LARGE_FILES
> 
> (In reply to comment #11)
> > I worked on some of the current large file defines in libgfortran.
> 
> I think there are two options:
> 
> a) libgfortran handles Windows large-file support explicitly, i.e. uses
> off64_t, ftello64, fseeko64 explicitly. (For truncation [cf. backspace on
> writing], one might need to do fseeko64 + SetEndOfFile(HANDLE).)
> 
> b) MinGW maps off_t to off64_t etc. when using the -D_FILE_OFFSET_BITS=64
> similar to (some) Unix.
> 
> I think (b) would automatically enable large-file support for libgfortran; Kai
> will discuss this with other MinGW developers.
> (a) would be an option independent of MinGW changes.
> 
> The plan was to wait for the result of the discussion regarding the MinGW
> changes before continuing here.
> 

Hello,

I spoke in team of mingw-w64 and with some of the team of mingw.org about this
issue. On one hand, we have to agree that this kind of feature would ease
porting of POSIX sources to windows, on the other we see here issues in general
compatibility for native win32 applications and wrong assumptions of users
about POSIX and windows native runtime. So we decided for now, that we won't
introduce this macro magic, and it would be best that libgfortran does this
porting for native windows by themself.

Cheers,
Kai


-- 


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

[Bug ada/41325] ACATS c37105a wrong code on armv5tel

[ramana at gcc dot gnu dot org]

--- Comment #1 from ramana at gcc dot gnu dot org  2009-09-13 09:20 ---
can you put a link to Mikaels patch here to make the bug report complete ? 


-- 


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

[Bug ada/41325] ACATS c37105a wrong code on armv5tel

[laurent at guerby dot net]

--- Comment #2 from laurent at guerby dot net  2009-09-13 09:51 ---
Here is the sjlj port patch:

http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00450.html


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net


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

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

[laurent at guerby dot net]

--- Comment #58 from laurent at guerby dot net  2009-09-13 11:36 ---
I'm still seeing a bootstrap comparison failure on sparc-linux as of revision
151650 so after the last commit:

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/sel-sched.o differs
gcc/c-common.o differs
gcc/c-omp.o differs
gcc/varasm.o differs
gcc/ipa-struct-reorg.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/guerby/build'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/guerby/build'
make: *** [bootstrap] Error 2

Is there a separate PR or should I reopen this one?


-- 


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

[Bug fortran/32131] knowing that stride==1 when using allocated arrays and escaping allocatable arrays

[tkoenig at gcc dot gnu dot org]

--- Comment #13 from tkoenig at gcc dot gnu dot org  2009-09-13 12:54 
---
Actually closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #32 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-09-13 13:58 ---
Created an attachment (id=18578)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18578&action=view)
A bug example for 4.4 patch

Shows a bug in 4.4 patch


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #33 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-09-13 13:59 ---
Created an attachment (id=18579)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18579&action=view)
Another bug in 4.4 patch

Another bug in 4.4 patch.


-- 


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

[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

[mikulas at artax dot karlin dot mff dot cuni dot cz]

--- Comment #34 from mikulas at artax dot karlin dot mff dot cuni dot cz  
2009-09-13 14:07 ---
So I posted these two examples that show that the patch is insufficient:

1) if the array is embedded in a structure and that structure is on the stack,
the stack is not aligned. (if the array were out of structure, it would be)

2) gcc sometimes spills xmm registers over function calls (spilling zero this
way is suboptimal, but that's only a performance issue) and the stack is not
aligned in this case.

Note, in align-counterexample2.c, there is another bug! Gcc shouldn't assume
that arrays "x" and "y" are 16-byte aligned. Arrays "x" and "y" are in common
section, that means that they can be declared in any other module and the
linker joins these declarations. So, for example, if in another module someone
declared int x[100] = { 1, 2, 3, 4 } and the module were compiled with
different compiler that doesn't align the array (the ABI allows it) , the
linker is forced to use the declaration with the initialization and the array
would be misaligned.

We can only assume alignment on the variables that are not in common section,
i.e. with -fno-common or explicitly initialized.


-- 


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

[Bug fortran/32382] missed optimization in internal read

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2009-09-13 14:30 
---
I will not have time to work on this one. Un-assigning.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


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

[Bug fortran/41192] NAMELIST input with just a comment ("&NAME ! comment \") fails

[jvdelisle at gcc dot gnu dot org]

--- Comment #13 from jvdelisle at gcc dot gnu dot org  2009-09-13 14:31 
---
Fixed.  I see no point in warning on a comment.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug fortran/41347] [middle-end, regression ] ICE with -O3

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2009-09-13 15:56 ---
Problem also occurs on *-*-freebsd.  This may be related to the
2009-08-18  Michael Matz  
commit.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |major
   Keywords||ice-on-valid-code
  Known to fail||4.5.0
  Known to work||4.3.4 4.4.2
   Priority|P3  |P2
Summary|ICE with -O3|[middle-end, regression ]
   ||ICE with -O3


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

[Bug bootstrap/41348] New: Bootstrap fails with --with-arch=i686

[aanisimov at inbox dot ru]

Compiling GCC started to fail in revision 151361 with the following error:
> Comparing stages 2 and 3
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs

Revision 151360 compiles fine.

I used the following arguments to configure GCC:

../gcc/configure --prefix=/tmp/gcc45 --enable-shared --enable-bootstrap
--enable-languages=c,c++ --enable-threads=posix --enable-checking=release
--with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit
--enable-libssp --with-gnu-ld --verbose --with-arch=i686
--target=i486-slackware-linux --build=i486-slackware-linux
--host=i486-slackware-linux


-- 
   Summary: Bootstrap fails with --with-arch=i686
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aanisimov at inbox dot ru
 GCC build triplet: i486-slackware-linux
  GCC host triplet: i486-slackware-linux
GCC target triplet: i486-slackware-linux


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

[Bug target/39635] [avr] integer wrong code bug

[hutchinsonandy at aim dot com]

--- Comment #5 from hutchinsonandy at aim dot com  2009-09-13 16:14 ---
It looks like most of AVR shift/rotates are messed up.
For the case we where we have non constant shifts, the peephole may grab a
scratch register. In this case it look like it grabs one that is free
afterwards and not before. Hence overlap issue

The rotate split pattern problem is different as noted in message links. .  In
this case it is not apparent why the split is used for only different
source/destination registers. If the split were constrained so that src=dest
the overlap would be much easily to handle and it would seemingly produce
better code for the common case where src=dest.


-- 


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

[Bug target/35294] iwmmxt intrinsics, internal compiler error

[den at openvz dot org]

--- Comment #4 from den at openvz dot org  2009-09-13 17:07 ---
same problem with gcc-4.3.4, sources comes from gentoo package

iris ~ $ arm-iwmmxt-linux-gnueabi-g++ -flax-vector-conversions -c -O2  1.cpp
/vol/marvel-4.3.2/bin/../lib/gcc/arm-iwmmxt-linux-gnueabi/4.3.4/include/mmintrin.h:
In function 'void foo()':
/vol/marvel-4.3.2/bin/../lib/gcc/arm-iwmmxt-linux-gnueabi/4.3.4/include/mmintrin.h:529:
internal compiler error: in arm_expand_binop_builtin, at config/arm/arm.c:15429
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
iris ~ $ arm-iwmmxt-linux-gnueabi-g++ -v
Using built-in specs.
Target: arm-iwmmxt-linux-gnueabi
Configured with: /vol/build/gcc-4.3.4/configure
--target=arm-iwmmxt-linux-gnueabi --with-cpu=iwmmxt --with-float=soft
--enable-cxx-flags=-msoft-float --disable-nls --enable-threads=posix
--enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++
--enable-shared --enable-c99 --enable-long-long
--with-sysroot=/opt/marvel/sysroot --prefix=/opt/marvel/
Thread model: posix
gcc version 4.3.4 (GCC) 


-- 

den at openvz dot org changed:

   What|Removed |Added

 CC||den at openvz dot org


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

[Bug middle-end/41009] [4.3 Regression] FAIL: gcc.c-torture/execute/20070614-1.c execution, -O0

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2009-09-13 17:34 ---
I believe this PR can be fixed by backporting:

2009-03-10  Richard Guenther  
Nathan Froyd  

PR middle-end/37850
* libgcc2.c (__mulMODE3): Use explicit assignments to form the result.
(__divMODE3): Likewise.

Don't know why this didn't bite before.


-- 


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

[Bug other/41234] Configure fails to find non-existent g++ preprocessor flag with syntax errors

[ktietz at gcc dot gnu dot org]

--- Comment #3 from ktietz at gcc dot gnu dot org  2009-09-13 17:43 ---
(In reply to comment #2)
> (In reply to comment #1)
> > You didn't say how you configured it.
> > As with bug 40950, you might need --enable-stage1-languages=c,c++
> 
> Sorry, it was configured with
> --enable-languages=c,c++,objc,obj-c++,fortran,java
> 
> It is a full build. Here's the whole thing:
> 
> ../configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
> --enable-multilib --enable-targets=all --prefix=/usr/system64
> --with-sysroot=/usr/system64 --with-mpc=/usr/system64 --with-ppl=/usr/system64
> --with-cloog=/usr/system64 --enable-languages=c,c++,objc,obj-c++,fortran,java
> --enable-fully-dynamic-strings --enable-libffi --enable-libgomp 
> --enable-shared
> --enable-version-specific-runtime-libs --disable-werror
> 
> --disable-werror is required building Win64 Native. Mingw-w64 is aware of the
> issues.
> 

As this is a build on base of x86_64 and using mingw, it could be related to
the issue that need_64bit_hwint wasn't set for this target in libcpp configure
and config.gcc. I corrected this today. Could you please retry it with recent
gcc trunk version, if this solves you issues.

Thanks,
Kai


-- 


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

[Bug middle-end/41347] [4.5 Regression] ICE with -O3

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org
Summary|[regression ] ICE with -O3  |[4.5 Regression] ICE with -
   ||O3
   Target Milestone|--- |4.5.0


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

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

[ebotcazou at gcc dot gnu dot org]

--- Comment #59 from ebotcazou at gcc dot gnu dot org  2009-09-13 21:31 
---
> Is there a separate PR or should I reopen this one?

This one is already overloaded, I'd suggest opening a new one.


-- 


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

[Bug bootstrap/41349] New: bootstrap comparison failure on sparc-linux

[laurent at guerby dot net]

I see a bootstrap comparison failure on sparc-linux (gcc54) as of revision
151664 so well after the last commit for PR41241 :

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/sel-sched.o differs
gcc/c-common.o differs
gcc/c-omp.o differs
gcc/varasm.o differs
gcc/ipa-struct-reorg.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/guerby/build'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/guerby/build'
make: *** [bootstrap] Error 2


-- 
   Summary: bootstrap comparison failure on sparc-linux
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
 GCC build triplet: sparc-unknown-linux-gnu
  GCC host triplet: sparc-unknown-linux-gnu
GCC target triplet: sparc-unknown-linux-gnu


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

[Bug bootstrap/41241] [4.5 regression] bootstrap comparison failure

[laurent at guerby dot net]

--- Comment #60 from laurent at guerby dot net  2009-09-13 21:44 ---
Ok I filed

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


-- 


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

[Bug bootstrap/41350] New: [4.5 regression] FreeBSD bootstrap failure: unimplemented: Multiple EH personalities are supported only with assemblers supporting .cfi.personality directive

[gerald at pfeifer dot com]

Bootstrap on i386-unknown-freebsd7.2 and presumably other systems with
olders versions of binutils now fails as follows:

/usr/test/gcc/libstdc++-v3/libsupc++/eh_alloc.cc: In function '(static
initializers for /usr/test/gcc/libstdc++-v3/libsupc++/eh_alloc.cc)':
/usr/test/gcc/libstdc++-v3/libsupc++/eh_alloc.cc:220:1: sorry,
unimplemented: Multiple EH personalities are supported only with assemblers
supporting .cfi.personality directive.
gmake[4]: *** [eh_alloc.lo] Error 1

I'm pretty sure this is related to the following patch:

  2009-09-13  Richard Guenther  
 Rafael Avila de Espindola  

* langhooks-def.h (LANG_HOOKS_EH_RUNTIME_TYPE): Define.
(LANG_HOOKS_EH_PERSONALITY): Likewise.
(LANG_HOOKS_INITIALIZER): Adjust.


-- 
   Summary: [4.5 regression] FreeBSD bootstrap failure:
unimplemented: Multiple EH personalities are supported
only with assemblers supporting .cfi.personality
directive
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
  GCC host triplet: i386-unknown-freebsd7.2


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

[Bug libstdc++/41351] New: std::rotate on RAI does not conform to ISO complexity requirement

[potswa at mac dot com]

According to C++03 and C++0x, std::rotate has "Complexity: At most last - first
swaps."

The random iterator implementation does not call std::swap at all, but rather
creates a temporary variable and uses the assignment operator to implement
swapping. std::swap often has different complexity than two assignments, so
this is non-conforming. Note that the standard requires that std::swap on any
container take constant time, but assignment will take linear time.

The temporary variable appears to be an optimization for native machine types:
rather than move each object to its final location with a swap operation, move
it with an assignment and avoid performing twice the necessary assignments.
This is a good goal, and perhaps it may be achieved using a special
temporary-variable template type which calls std::swap for all but some subset
of types.


-- 
   Summary: std::rotate on RAI does not conform to ISO complexity
requirement
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: potswa at mac dot com


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

[Bug middle-end/41352] New: [4..4 Regression] Revision 151676 failed to bootstrap

[hjl dot tools at gmail dot com]

On Linux/x86-64, revision 151676 caused:

In class 'gnu.java.security.hash.Tiger':
In method 'gnu.java.security.hash.Tiger.()':
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[6]: *** [gnu/java/security/hash.lo] Error 1


-- 
   Summary: [4..4 Regression] Revision 151676 failed to bootstrap
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug bootstrap/41350] [4.5 regression] FreeBSD bootstrap failure: unimplemented: Multiple EH personalities are supported only with assemblers supporting .cfi.personality directive

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2009-09-14 03:21 ---
Same failure on powerpc-apple-darwin9.


-- 


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

[Bug middle-end/41352] [4..4 Regression] Revision 151676 failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2009-09-14 05:09 ---
On Linux/ia64, I got

../../../../src-trunk/libstdc++-v3/libsupc++/eh_alloc.cc: In function '(static
initializers for ../../../../src-trunk/libstdc++-v3/libsupc++/eh_alloc.cc)':
../../../../src-trunk/libstdc++-v3/libsupc++/eh_alloc.cc:220:1: sorry,
unimplemented: Multiple EH personalities are supported only with assemblers
supporting .cfi.personality directive.
make[7]: *** [eh_alloc.lo] Error 1


-- 


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