http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #20 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #18)
> I think it is a bad idea to introduce the IFUNC into libgcc_s, because then
> while you speed up the few users of this builtin, you slow down all users of
> libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #19 from Cristian Rodríguez ---
(In reply to Jakub Jelinek from comment #18)
> I think it is a bad idea to introduce the IFUNC into libgcc_s, because then
> while you speed up the few users of this builtin, you slow down all users of
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687
David Edelsohn changed:
What|Removed |Added
Target|x86_64-apple-darwin10 |x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #17 from Marc Glisse ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Cristian Rodríguez from comment #14)
> > Because it will be useless to general purpose distributions of course.
>
> Then ifunc for this short of a fu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #16 from Marc Glisse ---
(In reply to Andrew Pinski from comment #13)
> I think it is a bad idea to use ifunc for such a function as most of the
> time it is link against statically in most cases.
g++ links to it dynamically by defaul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #15 from Andrew Pinski ---
(In reply to Cristian Rodríguez from comment #14)
> Because it will be useless to general purpose distributions of course.
Then ifunc for this short of a function is not useful either. Then maybe we
should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #14 from Cristian Rodríguez ---
(In reply to Andrew Pinski from comment #13)
> (In reply to Marc Glisse from comment #12)
Why can't you compile
> your code with -march=native for the places where you know you are going to
> compile an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #13 from Andrew Pinski ---
(In reply to Marc Glisse from comment #12)
> Created attachment 30381 [details]
> IFUNC proof of concept patch
I think it is a bad idea to use ifunc for such a function as most of the time
it is link against
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #12 from Marc Glisse ---
Created attachment 30381
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30381&action=edit
IFUNC proof of concept patch
Sadly, libgcc is compiled with gcc and not g++ so we can't use the recent
multiversio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56627
Paolo Carlini changed:
What|Removed |Added
CC||d.frey at gmx dot de
--- Comment #7 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57730
Paolo Carlini changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57730
Paolo Carlini changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #4 from joseph at codesourcery dot com ---
I'd say that in the presence of those extensions, it should be considered
unspecified whether pointers to distinct objects at the same address
compare equal or not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47040
--- Comment #4 from Dominique d'Humieres ---
> Nothing - it just needs to be packaged.
Do you want me to do it?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47040
Tobias Burnus changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from Tobias Burnus --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47803
Tobias Burnus changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from Tobias Burnus --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47040
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47803
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47803
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36041
--- Comment #11 from Cristian Rodríguez ---
Not to be annoying, but compiling the test case attached to this bug report
with clang 3.3 produces code in where
inline u32 popcount64_1(u64 x) { return __builtin_popcountll(x); }
is over 3 times fa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800
--- Comment #7 from Joost VandeVondele
---
(In reply to Tobias Burnus from comment #6)
> (Finally) FIXED on the GCC 4.9 trunk.
Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
Bug 27766 depends on bug 29800, which changed state.
Bug 29800 Summary: -fbounds-check: For derived types, write not also compound
name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800
What|Removed |Added
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800
--- Comment #5 from Tobias Burnus ---
Author: burnus
Date: Wed Jun 26 15:39:25 2013
New Revision: 200425
URL: http://gcc.gnu.org/viewcvs?rev=200425&root=gcc&view=rev
Log:
2013-06-26 Tobias Burnus
PR fortran/29800
* trans-array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #13 from Paolo Carlini ---
Curious, I understand, assuming they don't take new as a solid indication that
a fix is forthcoming. assigned normally is more reliable for that, still not
much more, unless, as I tried to explain, there are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49588
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46487
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727
--- Comment #7 from Themos Tsikas ---
I knew this was going to be my fault. Habe a good day sir.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727
--- Comment #6 from Andrew Pinski ---
(In reply to Themos Tsikas from comment #5)
> Then change your compiler's message and I might know how to do the right
> thing!
It is up to the distro to change the message. If the distro does not change
th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57627
--- Comment #1 from Harald van Dijk ---
I just realised the very similar example
void f4(char *dst, char *src)
{ __builtin_memcpy(dst, src, sizeof(src)); }
void f5(unsigned char *dst, unsigned char *src)
{ __builtin_memcpy(dst, src, sizeof(src))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727
--- Comment #5 from Themos Tsikas ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Themos Tsikas from comment #3)
> > Thanks, I will see if a more recent version is available in my distro.
>
> You really should have reported the bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57730
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
Chris King changed:
What|Removed |Added
CC||colanderman at gmail dot com
--- Comment #14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57730
Bug ID: 57730
Summary: class/struct mismatch for std::hash
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #12 from etherice ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to etherice from comment #10)
> > Isn't it defeating the purpose of having a 'status' field if it's not being
> > used?
>
> What makes you think it isn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727
Andrew Pinski changed:
What|Removed |Added
Component|c |target
--- Comment #4 from Andrew Pinski
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727
--- Comment #3 from Themos Tsikas ---
(In reply to ktkachov from comment #2)
> Reproduced with GCC 4.6.4.
> However, this is fixed on all currently maintained versions of GCC, it
> worked for me with 4.7.4, 4.8.1 and current trunk (4.9).
>
> GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728
--- Comment #3 from Jonathan Wakely ---
It's a bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728
--- Comment #2 from Bruce Merry ---
(In reply to Jonathan Wakely from comment #1)
> The explicit instantiation declaration suppresses the definition of
> A::A() in defaulted.o, but the explicit instantiation definition
> doesn't cause that symbol
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
Martin Liška changed:
What|Removed |Added
CC||marxin.liska at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #11 from Jonathan Wakely ---
(In reply to etherice from comment #10)
> Isn't it defeating the purpose of having a 'status' field if it's not being
> used?
What makes you think it isn't used? Paolo is saying that the difference
betwee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot de
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729
--- Comment #2 from Martin Liška ---
Created attachment 30380
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30380&action=edit
jsapi.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729
--- Comment #1 from Martin Liška ---
Created attachment 30379
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30379&action=edit
RegExp.cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57729
Bug ID: 57729
Summary: Always inline: indirect function call with a yet
undetermined callee
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728
Bug ID: 57728
Summary: Explicit template instantiation with defaulted method
causes missing symbol
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: norm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711
--- Comment #5 from Tobias Burnus ---
(In reply to Dmitry Kabanov from comment #4)
> Regarding the bug in JAC/DUMMY_JAC: I think for one-dimensional arrays there
> is no difference between ASSUMED-SIZE and ASSUMED-SHAPE.
That's wrong:
- Assumed-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #10 from etherice ---
(In reply to Paolo Carlini from comment #9)
> By the way, much more generally, I'm under the impression that often bug
> submitters attach way too much importance to the status change unconfirmed
> -> confirmed: I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602
--- Comment #4 from Igor Zamyatin ---
Created attachment 30377
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30377&action=edit
Untested patch that corrects the cleanup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57602
Igor Zamyatin changed:
What|Removed |Added
CC||hubicka at ucw dot cz
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57711
--- Comment #4 from Dmitry Kabanov ---
@Dominique:
a) I get the following error:
make all
gfortran -c vode.f
gfortran -c fcns.f90
gfortran -c main.f90
main.f90:8.75:
call vode(istate, lambda_fcn, dummy_jac, lambda, x_tmp, x_end, tol, pm)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727
--- Comment #1 from Themos Tsikas ---
Created attachment 30376
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30376&action=edit
preprocessed source exhibting bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57727
Bug ID: 57727
Summary: RaspberryPi gcc internal compiler error unrecognisable
insn
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #6 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57689
--- Comment #1 from Ian Lance Taylor ---
It's going to be hard for me to solve this using a cross-compiler. I would
need a full glibc to get to the point of failure. Can you try building the
compiler without optimization to see if you can get a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800
--- Comment #4 from Tobias Burnus ---
Patch: http://gcc.gnu.org/ml/fortran/2013-06/msg00135.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
--- Comment #3 from Martin Liška ---
Created attachment 30375
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30375&action=edit
Preprocessed syscall.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703
--- Comment #2 from Martin Liška ---
Created attachment 30374
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30374&action=edit
syscall.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #9 from Paolo Carlini ---
By the way, much more generally, I'm under the impression that often bug
submitters attach way too much importance to the status change unconfirmed ->
confirmed: I think it would be easy to prove that quite of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57726
--- Comment #1 from Martin Liška ---
Created attachment 30373
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30373&action=edit
onyx_if.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57726
Bug ID: 57726
Summary: LTO verify_flow_info: error: control flow in the
middle of basic block
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #8 from etherice ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to etherice from comment #6)
> > 2) My example was complete except for needing a couple #includes [...]
>
> So it was not complete then!
>
> This bug has
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #3 from jbeulich at novell dot com ---
Created attachment 30372
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30372&action=edit
auxiliary source (uninitialized data)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #2 from jbeulich at novell dot com ---
Created attachment 30371
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30371&action=edit
auxiliary source (initialized data)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
--- Comment #1 from jbeulich at novell dot com ---
Created attachment 30370
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30370&action=edit
main source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57725
Bug ID: 57725
Summary: conflicting language extensions
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724
--- Comment #3 from Jonathan Wakely ---
I'm inclined to say this is a Clang bug too.
[stmt.return]/3 "A return statement with an expression of type void can be used
only in functions with a return type of cv void;" and constructors do not have
an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724
--- Comment #2 from Jörg Richter ---
You mean the special case for 'void' does not apply in this case?
What a pity.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724
Fanael changed:
What|Removed |Added
CC||fanael4 at gmail dot com
--- Comment #1 from Fan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57724
Bug ID: 57724
Summary: wrong error: returning a value from a constructor
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #5 from petschy at gmail dot com ---
Created attachment 30368
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30368&action=edit
fixed test case (correct recursive traversal)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #4 from petschy at gmail dot com ---
Ooops, the test case won't perform the freeing completely, since the recursive
call is not inside the 'down' traversal loop, so only the first node on the
given level would be recursively freed, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #6 from etherice ---
(In reply to Jonathan Wakely from comment #4)
> Until someone analyses it and convinces themselves it's a bug.
>
> Not providing a complete testcase doesn't help. Code missing headers, even
> standard ones, is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800
Joost VandeVondele changed:
What|Removed |Added
Last reconfirmed|2007-02-16 16:08:18 |2013-06-26
--- Comment #3 from Joost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #3 from petschy at gmail dot com ---
Created attachment 30367
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30367&action=edit
clang amd64 disassembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #2 from petschy at gmail dot com ---
Created attachment 30366
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30366&action=edit
gcc amd64 disassembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #1 from petschy at gmail dot com ---
Created attachment 30365
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30365&action=edit
test case source
gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-languages=c,c++ --program-suffix=-4.9.0
Thread model: posix
gcc version 4.9.0 20130626 (experimental) (GCC)
commit 944f42fc29289812416f34d7b0c497ee79065396
command line:
g++-4.9.0 -std
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29800
Tobias Burnus changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57721
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57721
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #5 from Jonathan Wakely ---
N.B. Clang trunk aborts on Daniel's testcase and your first one.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57722
Bug ID: 57722
Summary: Floating point problems when building with no-sse and
no-mmx
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #4 from Jonathan Wakely ---
Until someone analyses it and convinces themselves it's a bug.
Not providing a complete testcase doesn't help. Code missing headers, even
standard ones, is not complete, and certainly doesn't compile "out o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57239
--- Comment #3 from etherice ---
Status is still unconfirmed... How long does it typically take to confirm a
bug?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57720
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57721
Bug ID: 57721
Summary: wrong error message with bounds checking.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57474
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637
--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to zhenqiang.chen from comment #7)
> Created attachment 30364 [details]
> update patch
>
>
> Please try the updated patch. Local tests: x86-64 and pandaboard bootstrap
This fixes the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57712
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #21 from Manuel López-Ibáñez ---
Once you are in trunk, you can ask the release managers to backport it to the
GCC 4.8 branch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
Manuel López-Ibáñez changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57719
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57714
--- Comment #10 from David Krauss ---
I don't plan on fixing this in GCC, but I did implement the feature today in my
own preprocessor, http://code.google.com/p/c-plus/source/list . It does require
a handshake between phases 2 and 3, because a tok
1 - 100 of 105 matches
Mail list logo
