GDB compiled with
x86_64-w64-mingw32-gcc (GCC) 4.5.0 20090726 (experimental)
doesn't work (refuses to load symbols for any executable).
This is happening because is_regular_file in gdb/source.c appears to be
mis-optimized (disabling optimization for that one file produces a working
GDB).
The so
--- Comment #3 from aph at gcc dot gnu dot org 2009-07-30 07:37 ---
This regression in debuginfo seems to have been downgraded to P4, with no
explanation or discussion of which I'm aware.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867
--- Comment #6 from uros at gcc dot gnu dot org 2009-07-30 07:45 ---
Subject: Bug 40577
Author: uros
Date: Thu Jul 30 07:45:26 2009
New Revision: 150249
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150249
Log:
PR target/40577
* config/alpha/alpha.c (alpha_expan
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-07-30
08:00 ---
(In reply to comment #2)
>
> Is it possible that it triggers the exception trying to write in text.unlikely
> which is READONLY?
>
Exactly. This is a linker, not a compiler issue. If you are using
--- Comment #3 from janus at gcc dot gnu dot org 2009-07-30 08:20 ---
In principle warnings for obsolescent features are already there (cf.
GFC_STD_F95_OBS). They are issued with -std=f95 or above, which does work e.g.
for arithmetic if. However, there is no warning for alternate return
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-07-30 08:38 ---
Hmm, possibly this is a bug in our inline functions of mingw-w64. Does the
switch -fno-strict-aliasing solves this issue, too?
We have here struct casts, which maybe are reasoning here strict aliasing
issues.
Kai
-
Computer Environment
OS:FreeBSD 8.0 Beta 2
CPU:Intel Pentium 4 3.06GHz(HT Enabled)
Mem:1.5GB(Memtest86+ Passed)
Situation
Installed from ports
GCC 4.4.1 Recomplie from GCC 4.4.1
Compile flag
/*
CFLAGS= -fmudflapir -fsel-sched-pipelining-outer-loops -fsel-sched-pipelining
-funsafe-loop-optimizatio
--- Comment #2 from htl10 at users dot sourceforge dot net 2009-07-30
09:52 ---
(In reply to comment #1)
> There is no indication in this bug report of whether the issue also
> appears for 4.5. If it does, please update the regression marker to
> "4.4/4.5 Regression".
I downloaded an
--- Comment #2 from sezeroz at gmail dot com 2009-07-30 09:58 ---
Hmm, with gcc-4.4.2 (branch rev. 150249), I always get "mode = 81ff" reported
on the console with both -O0 and -O2 compiled exes from t.c test. This is with
mingw-w64 headers and crt revision 1101, the exes cross-compiled
Compiling file test.c using command: gcc -c test.c -o test.o
test.c
/* 01 */ int foo[] = { 0 };
/* 02 */
/* 03 */ int (*bar)[] = &foo;
/* 04 */
/* 05 */ struct {
/* 06 */int (*bar)[];
/* 07 */ } myStruct = {
/* 08 */.bar = &foo
/* 09 */ };
/* 10 */
>>> test.c
raises the
I don't know if it is appropriate to file bugs against a snapshot... it is okay
to close this if the issue was transient and a latter commit fixes the issue
reported here. In the course of checking bug 40894 against current gcc code
base I got the gcc-4.5-20090723 weekly snapshot tar ball. make boo
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-30 10:22 ---
Don't use -fsee.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40910
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-30 10:24 ---
It indeed smells like a alias violation. Preprocessed source would help here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903
--- Comment #4 from joseph at codesourcery dot com 2009-07-30 11:24 ---
Subject: Re: [4.5 Regression] FAIL: StackTrace2 output
- source compiled test
On Thu, 30 Jul 2009, aph at gcc dot gnu dot org wrote:
> This regression in debuginfo seems to have been downgraded to P4, with no
> e
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-07-30 11:27 ---
*** This bug has been marked as a duplicate of 36432 ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from jsm28 at gcc dot gnu dot org 2009-07-30 11:27 ---
*** Bug 40911 has been marked as a duplicate of this bug. ***
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-30 11:30
---
Why don't you just use SVN? Also, is this failure new, or not? As far as I know
could even be months old...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-30 11:34 ---
Perhaps it would be better just to remove it in the next GCC 4.4 release (I
guess it has been fixed/removed in GCC 4.5). Telling people not to use it after
they discover it is broken is a bit useless.
--
manu at gcc
--- Comment #5 from aph at gcc dot gnu dot org 2009-07-30 11:36 ---
Hmm, this seems to me as a rather perverse interpretation of the rule that
"Java issues are not release-critical": this bug may be manifested in Java
programs, but there is no evidence of which I'm aware that this specif
--- Comment #2 from htl10 at users dot sourceforge dot net 2009-07-30
11:49 ---
(In reply to comment #1)
> Why don't you just use SVN? Also, is this failure new, or not? As far as I
> know
> could even be months old...
I am digging a hole for myself here - am currently building svn (a
--- Comment #16 from manu at gcc dot gnu dot org 2009-07-30 12:02 ---
(In reply to comment #8)
> If anyone cares to repeat my test results, here's a simple test case:
This is not a simple testcase. A simple testcase is a sufficiently small
self-contained compilable code that shows the p
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-30 12:41
---
Well, the file itself didn't *exist* in 4.3.x and 4.4.x...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
--- Comment #3 from laurent at guerby dot net 2009-07-30 12:42 ---
Seen on sparc-linux as well on farm machine gcc54, so confirming on this
platform. sparc64 (gccdoes work though.
Last known successful bootstrap at revision 149705
First FAIL at revision 149748
===X UPDATE === Fri Jul 1
--- Comment #3 from laurent at guerby dot net 2009-07-30 12:51 ---
So confirmed. I'm now trying to identify the commit.
--
laurent at guerby dot net changed:
What|Removed |Added
--
--- Comment #4 from htl10 at users dot sourceforge dot net 2009-07-30
12:57 ---
(In reply to comment #3)
> Well, the file itself didn't *exist* in 4.3.x and 4.4.x...
Oh, indeed... have been trying to build subversion for the last few hours just
so that I can try last night's instead of
--- Comment #3 from htl10 at users dot sourceforge dot net 2009-07-30
13:01 ---
FYI, the libstdc++v3 issue with gcc 4.5 is filed as bug 40912 . So gcc 4.4/4.5
support are both a bit broken, just differently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894
--- Comment #3 from bennett dot schneider at yahoo dot com 2009-07-30
13:06 ---
internal_mcount's from and self arguments were reversed from glibc's version.
Here's the full diff of gmon-sol2.c that produces correct output:
--- gcc/config/i386/gmon-sol2.c.origWed Jul 29 08:57:15 20
On hppa-hpux (32bit SOM, and likely 64bit ELF), installed libgcc_s.sl is
symlinked to libgcc_s.4, but does not have an 'internal name' (=soname) set.
So binaries linked against libgcc_s.sl have "libgcc_s.sl" encoded as dependent
library, while it should be "libgcc_s.4" instead.
As a result, the ru
--- Comment #4 from laurent at guerby dot net 2009-07-30 13:25 ---
boot ok 148068
boot fail 149083
binary search running on gcc40
--
laurent at guerby dot net changed:
What|Removed |Added
The code in ipa_analyze_call_uses tries to wade through the gimple to identify
uses of pointers to member functions that are invariant after inlining (due to
parameter passing). However, the code only looks for the vbit test on the
pointer part of the pmf not on the delta. On targets such as ARM
--- Comment #4 from ppluzhnikov at google dot com 2009-07-30 14:03 ---
Created an attachment (id=18272)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18272&action=view)
pre-processed t.c
Some answers:
The -fno-strict-aliasing does help:
/usr/local/mingw-w64/bin/x86_64-w64-mingw3
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-07-30 14:18 ---
Richi, not scalarizing things like the second foo() in the original
bug description will inevitably lead to warning failures in
g++.dg/warn/unit-1.C and gcc.dg/uninit-I.c. Is that OK? Should I
remove or XFAIl them?
--- Comment #4 from rguenther at suse dot de 2009-07-30 14:29 ---
Subject: Re: SRA scalarizes dead objects,
single-use objects
On Thu, 30 Jul 2009, jamborm at gcc dot gnu dot org wrote:
> --- Comment #3 from jamborm at gcc dot gnu dot org 2009-07-30 14:18
> ---
> Richi, not
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-30 14:34 ---
Yep:
extern __inline__ int __attribute__((__cdecl__)) stat(const char
*_Filename,struct stat *_Stat) {
return _stat64i32(_Filename,(struct _stat64i32 *)_Stat);
}
that isn't going to fly.
struct stat {
_dev
Executing on host: /home/dave/gcc-4.5/objdir/./gcc/g++ -shared-libgcc
-B/home/da
ve/gcc-4.5/objdir/./gcc -nostdinc++
-L/home/dave/gcc-4.5/objdir/hppa-linux/libst
dc++-v3/src -L/home/dave/gcc-4.5/objdir/hppa-linux/libstdc++-v3/src/.libs
-B/hom
e/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/
-B/home/dav
--- Comment #1 from danglin at gcc dot gnu dot org 2009-07-30 14:55 ---
2009-04-18 Jan Hubicka
* libsupc++/eh_type.cc (__cxa_current_exception_type) Mark throw().
* libsupc++/unwind-cxx.h (__cxa_get_globals,
__cxa_get_globals_fast): Mark const.
(__cxa_
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-30 15:05
---
Decorating the declaration in the testcase too would of course fix the problem
in the trivial way. Now however, I'm rather worried by the fact itself that
those decorations we are adding for optimization purpos
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-30 15:12
---
Ok, it's 17.4.4.8/1, we can proceed with the trivial patch.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #4 from paolo at gcc dot gnu dot org 2009-07-30 15:26 ---
Subject: Bug 40915
Author: paolo
Date: Thu Jul 30 15:26:44 2009
New Revision: 150260
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150260
Log:
2009-07-30 Paolo Carlini
PR libstdc++/40915
*
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-30 15:28
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-30 15:41
---
As a side note, I want to mention that we are very close to finally fixing
c/448 for 4.5.0. Then, any problem related to will disappear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
--- Comment #6 from htl10 at users dot sourceforge dot net 2009-07-30
15:58 ---
(In reply to comment #5)
> As a side note, I want to mention that we are very close to finally fixing
> c/448 for 4.5.0. Then, any problem related to will disappear.
What is 'c/448'? I have spent almost a
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-30 16:07 ---
-fsee was removed on the trunk so closing as won't fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-30 16:24 ---
Subject: Bug 40903
Author: rguenth
Date: Thu Jul 30 16:24:05 2009
New Revision: 150262
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150262
Log:
2009-07-30 Richard Guenther
PR lto/40903
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-30 16:24 ---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-30 16:25 ---
,
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from paolo dot carlini at oracle dot com 2009-07-30 16:26
---
Do you want something to click? PR448
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-07-30 16:26
---
Subject: Bug 40570
Author: jamborm
Date: Thu Jul 30 16:26:09 2009
New Revision: 150263
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150263
Log:
2009-07-30 Martin Jambor
PR tree-optimization/4
--- Comment #8 from joseph at codesourcery dot com 2009-07-30 16:30 ---
Subject: Re: 4.5 weekly snapshot: failed to pre-compile
bits/stdc++.h.gch/O2ggnu++0x.gch
On Thu, 30 Jul 2009, paolo dot carlini at oracle dot com wrote:
> As a side note, I want to mention that we are very close
--- Comment #4 from steven at gcc dot gnu dot org 2009-07-30 16:36 ---
And -O4 doesn't exist, FWIW.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40910
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-07-30 16:43
---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from htl10 at users dot sourceforge dot net 2009-07-30
16:54 ---
(In reply to comment #7)
> Do you want something to click? PR448
Oh, I didn't expect bug id that old to be relevant - I thought c/448 might be
short for bug XX448 so I tried bug 40448 :-).
(In reply to com
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-07-30 16:55 ---
(In reply to comment #4)
> And -O4 doesn't exist, FWIW.
well it does but it is the same as -O3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40910
--- Comment #3 from janis at gcc dot gnu dot org 2009-07-30 17:05 ---
Subject: Bug 39902
Author: janis
Date: Thu Jul 30 17:04:56 2009
New Revision: 150265
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150265
Log:
PR c/39902
* gcc.dg/dfp/pr39902.c: Fix typos in c
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-07-30 17:07 ---
Created an attachment (id=18273)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18273&action=view)
Proposed patch
The attached patch does turn SRA down a bit. Specifically, in order
to create a replacement,
--- Comment #4 from janis at gcc dot gnu dot org 2009-07-30 17:08 ---
Subject: Bug 39902
Author: janis
Date: Thu Jul 30 17:08:09 2009
New Revision: 150266
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150266
Log:
PR c/39902
* gcc.dg/dfp/pr39902.c: Fix typos in c
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-07-30 17:10 ---
Created an attachment (id=18274)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18274&action=view)
Proposed patch
Well, apparently I forgot to run quilt refresh, this is the current
patch with the testcase chan
--- Comment #6 from aph at gcc dot gnu dot org 2009-07-30 17:24 ---
This seems to be happening very early, because the very first tree dump shows:
StackTrace2$Inner.doCrash(java.lang.Object) (struct StackTrace2$Inner * this,
struct java.lang.Object * o)
[StackTrace2.java : 0:0] {
stru
--enable-clocale=gnu
--enable-java-gc=boehm --enable-java-awt=xlib --enable-languages=c,c++
--disable-bootstrap --disable-libstdcxx-pch
Thread model: posix
gcc version 4.5.0 20090730 (experimental) [trunk revision 150259] (GCC)
--
Summary: [4.5 Regression] FAIL:
23_conta
--- Comment #5 from amacleod at redhat dot com 2009-07-30 18:40 ---
I just checked in the code to track locations through PHI arguments.
Comments and patch is located:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01729.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26475
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-30 18:43
---
A run-time failure which depends on PCHs being enabled or not, isn't a library
issue.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-30 19:07 ---
See also http://gcc.gnu.org/ml/fortran/2009-07/msg00260.html and PR 40899.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-30 19:07 ---
See PR 38319
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40899
--- Comment #10 from joseph at codesourcery dot com 2009-07-30 19:28
---
Subject: Re: 4.5 weekly snapshot: failed to pre-compile
bits/stdc++.h.gch/O2ggnu++0x.gch
On Thu, 30 Jul 2009, htl10 at users dot sourceforge dot net wrote:
> I can't say about the others alpha*-dec-osf[45]*, bu
--- Comment #6 from sezeroz at gmail dot com 2009-07-30 19:30 ---
(In reply to comment #5)
> Yep:
>
> extern __inline__ int __attribute__((__cdecl__)) stat(const char
> *_Filename,struct stat *_Stat) {
> return _stat64i32(_Filename,(struct _stat64i32 *)_Stat);
> }
>
> that isn't goin
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-30 19:42
---
It's again a problem in the testcase.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Executing on host: /home/dave/gcc-4.5/objdir/./gcc/g++ -shared-libgcc
-B/home/da
ve/gcc-4.5/objdir/./gcc -nostdinc++
-L/home/dave/gcc-4.5/objdir/hppa-linux/libst
dc++-v3/src -L/home/dave/gcc-4.5/objdir/hppa-linux/libstdc++-v3/src/.libs
-B/hom
e/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/
-B/home/dav
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
I was not able to reproduce the bug on Linux, so I assume this is a
Windows-specific.
If an exception is generated inside shared library (DLL), then crosses the
DLL-boundary and gets caught in some other module, the std::uncaught_exception
will always return wrong (inverted) value from now on. Her
--- Comment #1 from andriys at gmail dot com 2009-07-30 20:22 ---
Created an attachment (id=18275)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18275&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
--- Comment #22 from danglin at gcc dot gnu dot org 2009-07-30 20:23
---
The following two tests also fail on hppa2.0w-hp-hpux11.11:
FAIL: ext/new_allocator/deallocate_global.cc execution test
FAIL: ext/throw_allocator/deallocate_global.cc execution test
--
danglin at gcc dot gnu d
Here is another testsuite issue:
Executing on host: /Users/dave/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/Users/
dave/gnu/gcc/objdir/./gcc -nostdinc++
-L/Users/dave/gnu/gcc/objdir/i686-apple-da
rwin9/libstdc++-v3/src
-L/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/libstdc++
-v3/src/.libs -B/opt/g
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-30 20:38
---
In general, this one must be just xfailed, can pass by chance with PCHs. Can
you please tweak the dg lines at the beginning of the testcase and make sure
it's actually xfailed for this target too? Patch preappr
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-30
20:47 ---
Subject: Re: FAIL: 26_numerics/headers/cmath/c99_classification_macros_c.cc
> In general, this one must be just xfailed, can pass by chance with PCHs. Can
> you please tweak the dg lines at the beginning o
--- Comment #1 from paolo at gcc dot gnu dot org 2009-07-30 21:03 ---
Subject: Bug 40917
Author: paolo
Date: Thu Jul 30 21:02:44 2009
New Revision: 150272
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150272
Log:
2009-07-30 Paolo Carlini
PR libstdc++/40917
*
--- Comment #3 from paolo at gcc dot gnu dot org 2009-07-30 21:03 ---
Subject: Bug 40916
Author: paolo
Date: Thu Jul 30 21:02:44 2009
New Revision: 150272
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150272
Log:
2009-07-30 Paolo Carlini
PR libstdc++/40917
*
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-30 21:05
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #4 from paolo dot carlini at oracle dot com 2009-07-30 21:06
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-30 21:08
---
Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40919
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/220286db9bb4#
The following program is rejected with the bogus message that the derived type
is not interoperable - it works if one moves the type declaration out of the
interface statement. It also works with SEQUE
--- Comment #4 from danglin at gcc dot gnu dot org 2009-07-30 22:34 ---
Subject: Bug 40919
Author: danglin
Date: Thu Jul 30 22:34:31 2009
New Revision: 150278
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150278
Log:
PR libstdc++/40919
* testsuite/26_numerics/he
--- Comment #5 from danglin at gcc dot gnu dot org 2009-07-30 22:36 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Consider the program that follows (you can cut & paste into a shell to get
foo.s). Functions A and B are mathematically identical on the reals.
On Mac OS X 10.5, gcc version 4.4.1, with -O2, we see A and B compiling
differently. In the assembly we see that A squares z, multiplies by y,
subtracts
--- Comment #25 from amylaar at gcc dot gnu dot org 2009-07-30 23:30
---
(In reply to comment #24)
> Unfortunately, there is still no word from the FSF on what they did with our
> Copyright Assignment.
As already mentioned in PR 38785, I've posted the patch here:
http://gcc.gnu.org/ml/
--- Comment #1 from joseph at codesourcery dot com 2009-07-30 23:45 ---
Subject: Re: New: missed optimization: x +
(-y * z * z) => x - y * z * z
Note that -frounding-math should disable the proposed optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40921
--- Comment #2 from benoit dot hudson at gmail dot com 2009-07-30 23:58
---
> Note that -frounding-math should disable the proposed optimization.
Ah, true; and that means that with the options I said to use, the optimization
is simply wrong. However, I see the same behaviour even with
--- Comment #17 from jhopper at safe-mail dot net 2009-07-30 23:58 ---
you can find a nicer version of results (and potentially future updates) here:
http://anonym.to?http://manoa.flnet.org/linux/compilers.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-31 00:00 ---
Yes, this seems wrong.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|U
--- Comment #11 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 01:00 ---
So I did this experiment whether the stack is aligned in current Linux
binaries.
I applied this patch for gcc, so that it crashes on function entry if the
function has stack not aligned on 16 b
--- Comment #12 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 01:04 ---
Created an attachment (id=18276)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18276&action=view)
Crash because gcc assumes false stack alignment
Here I'm submitting an example code that
--- Comment #26 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 01:18 ---
Very unfortunatelly, gcc does assume stack alignment.
The problem is not technical (the code to realign the stack is already there,
it's easy to activate it), the problem is ideological, becau
--- Comment #11 from htl10 at users dot sourceforge dot net 2009-07-31
01:50 ---
gcc-4.5-20090409 (svn r145863) breaks at the same place; gcc-4.5-20090402 (svn
r145482) breaks later at
-
make all-am
make[4]: Entering directory
`/home/htl10/tmp-build/45b/alphaev68-dec-osf5.1a/li
--- Comment #12 from htl10 at users dot sourceforge dot net 2009-07-31
02:14 ---
(In reply to comment #10)
It looks like 4.5 will be dead-on-arrival alpha*-dec-osf[45]*, unless I fix
this myself...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
One day, I built gcc 4.4.1 prerelease, with normal multilib. The next day, I
realized I forgot to add Ada, and all of a sudden multilib failed with the
exact same configuration. At the time, I didn't think too much of it and don't
remember if anything else happened between the two builds, but it is
--- Comment #1 from xenofears at gmail dot com 2009-07-31 03:47 ---
On Binutils I thought I could try an old version, but then realized trying an
old version doesn't really answer the question, it could still be in gcc's
field, or binutils causing a bug in gcc to surface, and leave the n
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-07-31
04:18 ---
(In reply to comment #0)
> I was not able to reproduce the bug on Linux, so I assume this is a
> Windows-specific.
>
> If an exception is generated inside shared library (DLL), then crosses the
> DLL-b
--- Comment #7 from sezeroz at gmail dot com 2009-07-31 06:30 ---
Besides my question in comment #6, I wonder why is this actually considered an
aliasing violation? The only difference between struct stat and struct
_stat64i32 is the time fields: _stat64i32 has __time64_t and stat has t
--- Comment #3 from andriys at gmail dot com 2009-07-31 06:56 ---
I'm linking using g++ driver, so shared libgcc is enabled by default in 4.4.0.
I've just tried to enabled shared libstdc++ as described in the Release Notes
to the MinGW GCC 4.4.0 release, which made no difference.
More o
--- Comment #4 from andriys at gmail dot com 2009-07-31 06:58 ---
Created an attachment (id=18277)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18277&action=view)
Modified test case (not dependent on libstdc++ at all)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
100 matches
Mail list logo
