This:
#define x =
?x
preprocesses to:
?=
It should preprocess to:
? =
-Chris
--
Summary: preprocessed output does not lex to correct tokens
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
gcc -E on:
#define z ?
?z(
emits:
??(
This won't lex correctly when trigraphs are enabled.
-Chris
--
Summary: -E output incorrectly concatenates tokens into trigraphs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
--
gbenson at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gbenson at redhat dot com
|dot org
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-07-28 08:53
---
(In reply to comment #0)
It would also be nice to have a compiler parameter to turn off
non-standard intrinsics.
By the way: the correct option to compile standard code is to use -std=f95.
That will turn off
--- Comment #8 from patchapp at dberlin dot org 2006-07-28 09:00 ---
Subject: Bug number profile/28480
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-07/msg01184.html
--
--- Comment #31 from patchapp at dberlin dot org 2006-07-28 09:30 ---
Subject: Bug number PR rtl-optimization/28071
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-07/msg01185.html
--
--- Comment #32 from hubicka at ucw dot cz 2006-07-28 09:41 ---
Subject: Re: [4.1/4.2 regression] A file that can not be compiled in
reasonable time/space
Hi,
I've added this testcase to our's memory regression tester (see
gcc-regression mainling list), so hopefully the quadratic
--- Comment #8 from tobias dot burnus at physik dot fu-berlin dot de
2006-07-28 10:16 ---
Resolution: FIXED
Fixed on 4.2
What about 4.1.x?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28339
The compiler generates the error:
a.cpp: In function #8216;int main()#8217;:
a.cpp:6: internal compiler error: in stabilize_call, at cp/tree.c:2248
For this code:
class A {};
class B : public A {};
int main()
{
throw (A) B();
return 0;
}
Info:
gcc version 4.1.1
Target:
--- Comment #5 from r dot schwebel at pengutronix dot de 2006-07-28 10:44
---
(In reply to comment #2)
The reduced testcase passes the -O because gcc un-nests the function. Is this
true of the original testcase, or does glibc require trampolines?
The original testcase doesn't pass;
$ cat a.c
void foo (float * restrict x, float * restrict y)
{
int i;
for (i = 0; i 1; i++)
x[i] = y[i] * y[i];
}
$ gcc a.c -O1 -ffast-math -msse -mfpmath=sse -ftree-vectorize
-ftree-vectorizer-verbose=5 -std=c99 -c
a.c:5: note: Alignment of access forced using peeling.
a.c:5: note:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-28 10:51 ---
*** This bug has been marked as a duplicate of 21465 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-28 10:51 ---
*** Bug 28524 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-07-28 10:53 ---
Richard, next time you tell someone to file a bug report, please at least look
quickly at other bug reports which were filed before telling them to file a new
one. Finding the other bug was easy because the summary
--- Comment #8 from gary at gcc dot gnu dot org 2006-07-28 10:54 ---
Subject: Bug 13604
Author: gary
Date: Fri Jul 28 10:54:11 2006
New Revision: 115793
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115793
Log:
2006-07-28 Gary Benson [EMAIL PROTECTED]
Casey
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-07-28 10:55
---
I did do a bugzilla search before writing to mailing-list, searching for the
error message relevant stmt not supported in the comment, but it looks like
the error message was changed at some point.
--
--- Comment #9 from gbenson at redhat dot com 2006-07-28 10:59 ---
Fixed.
--
gbenson at redhat dot com changed:
What|Removed |Added
Status|ASSIGNED
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-28 11:12 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
While debugging PR 28274 I came across the following problem:
If I apply the second hunk of the patch below, the C++ frontend
crashes on the following code:
==
void foo();
void foo() {}
==
built-in:0: note: OLD DECL2 'struct std::type_info'
zsh: 25734
--- Comment #3 from patchapp at dberlin dot org 2006-07-28 11:35 ---
Subject: Bug number PR c++/28274
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-07/msg01189.html
--
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28505
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-28 11:45 ---
the vectorizer should recognize this particular case or we might want to
expand pow() again at the tree level before the vectorizer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21465
In compiling the following program, I have got a error message.
I think it is a wrong behavior.
$ gfortran -v
Using built-in specs.
Target: powerpc-apple-darwin7.9.0
Configured with: ../gcc/configure --prefix=/usr/local/gfortran
--enable-languages=c,fortran
--- Comment #45 from bonzini at gnu dot org 2006-07-28 12:20 ---
(From update of attachment 8814)
The patch is not relevant anymore after the commit that Ian pointed out.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #6 from pbrook at gcc dot gnu dot org 2006-07-28 13:19 ---
If your test fails with -fno-exceptions then you're hitting a different bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
The g++ driver has problems with *.h files compiled with -x c++:
g++ -c -x c++ file.h
yields a precompiled header file.h.gch instead of file.o.
g++ -S -x c++ file.h
yields an error message:
cc1plus: error: output filename specified twice
With -x c everything works as expected. Also using
--- Comment #7 from r dot schwebel at pengutronix dot de 2006-07-28 13:46
---
(In reply to comment #6)
If your test fails with -fno-exceptions then you're hitting a different bug.
Different from ... what? The bug Martin reported is based on my report.
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13604
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2006-07-28 14:56
---
Lately, unless someone requests, I have not been committing to 4.1 branch.
However, since you asked, I will gladly do so. BTW Thanks for the bug reports.
--
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-07-28 15:06 ---
I don't believe that it's possible to trigger this ICE unless you specify
-fexceptions or -funwind-tables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28516
--- Comment #9 from r dot schwebel at pengutronix dot de 2006-07-28 15:30
---
(In reply to comment #8)
I don't believe that it's possible to trigger this ICE unless you specify
-fexceptions or -funwind-tables.
Confirmed:
Removing -fexceptions from the command line: ICE is still
--- Comment #10 from tbm at cyrius dot com 2006-07-28 15:37 ---
Here:
(sid)96:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -fexceptions orig.c
orig.c: In function check_match:
orig.c:5165: internal compiler error: in arm_unwind_emit_set, at
config/arm/arm.c:15419
Please submit a
--- Comment #11 from tbm at cyrius dot com 2006-07-28 15:40 ---
And the original ICE at -O2 only shows up when you comine -funwind-tables or
-fexceptions with -pg:
(sid)119:[EMAIL PROTECTED]: ~] gcc -c -std=gnu99 -mtp=soft -funwind-tables -pg
-O2
orig.c
orig.c: In function
--
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
--- Comment #12 from ro at techfak dot uni-bielefeld dot de 2006-07-28
16:03 ---
Subject: Re: [4.2 Regression] Ada bootstrap failure on Solaris 10/x86
rguenth at gcc dot gnu dot org writes:
Is this now fixed on the mainline?
A mainline bootstrap as of 20060724 was successful, so
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-07-28 16:21
---
Fixed so closing as such.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-28 16:23 ---
Hmm, phase 1 preprocessing happens before phase 2 (the macros) so I don't think
this is a bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-28 16:23 ---
Hmm, phase 1 (which includes trigraphs) preprocessing happens before phase 2
(macros) so I don't think this is a bug. And macros cannot produce trigraphs
either.
--
--- Comment #2 from sabre at nondot dot org 2006-07-28 16:26 ---
It should print a space for the same reason that this does:
#define x -
-x
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- Comment #2 from sabre at nondot dot org 2006-07-28 16:26 ---
It should print a space for the same reason that this does:
#define x -
-x
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-07-28 16:47
---
Subject: Bug 28339
Author: jvdelisle
Date: Fri Jul 28 16:46:57 2006
New Revision: 115798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115798
Log:
2006-07-28 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-07-28 16:49
---
Subject: Bug 28339
Author: jvdelisle
Date: Fri Jul 28 16:48:58 2006
New Revision: 115799
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115799
Log:
2006-07-28 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-07-28 17:01
---
Subject: Bug 27668
Author: lmillward
Date: Fri Jul 28 17:01:19 2006
New Revision: 115800
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115800
Log:
PR c++/27668
PR c++/27962
* pt.c
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-07-28 17:01
---
Subject: Bug 27962
Author: lmillward
Date: Fri Jul 28 17:01:19 2006
New Revision: 115800
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115800
Log:
PR c++/27668
PR c++/27962
* pt.c
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-07-28 17:02
---
Fixed on mainline. Will apply to 4.1 branch when testing completes.
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from lmillward at gcc dot gnu dot org 2006-07-28 17:03
---
Fixed on mainline. Will apply to 4.1 branch when testing completes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27962
--- Comment #3 from alex dot jacob at logicacmg dot com 2006-07-28 19:00
---
Hello,
Thanks for the prompt reply.
Sadly, I am not able to generate a test case for this. All the while loops I
write to try and duplicate this seems to work fine. The specific case where
this is a problem is
--- Comment #2 from spkelly at andrew dot cmu dot edu 2006-07-28 19:37
---
(In reply to comment #1)
Actually this is a dup of bug 25035.
*** This bug has been marked as a duplicate of 25035 ***
Actually, I'm getting the same list of errors when trying to build programs
~with~ an
--- Comment #4 from lmillward at gcc dot gnu dot org 2006-07-28 21:17
---
Subject: Bug 27962
Author: lmillward
Date: Fri Jul 28 21:17:28 2006
New Revision: 115801
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115801
Log:
PR c++/27668
PR c++/27962
* pt.c
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-07-28 21:17
---
Subject: Bug 27668
Author: lmillward
Date: Fri Jul 28 21:17:28 2006
New Revision: 115801
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115801
Log:
PR c++/27668
PR c++/27962
* pt.c
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-07-28 21:19
---
Fixed in 4.1.2
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-07-28 21:20
---
Fixed in 4.1.2
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from sje at cup dot hp dot com 2006-07-28 21:45 ---
If we apply the patch from
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg02094.html first then we can apply
the patch for PR 27291. I did this on the 4.1 branch and the bug went away. I
have not done a full bootstrap
--- Comment #28 from danglin at gcc dot gnu dot org 2006-07-28 21:51
---
I've been trying to figure out why we end up with the strange intialization for
the
parity loop. I see this rtl in the loop2 dump:
;; Start of basic block 7, registers live: (nil)
(code_label 57 56 108 7 47 [1
--- Comment #5 from tromey at gcc dot gnu dot org 2006-07-28 22:06 ---
I have a patch I'm testing.
This code in classpath looks quite bad :(
I fixed this problem by adding synchronization.
However, really very little synchronization should be needed.
Instead we could be doing something
I'm using gcc 3.4.6 and I get an ICE compiling this:
int setjmp(jmp_buf_t buf)
{
__asm__ __volatile__
(
movl %%edi,(%0)\n
movl %%esi,4(%0)\n
movl %%ebp,8(%0)\n
movl %%ebx,16(%0)\n
movl %%edx,20(%0)\n
--- Comment #3 from neil at gcc dot gnu dot org 2006-07-28 23:47 ---
Tokenization is correct on reprocessing since ?= is not a token.
--
neil at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from neil at gcc dot gnu dot org 2006-07-28 23:48 ---
Tokenization is correct since preprocessed output has been through stages 1-3
and starts at stage 4. If you're passing -trigraphs then your command line is
incorrect.
--
neil at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-28 23:48 ---
This code is invalid as you cannot pass a struct in a register.
Oh this is a dup of bug 8788 which has been fixed for 4.1.0.
*** This bug has been marked as a duplicate of 8788 ***
--
pinskia at gcc dot gnu
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-07-28 23:48
---
*** Bug 28529 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from sabre at nondot dot org 2006-07-28 23:58 ---
I realize that ?= is not a token. However, ?= is.
-Chris
--
sabre at nondot dot org changed:
What|Removed |Added
--- Comment #4 from sabre at nondot dot org 2006-07-28 23:59 ---
I realize that tokenization is correct. As per:
http://gcc.gnu.org/onlinedocs/cppinternals/Token-Spacing.html#Token-Spacing
GCC should be emitting the space so that the subsequent relex of the output
won't lex
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-29 00:04 ---
(In reply to comment #4)
I realize that ?= is not a token. However, ?= is.
No it is not a token. It is a trigraph which is different than a token.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-29 00:05 ---
No it is not a token. It is a trigraph which is different than a token.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from sabre at nondot dot org 2006-07-29 00:05 ---
?= is not a trigraph.
--
sabre at nondot dot org changed:
What|Removed |Added
--- Comment #7 from sabre at nondot dot org 2006-07-29 00:06 ---
more specifically ?= is the C++ min-equal extension operator.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-07-29 00:08 ---
(In reply to comment #6)
?= is not a trigraph.
And I don't see it as a token in the C or C++ standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- Comment #6 from sabre at nondot dot org 2006-07-29 00:08 ---
Andrew, I'm well aware that a trigraph is not a token. If you read the report,
I say that gcc -E produces output that a subsequent GCC will not reparse into
the same result.
Again, this is the whole point of:
--- Comment #9 from sabre at nondot dot org 2006-07-29 00:09 ---
As I mention above, it is a GCC extension. Isn't gcc great? :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-07-29 00:12
---
(In reply to comment #9)
As I mention above, it is a GCC extension. Isn't gcc great? :)
A deperated one at that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-07-29 00:13
---
which should have been removed for 4.2 but was not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- Comment #12 from sabre at nondot dot org 2006-07-29 00:13 ---
... which means it's a bug, so please stop closing it!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-07-29 00:13
---
So this is only really for C++ mode.
And at that is going away so really should be just suspended.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-07-29 00:14
---
Suspending until the extension is removed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-07-29 00:15
---
PR 14556 is another PR about this extension.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from sabre at nondot dot org 2006-07-29 00:15 ---
Do what ever you want, but it certainly is a bug with current GCC. I filed
this bug out of desire to help free software get better, not out of any great
need to have the bug fixed.
--
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-07-29 00:18
---
Actually in C++ mode, this is done correctly so this is invalid based on that.
earth:~gcc -E -o - t.cc
# 1 t.cc
# 1 built-in
# 1 command line
# 1 t.cc
? =
earth:~vi t.c
earth:~gcc -E -o - t.c
# 1 t.c
# 1
--- Comment #7 from steven at gcc dot gnu dot org 2006-07-29 00:32 ---
Seems like a bug to me alright.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2006-07-29 00:41 ---
Is it necessary to wait with posting until the copyright assignment process is
finished, or can the patch be posted for a first review before the assignment
is on file?
--
--- Comment #18 from sabre at nondot dot org 2006-07-29 01:08 ---
ok, fair enough.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28520
--- Comment #8 from neil at gcc dot gnu dot org 2006-07-29 05:02 ---
This is not a bug. If you are preprocessing preprocessed output, you must use
-fpreprocessed as documented. Otherwise many other things will go wrong, not
just this. The bug is on your command line.
--
neil at
--- Comment #9 from sabre at nondot dot org 2006-07-29 05:03 ---
ok
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28521
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-07-29 05:12
---
Fixed on 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ian at airs dot com 2006-07-29 05:21 ---
It is safest to avoid posting the patch to a gcc mailing list before the
copyright assignment is signed. It protects us in the (hopefully unlikely)
case that the copyright assignment never does get signed. Otherwise we have
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-07-29 05:22 ---
So the assembler adds the nops. Hmm, is there a reason why GCC could add them
instead?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-29 05:24 ---
Confirmed, I was the one who recommended that Roger file this bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-07-29 05:25 ---
I think this is 4.2 regression now but I need to reduce it.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-29 05:27 ---
I think the behavior changed in 3.4 with the additional of PCH but I need to
double check what happens in 3.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28528
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-07-29 05:28 ---
(In reply to comment #3)
Any ideas on the 'warning: Lowest section in /usr/lib/libthread.so.1 is
.dynamic' messages ?
That is a gdb question and I don't know how to answer it.
Also are you compiling with just -g
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-29 05:30 ---
The ggc_free there is new for 4.0.0 and was added by Mark, maybe you should CC
him. If commenting out the ggc_free makes this work, this is unrelated to PR
27100.
--
94 matches
Mail list logo
