--- Comment #17 from bonzini at gnu dot org 2009-02-05 08:03 ---
Confirmed:
3.3 -O2 3.11s
4.1 -O2 3.44s
4.4 -O2 3.36s
4.4 -O2 -fno-ivopts 3.00s
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #1 from hp at gcc dot gnu dot org 2009-02-05 08:17 ---
Isn't the answer an obvious no? Lots of s/flag_pic/flag_shlib/ remaining to
do?
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from bonzini at gnu dot org 2009-02-05 08:26 ---
We miss that out1_5+2 could be hoisted out of the loop and used as a base
object
use 0
address
in statement *D.1259_6 = in_7(D);
at position *D.1259_6
type short unsigned int *
base out1_5(D) + 2
step 2
base
Test code:
#include stdint.h
struct u64x2_t {
uint64_t u64a;
uint64_t u64b;
};
union u64_u {
uint64_t u64;
uint64_t *ptr_u64;
};
struct u64x2_t multiple_stack_stores(struct u64x2_t in) {
struct u64x2_t out;
out.u64a=in.u64a+1;
out.u64b=in.u64b;
if ((out.u64a 63)==0) {
--- Comment #20 from bonzini at gnu dot org 2009-02-05 08:52 ---
How much of the fallout (especially the scev-related failures) goes away with
-funsafe-loop-optimizations? I'm thinking that it is unavoidable. :-(
--
bonzini at gnu dot org changed:
What|Removed
--- Comment #10 from bonzini at gnu dot org 2009-02-05 09:01 ---
I get some SCCs that have 1500+ values in them. That is quite expensive to
maintain.
345,334,000 iterative_hash_hashval_t
199,259,509 ???:???
151,133,289 iterative_hash_expr
111,911,577 bitmap_bit_p
96,901,657
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-02-05 09:14
---
I get
tree PRE : 1.57 (50%) usr 0.09 (29%) sys 1.68 (29%) wall
295 kB ( 3%) ggc
on current trunk (w/o checking). While 50% is quite high the absolute time
is low. Though I wonder why
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-02-05 09:42
---
Fixed. I'm going to do a backport to the 4.3 branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from aph at gcc dot gnu dot org 2009-02-05 09:42 ---
.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
gcc 4.3 branch needs this patch:
http://article.gmane.org/gmane.comp.java.classpath.patches/12149
--
Summary: Deadlock in AWT
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-05 10:10 ---
Can you see which revision caused this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from s dot neumann at phase-zero dot de 2009-02-05 10:06
---
I have applied this patch and the problem is gone. Thanks a lot.
--
s dot neumann at phase-zero dot de changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-02-05 11:10
---
Subject: Bug 39100
Author: rguenth
Date: Thu Feb 5 11:10:02 2009
New Revision: 143961
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143961
Log:
2009-02-05 Daniel Berlin dber...@dberlin.org
Compiling the the most trivial program with GCC (using the SGI linker) results
in warnings :
$ gcc -o hello hello.c
ld: WARNING 84: /usr/local/gnu/lib/gcc/mips-sgi-irix5.3/4.3.3/libgcc.a is not
used for resolving any symbol.
ld: WARNING 84: /usr/local/gnu/lib/gcc/mips-sgi-irix5.3/4.3.3/libgcc.a
--- Comment #1 from J dot J dot vanderHeijden at gmail dot com 2009-02-05
11:36 ---
Created an attachment (id=17244)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17244action=view)
Call GAS with -mdebug when using stabs, do not emit .stabd directives
With this patch applied,
--- Comment #13 from rguenther at suse dot de 2009-02-05 10:31 ---
Subject: Re: [4.3/4.4 Regression] -fprofile-generate
= huge SCCs for PRE
On Thu, 5 Feb 2009, bonzini at gnu dot org wrote:
--- Comment #12 from bonzini at gnu dot org 2009-02-05 10:26 ---
FRE is not a
--- Comment #5 from jsm28 at gcc dot gnu dot org 2009-02-05 12:14 ---
Subject: Bug 35435
Author: jsm28
Date: Thu Feb 5 12:13:52 2009
New Revision: 143963
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143963
Log:
PR c/35435
* c-common.c
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-02-05 12:18 ---
Fixed for 4.4.0 and 4.3.4. I don't plan to work on a backport to 4.2.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from paolo dot carlini at oracle dot com 2009-02-05 12:48
---
Created an attachment (id=17246)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17246action=view)
draft, showing that the missing NULL_TREEs are indeed an issue
--
--- Comment #19 from paolo dot carlini at oracle dot com 2009-02-05 12:47
---
Indeed, in my experiments the problem seems due to build_min_nt not passing
NULL_TREEs as called by build_x_binary_op. The patch I'm going to attach then
works, in the sense that the testcase compiles (and
--- Comment #1 from J dot J dot vanderHeijden at gmail dot com 2009-02-05
11:55 ---
Created an attachment (id=17245)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17245action=view)
Fix unnecessary wanings about libgcc.a from SGI linker
This trivial patch assumes the patch for
extern C void abort ();
struct A
{
A (bool x = true);
};
class B
{
virtual bool bar (A , int) const =0;
};
class C : virtual public B
{
};
struct D : virtual public B
{
bool bar (A , int) const;
};
template int N
struct E : public D
{
bool bar (A x, int y) const
{
return baz().bar
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.4.0
--- Comment #12 from bonzini at gnu dot org 2009-02-05 10:26 ---
FRE is not a problem because all the time (93%) is spent computing ANTIC; of
this, half is phi_translate and the other half is bitmap_set operations.
I get a relatively good (15%) improvement from
Index: tree-ssa-sccvn.c
--- Comment #14 from bonzini at gnu dot org 2009-02-05 13:02 ---
20% of PRE time is spent in qsort via sorted_array_from_bitmap_set. Rewriting
it like this makes it a bit faster (it shaves 12% more of PRE time):
FOR_EACH_VALUE_ID_IN_SET (set, i, bi)
{
/* The number of
On IRIX 5.3, stabs debug info is embedded in ECOFF. Beginning with gas 2.13,
-mdebug must be passed to correctly handle COFF debugging info. GCC does not do
this.
The result is a lot of stabs related failures:
http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02896.html
A possible solution is to
--- Comment #17 from rguenth at gcc dot gnu dot org 2009-02-05 13:37
---
Testing for fork as well doesn't fix it either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38977
configuring libstdc++ in an i686-pc-linux-gnu-i686-pc-mingw32 crosscompiler
fails with
checking for ld that supports -Wl,--gc-sections... configure: error: Link tests
are not allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libstdc++-v3] Error 1
--
Summary: Building
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-02-05 13:40
---
pre-allocating the VEC with some reasonable defaults (add some stats for this
testcase) should make it even more fast.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
--- Comment #2 from bero at arklinux dot org 2009-02-05 13:52 ---
A bit below the check for --gc-sections, GLIBCXX_CHECK_LINKER_FEATURES actually
checks for another linker feature in a way that doesn't break crosscompiling:
cxx_z_relo=`$LD -v --help 2/dev/null | grep z relro`
--- Comment #3 from bero at arklinux dot org 2009-02-05 13:58 ---
Created an attachment (id=17247)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17247action=view)
Proposed patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-05 14:09
---
But, isn't GLIBCXX_CHECK_LINKER_FEATURES called *only* when $GLIBCXX_IS_NATIVE?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-05 14:23 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
when configuring libgcc:
configure:2611: /home/falk/lto/build/./gcc/xgcc -B/home/falk/lto/build/./gcc/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/
-B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem
/usr/local/alphaev68-unknown-linux-gnu/include -isystem
struct N
{
private:
virtual ~N ();
};
N *
foo ()
{
return new N ();
}
used to compile until http://gcc.gnu.org/viewcvs?root=gccview=revrev=138355
Does it really need to have an accessible destructor if it is never deleted?
Dodji cited [basic.life]/4 which could mean this is valid.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39109
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-02-05 15:31
---
Some more details:
jobs.c: In function 'make_child':
jobs.c:4121: error: corrupted profile info: profile data is not flow-consistent
jobs.c:4121: error: corrupted profile info: number of executions for edge 10-11
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-05 15:36
---
Note the first snippet only triggers a warning with ICC / Comeau in strict
mode, the second one, compiles just fine...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36406
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-02-05 15:36
---
Relevant source snippet:
if (default_buffered_input != -1
(!async_p || default_buffered_input 0))
sync_buffered_stream (default_buffered_input);
if ((pid = fork ()) 0)
{
sys_error
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-05 15:55 ---
Created an attachment (id=17248)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17248action=view)
gcc44-pr39106.patch
Patch I'm going to bootstrap/regtest. The problem is that
cgraph_function_versioning copies
--- Comment #5 from bero at arklinux dot org 2009-02-05 15:56 ---
It does get called when building that i686-pc-linux-gnu - i686-pc-mingw32
crosscompiler -- but maybe the fact that it does indicates a bug elsewhere in
the build system
--
Revision 143939:
http://gcc.gnu.org/ml/gcc-cvs/2009-02/msg00105.html
caused miscompilation of the fortran compiler on ia64.
--
Summary: [4.4 Regression] Revision 143939 breaks bootstrap on
Linux/ia64
Product: gcc
Version: 4.4.0
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.4.0
--- Comment #1 from bonzini at gnu dot org 2009-02-05 16:28 ---
Can you please attach .i files for the fortran compiler? thanks
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #16 from bonzini at gnu dot org 2009-02-05 16:30 ---
Not much. The remaining compile-time hogs (~25%) are the pre_expr and
expr_pred_trans hash tables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35639
--- Comment #6 from r dot emrich at de dot tecosim dot com 2009-02-05
16:34 ---
(In reply to comment #5)
It does get called when building that i686-pc-linux-gnu - i686-pc-mingw32
crosscompiler -- but maybe the fact that it does indicates a bug elsewhere in
the build system
The
--- Comment #4 from bonzini at gnu dot org 2009-02-05 16:37 ---
Maybe a dup of 39110 -- try revision 143938.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39101
--- Comment #17 from dberlin at gcc dot gnu dot org 2009-02-05 16:41
---
Subject: Re: [4.3/4.4 Regression]
-fprofile-generate = huge SCCs for PRE
Ugh.
It might make sense to just replace the hash table implementation we
use with something better (simple power of 2, key-value
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-02-05
16:53 ---
Subject: Re: [4.4 Regression] Null pointer dereference in delay slot
Maybe a dup of 39110 -- try revision 143938.
I'm reconfirming, but I believe 143938 is ok. The problem
is present with 143939.
Dave
--- Comment #6 from bonzini at gnu dot org 2009-02-05 17:05 ---
That would indeed make it a dup. (I meant 143938 would be the last good
build).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39101
--- Comment #18 from dberlin at gcc dot gnu dot org 2009-02-05 17:43
---
Subject: Re: [4.3/4.4 Regression]
-fprofile-generate = huge SCCs for PRE
My hacking will seriously improve this, since it doesn't iterate over
pieces of the SCC that aren't changing (which often is most
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-05 17:49 ---
Program received signal SIGSEGV, Segmentation fault.
0x4006ac11 in gfc_check_interfaces (ns=0x602b05c0)
at /net/gnu-13/export/gnu/src/gcc/gcc/gcc/fortran/interface.c:1301
1301 switch
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-05 17:54 ---
Created an attachment (id=17249)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17249action=view)
Processed gcc/fortran/interface.c
This file is miscompiled with
-DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC
--- Comment #4 from bonzini at gnu dot org 2009-02-05 18:14 ---
*** Bug 39101 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from bonzini at gnu dot org 2009-02-05 18:14 ---
every strict alignment platform is broken.
*** This bug has been marked as a duplicate of 39110 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from aph at gcc dot gnu dot org 2009-02-05 18:18 ---
Created an attachment (id=17250)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17250action=view)
This should do it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38861
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-05 18:25 ---
Every strict alignment platform is broken.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #6 from bonzini at gnu dot org 2009-02-05 18:29 ---
Subject: Bug 39110
Author: bonzini
Date: Thu Feb 5 18:29:11 2009
New Revision: 143971
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143971
Log:
2009-02-05 Paolo Bonzini bonz...@gnu.org
PR
--- Comment #7 from bonzini at gnu dot org 2009-02-05 18:30 ---
patch committed, please close it as soon as you can confirm it is fixed.
--
bonzini at gnu dot org changed:
What|Removed |Added
On Solaris (and HPUX, other ...) Operating Systems the OS's Manufacturer
has their own Linker and recommends it be used for all linking.
The OpenSolaris default gcc supplied by Sun is:
# /usr/sfw/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/specs
Configured with:
--- Comment #1 from rob1weld at aol dot com 2009-02-05 18:36 ---
Correction (not careful enough with the cut-and-pasting):
The BUG is this:
If you compile gcc (using a gcc that uses Sun's Linker) to make a gcc
Toolchain that uses GNU's Linker the resulting gcc Toolchain will WORK
--- Comment #1 from laurent at guerby dot net 2009-02-05 19:25 ---
At rev 143942 on trunk the test now PASS
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00541.html
Executing on host: /mnt/LG500/home/guerby/build-143942/gcc/xgcc
-B/mnt/LG500/home/guerby/build-143942/gcc/
--- Comment #4 from rsa at us dot ibm dot com 2009-02-05 19:28 ---
This situation is a little bit muddy.
The position of the GLIBC maintainer is that requirements of the DFP Technical
Report will NEVER be added to GLIBC proper.
There is indeed currently a EGLIBC branch that is hosting
--- Comment #5 from rsa at us dot ibm dot com 2009-02-05 19:32 ---
From the libdfp math.h:
#if __STDC_WANT_DEC_FP__
# define DEC_INFINITY---__builtin_infd32()
# define DEC_NAN---(0.0DF * DEC_INFINITY)
# define HUGE_VAL_D64--__builtin_infd64()
# define HUGE_VAL_D64
--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-05 19:36
---
Yes. Please add details about the way you are setting up your build, give
people a chance to analyse it.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|4.3.0 |4.3.0 4.2.2
Target Milestone|--- |4.2.2
--- Comment #8 from bero at arklinux dot org 2009-02-05 20:14 ---
mkdir build
cd build
../configure --prefix=/usr --enable-static --enable-shared
--enable-fast-install --enable-c99 --enable-wchar_t --disable-gconf-peer
--target=i686-pc-mingw32 --enable-threads --enable-tls --with-tls
there is a class with a static const double member:
struct Foobar{
static const double var;
};
In one translation unit variable 'var' is defined and initialized as 1.0:
const double Foobar::var = 1.0;
When I access Foobar::var from another translation unit, it's value is 0
instead of 1.0 !
--- Comment #1 from alexey dot pushkin at mererand dot com 2009-02-05
20:27 ---
Created an attachment (id=17251)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17251action=view)
example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39112
--- Comment #8 from sje at cup dot hp dot com 2009-02-05 20:41 ---
My IA64 HP-UX bootstrap worked but my IA64 Linux bootstrap failed. When
building libgfortran the configure script tried to compile:
| program foo
| real, parameter :: bar = sin (12.34 / 2.5)
| end
--- Comment #9 from sje at cup dot hp dot com 2009-02-05 20:45 ---
Ack, my HP-UX and Linux builds were from two different source trees. The HP-UX
build that worked had the patch, the Linux build that failed did not have the
patch applied.
--
$gcc -O -Wextra -save-temps um3.c
$
um3.c
#include stdio.h
main()
{
char *J;
if (rand())
J = NULL;
printf(\ntest %s\n,J);
}
In this example, J could be used uninitialized but the compiler is not giving
that warning.
--
Summary: no warning that a variable may be used
--- Comment #10 from hjl dot tools at gmail dot com 2009-02-05 20:50
---
Linux/ia64 is OK now:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00543.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from dhill at clusterresources dot com 2009-02-05 20:51
---
Created an attachment (id=17252)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17252action=view)
.i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39113
--- Comment #2 from dhill at clusterresources dot com 2009-02-05 21:04
---
Here is the gcc -v output if that is helpful
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu12'
--- Comment #4 from spop at gcc dot gnu dot org 2009-02-05 21:45 ---
Subject: Bug 38953
Author: spop
Date: Thu Feb 5 21:44:57 2009
New Revision: 143972
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143972
Log:
2009-02-05 Sebastian Pop sebastian@amd.com
PR
I am using gcc 4.3.2 on a Linux x86_64 system, compiling *.f and *.f90
source code files with gfortran and using the -Wall option. I am getting
several warnings about unused dummy arguments in my code. The warnings are
valid, but I would like to suppress them because they are non-trivial to
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-05 21:54 ---
Subject: Bug 39106
Author: jakub
Date: Thu Feb 5 21:54:06 2009
New Revision: 143973
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143973
Log:
PR c++/39106
* cgraphunit.c
--- Comment #22 from pinskia at gcc dot gnu dot org 2009-02-05 21:57
---
*** Bug 39113 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-05 22:03 ---
5% is way below our release criteria threshold. P4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-05 21:57 ---
*** This bug has been marked as a duplicate of 18501 ***
*** This bug has been marked as a duplicate of 18501 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39077
gcc-4.1 -v -save-temps -msse2 gnu_bug_test.c
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--- Comment #1 from fabrice at mocana dot com 2009-02-05 22:05 ---
Created an attachment (id=17253)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17253action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39114
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-02-05 22:06 ---
Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-05 22:06 ---
eax(a[0])
That is not how you use constraints.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from alexey dot pushkin at mererand dot com 2009-02-05
22:08 ---
I believe you are right that it works on x86-linux,
the problem is it doesn't work on x86_64-windows :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39112
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P3 |P1
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-05 22:11 ---
Indeed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-02-05 22:13
---
I have a patch that works.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-05 22:17 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #23 from dhill at clusterresources dot com 2009-02-05 22:44
---
note that gcc version 3.2.3 correctly reports this warning
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-05 22:44 ---
Created an attachment (id=17254)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17254action=view)
reduced testcase
ICEs with -O2 -fno-tree-sra -g [-m32]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-02-05 22:48 ---
4.3 rejects the reduced testcase, the original works though.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
[The bug has been reported to the Debian BTS before:
http://bugs.debian.org/491137]
On s390, when using -O2, the attached code fails to throw an exception,
apparently because it does not re-evaluate the value of a variable. If the
variable is marked volatile, the code works as expected.
Best,
--- Comment #1 from mt at debian dot org 2009-02-05 23:01 ---
Created an attachment (id=17255)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17255action=view)
Not fully preprocessed source (includes string), compile with -DVOLATILE to
see the correct behaviour
--
--- Comment #2 from mt at debian dot org 2009-02-05 23:02 ---
Created an attachment (id=17256)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17256action=view)
Fully preprocessed source, compile with -O2 to see wrong behaviour
--
--- Comment #3 from mt at debian dot org 2009-02-05 23:04 ---
I should have added that this worked fine on 4.2 and was broken as of 4.3.1 at
least, earlier versions ( 4.2) untested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39115
--- Comment #3 from gnu_andrew at member dot fsf dot org 2009-02-05 23:09
---
Committed to GNU Classpath for 0.98.
CVSROOT:/sources/classpath
Module name:classpath
Changes by: Andrew John Hughes gnu_andrew 09/02/05 22:54:11
Modified files:
. :
--- Comment #10 from jakub at gcc dot gnu dot org 2009-02-05 23:39 ---
Just s/class ios_base/struct ios_base/ if you don't want 4.3 to reject it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39086
1 - 100 of 129 matches
Mail list logo
