--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-21 05:59 ---
This is a dup of bug 23813 and many others. This is the standard subreg
problem.
*** This bug has been marked as a duplicate of 23813 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-21 05:59 ---
*** Bug 27125 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-08-21 06:08 ---
I think to fix this one, we need a real pass to remove the promotions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-21 06:11 ---
I am going to try to get this done for 4.3.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-21 06:12 ---
I am going to fix up my patch for 4.3.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-08-21 06:14
---
I am going try to get this fixed for 4.3.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-21 06:15 ---
I think the comment can just go away since we are lowering the VL variables
before inlining so we get alloca now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25566
--- Comment #15 from bonzini at gnu dot org 2006-08-21 06:20 ---
Created an attachment (id=12108)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12108action=view)
patch that does not touch the middle-end
patch that does not touch the common parts of the compiler
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-21 06:22 ---
(In reply to comment #1)
on x86-64 I get:
That is what I get on x86 also now:
f:
movli.1523, %eax
pushl %ebp
movl%esp, %ebp
testl %eax, %eax
jne .L2
--- Comment #10 from quanah at stanford dot edu 2006-08-21 06:28 ---
MySQL compiles fine with gcc3.3 and gcc3.4, so this is definately a problem in
4.0.3 itself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27935
--- 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
The following code snippet crashes GCC 4.1.1 and 4.2.0 20060820 (experimental):
--
templatetypename T
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:
--- 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
--- 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 #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 #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
-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-unknown
--- 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,
--- 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:
--
templatetypename
void f()
{
typedef void (t)();
t a = x;
}
void g()
{
fint();
}
--
This produces the following output:
$ sha512sum /dev/null
587d521d772a30110a26eda2a81cc763008c8c3d95f5b68abd6a7a66790e0c5a19aec0be2bbabd67680fa6f37ca7ab72b41280e74eeb5f417554c12d3ffeb031
-
--
Summary: [4.1 regression] sha512sum miscompiled
Product: gcc
Version: 4.1.2
Status:
--- 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=12109action=view)
Testcase
$ gcc -O2 sha512.c ; ./a.out ; echo $?
1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28789
--- 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
! { 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
--- 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
--- 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 #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 #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 #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
--- 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.
--
--- 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 #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
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
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
--- 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=12110action=view)
C source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28792
--- 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
--- 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 #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 #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=revrev=91097
r91097 | kazu | 2004-11-23 17:45:50 + (Tue, 23 Nov 2004)
--
--- 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
Compiler: gcc 4.0.2 (bug can exist in higher versions)
OS: Red Hat Linux Adv. Server
Code, that generate error:
//=
#include iostream
template typename F
void MainFunction (F f)
{
}
template typename Type
void TestFunc (Type t)
{
}
template
--- 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)
--
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 #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
--- 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 #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=gccview=revrev=116301
Log:
PR c++/26269
* decl.c (duplicate_decls):
--- 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 #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=gccview=revrev=116302
Log:
PR c++/28505
* decl.c (grokdeclarator):
--- 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 #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.
--
--- 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=gccview=revrev=116303
Log:
PR c++/28741
* tree.c
--- 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 #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
--- 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 #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=revrev=66019
r66019 | neil | 2003-04-23 22:44:06 + (Wed, 23 Apr 2003)
--
janis at gcc dot gnu dot org
--- 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 there is
--- 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=gccview=revrev=116311
Log:
PR c++/27115
* gimplify.c (voidify_wrapper_expr):
--- 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=revrev=61136
r61136 | geoffk | 2003-01-10 02:22:34 + (Fri, 10 Jan 2003)
If
--- 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 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 #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=gccview=revrev=116313
Log:
boehm-gc
PR libgcj/13212:
* configure.ac: Check
--
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 #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
--- 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 #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 #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=12111action=view)
patch to prevent searching of configured path with relocated toolchain
The attached patch against gcc 4.1.1
--- 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
int f(int x, int y)
{
int t;
for (t = 0; t 50; t++)
g(t0);
}
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 #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.
--
--- 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 #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
--- 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
--- 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
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 math.h
#include stdio.h
#include stdint.h
int main(
--- 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
--- 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 #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*.
--- 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 #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
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
--- 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
--- 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
--- 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
--- 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
--- 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 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
--- 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
--- 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
--- 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
--- 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 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
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 allows for
--- 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 because
--- 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:42
--- 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
--- 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:
--- 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
--- 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
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 f2(int () [((2) + (3)) + (1)]), should
be: void f2(int () [((2)+(3))+(1)])
--- 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 f2(int () [((2) + (3)) + (1)]), should
be: void f2(int () [((2)+(3))+(1)])
--- 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.
1 - 100 of 102 matches
Mail list logo
