On 5/23/06, DJ Delorie [EMAIL PROTECTED] wrote:
What seems to happen is, we delete the simple jump even if we can't
fallthru, and thus the blocks get rearranged in an incorrect order.
Is there a bug here, or am I misunderstanding how this code works?
You're misunderstanding how this code
On 5/23/06, Steven Bosscher [EMAIL PROTECTED] wrote:
On 5/23/06, DJ Delorie [EMAIL PROTECTED] wrote:
What seems to happen is, we delete the simple jump even if we can't
fallthru, and thus the blocks get rearranged in an incorrect order.
Is there a bug here, or am I misunderstanding how this
Jan-Benedict Glaw wrote:
On Mon, 2006-05-22 21:42:07 -0700, Andrew Pinski [EMAIL PROTECTED] wrote:
On May 22, 2006, at 9:36 PM, H. J. Lu wrote:
on Linux/ia64. The last working revision is 113936. Linux/x86 and
Linux/x86-64 pass the same spot. Has anyone else seen it?
Yes for hppa-linux-gnu,
Hi,
could please someone help me with this one:
http://gcc.gnu.org/ml/gcc/2006-05/msg00337.html
Bye,
-Andreas-
On 22 May 2006 20:11, Gerald Pfeifer wrote:
On Mon, 15 May 2006 [EMAIL PROTECTED] wrote:
The link crossgcc FAQ in the middle of the page:
http://gcc.gnu.org/install/build.html; doesn't seem to link to a page that
offers the cross-gcc faq. Instead it appears to be a site of a consultant
On 17 May 2006 19:48, Andreas Krebbel wrote:
Doesn't this mean that your insn patterns should be using numerical (aka
matching) constraints?
Oh we are using matching constraints. But of course nobody except reload
does care about them. If the only constraints for an operand are matching
Hi,
Hmm. I note that if you /were/ using match_dups, the problem would be
solved because all four changes would go through the 'then' clause of the
if...else construct. Maybe it would be more worthwhile for you to have
separate patterns after all and find some other way of making reload
On 23 May 2006 15:42, Andreas Krebbel wrote:
Hi,
Hmm. I note that if you /were/ using match_dups, the problem would be
solved because all four changes would go through the 'then' clause of the
if...else construct. Maybe it would be more worthwhile for you to have
separate patterns
Looking at assembly listings of the Linux kernel I see thousands of
places where function returns are checked to be non-zero to indicate
errors. For example something like this:
mov bx, 0
.L1
call foo
test ax,ax
jnz .Lerror
inc bx
cmp bx, 10
jne .L1
.Lerror
On Tue, May 23, 2006 at 04:14:23PM +0100, Dave Korn wrote:
(I don't think that prefixing
anddi3 with an asterisk will hide it from the compiler and prevent it being
treated as the named pattern for anddi3; IIRC that doesn't work to protect the
well-known names, and so neither can you have,
Has work been done to evaluate a calling convention that takes error
checks like this into account? Are there size/performance wins? Or am
I just reinventing a variation on exception handling?
This introduces an extra stack push and will confuse a call-stack branch
predictor. If both the call
I get this failure when trying to do a proifledbootstrap on amd64. This is
a gentoo Linux machine with gcc 3.4.4, glibc 2.35, binutils 2.16.1,
autoconf 2.59, etc, etc.
make[6]: Entering directory
`/home/matt/src/gcc-bin/x86_64-unknown-linux-gnu/libstdc++-v3'
if [ -z 32 ]; then \
true; \
else \
On 5/23/06, Paul Brook [EMAIL PROTECTED] wrote:
Has work been done to evaluate a calling convention that takes error
checks like this into account? Are there size/performance wins? Or am
I just reinventing a variation on exception handling?
This introduces an extra stack push and will
An insn matched by anddi_1_rex64 must not be emitted via the anddi3
expander.
must not should be replaced here by does not need to
a common error for Germans ... or well at least for me ;-)
On May 23, 2006, at 8:21 AM, Jon Smirl wrote:
Or am I just reinventing a variation on exception handling?
:-)
DJ Delorie wrote:
FYI m32c still doesn't build libssp due to the GCC_NO_EXECUTABLES
thing. Works OK with it disabled, though, for C and C++. From whence
will release notes be published?
I think there are several kinds of release notes. One is the manually
prepared bug-summaries done by Joe
I'd imagine you might want to update bugs.html, in this case?
Or, perhaps, branch's install.texi's Host/Target specific
installation notes for GCC ?
DJ Delorie wrote:
I'd imagine you might want to update bugs.html, in this case?
Or, perhaps, branch's install.texi's Host/Target specific
installation notes for GCC ?
Yes, that's probably even better.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
* Jon Smirl:
Is the callstack branch correctly predicted if the routine being
called is complex?
At least the AMD CPUs have implemented a special return stack cache,
so the answer is probably yes.
This does eliminate the test./jmp after every function call.
Yes, but the test/jump now
On 5/23/06, Florian Weimer [EMAIL PROTECTED] wrote:
Yes, but the test/jump now happens in the callee, and you need to
maintain an additional stack slot. I wouldn't be surprised if the
The callee already had to implement the test/jmp in order to decide to
return the error. So this shouldn't
On Tue, May 23, 2006 at 11:21:46AM -0400, Jon Smirl wrote:
Has work been done to evaluate a calling convention that takes error
checks like this into account? Are there size/performance wins? Or am
I just reinventing a variation on exception handling?
It's fairly close to Fortran alternate
You're misunderstanding how this code works. In cfglayout mode,
there is no order in the basic blocks such that
BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB-next_bb. This means
that you can fall through to other blocks than next_bb.
Thanks for the tip, I figured out what was really
On 5/23/06, DJ Delorie [EMAIL PROTECTED] wrote:
You're misunderstanding how this code works. In cfglayout mode,
there is no order in the basic blocks such that
BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB-next_bb. This means
that you can fall through to other blocks than next_bb.
Thanks
Sounds like you need a memory clobber constraint on the asm... ?
Yup, that looks like it would do the trick. Thanks!
On 5/23/06, Gabriel Paubert [EMAIL PROTECTED] wrote:
On Tue, May 23, 2006 at 11:21:46AM -0400, Jon Smirl wrote:
Has work been done to evaluate a calling convention that takes error
checks like this into account? Are there size/performance wins? Or am
I just reinventing a variation on
On 5/23/06, DJ Delorie [EMAIL PROTECTED] wrote:
You're misunderstanding how this code works. In cfglayout mode,
there is no order in the basic blocks such that
BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB-next_bb. This means
that you can fall through to other blocks than next_bb.
In building the current gcc trunk under fink on MacOS X, I noticed
that 'fink validate' reported...
Error: Libtool file points to fink build dir.
Offending file: /sw/lib/gcc4/lib/libstdc++.la
Offending file: /sw/lib/gcc4/lib/libsupc++.la
which alerted me to the fact that both
In building the current gcc trunk under fink on MacOS X, I noticed
that 'fink validate' reported...
Error: Libtool file points to fink build dir.
Offending file: /sw/lib/gcc4/lib/libstdc++.la
Offending file: /sw/lib/gcc4/lib/libsupc++.la
which alerted me to the fact
GCC 4.1.1 RC1 is available from:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.1-20060517
Please download, build, and test these packages -- not trees
checked out
from SVN -- so that we can detect packaging problems.
Please post test results here:
Hi,
Our company had developed a new 32bit embedded processor many years age,
now we had ported GCC4.X for it(c/c++), and we want add its GCC4.x backend
to your GCC packages, can you tell me what should we do next?
Best Regards
Liqin
On May 23, 2006, at 6:01 PM, [EMAIL PROTECTED] wrote:
Our company had developed a new 32bit embedded processor many years
age,
now we had ported GCC4.X for it(c/c++), and we want add its GCC4.x
backend
to your GCC packages, can you tell me what should we do next?
First step, read our web
I will be building the GCC 4.1.1 release later tonight, or, at latest,
tomorrow (Wednesday) in California. Please refrain from all check-ins
on the branch until I have announced the release.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
--- Comment #3 from rsandifo at gcc dot gnu dot org 2006-05-23 06:17
---
Created an attachment (id=11498)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11498action=view)
Possible patch
I'm very sorry for the breakage. Here's a patch that appears
to fix the bug. I'll continue
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-23 06:51 ---
Reduced testcase:
struct st{
int _mark;
};
unsigned long long t = ((int)(((struct st*)16)-_mark) - 16);
This is undefined code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from jbglaw at lug-owl dot de 2006-05-23 07:54 ---
Bisected down to r113983 (which was ment to fix this problem for m68k), I'm
getting exactly this internal consistency failure when compiling parts of
uClibc for vax-linux-uClibc. (That is, starting with r113981:-) From
I work on a small c++ project named yans (http://yans.inria.fr). Whenever I try
to perform a profile-directed optimized build, I get the following errors with
the FC5-provided compiler:
src/ipv4/ipv4-end-point.cc: In function
voidunnamed::invoke_now(yans::Callbackvoid, yans::Ipv4EndPoint*,
Hello,
I have tried to compile the following simple code using g++ version 3.4.4.
int main(int argc, char *argv[])
{
double or;
return 1;
}
The compiler returns the following errors:
main.cpp: In function `int main(int, char**)':
main.cpp:3: error: expected
--- Comment #1 from mathieu dot lacage at sophia dot inria dot fr
2006-05-23 08:56 ---
hrm, ok, I tried to reproduce the bug with less code involved. If you pull
changeset 020b7defcc5f instead:
hg clone http://yans.inria.fr/code/yans yans-buggy
cd yans-buggy
hg revert -r 020b7defcc5f
Gfortran is slowly growing up. As part of that process, as of gcc 4.2 we should
IMHO be more serious about ABI compatibility.
I have a patch forthcoming that bumps the so version and introduces symbol
versioning.
--
Summary: libgfortran should use versioned symbols
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-05-23 09:02 ---
looks like creative offsetof
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724
--- Comment #3 from alessandro dot lonardo at roma1 dot infn dot it
2006-05-23 09:22 ---
(In reply to comment #2)
Use:
asm volatile(\tmovl (%1), %0\n
\tincl %0\n
:=r (res) : r (pi): memory);
or
asm volatile(\tmovl (%2), %0\n
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-23 09:37 ---
Nice. Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
gcj/javaprims.h has to be regenerated by hand using the classes.pl script
whenever you add a class to java.lang, java.io, or java.util (including
sub-packages, like java.lang.ref). The procedure is described in the HACKING
file. It would be nice to automate this process since it can only be done
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-23 09:44 ---
4.0.3 has
t.C: In function 'int main(int, char**)':
t.C:3: error: expected unqualified-id before '||' token
which is hinting at the problem. Same for 3.4.5.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-23 09:47 ---
This is fixed in 4.2.0 I believe. Try using -frandom-seed=0 for both the
-fprofile-generate and -fprofile-use compilations as workaround.
*** This bug has been marked as a duplicate of 20815 ***
--
rguenth at
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-05-23 09:47
---
*** Bug 27738 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
/usr/local/4.2/bin/g++4.2.0 -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2-svn/configure --enable-languages=c,c++
--prefix=/usr/local/4.2 --program-suffix=4.2.0
Thread model: posix
gcc version 4.2.0 20060523 (experimental)
Revision: 114016
/usr/local/4.2/libexec
--- Comment #3 from mathieu dot lacage at sophia dot inria dot fr
2006-05-23 12:05 ---
yes, the -frandom-seed thing fixes the build. The speedup I get out of
profile-drive optimization of the code for a static link is:
no profile: 14.76s +/- 0.07
profile: 14.44s +/- 0.06
--
--- Comment #4 from rsandifo at gcc dot gnu dot org 2006-05-23 13:06
---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01169.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27736
A double shift with both constants and cast in between is illegally folded into
a single shift. My first checks indicate that the change made for PR
tree-optimization/14796 on 2005-06-12 clashes with a piece of code earlier in
the function fold_binary. The comment starting with Strip any
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-23
13:49 ---
Subject: Re: [4.1/4.2 Regression] Large compile time regression
This is not the first time multiply expand is taking this long.
There was another bug about something like this but for alpha.
Note
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-23
13:51 ---
Subject: Re: [4.2 Regression] unwind-dw2-fde.c:833: fatal error: internal
consistency failure
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01169.html
So far, this fix is looking good.
--- Comment #25 from amacleod at redhat dot com 2006-05-23 14:07 ---
Subject: Bug 26757
Author: amacleod
Date: Tue May 23 14:07:21 2006
New Revision: 114018
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114018
Log:
2006-05-23 Andrew MacLeod [EMAIL PROTECTED]
PR
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-05-23 14:17 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-05-23 14:27 ---
/* Turn (a OP c1) OP c2 into a OP (c1+c2). */
if (TREE_CODE (arg0) == code host_integerp (arg1, false)
TREE_INT_CST_LOW (arg1) TYPE_PRECISION (type)
host_integerp (TREE_OPERAND
--- Comment #6 from rth at gcc dot gnu dot org 2006-05-23 15:00 ---
(In reply to comment #4)
This isn't a target bug as far as I can tell. The value generated
by __builtin_nanf() as shown by Nan2.c is 0x7fc0. The same
value is printed on x86. This is a signaling NaN. Positive
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-05-23 15:07
---
Subject: Bug 27736
Author: rsandifo
Date: Tue May 23 15:07:00 2006
New Revision: 114019
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114019
Log:
PR rtl-optimization/27736
* combine.c
--- Comment #7 from rsandifo at gcc dot gnu dot org 2006-05-23 15:08
---
Patch applied. (Thanks to Roger for the quick review.)
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from widman at gimpel dot com 2006-05-23 15:10 ---
By the way: whoever tackles this may also want to take a look at:
template int* p struct A { };
template struct A(int*)0;
...which was made permissible by the recently-adopted wording that was proposed
for Defect
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-23 15:27 ---
Read http://gcc.gnu.org/bugs.html.
We need the preprocessed source.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-23 15:36 ---
Actually Loop invariant motion is still doing its job even if the asm does not
clober memory, it does read memory and you did not record that. The correct
way to fix this is:
asm volatile(\tmovl (%1), %0\n
--- Comment #2 from gcc at pdoerfler dot com 2006-05-23 15:38 ---
Created an attachment (id=11501)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11501action=view)
gzipped prepocessed source code
Please note again that the preprocessed source code does *not* trigger the ICE.
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-23 15:43 ---
Reducing, this is a GC issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jb at gcc dot gnu dot org 2006-05-23 15:59 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01186.html
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-23
16:28 ---
Subject: Re: __builtin_nanf() doesn't return a _quiet_ nan on parisc
--- Comment #6 from rth at gcc dot gnu dot org 2006-05-23 15:00 ---
(In reply to comment #4)
This isn't a target bug as
--- Comment #11 from pault at gcc dot gnu dot org 2006-05-23 16:28 ---
(In reply to comment #10)
I applied the same patch to gcc 4.1 redhat. Now I can build and run SPEC CPU
2006 successfully with gcc for the first time. The only issue is I have to
apply 2 patches to tonto in SPEC
--- Comment #12 from hjl at lucon dot org 2006-05-23 17:15 ---
Are you using Tonto in SPEC CPU 2006? It is slightly different from Tonto 1.0
on SF. The problem in Tonto in SPEC CPU 2006 is it uses something like
integer, pointer :: d
...
if (associated(d)) call abort()
But nullify is
--- Comment #1 from pault at gcc dot gnu dot org 2006-05-23 17:24 ---
Is this standard conforming?
I just re-read the section on specification expressions for the unmpteenth time
and have not clarified it in my mind!
If you cannot point to the bit of the standard that allows it, I
--- Comment #2 from David at ham dot dropbear dot id dot au 2006-05-23
18:18 ---
(In reply to comment #1)
Is this standard conforming?
I've got the May 2004 draft Fortran 2003 standard from the WG5 archive.
Hopefully it says the same thing as F95 and final F2003.
I presume that
--- Comment #5 from dir at lanl dot gov 2006-05-23 19:16 ---
Has anybody else with a powerPC Macintosh tried the testsuite recently ?
I down loaded and rebuild 4.1.1 and 4.2.0 today. 4.1.1 is Ok. 4.2.0 has the
same errors.
The test problem in comment #3 works with -g, but when
The following code:
#include stdio.h
int main(int argc, char **argv) {
void *v = (void*) 1;
int *i = (int*) v;
int intpos;
for (intpos = 0; intpos (sizeof(void*) / sizeof(int)); intpos++)
if (i[intpos] == 1)
break;
printf(intpos = %d\n,intpos);
}
Produces:
intpos = 0
--- Comment #1 from falk at debian dot org 2006-05-23 19:40 ---
This code accesses v, which is of type void*, via an lvalue of type int.
This is not allowed by C aliasing rules. Use -fno-strict-aliasing or a
union to express this operation.
--
falk at debian dot org changed:
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-23 20:42 ---
to mark this as a dup of bug 21920.
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-23 20:41 ---
Reopening to
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #97 from pinskia at gcc dot gnu dot org 2006-05-23 20:42
---
*** Bug 27744 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-05-23 20:45
---
Subject: Bug 20173
Author: mmitchel
Date: Tue May 23 20:45:44 2006
New Revision: 114023
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114023
Log:
PR c++/20173
* pt.c
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-05-23 20:47
---
Fixed in 4.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-23 20:48 ---
This patch looks as if it could do the job:
Index: io.c
===
--- io.c(revision 113958)
+++ io.c(working copy)
@@ -2424,6 +2424,12 @@
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-23 21:17 ---
The previous patch was bogus. This one actually works:
Index: io.c
===
--- io.c(revision 113958)
+++ io.c(working copy)
@@ -2424,6
--- Comment #3 from geoffk at gcc dot gnu dot org 2006-05-23 21:21 ---
(In reply to comment #2)
Can we then have a new cctools which includes a newer ld64 also since right
now
powerpc-darwin is broken on a G5 without using --disable-multilib.
This specific problem should be
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-23 21:41 ---
(In reply to comment #3)
So in GCC 4.1.0, the only problem seems to be that _gfortran_runtime_error is
not printing the filename and the line number and the line number seems to be
the line number of the
--- Comment #6 from bero at arklinux dot org 2006-05-23 21:41 ---
It is creative offsetof indeed -- this a explanation from a bit of code
referenced to this one [while it isn't free yet, its license does allow posting
bits of it online]:
// HACK: gcc warns about applying offsetof()
--- Comment #6 from bero at arklinux dot org 2006-05-23 21:41 ---
It is creative offsetof indeed -- this a explanation from a bit of code
referenced to this one [while it isn't free yet, its license does allow
posting
bits of it online]:
Looks like someone was desperate to
--- Comment #7 from pinskia at physics dot uc dot edu 2006-05-23 21:42
---
Subject: Re: [4.1/4.2 Regression] internal compiler error: no-op convert from
4 to 8 bytes in initializer
--- Comment #6 from bero at arklinux dot org 2006-05-23 21:41 ---
It is creative
--- Comment #8 from gdr at cs dot tamu dot edu 2006-05-23 21:58 ---
Subject: Re: __builtin_nanf() doesn't return a _quiet_ nan on parisc
dave at hiauly1 dot hia dot nrc dot ca [EMAIL PROTECTED] writes:
| --- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-05-23
16:28
GNU Fortran fails on powerpc-linux with -O2 -ftree-loop-linear with an ICE
for this testcase, minimized from swim.f in SPEC CPU2000:
SUBROUTINE BUG
INTEGER I, J, M
REAL V
COMMON A(100,100), B(100,100), M, V
DO 200 I = 1, M
DO 100 J = 1, M
V = V +
Using gcc 4.2 from SVN:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/local_scratch/owe043/gcc_svn
Thread model: posix
gcc version 4.2.0 20060523 (experimental)
I get an ICE when when compiling (g++ -fopenmp omp.cc) the following program:
#define
--- Comment #1 from bowie dot owens at csiro dot au 2006-05-24 01:47
---
Created an attachment (id=11502)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11502action=view)
c++ file which causes ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27746
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-24 03:08 ---
The ICE:
t1.cc:9: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
The backtrace:
#0 0x90128b54
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-24 03:10 ---
C also has the same issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-24 03:23 ---
Here is a reduced testcase:
#define parallel _Pragma(omp parallel)
int
main()
{
#pragma omp parallel
{}
}
The question is does macros allow to stuff in #pragmas.
I want to say yes.
Anyways here is a non
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-24 03:24 ---
(In reply to comment #4)
Anyways here is a non openmp testcase that fails currently but it ICEs
differently:
And I am going to file a different bug about that.
--
Testcase:
#define push _Pragma (pack(push))
#define push1 _Pragma (pack(push))
push1
--
This ICEs like:
pc64:~ ~/newtest/bin/gcc t.c
t.c:4: internal compiler error: in c_parser_consume_token, at c-parser.c:639
Please submit a full
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.0
Known to work||4.1.0
Testcase:
#define push _Pragma (pack(push))
#define push1 _Pragma (pack(push))
push1
--
In 4.1.0, this is accpeted and in 4.2.0, this is rejected:
t.c:4: warning: malformed #pragma pack - ignored
t.c:4: error: expected
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-24 03:29 ---
(In reply to comment #4)
The question is does macros allow to stuff in #pragmas.
I want to say yes.
I changed my mind, no it should not be except for some cases.
Or at least the documented ones. I don't even
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.0
Known to work||4.1.0
--- Comment #4 from patchapp at dberlin dot org 2006-05-24 03:30 ---
Subject: Bug number PR rtl-optimization/27661
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01175.html
--
1 - 100 of 108 matches
Mail list logo
