https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800
--- Comment #8 from Tamar Christina ---
Author: tnfchris
Date: Thu Oct 26 06:42:41 2017
New Revision: 254098
URL: https://gcc.gnu.org/viewcvs?rev=254098&root=gcc&view=rev
Log:
2017-10-26 Tamar Christina
PR target/81800
* conf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82707
--- Comment #4 from Tom de Vries ---
Created attachment 42475
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42475&action=edit
Tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82722
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82725
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82727
Bug ID: 82727
Summary: ICE in emit_library_call_value_1, at calls.c:4975
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82726
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82726
Bug ID: 82726
Summary: ICE in verify_ssa during GIMPLE pass: pcom
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724
--- Comment #6 from David Blaikie ---
(In reply to Paul Robinson from comment #5)
> (In reply to David Blaikie from comment #4)
> > What I'm saying is consumers already have to parse it to match up the same
> > type name between compilers.
>
> C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #33 from Max TenEyck Woodbury ---
The way it is currently implemented by GCC makes #line __LINE__ a
useless construct. The form where subsequent line numbers remain
unchanged is very useful. From the literature, that was the way it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81938
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724
--- Comment #5 from Paul Robinson
---
(In reply to David Blaikie from comment #4)
> What I'm saying is consumers already have to parse it to match up the same
> type name between compilers.
Consumers of objects produced by gcc or unmodified cla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724
--- Comment #4 from David Blaikie ---
> Making consumers parse names on the off chance they contain semantically
> significant information seems like a bit much, though. Especially if they
> contain information in a ridiculous variety of spellin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82725
Bug ID: 82725
Summary: [8 Regression] [i386] internal compiler error: in
change_address_1, at emit-rtl.c:2162
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724
--- Comment #3 from Paul Robinson
---
Admittedly the function parameter analogy is a bit of a stretch.
Making consumers parse names on the off chance they contain semantically
significant information seems like a bit much, though. Especially i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44515
--- Comment #9 from David Malcolm ---
Trunk now emits:
t.c: In function ‘foo’:
t.c:4:8: error: expected ‘;’ before ‘}’ token
bar()
^
;
t.c:7:1:
}
~
(as of r253690, I believe).
This improves the location for the diag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #41 from Misty De Meo ---
I requested a suggestion from Apple as to how to fix this, and was directed to
the developer technical support page:
https://developer.apple.com/support/technical/ Would you like me to file a
support request,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7356
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44515
--- Comment #8 from David Malcolm ---
Author: dmalcolm
Date: Wed Oct 25 23:53:41 2017
New Revision: 254093
URL: https://gcc.gnu.org/viewcvs?rev=254093&root=gcc&view=rev
Log:
C: detect more missing semicolons (PR c/7356)
c_parser_declaration_or_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7356
--- Comment #8 from David Malcolm ---
Author: dmalcolm
Date: Wed Oct 25 23:53:41 2017
New Revision: 254093
URL: https://gcc.gnu.org/viewcvs?rev=254093&root=gcc&view=rev
Log:
C: detect more missing semicolons (PR c/7356)
c_parser_declaration_or_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #40 from Campbell ---
(In reply to Chris Johns from comment #38)
> FYI I do not see any build errors with the same version of MacOS on
> different hardware running HPFS. It is a different machine with a Fusion
> disk and that disk is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724
--- Comment #2 from David Blaikie ---
Thanks for chiming in, Paul - figured it was an interesting case I ran into
that came up against/near some of the stuff we'd touched on recently (for a hot
second I thought maybe Clang's omission of the templ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724
--- Comment #1 from Paul Robinson
---
David and I have differing opinions on this one, but he was kind enough
to cc me on the bug so I'll offer up my take on it.
It's inarguable that omitting information makes the information smaller.
The quest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #39 from Jonathan Wakely ---
Using .NOTPARALLEL is definitely not an acceptable solution.
**Maybe** using it for affected targets only would be acceptable. Using it for
all targets is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #38 from Chris Johns ---
(In reply to Jonathan Wakely from comment #36)
> Also, this strongly suggests the problem for RTEMS is different:
>
> (In reply to Chris Johns from comment #24)
> > I would welcome a patch attached to this ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82719
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
--- Comment #4 from palmer at gcc dot gnu.org ---
(In reply to Alex Bradbury from comment #2)
> (In reply to palmer from comment #1)
> > Thanks Alex -- you're correct that this is a documentation/code mismatch. I
> > just talked to Andrew and we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724
Bug ID: 82724
Summary: Larger than needed DWARF type declarations for
explicitly instantiated class templates
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692
--- Comment #17 from Segher Boessenkool ---
So we have a compare:CCFPU, the resulting flags is used in a GE
only, and ix86_cc_mode thinks the best mode to use for that is CCFP.
Which is fine, except compare:CCFPU is a different instruction, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82723
--- Comment #1 from Jonathan Wakely ---
Firstly, the linker is not part of GCC, so this is the wrong place to report
it, and secondly, this is by design, see http://www.airs.com/blog/archives/307
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092
Jonathan Wakely changed:
What|Removed |Added
CC||john at mcfarlane dot name
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82226
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82062
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82062
--- Comment #14 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Oct 25 21:53:21 2017
New Revision: 254089
URL: https://gcc.gnu.org/viewcvs?rev=254089&root=gcc&view=rev
Log:
PR middle-end/82062
* fold-const.c (operand_equal_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82718
--- Comment #5 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 42474 [details]
> gcc8-pr82718.patch
>
> Untested fix.
Works for me. elfutils builds with this patch and gcc -O2 -gdwarf-5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81938
Dominique d'Humieres changed:
What|Removed |Added
Blocks||78672
--- Comment #4 from Dominiq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82561
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|2017-10-16 00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
--- Comment #3 from Andrew Waterman ---
On Wed, Oct 25, 2017 at 12:27 PM, asb at lowrisc dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
>
> --- Comment #2 from Alex Bradbury ---
> (In reply to palmer from comment #1)
>> Tha
On Wed, Oct 25, 2017 at 12:27 PM, asb at lowrisc dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
>
> --- Comment #2 from Alex Bradbury ---
> (In reply to palmer from comment #1)
>> Thanks Alex -- you're correct that this is a documentation/code mismatch. I
>> just talked to A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #32 from joseph at codesourcery dot com ---
The evidence from the DR discussion is that it's the *less* portable
interpretation - that none of the implementations tested behaved as you
suggest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
--- Comment #2 from Alex Bradbury ---
(In reply to palmer from comment #1)
> Thanks Alex -- you're correct that this is a documentation/code mismatch. I
> just talked to Andrew and we think it's best to change the documentation.
> How does this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82723
Bug ID: 82723
Summary: Collisions with standard library not detected by
linker
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82718
--- Comment #4 from Jakub Jelinek ---
Created attachment 42474
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42474&action=edit
gcc8-pr82718.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #31 from Max TenEyck Woodbury ---
The request in 82176 would remove all file components except the
filename itself. It also puts control of the option on the comand
line which would usually mandate its use for all modules in a pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82719
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82720
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52202
--- Comment #3 from Eric Gallager ---
(In reply to ensadc from comment #2)
> Superseded by issue 1299? See http://wg21.link/p0727.
To clarify for people who don't click on the link, that's C++ Core Issue 1299,
not GCC's bug 1299.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
palmer at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692
--- Comment #16 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #15)
> My point is that doing this only for FLOAT_MODE_P makes no real sense.
> If we can describe ordered comparisons with special CC modes, we should
> do tests w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82720
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82226
--- Comment #2 from John McFarlane ---
79092?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82718
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82721
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #30 from joseph at codesourcery dot com ---
An option to use just the file's basename in __FILE__ is bug 82176. I
think that's a much more reasonable feature than straining the
interpretation of what counts as the line number for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82721
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82708
--- Comment #7 from joseph at codesourcery dot com ---
On Wed, 25 Oct 2017, keno at juliacomputing dot com wrote:
> First, the build process looking for the headers in /sys-include rather
> than /include where glibc installs them. Leads to the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82722
Bug ID: 82722
Summary: internal compiler error: in finish_member_declaration,
at cp/semantics.c:2984
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82639
Victor Porton changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82721
--- Comment #1 from G. Steinmetz ---
With a test version (configured with --enable-checking=yes)
sometimes a backtrace is produced, like :
f951: internal compiler error: Segmentation fault
0xca7e1f crash_signal
../../gcc/toplev.c:326
0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82721
Bug ID: 82721
Summary: Error message with corrupted text, sometimes ICE
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82686
--- Comment #8 from Dennis Clarke ---
That helps actually. However I am concerned that the folks from IBM are
entirely focused on a particular power architecture and old powerpc cpus
are not considered. Freescale implementations even less so. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82720
Bug ID: 82720
Summary: [PDT] ICE in gfc_conv_component_ref, at
fortran/trans-expr.c:2400
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82719
G. Steinmetz changed:
What|Removed |Added
Blocks||82173
--- Comment #1 from G. Steinmetz -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82719
Bug ID: 82719
Summary: [PDT] ICE in transfer_expr, at fortran/trans-io.c:2393
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82622
--- Comment #6 from G. Steinmetz ---
(In reply to kargl from comment #5)
> Is this valid code and should compile
It should be legal, IMO. Note that "a" in z1.f90 is effectively unused
(the type parameters need not be used anywhere in the DT).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692
--- Comment #15 from Segher Boessenkool ---
My point is that doing this only for FLOAT_MODE_P makes no real sense.
If we can describe ordered comparisons with special CC modes, we should
do tests with those modes only here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82718
--- Comment #2 from Mark Wielaard ---
Created attachment 42472
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42472&action=edit
generated assembler e.s
assembler produced with gcc (GCC) 8.0.0 20171024 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82718
--- Comment #1 from Mark Wielaard ---
Created attachment 42471
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42471&action=edit
preprocessed e.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82718
Bug ID: 82718
Summary: Bad DWARF5 .debug_loclists generation
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091
Martin Sebor changed:
What|Removed |Added
Keywords||rejects-valid
Status|RESOLVED
word 1073741824
.align 2
.LC1:
.word 1065353216
.ident "GCC: (GNU) 8.0.0 20171025 (experimental)"
I would also note that the documentation could be improved by better detailing
the accepted ABI strings and giving valid examples (ILP32 isn't accepted as it
is uppercase).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82716
Jonathan Wakely changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #3 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82716
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Wed Oct 25 13:55:56 2017
New Revision: 254077
URL: https://gcc.gnu.org/viewcvs?rev=254077&root=gcc&view=rev
Log:
PR libstdc++/82716 avoid stupid -Wmismatched-tags warnings
PR li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #37 from Francois-Xavier Coudert ---
(In reply to Jonathan Wakely from comment #35)
> Can somebody confirm the links are not only present, but point to the
> relevant file in the source tree?
It seems OK:
In file included from
/User
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77267
--- Comment #12 from Matthias Klose ---
fyi, this is now fixed in Ubuntu 16.04 LTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82062
--- Comment #13 from rguenther at suse dot de ---
On Wed, 25 Oct 2017, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82062
>
> --- Comment #11 from Eric Botcazou ---
> > Simplified but not equal - you are a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82716
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82716
Bug ID: 82716
Summary: struct/class vs. tuple_element/tuple_size
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82062
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82062
--- Comment #11 from Eric Botcazou ---
> Simplified but not equal - you are also stripping a possible truncation.
> I think the original code only ever stripped widening conversions.
Right, but IMO there is no real reason to distinguish the 2 ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79283
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Wed Oct 25 12:42:58 2017
New Revision: 254076
URL: https://gcc.gnu.org/viewcvs?rev=254076&root=gcc&view=rev
Log:
PR libstdc++/79283 fix filesystem::read_symlink for /proc
PR lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82710
Jonathan Wakely changed:
What|Removed |Added
Summary|Incorrect |[8 Regression] Incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82707
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78511
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81938
--- Comment #3 from Rimvydas (RJ) ---
fmt_cache_1.f in valgrind is reproducible on aarch64-suse-linux
One scientific package has a tendency to crash in similar place.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x40003b9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81938
Rimvydas (RJ) changed:
What|Removed |Added
CC||rimvydas.jas at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692
--- Comment #14 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to Segher Boessenkool from comment #12)
> > But why only do this for FLOAT_MODE_P? Either the logic here isn't
> > correct, or cc_modes_compatible isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #36 from Jonathan Wakely ---
Also, this strongly suggests the problem for RTEMS is different:
(In reply to Chris Johns from comment #24)
> I would welcome a patch attached to this ticket.
>
> My efforts with .NOTPARALLEL cannot get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82692
--- Comment #13 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #12)
> But why only do this for FLOAT_MODE_P? Either the logic here isn't
> correct, or cc_modes_compatible isn't the correct hook (we'll need
> a new hook then?),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #35 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #34)
> So all the files in ${allstamped} will have been created, which means all
> the symlinks will be present (assuming no errors from the $(LN_S) command,
> whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82702
--- Comment #6 from Martin Liška ---
Marco is right that it started with the mentioned revision. But let me start in
more general context:
Consider virtual.cpp file that includes some standard header files.
In that case gcov tool can be invoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #34 from Jonathan Wakely ---
(In reply to Jack Howarth from comment #15)
> Maybe I'm just thick, but from the generated
> x86_64-apple-darwin17.0.0/libstdc++-v3/include/Makefile, it is entirely
> unclear to me how the stamp mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #29 from Max TenEyck Woodbury ---
While #line is indeed most commonly used by code generators, it can be used in
other contexts. The most common other use is to remove sensitive and useless
file name components from the file specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #33 from Jonathan Wakely ---
(In reply to Marc Glisse from comment #28)
> Generally, I don't understand why we are linking sources in the build
> directory instead of passing -I flags pointing directly to the source
> directory.
I th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82710
Nathan Sidwell changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #39 from Thomas Koenig ---
Clang has this implemented via polyhedral optimization,
see https://polly.llvm.org/ (news from September 2017).
Can gcc do something similar?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81862
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82647
--- Comment #3 from Jonathan Wakely ---
FWIW libc++ only accepts this code because includes the whole of
which includes which includes . So libc++ also
accepts:
#include
int
main()
{
std::tuple t;
std::shared_ptr s;
}
And clearly t
1 - 100 of 151 matches
Mail list logo
