The testcase from PR/2161:
#define ONE else if (0) { }
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOUHUN HUN HUN HUN HUN HUN HUN HUN HUN HUN
void foo()
{
if (0) { }
/* 11,000 else if's. */
THOU THOU THOU
--- Comment #32 from bonzini at gnu dot org 2009-07-15 06:05 ---
Yes, but I don't think it's infinite recursion. There are 11,000 else ifs in
the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
--- Comment #1 from bonzini at gnu dot org 2009-07-15 06:06 ---
A regression from when, well, there was no gimplifier.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #28 from burnus at gcc dot gnu dot org 2009-07-15 06:08 ---
In a quick scan of the patch, I note that the mpfr versions
of the simplifications weren't in the patch.
MPFR or MPC? The MPFR version should be there since years; the MPC version of
tan/sinh/cosh/tanh should be
#define ONE while (b())
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define HUN TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOUHUN HUN HUN HUN HUN HUN HUN HUN HUN HUN
void foo()
{
/* 11,000 nested whiles. */
THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-07-15 06:27
---
Thanks for the report, but we need a preprocessed testcase, see instructions at
http://gcc.gnu.org/bugs.html
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
Seen on Ubuntu Hardy. The -O2 result seems to be wrong. Also valgrind says
this about the -O2 compilation:
==6729== Conditional jump or move depends on uninitialised value(s)
==6729==at 0x84F22CB: solve_graph (tree-ssa-structalias.c:1570)
reg...@john-home:~/volatile/tmp174$ current-gcc
--- Comment #1 from steven at gcc dot gnu dot org 2009-07-15 07:21 ---
Ack.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.5.0
Known to work||4.3.0
Target
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40500
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40543
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40660
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40671
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40701
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40743
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
--- Comment #12 from steven at gcc dot gnu dot org 2009-07-15 07:30 ---
Tom, ping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39533
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40154
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40714
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40760
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 07:34 ---
Does seem to be a real issue, somewhere.
When trunk builds again, can you please give it a try too?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2009-07-15 07:36 ---
Paul, ping. This is almost 3 years with zero progress. If this is not an
issue in GCC 4.3 or later, then please close this PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28547
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 07:38 ---
The audit log for this PR is awfully quiet... Ping?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|sparc-unknown-linux-gnu |
GCC host triplet|sparc-unknown-linux-gnu |
GCC target
--- Comment #8 from burnus at gcc dot gnu dot org 2009-07-15 07:42 ---
I pointed this out to Paul already, but appearantly it is still stuck in his
whole-file patch queue.
Last incarnation of that patch (containing this fix) is at:
--- Comment #5 from dcb314 at hotmail dot com 2009-07-15 07:44 ---
(In reply to comment #4)
Fixed by the patch for PR debug/40705
I don't think so.
I tried the code on snapshot 20090709 and it still hangs.
By the way, how can a fix for a crash also fix a hang ?
I would have thought
--- Comment #1 from steven at gcc dot gnu dot org 2009-07-15 07:46 ---
Richi, this looks like it should go into your bucket of things to look at:
==6729== Conditional jump or move depends on uninitialised value(s)
==6729==at 0x84F22CB: solve_graph (tree-ssa-structalias.c:1570)
--
--- Comment #6 from photon at seznam dot cz 2009-07-15 07:50 ---
(In reply to comment #1)
Theses are not false warnings:
c = 1;
is really c = (int)c 1;
They are false warnings. The implicit conversion cannot alter the value.
--
--- Comment #6 from jason at redhat dot com 2009-07-15 07:51 ---
Subject: Re: [4.5 Regression] compiler hang for C++ code
On 07/15/2009 09:44 AM, dcb314 at hotmail dot com wrote:
I tried the code on snapshot 20090709 and it still hangs.
The patch wasn't in that snapshot; it wasn't
--- Comment #7 from photon at seznam dot cz 2009-07-15 07:54 ---
(In reply to comment #5)
Then, let's keep this around as an enhancement request.
I think this is actually a bug as the specification of the warning is: Warn for
implicit conversions that may alter a value. This is not
--- Comment #7 from carrot at google dot com 2009-07-15 08:07 ---
(In reply to comment #6)
Carrot, can you please try this test case with my patch
crossjump_abstract.diff from Bug 20070 applied?
I tried your patch. It did remove the redundant memory load. Following is the
output
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-07-15 08:13 ---
For:
c += (char) 1;
The value can change as you have a wrapping if c is CHAR_MAX.
Likewise with:
c += c2;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
--- Comment #1 from ubizjak at gmail dot com 2009-07-15 08:19 ---
Confirmed on i686 (x86_64 with -m32):
Program received signal SIGSEGV, Segmentation fault.
useless_type_conversion_p (outer_type=0x2ac18624b240, inner_type=0x0)
at ../../gcc-svn/trunk/gcc/tree-ssa.c:1003
1003 if
--- Comment #5 from sezeroz at gmail dot com 2009-07-15 08:19 ---
This bug may result in unreliable binary outputs, why is it targeted for fixing
in 4.4.2 and not in 4.4.1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40759
--- Comment #6 from jakub at gcc dot gnu dot org 2009-07-15 08:28 ---
I'm already bootstrapping/regtesting a fix, will post afterwards.
If it gets approved quickly, I'll include it in 4.4.1-rc1 I plan to roll today.
--
jakub at gcc dot gnu dot org changed:
What
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40747
--- Comment #17 from jakub at gcc dot gnu dot org 2009-07-15 08:32 ---
Retargetting to 4.4.2, this doesn't seem to get to resolution soon enough.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from janus at gcc dot gnu dot org 2009-07-15 08:41 ---
Subject: Bug 40743
Author: janus
Date: Wed Jul 15 08:41:29 2009
New Revision: 149662
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149662
Log:
2009-07-15 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #9 from janus at gcc dot gnu dot org 2009-07-15 08:47 ---
Fixed with r149662. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 09:25 ---
Subject: Bug 40753
Author: rguenth
Date: Wed Jul 15 09:25:34 2009
New Revision: 149664
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149664
Log:
2009-07-15 Richard Guenther rguent...@suse.de
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:34 ---
switch-conversion could try to handle this. Generally perfect hashing during
switch expansion is another thing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-15 09:37 ---
Confirmed. 4.2 reports
g++-4.2 -Wall t.C
t.C: In function const A a():
t.C:6: warning: control reaches end of non-void function
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-15 09:41 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #28 from burnus at gcc dot gnu dot org 2009-07-15 09:41 ---
(In reply to comment #24)
So maybe approach the question differently. Which element in an array of NaNs
is the smallest one and what is its value? If I pick any one element, its
value is NaN. It does not
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-07-15 09:43 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-15 09:44 ---
DF time on this testcase is already big, and the testcase has lots of function
calls which would explain the difference between targets (DF needs to track all
call-used/clobbered regs).
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40755
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--- Comment #8 from steven at gcc dot gnu dot org 2009-07-15 09:47 ---
That redundant move has to be a separate issue, indeed. I would expect the
register allocator to coalesce those registers.
I hadn't expected this. I thought the result would be just the removal of the
redundant
--- Comment #7 from jakub at gcc dot gnu dot org 2009-07-15 09:48 ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00842.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:53 ---
Program received signal SIGSEGV, Segmentation fault.
0x086e621a in useless_type_conversion_p (outer_type=0xb7cd43f0, inner_type=0x0)
at /home/richard/src/trunk/gcc/tree-ssa.c:1003
1003 if (POINTER_TYPE_P
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 09:55 ---
I would also recommend to try a newer snapshot from the gcc 4.4 release branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 09:56 ---
Is it the nesting of loops or really the number of function calls that is
important?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 10:09 ---
Confirmed. With -O2 -fno-inline we get in .optimized
func_36 ()
{
bb 2:
g_10 = 1;
func_53 ();
g_64 = 1;
return 1;
FRE does this. I'll check.
--
rguenth at gcc dot gnu dot org changed:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-15 10:17 ---
We have wrong SSA form before FRE:
;; Function func_36 (func_36)
func_36 ()
{
uint8_t g_64.8;
int64_t g_10.5;
bb 2:
# .MEM_17 = VDEF .MEM_16(D)
g_10 = 1;
# VUSE .MEM_17
g_10.5_2 = g_10;
if (g_10.5_2
--- Comment #8 from jakub at gcc dot gnu dot org 2009-07-15 10:18 ---
Subject: Bug 40747
Author: jakub
Date: Wed Jul 15 10:17:54 2009
New Revision: 149675
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149675
Log:
PR middle-end/40747
* fold-const.c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot
|dot org
--- Comment #12 from rearnsha at gcc dot gnu dot org 2009-07-15 10:31
---
Fixed with:
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00848.html
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-15 10:54 ---
For me
./xgcc -B. -shared ice.o -flto
takes ages because iterative_hash_gimple_type seems to be exponential in time!?
Called from gimple_register_type on
pointer_type 0xb7becb60
type function_type
--- Comment #3 from bonzini at gnu dot org 2009-07-15 11:11 ---
do while does not have the same behavior, so the loop shape is important.
the following is as bad and does not have function calls.
#define ONE while (x-- y)
#define TEN ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
--- Comment #7 from reichelt at gcc dot gnu dot org 2009-07-15 11:19
---
This is really fixed.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2009-07-15 11:23 ---
Subject: Bug 40747
Author: jakub
Date: Wed Jul 15 11:23:22 2009
New Revision: 149681
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149681
Log:
PR middle-end/40747
* fold-const.c
--- Comment #10 from jakub at gcc dot gnu dot org 2009-07-15 11:26 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Without -O3, code works as expected.
With -O3, varible is reset to 0.
Also, probably index overflow.
Where goes the .cc or .i ??
Bugzilla: Horribly scarce user interface!
g++ -v outputs:
Es werden eingebaute Spezifikationen verwendet.
Ziel: i486-linux-gnu
Konfiguriert mit: ../src/configure -v
--- Comment #3 from hubicka at ucw dot cz 2009-07-15 11:29 ---
Subject: Re: [4.5 Regression] segfault in useless_type_conversion_p
I hope that patch for PR40676 should cure those problems. I am just on
the way to Prague, but I will try to look into it tomorrow.
Honza
--
--- Comment #18 from ich at az2000 dot de 2009-07-15 11:31 ---
Will this workaround-patch be included in 4.4.1? Because otherwise the whole
4.4.1 release will be pretty much useless for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40321
--- Comment #1 from vielhaber at gmail dot com 2009-07-15 11:31 ---
Created an attachment (id=18198)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18198action=view)
The .i with -O3 on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40764
--- Comment #2 from vielhaber at gmail dot com 2009-07-15 11:32 ---
Created an attachment (id=18199)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18199action=view)
The .i file without optimization
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40764
--- Comment #19 from rguenther at suse dot de 2009-07-15 11:33 ---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
On Wed, 15 Jul 2009, ich at az2000 dot de wrote:
--- Comment #18 from ich at az2000 dot de 2009-07-15 11:31
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-languages=c --enable-lto
--disable-bootstrap
Thread model: posix
gcc version 4.5.0 20090714 (experimental) [lto revision 149644] (lto merged
with
--- Comment #3 from vielhaber at gmail dot com 2009-07-15 11:43 ---
Created an attachment (id=18200)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18200action=view)
The C++ source with comments.
Comments in lines 180 describe the erroneous behaviour.
Output line starting with 1356
--- Comment #1 from rmansfield at qnx dot com 2009-07-15 11:44 ---
Created an attachment (id=18201)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18201action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40765
--- Comment #5 from dje at gcc dot gnu dot org 2009-07-15 12:38 ---
The patch seems reasonable, but it exposes a latent bug in Nathan's mmultiple
patch that was not tested because of this bug.
This patch should have been tested and posted to the GCC mailinglist
referencing this PR.
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-07-15 12:42
---
One thing that is odd is that the maximal set misses a_1 and b_2 (but it does
have the default defs). Adding PHI arguments to the maximal set fixes this
PR...
Index: tree-ssa-pre.c
--- Comment #6 from dje at gcc dot gnu dot org 2009-07-15 12:50 ---
The fix for this actually is more involved. Nathan had a patch last October
which exposed similar bootstrap problems. He posted a revised patch
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01103.html
--
dje at
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-07-15 12:54
---
Correction - only b_2 is missing from the maximal set, a_1 is there because
it is used in non-PHI nodes. The fix indeed looks quite obvious to me now ...
For reference, here is the function before PRE again:
bb
--- Comment #3 from rmansfield at qnx dot com 2009-07-15 12:58 ---
I was able to the ICE using different source. Same usage:
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. ice2.i -O -flto -c
r...@ryan:~/gcc/lto/x86-build/gcc$ ./xgcc -B. ice2.o -flto -shared
In file included from :935:0:
--- Comment #4 from rmansfield at qnx dot com 2009-07-15 13:02 ---
Created an attachment (id=18202)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18202action=view)
2nd preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40758
--- Comment #4 from mikpe at it dot uu dot se 2009-07-15 13:15 ---
mpfr-2.4.1 compiles and tests Ok for me on an Ultra5 (USIIi) running
sparc64-linux, with gmp-4.2.4 (compiled by gcc-4.3.4) and gcc 4.3.4, 4.4.0, and
4.4.1 20090630.
I don't have a T2, but could possibly do some tests on
--- Comment #6 from joerg dot richter at pdv-fs dot de 2009-07-15 13:15
---
I stumpled across the same problem recently.
Executable references both libstdc++.so and libgcc_s.so.
libstdc++.so references libgcc_s.so.
Both executable dependencies will be correctly resolved (due to
--- Comment #22 from dberlin at gcc dot gnu dot org 2009-07-15 13:37
---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
Phi uses can be in the maximum set as long as they are not phi's themselves.
There is a comment above
--- Comment #23 from dberlin at gcc dot gnu dot org 2009-07-15 13:46
---
Subject: Re: [4.4/4.5 Regression] internal
compiler error: in compute_antic, at tree-ssa-pre.c:2501
a_1 shouldn't be in the maximal set. If it is, that's a bug.
The history here:
We didn't use to have
I did a quick scan for misuse of pointer values after failed
asprintf-style function uses and spotted a few. Here's a patch
for one of them:
[this patch is relative to just-updated trunk]
From 1f71a26ec38860d863ca751aef049d314a4f34b4 Mon Sep 17 00:00:00 2001
From: Jim Meyering
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #1 from linuxl4 at sohu dot com 2009-07-15 15:49 ---
My server is an atom330/gentoo
gfortran -v
GNU Fortran (GCC) 4.5.0 20090715 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.
gfortran 1.f90; time ./a.out
4.28173363E+09
real120m30.599s
user
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-15 15:55 ---
What is the timing when adding -O3 to the command line. GCC defaults to no
optimizations turned on. This is unlike ifort which defaults to having
optimizations turned on.
--
--- Comment #3 from ro at gcc dot gnu dot org 2009-07-15 16:03 ---
I don't think this is a duplicate: even if the bootstrap compiler is gcc, it
may still lack visibility support (as it did on Solaris until recently or on
IRIX where ld/rld lack the necessary support). At least, this
--- Comment #3 from ro at gcc dot gnu dot org 2009-07-15 16:05 ---
Sorry, my Comment #1 was directed at the wrong bug. mkdtemp is still used
unconditionally, and this would e.g. affect Solaris 10 where it is missing.
--
ro at gcc dot gnu dot org changed:
What
--- Comment #13 from bonzini at gnu dot org 2009-07-15 16:20 ---
For the record, it's actually somewhat related to PR39726 (a m68k
pessimization), not PR39715. However, because of the way combine canonicalizes
the resulting expression, the patch for that bug does not fix the testcase.
--- Comment #1 from ro at gcc dot gnu dot org 2009-07-15 16:51 ---
I've rebuilt lto1 with just -g and re-run it under gdb. This is not a
NULL-pointer
dereference, but an improperly aligned pointer:
Starting program:
/vol/gccsrc/obj/gcc-lto-20090709/11-gcc/gcc/testsuite/g++/lto1 -quiet
--- Comment #11 from photon at seznam dot cz 2009-07-15 16:55 ---
(In reply to comment #8)
For:
c += (char) 1;
The value can change as you have a wrapping if c is CHAR_MAX.
Likewise with:
c += c2;
The value cannot change even if an overflow occurs.
{
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-07-15 16:58
---
Except it does alter its value from 0x100 to 0x00 :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-07-15 17:00
---
Or rather from SCHAR_MAX + 1 to SCHAR_MIN :). Since it is 0x7F + 1 ==
(int)0x80. So we have a negative value now from a positive value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752
1 - 100 of 124 matches
Mail list logo
