I just noticed a slight change in behaviour... on my system, I have
edited dejagnu's remote.exp such that it defaults its timeout to 1800
instead of 300. However, on gcc trunk, I see that, for example, in the
libstdc++ testsuite log, the timeout is set to 600, while in, e.g.,
gcc's log file, its
On 8/21/06, Christian Joensson [EMAIL PROTECTED] wrote:
I just noticed a slight change in behaviour... on my system, I have
edited dejagnu's remote.exp such that it defaults its timeout to 1800
instead of 300. However, on gcc trunk, I see that, for example, in the
libstdc++ testsuite log, the
In order to build a metrication tool I need a frontend that can
provide me with an abstract syntax tree containing information on all
actual language constructs in the code and also a CFG representation.
I reckon GCC has these capabilities and I was wondering if any of you
could tell me if it is
Hi,
I would like to ask whose approval is needed to start developing a GCC
front-end for the abstract test language TTCN-3.
More information about the language can be found here:
http://www.ttcn-3.org/
Thanks,
Cosmin
--
---
On 8/21/06, Cosmin Rentea [EMAIL PROTECTED] wrote:
Hi,
I would like to ask whose approval is needed to start developing a GCC
front-end for the abstract test language TTCN-3.
You don't need an approval for that. See the COPYING file distributed
with GCC for the details.
More information
Mike,
As I mentioned before, the simple test case of...
program test
integer i
end
shows the following change in its .s file when the common i
is added...
--- assign.s.nocommon 2006-08-19 10:45:59.0 -0400
+++ assign.s2006-08-19 10:46:19.0 -0400
@@
This patch:
r116277 | hubicka | 2006-08-21 02:00:14 +0200 (Mon, 21 Aug 2006) | 6 lines
PR rtl-optimization/28071
* reload1.c (reg_has_output_reload): Turn into regset.
(reload_as_needed,
This patch:
r116277 | hubicka | 2006-08-21 02:00:14 +0200 (Mon, 21 Aug 2006) | 6 lines
PR rtl-optimization/28071
* reload1.c (reg_has_output_reload): Turn into regset.
(reload_as_needed,
Jan Hubicka [EMAIL PROTECTED] wrote on 08/19/2006 07:51:42 PM:
Hi,
thepatch limiting minimal probability to 2% seems to make sense to me,
so please submit it for review. It would be nice to have the code to
compute maximal number of exits from loop too, but if it is really 9,
we
On Aug 21, 2006, at 6:34 AM, Jack Howarth wrote:
I just wanted to be clear that you believe only the line...
+ .stabs i:G(0,3),32,0,4,0
in that .s file is incorrect
I never said that, let me refer you to my previous email for what I
said. I did say that it was causing the problem.
Trunk fails to build for me with:
/cvs/gcc-svn/trunk/gcc/libgcov.c: In function ‘gcov_exit’:
/cvs/gcc-svn/trunk/gcc/libgcov.c:532: internal compiler error: RTL check:
expected code 'reg', have 'symbol_ref' in emit_reload_insns, at reload1.c:7397
Please submit a full bug report,
with
Erich Plondke wrote:
As it turns out this is very handy when I'm writing code by hand, but I
haven't
figured out a good way to teach GCC about it. So my question is: what
strategy should I use to teach GCC about this?
There are several issues you are asking about here.
One of them is
On Aug 21, 2006, at 11:59 AM, Andreas Jaeger wrote:
Trunk fails to build for me with:
Maybe related (from http://gcc.gnu.org/regtest/HEAD/):
2006-08-16T23:25:59Z 2006-08-17T14:40:57Z pass native 116195
2006-08-17T14:43:02Z 2006-08-17T15:38:47Z build native 116224
2006-08-17T17:16:01Z
On Aug 21, 2006, at 11:59 AM, Andreas Jaeger wrote:
Trunk fails to build for me with:
Maybe related (from http://gcc.gnu.org/regtest/HEAD/):
2006-08-16T23:25:59Z 2006-08-17T14:40:57Z pass native 116195
2006-08-17T14:43:02Z 2006-08-17T15:38:47Z build native 116224
This is unrelated.
On Mon, Aug 21, 2006 at 05:25:09PM -0400, Andrew Pinski wrote:
On Aug 21, 2006, at 11:59 AM, Andreas Jaeger wrote:
Trunk fails to build for me with:
Maybe related (from http://gcc.gnu.org/regtest/HEAD/):
2006-08-16T23:25:59Z 2006-08-17T14:40:57Z pass native 116195
On Mon, Aug 21, 2006 at 05:25:09PM -0400, Andrew Pinski wrote:
On Aug 21, 2006, at 11:59 AM, Andreas Jaeger wrote:
Trunk fails to build for me with:
Maybe related (from http://gcc.gnu.org/regtest/HEAD/):
2006-08-16T23:25:59Z 2006-08-17T14:40:57Z pass native 116195
All -
I've been investigating the cause of pr25505, where the amount of stack
space being used for a particular C++ function went from 1K to ~20K
between gcc 3.3 and 4.0. One of the issues I ran into was that the
stack slot allocated to hold the result of a function returning a
structure was
On 18/08/2006, at 6:39 PM, Ian Lance Taylor wrote:
Geoffrey Keating [EMAIL PROTECTED] writes:
On 18/08/2006, at 5:42 PM, Ian Lance Taylor wrote:
...
We could change CSA so that when it combines a prologue instruction
with a non-prologue instruction it sets a new flag on the
instruction,
So, my question is: is it really necessary to mark this location as
having its address taken? Yes, the address of the slot is passed to a
function, however I can't imagine any instances where the function
retaining that address after the call would be valid.
Your tracing below confirms my
Richard Kenner wrote:
So, my question is: is it really necessary to mark this location as
having its address taken? Yes, the address of the slot is passed to a
function, however I can't imagine any instances where the function
retaining that address after the call would be valid.
Your
Might you be able to provide any insight as to why you were able to
remove the other calls to mark_temp_addr_taken? Was it indeed because
of improved alias analysis of MEM locations? I wasn't, unfortunately,
able to derive this from the email traffic.
My *guess*, and it's just that, is
Richard Kenner wrote:
I did investigate the case you described, where two function parameters
are calls to the same function returning a structure. The front-end
generates temporaries to handle this, and so the middle-end-generated
temporaries are still restricted to a lifetime of a single
Mike,
Actually, while building tonight's svn pull, I noticed that the linker
warnings have actually been present during the linkage of libgfortran.dylib
for the -m64 part of the multilib build...
/bin/sh ./libtool --mode=link
/sw/src/fink.build/gcc4-4.1.999-20060821/darwin_objdir/./gcc
--- 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*.
1 - 100 of 126 matches
Mail list logo
