--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 06:17 ---
We should never had needed resize_phi_node inside PRE and resize_phi_node also
does an exact replacement so that means you are keeping a reference to the old
PHI node when adding an edge which is wrong.
--
pinski
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-22 06:10 ---
What are you trying to do?
It seems like you are using the API wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28798
If a phi node has been resized using resize_phi_node, it may later be attempted
to be removed by remove_dead_inserted_code using remove_phi_node, as the old
phi node will be present in inserted_exprs, yet the phi node will not be in the
chain of phi nodes for its original basic block.
I believe th
--- Comment #3 from kurkov at gorodok dot net 2006-08-22 05:52 ---
(In reply to comment #1)
Sorry for space and unsigned int issues, I should just correct compare files
for my test.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28797
--- Comment #1 from pault at gcc dot gnu dot org 2006-08-22 05:30 ---
> This problem was not present a few days ago, and it is quite elusive. Even
> adding or removing a few "!innocent" lines can change the error message,
> e.g. to something like
This is my doing, for which I apologise.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 05:26 ---
(In reply to comment #1)
> The double ones are weird, maybe we should print out the C99 hex float
> instead,
> there is a bug about this before too.
See PR 13045, there is most likely more discussion about this.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-22 05:21 ---
_Z1fA37_iPS_ -> f(int [37], int (*) [37]), should be: f(int[37], int (*) [37])
Isn't that just a space?
_Z1fILi2EEvRAplplT_Li3ELi1E_i -> void f<2>(int (&) [((2) + (3)) + (1)]), should
be: void f<2>(int (&) [((2)+(3)
I used a simple program which calls __cxa_demangle function. These mangled
names were demangled wrong:
_Z1fA37_iPS_ -> f(int [37], int (*) [37]), should be: f(int[37], int (*) [37])
_Z1fILi2EEvRAplplT_Li3ELi1E_i -> void f<2>(int (&) [((2) + (3)) + (1)]), should
be: void f<2>(int (&) [((2)+(3))+(1)]
--- Comment #12 from iano at apple dot com 2006-08-22 02:05 ---
"That however is not a clear bug.
-ffinite-math-only says that it assumes that there are no NaNs in the
input, and you violated that assumption, so the results you will get are
undefined. That is, gcc is allowed to give
--- Comment #11 from iano at apple dot com 2006-08-22 01:45 ---
About the manual wrongheadedness:
The major argument that I have heard from members of the GCC community (here
and elsewhere) against isnan() in its various forms correctly detecting NaN
when various hacky math flags are tu
--- Comment #10 from wilson at specifix dot com 2006-08-22 01:37 ---
Subject: Re: New: __builtin_nan() and __builtin_unordered()
inconsistent
iano at apple dot com wrote:
> Cloning due to closed minded bug screener:
> ^^^
> >ATTN: P
--- Comment #6 from geoffk at gcc dot gnu dot org 2006-08-22 01:20 ---
It turns out that if you compile this with 'gcc -mcpu=G4 -O -gdwarf-2' on
powerpc-darwin, this testcase works fine, but if you do it with '-mcpu=G3', it
fails; that is, it fails when V4SFmode is not supported by the t
--- Comment #9 from iano at apple dot com 2006-08-22 00:49 ---
Subject: Re: __builtin_nan() and __builtin_unordered() inconsistent
On Aug 21, 2006, at 5:42 PM, pinskia at physics dot uc dot edu wrote:
>
>
> --- Comment #8 from pinskia at physics dot uc dot edu
> 2006-08-22 00:
--- Comment #8 from pinskia at physics dot uc dot edu 2006-08-22 00:42
---
Subject: Re: __builtin_nan() and __builtin_unordered() inconsistent
> Which part of:
>
> __builtin_isunordered(nan,nan) = 1
> __builtin_isnan(nan) = 0
>
> is consistent?
Did you read what the options do beca
> Which part of:
>
> __builtin_isunordered(nan,nan) = 1
> __builtin_isnan(nan) = 0
>
> is consistent?
Did you read what the options do because it seems like you did not and you keep
on agruing that
it is inconsistent except for the fact this is way these options are done as it
just says "allow
--- Comment #7 from iano at apple dot com 2006-08-22 00:39 ---
Subject: Re: __builtin_nan() and __builtin_unordered() inconsistent
On Aug 21, 2006, at 5:34 PM, pinskia at gcc dot gnu dot org wrote:
>
>
> --- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-22
> 00:34 ---
--- Comment #9 from dannysmith at users dot sourceforge dot net 2006-08-22
00:37 ---
(In reply to comment #8)
> patch to prevent searching of configured path with relocated toolchain
Are you aware of this discussion
http://gcc.gnu.org/ml/gcc/2006-07/msg00313.html
and this alternative
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-22 00:37 ---
I should mention "We intend for a
library implementor to be able to simply #define each standard macro to its
built-in equivalent." is when not using -ffast-math and other options which
turn off IEEE/C99 complaincy w
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-22 00:34 ---
(In reply to comment #5)
> My first complaint is that the implementation is inconsistent.
It is not inconsistent really. Just the -funsafe-math-optimizations is done
incorrectly for x86 (see the other bug which I k
--- Comment #5 from iano at apple dot com 2006-08-22 00:31 ---
My first complaint is that the implementation is inconsistent.
My second complaint is that the fine manual is wrong headed, leading to hacky
math flags that are less useful than they otherwise would be.
--
iano at apple d
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-22 00:31 ---
For x86, -ffinite-math-only should turn off IEEE-FP compares which you will get
the correct results at -O0 which case this is really the problem mentioned in
PR 19116 which is about how unsafe-math-optimizations turn
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-22 00:28 ---
Allow optimizations for floating-point arithmetic that assume that
arguments and results are not NaNs or +-Infs.
So really this says allow for them, so really this is still not a bug as you
should read the fine
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-08-22 00:25
---
I will take this on,
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
A
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 00:24 ---
-mno-ieee-fp is specificially documented as that so that part is not a bug for
sure.
-funsafe-math-optimizations is already mentioned as a different bug.
So only builtin_isunordered without optimizations with -ffinit
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-22 00:23 ---
For:
gcc main3.c -Wall -ffinite-math-only -O2; ./a.out
I get:
__FINITE_MATH_ONLY__ = 1
__builtin_isunordered() = 0
__builtin_isnan() = 0
( != ) = 0
Note I removed the %f to look at the asm easiler.
--
pinskia a
--- Comment #6 from iano at apple dot com 2006-08-22 00:18 ---
Subject: Re: __builtin_isunordered() and __builtin_isnan() should behave
consistently
On Aug 21, 2006, at 5:16 PM, pinskia at gcc dot gnu dot org wrote:
>
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2006-0
Cloning due to closed minded bug screener:
^^^
>ATTN: PINKSI -- read comments attached at bottom <
^^^
I expect this is widespread over the entire GCC family, but at least with
Apple's GCC we h
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-08-22 00:16 ---
(In reply to comment #4)
> Pinski, look at the data I presented.
>
> You do not actually return 0 for these cases
Try it on a real processor instead of x86 which does funny stuff in the
back-end and does not fully
--- Comment #4 from iano at apple dot com 2006-08-22 00:14 ---
Pinski, look at the data I presented.
You do not actually return 0 for these cases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28795
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-22 00:13 ---
...with emphasis on the last sentence. I can not do this until you are
actually C99 compliant *all the time*. I have to support well written legacy
applications that expect this macro to work *all the time*.
For
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-22 00:10 ---
If you read the C99 standard and it mentions specificly about the case where
NaNs are not supported isnan should always return false.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28795
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-22 00:07 ---
First -ffinite-math-only results are correct.
Second this is fully a target issue.
Third the -funsafe-math-optimizations problem is PR 19116.
--
pinskia at gcc dot gnu dot org changed:
What|Remove
I expect this is widespread over the entire GCC family, but at least with
Apple's GCC we have a consistency problem with the meaning of various hacky
math flags in GCC and methods to detect NaN's in GCC:
[ollmia:/tmp] iano% cat main3.c
#include
#include
#include
int main( void )
{
unio
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-21 23:52 ---
For x86, there is no difference in the code gen for f and f1/f2, but for PPC32,
there is:
for f1/f2:
addic %r0,%r31,-1
subfe %r3,%r0,%r31
For f:
srawi %r3,%r31,31
subf %r3,%r31,%r3
--- Comment #17 from jconner at apple dot com 2006-08-21 23:43 ---
I can reduce the stack size in this example to ~13k by not invoking
mark_temp_addr_taken from expand_call (calls.c). This allows
compiler-generated temps used to store return values to share stack slots, even
when the fu
--- Comment #8 from janis at gcc dot gnu dot org 2006-08-21 23:34 ---
In response to Geoff's request in comment #6:
elm3b11% /home/janis/tools/gcc-3.3.5-ppc32/bin/g++ -B./ -c -x c++ 28528.i -###
Reading specs from
/home/janis/tools/gcc-3.3.5-ppc32/lib/gcc-lib/powerpc-linux/3.3.5/specs
C
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-21 23:31 ---
I found this while trying to figure out how to get VRP to optimize:
a_1 != 0 into a_1 if the range of a_1 is [0,1] (well with a NOP_EXPR).
If I do it inside simplify_cond_using_ranges, I miss all the MODIFY_EXPRs.
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-21 23:27 ---
(In reply to comment #6)
> If someone has a built FSF 3.3 around, it would be good if they could check
> whether this behaviour persists there.
That does not change the fact this is an user visiable regression.
--
int f(int x, int y)
{
int t;
for (t = 0; t < 50; t++)
g(t>0);
}
void f1(int x, int y)
{
int t;
for (t = 0; t < 50; t++)
g(t!=0);
}
--
The above two functions should produce the same code with f1 being better than
f.
If we change it to:
void f2(int x, int y)
{
int t;
--- Comment #6 from geoffk at gcc dot gnu dot org 2006-08-21 23:22 ---
The same thing happens if you use 'file.i' rather than 'file.h': it gets
treated as preprocessed rather than C++ source:
$ ./g++ -B./ -c -x c++ file.i -###
Reading specs from ./specs
Target: i386-apple-darwin9.0.0d2
--- Comment #8 from wintermute2k4 at ntlworld dot com 2006-08-21 22:35
---
Created an attachment (id=12111)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12111&action=view)
patch to prevent searching of configured path with relocated toolchain
The attached patch against gcc 4.1.1
--- Comment #10 from tromey at gcc dot gnu dot org 2006-08-21 22:19 ---
See also PR 28775
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27890
--- Comment #2 from tromey at gcc dot gnu dot org 2006-08-21 22:19 ---
This looks related to PR 27890.
FWIW I thought we no longer needed a .security file to be installed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28775
--- Comment #37 from tromey at gcc dot gnu dot org 2006-08-21 22:09 ---
I've checked in the patch which enables explicit thread registration.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |geoffk at gcc dot gnu dot
|dot org
--- Comment #36 from tromey at gcc dot gnu dot org 2006-08-21 22:07 ---
Subject: Bug 13212
Author: tromey
Date: Mon Aug 21 22:07:30 2006
New Revision: 116313
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116313
Log:
boehm-gc
PR libgcj/13212:
* configure.ac: Chec
--- Comment #5 from geoffk at geoffk dot org 2006-08-21 22:06 ---
Subject: Re: [4.2 Regression] ICE in rtl_for_decl_init, at dwarf2out.c
On 20/08/2006, at 9:32 PM, pinskia at gcc dot gnu dot org wrote:
> --- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-21
> 04:32 ---
--- Comment #8 from jason at redhat dot com 2006-08-21 22:04 ---
Subject: Re: [4.2 regression] ICE (segfault) while compiling
kdelibs 4.0 snapshot
I think this patch fixes the bug, but don't have time to test before
going out for the evening.
Index: decl2.c
==
--- Comment #5 from janis at gcc dot gnu dot org 2006-08-21 21:20 ---
A regression hunt on powerpc-linux identified this patch, which is a merge of
the pch-branch:
http://gcc.gnu.org/viewcvs?view=rev&rev=61136
r61136 | geoffk | 2003-01-10 02:22:34 + (Fri, 10 Jan 2003)
If i
--- Comment #6 from jason at gcc dot gnu dot org 2006-08-21 20:55 ---
Subject: Bug 27115
Author: jason
Date: Mon Aug 21 20:54:57 2006
New Revision: 116311
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116311
Log:
PR c++/27115
* gimplify.c (voidify_wrapper_expr):
--- Comment #24 from paulthomas2 at wanadoo dot fr 2006-08-21 20:13 ---
Subject: Re: spurious warnings with -W -Wunused
martin,
>--- Comment #23 from martin at mpa-garching dot mpg dot de 2006-08-21
>16:59 ---
>(In reply to comment #22)
>
>
>
>>I have a half memory that th
--- Comment #5 from janis at gcc dot gnu dot org 2006-08-21 18:29 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=66019
r66019 | neil | 2003-04-23 22:44:06 + (Wed, 23 Apr 2003)
--
janis at gcc dot gnu dot org change
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-21 18:29 ---
(In reply to comment #3)
> A variation of the code crashes GCC 4.2.0 20060820 (experimental) with a
> different ICE:
That is most likely PR 27961.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28787
--- Comment #10 from hjl at lucon dot org 2006-08-21 17:42 ---
I have a mixed feeling toward this. On one hand, gcc does assume 16byte stack
aligment. On the other hand, the original ia32 psABI only calls for 4 byte
stack aliment. Requiring 16 byte aligment will make sure the outputs fro
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-21 17:42
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-21 17:41
---
Subject: Bug 28741
Author: lmillward
Date: Mon Aug 21 17:41:18 2006
New Revision: 116303
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116303
Log:
PR c++/28741
* tree.c (decl_anon_ns_mem_
--- Comment #5 from rwcrocombe at raytheon dot com 2006-08-21 17:39 ---
Hrm: I considered the problem moot since I was able to get gcc working.
Machine is unavailable for further testing at this point, and thankfully my
contact with SGI has basically ended.
--
http://gcc.gnu.org/bu
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-08-21 17:36
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-08-21 17:34
---
Subject: Bug 28505
Author: lmillward
Date: Mon Aug 21 17:34:44 2006
New Revision: 116302
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116302
Log:
PR c++/28505
* decl.c (grokdeclarator):
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-08-21 17:28
---
Fixed on mainline.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-08-21 17:27
---
Subject: Bug 26269
Author: lmillward
Date: Mon Aug 21 17:27:48 2006
New Revision: 116301
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116301
Log:
PR c++/26269
* decl.c (duplicate_decls):
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-21 17:13 ---
*** Bug 28793 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-21 17:13 ---
*** This bug has been marked as a duplicate of 5458 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28793
--- Comment #46 from hubicka at ucw dot cz 2006-08-21 17:11 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
for completeness the -O3 -fno-tree-pre -fno-tree-fre results
(tree-pre/fre needs something little over 2GB of ram to converge)
Compiler: gcc 4.0.2 (bug can exist in higher versions)
OS: Red Hat Linux Adv. Server
Code, that generate error:
//=
#include
template
void MainFunction (F f)
{
}
template
void TestFunc (Type & t)
{
}
template
void TestFunc (T1 & t1, T2 & t2
--- Comment #23 from martin at mpa-garching dot mpg dot de 2006-08-21
16:59 ---
(In reply to comment #22)
> I have a half memory that there is already a PR for this. Could you
> check first before submitting a new one, please?
If you are referring to PR21918, I think the current beh
--- Comment #10 from janis at gcc dot gnu dot org 2006-08-21 16:34 ---
A regression hunt on powerpc-linux using the testcase from comment #3
identified this patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=91097
r91097 | kazu | 2004-11-23 17:45:50 + (Tue, 23 Nov 2004)
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-21 15:23 ---
The code violates C aliasing rules:
struct pseudoheader ph;
csum = my_chksum_tcp((u_int16_t *)&ph, (u_int16_t *)pkt, len);
.
static unsigned short my_chksum_tcp( unsigned short *h, unsigned short * d, int
--- Comment #105 from pinskia at gcc dot gnu dot org 2006-08-21 15:23
---
*** Bug 28792 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from chiabaut at nortel dot com 2006-08-21 15:20 ---
gcc -v -save-temps -g -Wall -O2 -mtune=generic bug.c
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-
--- Comment #1 from chiabaut at nortel dot com 2006-08-21 15:16 ---
Created an attachment (id=12110)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12110&action=view)
C source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28792
gcc 4.1.1 generates incorrect 386 code with -O2 or -O3 flag for an inlined
function if the -mtune cpu-type is one of: generic, i586, i686, pentium2,
pentium3, pentium-m. The generated code seems to be correct for the following
cpu-types: i386, i486, pentium4 & prescott.
The problem is also present
The -mdiv=inv:minlat option no longer rearranges the computations;
It appears the combiner pattern falls foul of the combine_validate_cost
check. The assumed cost of the three constituent instructions is 4 each,
while the cost of the combined instruction is assumed to be 16.
sh_rtx_costs needs to
--- Comment #9 from schwab at suse dot de 2006-08-21 14:27 ---
*** Bug 28789 has been marked as a duplicate of this bug. ***
--
schwab at suse dot de changed:
What|Removed |Added
-
--- Comment #3 from schwab at suse dot de 2006-08-21 14:27 ---
*** This bug has been marked as a duplicate of 28146 ***
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-21 14:14 ---
This is most likely a dup of bug 28146 which was not mentioned was a regression
and two the patch is inside reload which makes it harder to backport and make
sure all the rest of the targets stay working.
--
htt
--- Comment #6 from pault at gcc dot gnu dot org 2006-08-21 13:35 ---
Jakub and co.,
Does the below do it for you? Instead of passing null, I propose to pass the
address of a longlong containing zero. This then leaves the normal passing of
NULL to possibly represent a missing optional
--- Comment #3 from ian dot cowan at atkinsglobal dot com 2006-08-21 13:34
---
I also have the same problem with "gmake bootstrap", with my opteron based RHEL
systems (kernels 2.4.21-20.ELsmp and 2.6.9-11.ELsmp).
--
ian dot cowan at atkinsglobal dot com changed:
What
--- Comment #22 from paulthomas2 at wanadoo dot fr 2006-08-21 13:31 ---
Subject: Re: spurious warnings with -W -Wunused
martin,
>
>Should I open a new PR for this?
>
>
>
>
I have a half memory that there is already a PR for this. Could you
check first before submitting a new one,
--- Comment #45 from hubicka at ucw dot cz 2006-08-21 12:56 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
-O2 times:
Execution times (seconds)
life analysis : 18.08 ( 3%) usr 0.04 ( 1%) sys 19.42 ( 3%) wall
1120 kB (
--- Comment #11 from hubicka at gcc dot gnu dot org 2006-08-21 12:44
---
Just to note that for simple accestors (optimizing to single move), the
compiler should be smart enough to figure out that inlining always reduce code
size and inlining those will never hit any of the parameters me
! { dg-do compile }
! { dg-options "-O2 -fopenmp" }
program nestomp
integer :: j
j = 8
call bar
contains
subroutine foo (i)
integer :: i
!$omp atomic
j = j + 1
end subroutine
subroutine bar
integer :: i
i = 6
!$omp parallel
call foo(i)
!$omp end parallel
end sub
--- Comment #2 from jakub at gcc dot gnu dot org 2006-08-21 12:35 ---
It is not that hard to try the testcase. It is still broken.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from schwab at suse dot de 2006-08-21 12:33 ---
Created an attachment (id=12109)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12109&action=view)
Testcase
$ gcc -O2 sha512.c ; ./a.out ; echo $?
1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28789
$ sha512sum < /dev/null
587d521d772a30110a26eda2a81cc763008c8c3d95f5b68abd6a7a66790e0c5a19aec0be2bbabd67680fa6f37ca7ab72b41280e74eeb5f417554c12d3ffeb031
-
--
Summary: [4.1 regression] sha512sum miscompiled
Product: gcc
Version: 4.1.2
Status: UNCONFIR
--- Comment #3 from vlukas at gmx dot de 2006-08-21 12:04 ---
A variation of the code crashes GCC 4.2.0 20060820 (experimental) with a
different ICE:
--
template
void f()
{
typedef void (t)();
t a = x;
}
void g()
{
f();
}
--
This produces the following output:
--
b.cc: In f
--- Comment #21 from martin at mpa-garching dot mpg dot de 2006-08-21
11:58 ---
(In reply to comment #20)
> Fixed on trunk and 4.1
Thanks! The incorrect warnings have gone away.
However, if I provoke correct warnings now, the line numbers in the warning
messages are really confused, e
ble-multilib
--with-gmp=/home/martin/software/mygmp --with-mpfr=/home/martin/software/mympfr
--prefix=/home/martin/software/ugcc --enable-languages=c++,fortran
--enable-checking=release
Thread model: posix
gcc version 4.2.0 20060821 (experimental)
/home/martin/software/ugcc/libexec/gcc/x86_64-unkn
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-08-21 11:26
---
OK, right, I don't have time to fix this. I've looked at the rounding code, and
carry propagation, and I think we'd need a new special case to handle that, but
couldn't find a way to do it that doesn't break other
--- Comment #2 from vlukas at gmx dot de 2006-08-21 11:01 ---
>Indeed a dup of that PR.
>
>*** This bug has been marked as a duplicate of 27807 ***
I do not mean to sound impertinent, but with GCC 4.2.0 20060820 (experimental),
I can not reproduce bug 27807. However the code I submitted
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-08-21 10:48 ---
*** Bug 28787 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-08-21 10:48 ---
Indeed a dup of that PR.
*** This bug has been marked as a duplicate of 27807 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
The following code snippet crashes GCC 4.1.1 and 4.2.0 20060820 (experimental):
--
template
void f(T& r)
{
T a = r;
}
void g()
{
f(g);
}
--
Saving the code in a file a.cc and executing "c++ -c a.cc" produces:
--
a.cc: In function 'void f(T&) [with T = void ()()]':
a.cc:9: instantiat
--- Comment #4 from drnj at redherring dot co dot uk 2006-08-21 09:28
---
Subject: Re: Compiler crash building PHP component
Swap space problem in NSLU2 linux based system - not a compiler bug.
Appologies for not feeding that back sooner
On 21 Aug 2006 05:31:59 -, "pinskia at
95 matches
Mail list logo
