--- Comment #3 from pault at gcc dot gnu dot org 2006-04-23 06:08 ---
Fixed if 24406 has really gone away.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #17 from pault at gcc dot gnu dot org 2006-04-23 06:07 ---
This has been dealt with, has it not?
I have marked it as fixed - if I am wrong, please unfix it!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pault at gcc dot gnu dot org 2006-04-23 06:03 ---
This looks to be fixable at trans-intrinsic.c(gfc_conv_intrinsic_len), here a
special switch branch for constructors is needed.
I will make it so.
Paul
--
pault at gcc dot gnu dot org changed:
What
--- Comment #9 from pault at gcc dot gnu dot org 2006-04-23 05:44 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2006-04-23 05:44 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-23 05:43 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2006-04-23 05:42 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2006-04-23 05:42 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2006-04-23 05:41 ---
Fixed on trunk but not fixable on 4.1 because of divergences between the trees.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from pault at gcc dot gnu dot org 2006-04-23 05:39 ---
Fixed on trunk but,sadly, not on 4.1 because divergences have become too great.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from pault at gcc dot gnu dot org 2006-04-23 05:38 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pault at gcc dot gnu dot org 2006-04-23 05:37 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pault at gcc dot gnu dot org 2006-04-23 05:33 ---
Subject: Bug 25597
Author: pault
Date: Sun Apr 23 05:33:16 2006
New Revision: 113191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191
Log:
2006-04-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-23 05:33 ---
Subject: Bug 27124
Author: pault
Date: Sun Apr 23 05:33:16 2006
New Revision: 113191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191
Log:
2006-04-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2006-04-23 05:33 ---
Subject: Bug 26834
Author: pault
Date: Sun Apr 23 05:33:16 2006
New Revision: 113191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191
Log:
2006-04-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #4 from pault at gcc dot gnu dot org 2006-04-23 05:33 ---
Subject: Bug 27089
Author: pault
Date: Sun Apr 23 05:33:16 2006
New Revision: 113191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191
Log:
2006-04-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from pault at gcc dot gnu dot org 2006-04-23 05:33 ---
Subject: Bug 26787
Author: pault
Date: Sun Apr 23 05:33:16 2006
New Revision: 113191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191
Log:
2006-04-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #9 from pault at gcc dot gnu dot org 2006-04-23 05:33 ---
Subject: Bug 26822
Author: pault
Date: Sun Apr 23 05:33:16 2006
New Revision: 113191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191
Log:
2006-04-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #8 from pault at gcc dot gnu dot org 2006-04-23 05:33 ---
Subject: Bug 25669
Author: pault
Date: Sun Apr 23 05:33:16 2006
New Revision: 113191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191
Log:
2006-04-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #4 from pault at gcc dot gnu dot org 2006-04-23 05:33 ---
Subject: Bug 27122
Author: pault
Date: Sun Apr 23 05:33:16 2006
New Revision: 113191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191
Log:
2006-04-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pault at gcc dot gnu dot org 2006-04-23 05:33 ---
Subject: Bug 27113
Author: pault
Date: Sun Apr 23 05:33:16 2006
New Revision: 113191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191
Log:
2006-04-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #14 from pault at gcc dot gnu dot org 2006-04-23 05:33 ---
Subject: Bug 18803
Author: pault
Date: Sun Apr 23 05:33:16 2006
New Revision: 113191
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113191
Log:
2006-04-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-04-23 03:16
---
Generating the explicit masking operations in the front end seems to be safe,
but suboptimal. The middle-end will not optimize code like:
struct A {int i : 3; };
struct A a;
int f() { return a.i > 3; } //
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-23 02:24 ---
There is a patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00857.html
But I feel it is the wrong approach in that the driver now needs to know about
the options which is semi wrong. There must be an easi
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-23 02:19 ---
Fixed in 4.2.0, by an import of the new libltdl from libtool.
2006-03-28 Tom Tromey <[EMAIL PROTECTED]>
PR libgcj/26441:
* Merged libltdl 1.5.16 from vendor branch.
The patch mentioned below is n
--- Comment #1 from greenrd at gcc dot gnu dot org 2006-04-23 02:14 ---
Looks like ltdl's configure script is setting the wrong default search path on
x86_64.
I found this patch that might help:
http://dev.gentoo.org/~halcy0n/patches/patch/10_all_gcc4-libltdl-multilib.patch
--
htt
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-23 02:12
---
A couple of points. One GCC follows the ABI and with changes like regparm it
still follows a defined ABI.
There are a couple more cases than just sibcalling which will fail even now.
Reload (and future RAs) uses
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-23 02:09 ---
fstp(%edi)
fstp4(%edi)
fstp(%esi)
fstp4(%esi)
Those are the instructions which are failing.
So please attach the preprocessed source file.
--
pinskia at gcc dot g
--- Comment #10 from acahalan at gmail dot com 2006-04-23 02:09 ---
A couple quotes from Linus on the linux-kernel mailing list, in response to the
idea (expressed in comment #3 above) of having the assembly set up the normal
stack:
-- 1 --
Sure, we could just do a slower system call e
--- Comment #9 from acahalan at gmail dot com 2006-04-23 02:05 ---
Actually, there is no desire to prevent sibling calls. That's a hack. Sibling
calls are desirable as long as they don't muck with the incoming argument
stack.
Using -fno-sibcalling is definitely out of the question. It w
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-04-23 02:05
---
Subject: Bug 20257
Author: jvdelisle
Date: Sun Apr 23 02:04:58 2006
New Revision: 113190
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113190
Log:
2006-04-22 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-23 02:02 ---
Second where is the preprocessed source file?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27264
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-23 02:01 ---
This should be reported to Apple since this is Apple's GCC and not the FSF and
x86-darwin is not support for FSF GCC until 4.2.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from patchapp at dberlin dot org 2006-04-23 01:15 ---
Subject: Bug number PR c++/8171
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00861.html
--
http://gcc.gnu.org/bugzill
On x86_64, the following test produces an error:
public class TestAWT {
public static void main (String args[]) {
new java.awt.Frame();
}
}
Exception in thread "main" java.awt.AWTError: Cannot load AWT toolkit:
gnu.java.awt.peer.gtk.GtkToolkit
at java.awt.Toolki
Compiling FFTW 3.1.1 on a new Intel Mac, gcc 4.0.1 generates unassemblable code
for several of the main files, e.g. the following,
[stp:/Users/stp/Code/MacLibs/fftw-3.1.1/kernel] make trig.lo
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../simd -O3 -fomit-frame-pointer
-malign-double -fstrict-aliasing -ffa
--- Comment #8 from joshudson at gmail dot com 2006-04-22 23:28 ---
The code that calls all the "asmlinkage" calls does so through a vector table.
Consequently, it does not know how many arguments it calls. However, the
arguments live in particular registers when called, so it just pushe
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot
|dot org
Target: armv5te-linux-gnueabi
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/armv5te-linux-gnueabi/include/c++/4.1.0
--pro
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-22 21:37 ---
Bootstrapped and tested on x86_64-unknown-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27236
--- Comment #7 from schwab at suse dot de 2006-04-22 21:09 ---
It's called __attribute__((syscall_linkage)) on ia64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27234
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-22 20:58 ---
FastJar has since been removed from GCC's sources
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-22 20:57 ---
FastJar has since been removed from GCC's sources
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-22 20:57 ---
FastJar has since been removed from GCC's sources
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-22 20:56 ---
FastJar has since been removed from GCC's sources
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-22 20:55 ---
FastJar has since been removed from GCC's sources
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-22 20:52 ---
This is not really that useful, the problem comes down to if the user messes up
(which is 90% of the time anyways), they get a crash in their program and blame
GCC. So exosing stuff like this is crazy to do really.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-22 20:52 ---
This is not really that useful, the problem comes down to if the user messes up
(which is 90% of the time anyways), they get a crash in their program and blame
GCC. So exosing stuff like this is crazy to do really.
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-04-22 20:44
---
There is no way non PODs will ever work with shared memory. This is why they
are called non-PODs and they never should be shared outside of the program. In
fact non-PODs cannot be passed via var-args or even look
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-22 20:42 ---
Also strings have two different phases which is why the handing is different
IIRC. You should point out in the standard why you think this behavior is
wrong really before filing a bug.
--
http://gcc.gnu.org/bug
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-22 20:39 ---
THis is not a libgfortran bug but rather a bug in the libm on your system. The
libgfortran version of csqrt was fixed and works. Glibc's version was also
fixed at the same time.
--
pinskia at gcc dot gnu dot or
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-22 20:36 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00825.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-22 20:35 ---
So you want __attribute__((incoming_stack_frame_read_only)).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--- Comment #4 from tim at yeung dot com 2006-04-22 20:33 ---
Thank you. We will upgrade to 4.1.x
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27258
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-22 20:27 ---
I don't know if it is that bogus. First it assumes if it is not defiend, it is
a normal member function and not a templated member function which seems
reasonable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-22 20:24 ---
Use -fno-sibcalling if you cannot use this optimization because you are
violating the ABI really and since GCC depends on the ABI being followed,
there is almost nothing GCC can do.
If the kernel wants to do tricks
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-22 20:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #8 from fche at redhat dot com 2006-04-22 20:10 ---
The problem is triggered for the synthetic _gcov_* type global variables that
the profiling code emits. mudflap tries to register them with libmudflap.
--
fche at redhat dot com changed:
What|Removed
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-04-22 20:05 ---
Bootstrapped and tested on x86_64-unknown-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27218
--- Comment #1 from kalle at enrogue dot com 2006-04-22 20:02 ---
Created an attachment (id=11316)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11316&action=view)
Demonstrates the bug.
This attachment contains:
- CREATION (a bash-script which contains the 2 commands used in gener
Parsing a Document instance from file, setting the "id" attribute of an element
on that instance to some value, and then flagging the "id" attribute for that
element to be the IdAttribute using (Element).setIdAttribute("id", true) does
not seem to work.
Retrieving that very same element via getEle
--- Comment #12 from pcarlini at suse dot de 2006-04-22 19:54 ---
*** Bug 27258 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2006-04-22 19:54 ---
*** This bug has been marked as a duplicate of 26123 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2006-04-22 19:47 ---
Indeed, I can't reproduce with 4.1.0, 4.1.1 pre and mainline. The problem seems
still present in 4_0-branch, but frankly I have no idea which patch fixed it, I
seriously doubt was a libstdc++ patch...
--
http://gcc.gnu
--- Comment #10 from csm at gnu dot org 2006-04-22 19:26 ---
I don't know; a confusing internal structure doesn't impact anyone trying to
use Classpath with their application, they'll just want their program to work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27228
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-22 19:19 ---
One more inliner fix:
Index: tree-inline.c
===
--- tree-inline.c (revision 112997)
+++ tree-inline.c (working copy)
@@ -590,6 +590,7 @@ copy
--- Comment #9 from david at jpackage dot org 2006-04-22 19:18 ---
Maybe we can consider moving these class before closing this bug? I am also
wondering why the are Diffie Hellman classes in the `sig' package. DH is not a
digital signature algorithm, unless we are accounting for the obvi
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-22 19:07 ---
ipa-pure-const is just a symtom of the problem.
TREE_THIS_VOLATILE is not set on the INDIRECT_REF.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-22 18:36 ---
Confirmed. Note I was talking about the internal representation in that, the
instructions are not modeled correctly.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |A
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-22 18:33 ---
*** Bug 27224 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-22 18:33 ---
As a dup of bug 15145.
*** This bug has been marked as a duplicate of 15145 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-22 18:33 ---
(In reply to comment #4)
> One has still to use the -Wsequence-point, in C++?
> It would be good if there was no need to explicitly use such a switch...
For 4.1 (and maybe 4.0 I forget), -Wall includes -Wsequence-po
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-22 18:29 ---
This patch fixes it for me (but I don't have time right now to test it):
Index: tree-inline.c
===
--- tree-inline.c (revision 112997)
+++ tree-inl
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-22 18:13 ---
The inliner is not producing the NOP_EXPR at all
but instead if comes from build_fold_addr_expr_with_type
And:
if (TREE_TYPE (t) != ptrtype)
t = build1 (NOP_EXPR, ptrtype, t);
Here the types don't matc
--- Comment #8 from cvs-commit at developer dot classpath dot org
2006-04-22 18:11 ---
Subject: Bug 27228
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Casey Marshall <[EMAIL PROTECTED]> 06/04/22 17:57:19
Modified files:
.
--- Comment #4 from fche at gcc dot gnu dot org 2006-04-22 16:22 ---
Subject: Bug 26864
Author: fche
Date: Sat Apr 22 16:22:54 2006
New Revision: 113179
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113179
Log:
2006-04-22 Frank Ch. Eigler <[EMAIL PROTECTED]>
PR libmu
--- Comment #3 from fche at redhat dot com 2006-04-22 16:22 ---
patch committed to mainline
--
fche at redhat dot com changed:
What|Removed |Added
Status|ASSI
--- Comment #5 from pault at gcc dot gnu dot org 2006-04-22 15:49 ---
trunk and 4.1 have diverged too far, especially in characters, for the fix to
work on 4.1. I started trying to make up the difference but it is just too
much to be worthwhile.
I am marking this as fixed on trunk.
Pa
--- Comment #5 from pault at gcc dot gnu dot org 2006-04-22 15:47 ---
trunk and 4.1 have diverged too far, especially in characters, for the fix to
work on 4.1. I started trying to make up the difference but it is just too
much to be worthwhile.
I am marking this as fixed on trunk.
Pa
--- Comment #2 from fche at redhat dot com 2006-04-22 15:42 ---
Indeed, -fmudflapth used to imply -fmudflap, but something broke that
association. As a workaround, the test case works if both -fmudflap and
-fmudflapth are specified.
--
fche at redhat dot com changed:
Wha
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-22 15:41 ---
*** Bug 27261 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-22 15:41 ---
*** This bug has been marked as a duplicate of 19020 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-22 15:37 ---
Use -lm when linking the math functions have been in libm for 20 or more years
now on UNIX.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from fche at redhat dot com 2006-04-22 15:37 ---
(In reply to comment #3)
>
> I investigated further and found that it is not the size of the memory that
> matters. The problem seems to be that we also use fortran code, which is not
> mudflapped, but needs the gfortran li
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-22 15:35 ---
This is signed int overflow being undefined, in fact I should I know because I
was the one who write the patch to optimize this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-04-22 15:34 ---
GCC is not going to implement by default a non standard version of C++ (well
some extensions are on by default but those are usually more defined than
this).
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from hjl at lucon dot org 2006-04-22 15:33 ---
[EMAIL PROTECTED] stage1-gcc]$ ./xgcc -B./ -c -g -v /tmp/x.s -gstabs -gdwarf-2
Reading specs from ./specs
Target: x86_64-unknown-linux-gnu
Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure
--enable-clocale=gnu --
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-22 15:33 ---
Can you try a 4.0.x or 4.1.0 as 3.4.x is no longer being updated and I think
this fixed already.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pluto at agmk dot net 2006-04-22 14:07 ---
of course command line shoud be: $ g++ signed_overflow_3.cpp -ftrapv ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27261
#include
int main()
{
int x = 0x8000;
std::printf( "%08x\n", x );
x *= 2;
std::printf( "%08x\n", x );
// still here?
std::puts( "-ftrapv doesn't work :(" );
return 0;
}
$ g++ signed_overflow_3.cpp; ./a.out; echo $?
8000
-ftr
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-04-22 13:19 ---
Testcase also fails on mainline x86_64 with -Os.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from aj at gcc dot gnu dot org 2006-04-22 13:12 ---
The original ICE happens on PPC and IA64. I have not checked whether the
reduced testcase ICEs on both.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27260
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-04-22 13:08 ---
The problem is we expand the value in QI mode because of
val = builtin_save_expr (val);
len = builtin_save_expr (len);
len_rtx = expand_expr (len, NULL_RTX, VOIDmode, 0);
dest_mem = get_memo
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-04-22 11:15 ---
More reduced testcase:
void cmdModuleTrace(int i)
{
char *cmd_table;
cmd_table = (char *) __builtin_malloc( 3);
__builtin_memset (cmd_table, !i, 3);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-22 11:04 ---
Testcase:
typedef unsigned int size_t;
typedef void *ClientData;
typedef struct Tcl_Interp { } Tcl_Interp;
extern char *addRE;
extern char *rmRE;
extern char *aproposRE;
typedef struct _mod_trace { char **re_ptr; }
6750 gcc_assert (GET_MODE (DECL_RTL (exp)) == pmode);
(gdb) print pmode
$1 = SImode
(gdb) call debug_tree(exp)
unit size
align 32 symtab 0 alias set -1 precision 32 min max
pointer_to_this >
used ignored SI file cmdTrace.min.i line 28 size unit size
1 - 100 of 109 matches
Mail list logo
