https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #17 from Marc Glisse ---
(In reply to Martin Sebor from comment #16)
> The warning code considers just the argument to the call. It doesn't know
> (and in the constant case can't tell) where the argument came from. It
> would need t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72751
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69971
--- Comment #3 from Eric Gallager ---
(In reply to Martin Sebor from comment #2)
> Yes, the warning does exist to warn about unsafe calls to the function (I
> added it here: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01702.html).
> This bug w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #16 from Martin Sebor ---
The warning code considers just the argument to the call. It doesn't know (and
in the constant case can't tell) where the argument came from. It would need
to be reworked to tell the difference (e.g., along
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80351
Eric Gallager changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79707
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87571
Bug ID: 87571
Summary: [8/9 Regression] ICE in friend_accessible_p, accessing
protected member of template friend inside template
class
Product: gcc
Version: 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86747
François-R Boyer changed:
What|Removed |Added
CC||Francois-R.Boyer at PolyMtl
dot ca
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #15 from Jonathan Wakely ---
Thanks Martin and Marc for the explanations. The warning sounds a lot more
definite than "there is some possible execution where the value is too large".
The phrasing of the warning makes it look like that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83522
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87570
Bug ID: 87570
Summary: Rejects valid alias template usage (as a type pack
size requirement)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: rejects-vali
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84423
--- Comment #6 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue Oct 9 21:16:09 2018
New Revision: 264996
URL: https://gcc.gnu.org/viewcvs?rev=264996&root=gcc&view=rev
Log:
/cp
2018-10-09 Paolo Carlini
PR c++/84423
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731
Will Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86731
--- Comment #6 from Will Schmidt ---
Author: willschm
Date: Tue Oct 9 20:55:25 2018
New Revision: 264994
URL: https://gcc.gnu.org/viewcvs?rev=264994&root=gcc&view=rev
Log:
[gcc]
2018-10-09 Will Schmidt
Backport from trunk.
2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87567
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87569
Bug ID: 87569
Summary: defining type in ‘sizeof’ expression is invalid in C++
references wrong operator
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #14 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #11)
> Why does it think we're calling it with max_size()?
_M_check_len contains a path (hopefully not taken, but gcc doesn't see that)
where it returns max_size(), a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
--- Comment #5 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #4)
> Another thing is the too complicated alias check where for
>
> (gdb) p debug_data_reference (dr_a.dr)
> #(Data Ref:
> # bb: 14
> # stmt: _28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83522
--- Comment #7 from Tobias Burnus ---
Author: burnus
Date: Tue Oct 9 18:03:31 2018
New Revision: 264990
URL: https://gcc.gnu.org/viewcvs?rev=264990&root=gcc&view=rev
Log:
2018-10-09 Tobias Burnus
PR fortran/83522
* resolve.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370
--- Comment #8 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Oct 9 17:23:06 2018
New Revision: 264989
URL: https://gcc.gnu.org/viewcvs?rev=264989&root=gcc&view=rev
Log:
i386: Use TImode for BLKmode values in 2 integer registers
When pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370
--- Comment #7 from hjl at gcc dot gnu.org ---
Author: hjl
Date: Tue Oct 9 17:17:41 2018
New Revision: 264987
URL: https://gcc.gnu.org/viewcvs?rev=264987&root=gcc&view=rev
Log:
i386: Use TImode for BLKmode values in 2 integer registers
When pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
Thomas Preud'homme changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86659
--- Comment #7 from Eric Botcazou ---
Author: ebotcazou
Date: Tue Oct 9 17:16:24 2018
New Revision: 264986
URL: https://gcc.gnu.org/viewcvs?rev=264986&root=gcc&view=rev
Log:
PR tree-optimization/86659
* gimple-match.h (gimple_ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #9 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #8)
> (In reply to Thomas Preud'homme from comment #7)
> > (In reply to Thomas Preud'homme from comment #6)
> > > Happens at expand time. Diving in.
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #8 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #7)
> (In reply to Thomas Preud'homme from comment #6)
> > Happens at expand time. Diving in.
>
> There's a giant if in expand_expr_real_1 with the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87568
Bug ID: 87568
Summary: Gfortran compile fails with bogus error message.
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87563
Renlin Li changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87567
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
Thomas Preud'homme changed:
What|Removed |Added
CC||thopre01 at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87567
Bug ID: 87567
Summary: constexpr evaluation rejects call to non-constexpr
function
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #13 from Martin Sebor ---
There is a call to malloc(SIZE_MAX - 15) in GIMPLE, as a result of the
conditional and I believe jump threading. Just after thread1 we see this in
the vrp1 dump:
[local count: 32272892]:
# _91 = PHI <_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87565
--- Comment #2 from Alexander Monakov ---
PLT trampolines all end with 'ldr pc, [ip, xxx]!', so do all calls via PLT
suffer from poor branch prediction of such indirect jumps?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83256
--- Comment #3 from joseph at codesourcery dot com ---
Unless someone can identify a commit that deliberately fixed the bug *and
added appropriate tests to the testsuite*, I'd strongly advise adding
tests to the testsuite before marking FIXED o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87565
--- Comment #1 from Richard Earnshaw ---
Not a good idea. Modern CPUs often don't predict such operations correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
--- Comment #6 from Thomas Preud'homme ---
Happens at expand time. Diving in.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #12 from Jonathan Wakely ---
(In reply to Martin Sebor from comment #3)
> At the same time, since the call malloc(SIZE_MAX) is guaranteed to fail, GCC
> could fold it to zero
But there is no call to malloc(SIZE_MAX), GCC is confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #11 from Jonathan Wakely ---
I can make these changes to libstdc++, but why is the compiler warning anyway?
It says:
In function ‘T* my_allocator::allocate(std::size_t, const void*) [with T =
int]’,
inlined from ‘void std::vecto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86815
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||needs-reduction
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #30 from Oleg Endo ---
(In reply to Eric Gallager from comment #29)
>
> So maybe it's worth splitting up into sub-issues?
It'd be better to, yes. But at the moment I don't have a lot of time to go
through all the cases and factor o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
Bug ID: 87566
Summary: ICE with class(*) and select
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85153
Peter Maydell changed:
What|Removed |Added
CC||peter.maydell at linaro dot org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87565
Bug ID: 87565
Summary: suboptimal memory-indirect tailcalls on arm
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83256
Peter Maydell changed:
What|Removed |Added
CC||peter.maydell at linaro dot org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85890
--- Comment #3 from Jonathan Wakely ---
And fixed on trunk by r258116
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83256
--- Comment #2 from Peter Maydell ---
Created attachment 44817
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44817&action=edit
repro for similar bug, apparently broken up to 8.3 but fixed in trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82793
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77698
--- Comment #7 from Pat Haugen ---
I also see the loop now being aligned when I apply your patch.
srdi 10,10,2
mtctr 10
.p2align 4,,15
.L6:
ld 9,0(11)
ld 8,0(4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79768
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83409
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #6 from rguenther at suse dot de ---
On Tue, 9 Oct 2018, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
>
> --- Comment #5 from Martin Liška ---
> Richi is it fixed?
No.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #5 from Martin Liška ---
Richi is it fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85890
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
--- Comment #11 from sudi at gcc dot gnu.org ---
Yes I remember spending a while to get it to reduce further. But it needs a big
constructor to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
Richard Biener changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87468
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85114
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|WAIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
--- Comment #9 from Martin Liška ---
Now confirmed!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
--- Comment #45 from Richard Biener ---
Author: rguenth
Date: Tue Oct 9 11:43:46 2018
New Revision: 264956
URL: https://gcc.gnu.org/viewcvs?rev=264956&root=gcc&view=rev
Log:
2018-10-09 Richard Biener
PR tree-optimization/63155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77698
Martin Liška changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
--- Comment #6 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 87564, which changed state.
Bug 87564 Summary: Missing -Wuninitialized with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87564
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87564
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #10 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #9)
> Do we want something like this as well? (and for malloc_allocator too)
I think so. Changing allocator_traits as LWG seems likely to agree won't help
much until
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87551
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #1 from Bernd Edlinger ---
>> Rainer, can you try this?
>
> Looks good so far: an i386-pc-s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87561
--- Comment #2 from Richard Biener ---
OK, so on haswell I see (- is bad, + is good):
-0x2342ca0 _40 + _45 1 times scalar_stmt costs 12 in body
+0x2342ca0 _40 + _45 1 times scalar_stmt costs 4 in body
so a simple add changes cost from 4 to 12 w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
--- Comment #8 from Ramana Radhakrishnan ---
(In reply to Martin Liška from comment #5)
> (In reply to Ramana Radhakrishnan from comment #4)
> > (In reply to Martin Liška from comment #3)
> > > Can't reproduce with GCC 7.3.0 on x86_64:
> > >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
--- Comment #7 from sudi at gcc dot gnu.org ---
It is not failing on x86_64 trunk anymore but with 8.0.1
+ TARGET=x86_64-pc-linux-gnu
+ GCC_INSTALL=/work/x86-trunk/bld
+ GCC=/work/x86-trunk/bld/bin/x86_64-pc-linux-gnu-gcc-8.0.1
+ LTO1=/work/x86-t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87544
--- Comment #9 from Jonathan Wakely ---
Do we want something like this as well? (and for malloc_allocator too)
--- a/libstdc++-v3/include/ext/new_allocator.h
+++ b/libstdc++-v3/include/ext/new_allocator.h
@@ -130,7 +130,13 @@ _GLIBCXX_BEGIN_NAME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
--- Comment #6 from sudi at gcc dot gnu.org ---
Still fails for me on aarch64-none-linux-gnu-gcc and aarch64-none-elf-gcc on
trunk and gcc-8.2.1 with the same error
Reading object files: test_1.o test_2.olto1: internal compiler error: in
linemap_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85114
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87564
Bug ID: 87564
Summary: Missing -Wuninitialized with -O0
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87563
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487
--- Comment #9 from Martin Liška ---
Can please anybody from Fotran community dig into this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
--- Comment #5 from Martin Liška ---
(In reply to Ramana Radhakrishnan from comment #4)
> (In reply to Martin Liška from comment #3)
> > Can't reproduce with GCC 7.3.0 on x86_64:
> >
> > + gcc-7 -O2 -flto -c test_1.i -o test_1.o
> > + gcc-7 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85114
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
Ramana Radhakrishnan changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Ramana Ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85870
Martin Liška changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #3 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84191
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Known to w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87553
--- Comment #9 from Martin Liška ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #7 from Martin Liška ---
> [...]
> > You can use gcov-dump -l to dump content of the files. However, it's not
> > problem as the fil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562
--- Comment #1 from David Malcolm ---
linemap_position_for_line_and_column(line_maps*, line_map_ordinary const*,
unsigned int, unsigned int) at libcpp/line-map.c:848
is:
linemap_assert (ORDINARY_MAP_STARTING_LINE_NUMBER (ord_map) <= line);
I w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87547
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87559
--- Comment #4 from Jonathan Wakely ---
Yes. Started to ICE with r253266 and was fixed by r261121.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87563
Ramana Radhakrishnan changed:
What|Removed |Added
Target||aarch64-none-elf
Target Milesto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87563
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||ice-on-valid-code
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87563
Bug ID: 87563
Summary: [9 regression ] ICE with -march=armv8-a+sve
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87559
--- Comment #3 from Jakub Jelinek ---
Yeah. I think it is r261121 aka PR85761 that fixed the ICE.
Wonder if it would be useful to add the #c1 testcase into testsuite or if
lambda-const8.C is close enough that it covers it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87559
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> But GCC 8 gets them all right
8.1 crashes with an ICE (which makes bisection hard), 8.2 gets them right.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787
--- Comment #14 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #13)
> > (null):0: confused by earlier errors, bailing out
>
> Your compiler is configured with --enable-checking=release (either
> explicitly or because your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787
--- Comment #13 from Dominique d'Humieres ---
> (null):0: confused by earlier errors, bailing out
Your compiler is configured with --enable-checking=release (either explicitly
or because your are using a release). The above message is the equiva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87553
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Martin Liška ---
[...]
> You can use gcov-dump -l to dump content of the files. However, it's not
> problem as the file exists. The warning should be only shown whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87559
--- Comment #1 from Jonathan Wakely ---
Any gcc bugs seem to be fixed in current trunk. As a single testcase:
extern "C" int puts(const char*);
constexpr char top_doc[] = "";
void f1() {
constexpr auto& doc = top_doc;
[](int) { puts(doc);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787
--- Comment #12 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #11)
> > I can confirm that this ICEs on Linux, but not on MACOSX.
>
> I get the ICE with MACOSX:
>
> ...
> Error: Expecting END SUBROUTINE statement at (1)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787
--- Comment #11 from Dominique d'Humieres ---
> I can confirm that this ICEs on Linux, but not on MACOSX.
I get the ICE with MACOSX:
...
Error: Expecting END SUBROUTINE statement at (1)
f951: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86576
--- Comment #4 from Paul Thomas ---
(In reply to Dominique d'Humieres from comment #3)
> AFAICT the test in comment 2 has been fixed between revisions r264451
> (2018-09-20) and r264486 (2018-09-21), may be r264485 (pr87359).
Unfortunately, the
1 - 100 of 124 matches
Mail list logo
