https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93298
Richard Biener changed:
What|Removed |Added
Resolution|DUPLICATE |INVALID
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93294
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93119
--- Comment #7 from Andrew Pinski ---
So looking further, my patch is incorrect.
The glibc sources for __tls_get_addr says it returns void* which is a 32bit
value which might or might not be zero extended.
So I need to fix this slightly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
--- Comment #12 from Richard Biener ---
Ah, sorry I failed to see the entry from BB2 isn't fallthru. I agree the
difference is spurious in this particular case but in general it's quite hard
to do better without excessively rotating most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #20 from rguenther at suse dot de ---
On Fri, 17 Jan 2020, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
>
> --- Comment #19 from Andrew Pinski ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
--- Comment #11 from Hongyu Wang ---
(In reply to rguent...@suse.de from comment #10)
>
> It has two exits which makes it difficult
> Or impossible to make it truly do-while.
> But it's close enough and further rotating the loop doesn't make it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #19 from Andrew Pinski ---
(In reply to Richard Biener from comment #14)
> Testcase from PR81028
>
> extern void abort();
>
> typedef int A;
> typedef float B;
>
> void __attribute__((noinline,noclone))
> foo(A *p, B *q, long unk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93298
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
Andrew Pinski changed:
What|Removed |Added
CC||msl023508 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93298
Bug ID: 93298
Summary: GCC 10.0 non-current union member access
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93286
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93286
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:5194b51ed9714808d88827531e91474895b6c706
commit r10-6029-g5194b51ed9714808d88827531e91474895b6c706
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93119
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 47663 [details]
> Patch which fixes the problem
>
> So we need to accept P modes and not PTR modes for the aarch64_valid_symref.
> And then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93119
--- Comment #5 from Andrew Pinski ---
Created attachment 47663
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47663=edit
Patch which fixes the problem
So we need to accept P modes and not PTR modes for the aarch64_valid_symref.
And then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93297
fdlbxtqi changed:
What|Removed |Added
CC||euloanty at live dot com
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93297
Bug ID: 93297
Summary: internal compiler error: in set_constraints, at
cp/constraint.cc:
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-checking,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291
--- Comment #2 from Andrew Pinski ---
(In reply to David Malcolm from comment #1)
> I'm not sure where the difference between the targets originates; is there a
> way to force the usage of bitwise-or here?
Try to write it this way:
bool tmp1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92833
Joseph S. Myers changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92833
--- Comment #7 from CVS Commits ---
The master branch has been updated by Joseph Myers :
https://gcc.gnu.org/g:852f0ae80555238c425e33f98df5c7077694bd9f
commit r10-6026-g852f0ae80555238c425e33f98df5c7077694bd9f
Author: Kerem Kat
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89358
--- Comment #23 from Roger Orr ---
That's good to hear -- thank you very much!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93280
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93280
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:801f5b96775288e55193a66a746caab1ddd56f4a
commit r10-6024-g801f5b96775288e55193a66a746caab1ddd56f4a
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93296
Bug ID: 93296
Summary: Compiler error when assigning array to const reference
with implicit constructor call.
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93036
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93239
--- Comment #2 from joseph at codesourcery dot com ---
I'd be concerned about trouble when code processing statements tries to
deal with context that doesn't exist outside of functions. Consider a
statement expression containing a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93293
--- Comment #1 from David Malcolm ---
Thanks for filing this.
I was using record-style labels, but switched to HTML-style labels when I
upgraded graphviz and my record-style labels stopped working.
Based on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93286
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93028
--- Comment #7 from Marek Polacek ---
Trying to compile test.cpp from Comment 5 again, I did see an ICE:
internal compiler error: tree check: expected tree that contains ‘decl minimal’
structure, have ‘tree_list’ in lookup_type_scope_1, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291
--- Comment #1 from David Malcolm ---
Thanks. The test is rather over-specified, it seems.
x86_64 gimple for test_2 is:
_1 = p_5(D) == 0B;
_2 = q_6(D) == 0B;
_3 = _1 | _2;
if (_3 != 0)
goto ; [51.12%]
else
goto ; [48.88%]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93292
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91298
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93239
--- Comment #1 from pskocik at gmail dot com ---
Fixing this seems as simple as removing/commenting-out:
gcc/c/c-parser.c:8195 /* If we've not yet started the current function's
statement list,
gcc/c/c-parser.c:8196or we're in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93295
--- Comment #2 from Marek Polacek ---
commit 1a291106384cabc73da0bc0f457b1cd3a4015970
Author: Jason Merrill
Date: Wed Nov 27 17:05:53 2019 -0500
Implement P1814R0, CTAD for alias templates.
This patch implements C++20 class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93295
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93295
Bug ID: 93295
Summary: ICE in alias_ctad_tweaks
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #29 from Marc Glisse ---
Note that __is_bitwise_relocatable is specialized to true for deque, so we are
not super consistent here ;-)
The original patch used is_trivially_move_constructible, IIRC I changed it to
is_trivial so the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278
--- Comment #3 from Jakub Jelinek ---
If you mean [ rather than { before HUGE, that doesn't change anything at all.
Maybe it is assembler or linker that need a lot of memory or time, but gcc
certainly doesn't.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #28 from Dan Stahlke ---
Thank you. That makes sense. I had asked about it here:
https://stackoverflow.com/questions/59690019 I was directed to this thread,
and linked back to the SO thread you provided.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93292
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93285
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93280
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93280
--- Comment #4 from Jason Merrill ---
*** Bug 93285 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93289
--- Comment #4 from Steve Kargl ---
On Thu, Jan 16, 2020 at 05:14:44PM +, burnus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93289
>
> --- Comment #3 from Tobias Burnus ---
> Okay, it is indeed a -std=gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93133
--- Comment #5 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #1)
> This happens during combine. If whether the comparison raises exception or
> not is distinguished on aarch64 with CCFPEmode vs. CCFPmode, then guess the
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64271
--- Comment #15 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:98d56ea8900fdcff8f1987cf2bf499a5b7399857
commit r10-6022-g98d56ea8900fdcff8f1987cf2bf499a5b7399857
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92517
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93289
--- Comment #3 from Tobias Burnus ---
Okay, it is indeed a -std=gnu extension. I still regard it as bug that it
differs, but we can now think about which one to change. Namely:
In the always-error case (i.e. literal first):
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93294
Bug ID: 93294
Summary: [10 Regression] Addition of -fdiagnostic-urls=never to
testsuite flags broke compat.exp testing with
ALT_CC_UNDER_TEST=gcc etc.
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93294
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93133
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to rsand...@gcc.gnu.org from comment #3)
> Mine. TBH I'm not really sure why the AArch64 definition
> of REVERSE_CONDITION is there. We can't use CCFP GT as
> a form of quiet GT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93289
--- Comment #2 from Tobias Burnus ---
(In reply to kargl from comment #1)
> It appears to be an undocumented extension. Add -Wall to your command line.
I would rather call it a bug :-)
The truncation warning is a separate thing. For instance,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93133
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93293
Bug ID: 93293
Summary: 'FAIL: gcc.dg/analyzer/dot-output.c dg-check-dot
dot-output.c.state-purge.dot'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at ubuntu dot com
Target Milestone: ---
seen with 20200116 on powerpc64-linux-gnu
$ cat editor_profiler.ii
class a {
public:
static int c(float p1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91263
--- Comment #5 from Jonathan Wakely ---
Fixed on trunk. Let's keep this open and decide whether to backport it to the
release branches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278
--- Comment #2 from doug mcilroy ---
My error. I omitted half the program. The bad behavior is exhibited by
char a{HUGE] = "x";
int main(){ return 0; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93291
Bug ID: 93291
Summary: 'FAIL: gcc.dg/analyzer/pattern-test-2.c' for a few
configurations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #99 from Dzianis Kahanovich ---
PPS About some hidden thinks/things. In pure theory. "*cost-model=cheap" can
reduce SSE usage, -mstackrealign - can increase function prolog/epilog
overhead. In my case - x7-Z8700 CPU have 2 FPU cores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288
--- Comment #2 from pmatos at gcc dot gnu.org ---
(In reply to David Malcolm from comment #1)
> Note that C++ is out-of-scope for the analyzer for GCC 10.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x01cb37ed in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #98 from Dzianis Kahanovich ---
fix: "I not try to rebuild 32bit "world" without ANY workaround" - on modern
gcc (now all under 9.2). Previous experiments was times & versions ago, so many
other new factors/fixes can solve most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93285
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #97 from Dzianis Kahanovich ---
No. Looking into gcc/opts.c - "-O3 optimizations" section - line:
{ OPT_LEVELS_3_PLUS, OPT_fvect_cost_model_, NULL, VECT_COST_MODEL_DYNAMIC },
- so, for -O3 it's "dynamic". Then, RTFM, "cheap" more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93290
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93289
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
--- Comment #2 from Andreas Krebbel ---
This problem to some degree is specific to IBM Z since our EH regs are
call-saved registers. For targets using call-clobbered EH regs such a
collisions usually cannot happen. Perhaps it can be provoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91263
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:d916538965ea260c6bcdb1d46581f6d572017ce8
commit r10-6005-gd916538965ea260c6bcdb1d46581f6d572017ce8
Author: Fran�ois Dumont
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93290
Bug ID: 93290
Summary: analyzer ICE on isnan()
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93289
Bug ID: 93289
Summary: array constructor of different length: Missing
diagnostic when PARAMETER is in list
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93286
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288
--- Comment #1 from David Malcolm ---
Note that C++ is out-of-scope for the analyzer for GCC 10.
Program received signal SIGSEGV, Segmentation fault.
0x01cb37ed in supergraph::supergraph (this=0x7fffcda0, logger=0x0)
at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93231
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93286
--- Comment #1 from Bernd Edlinger ---
with the following command it started already earlier:
gcc -Wshadow-compatible-local -fmax-errors=1 -std=c++17 -c effect.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93287
--- Comment #6 from Andrew Pinski ---
(In reply to Markus F.X.J. Oberhumer from comment #5)
> Still this is not nice from a usability perspective - why did the standard
> make this a declaration instead of a statement?
I said why, to allow it
) GCC:
$ /home/pmatos/installs/gcc-20200116/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/pmatos/installs/gcc-20200116/bin/g++
COLLECT_LTO_WRAPPER=/home/pmatos/installs/gcc-20200116/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93287
--- Comment #5 from Markus F.X.J. Oberhumer ---
I see, many thanks for the clarification.
Still this is not nice from a usability perspective - why did the standard make
this a declaration instead of a statement?
Well, will revert back to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92429
avieira at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93287
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93278
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93166
--- Comment #3 from fxue at gcc dot gnu.org ---
(In reply to Martin Jambor from comment #2)
> I have analyzed this ICE and came to the conclusion that the assert is
> wrong for polymorphic context lattices - e.g. in the reported case we
> always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93287
--- Comment #3 from Andrew Pinski ---
(In reply to Markus F.X.J. Oberhumer from comment #2)
> This is somewhat unexpected, and I do not get any warnings when using clang:
>
> $ clang-9 -Wdeclaration-after-statement test.c
But clang might be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93287
--- Comment #2 from Markus F.X.J. Oberhumer ---
This is somewhat unexpected, and I do not get any warnings when using clang:
$ clang-9 -Wdeclaration-after-statement test.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93287
--- Comment #1 from Andrew Pinski ---
_Static_assert is considered a declaration IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93287
Bug ID: 93287
Summary: _Static_assert creates spurious
-Wdeclaration-after-statement warnings
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #11 from Andreas Krebbel ---
(In reply to CVS Commits from comment #10)
> The master branch has been updated by Andreas Krebbel :
>
> https://gcc.gnu.org/g:3b5757ea87ad2274b841340335bf7536204e615b
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93282
Matthias Klose changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263
--- Comment #10 from markeggleston at gcc dot gnu.org ---
This is relevant:
https://gcc.gnu.org/ml/fortran/2017-12/msg00082.html
since the non_recursive keyword is not yet recognised by gfortran, I think it
SHOULD be postponed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #96 from Viktor Ostashevskyi ---
Honestly, I don't see how your compiler flags could help. cost-model=cheap
is default, data-alignment doesn't change incoming stack alignment.
ср, 15 січ. 2020, 14:31 користувач mahatma at eu dot by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263
--- Comment #9 from markeggleston at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #7)
> (In reply to Tobias Burnus from comment #5)
> > Side remark: The Fortran 2018 introduction states:
> >
> > "the RECURSIVE keyword is advisory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92429
--- Comment #6 from CVS Commits ---
The master branch has been updated by Andre Simoes Dias Vieira
:
https://gcc.gnu.org/g:f7dff7699fd70d3b8c3e637818e18c86f93ccfec
commit r10-5997-gf7dff7699fd70d3b8c3e637818e18c86f93ccfec
Author: Andre Vieira
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263
--- Comment #8 from markeggleston at gcc dot gnu.org ---
The change to:
if (ns->save_all || (!flag_automatic && !recursive))
Now allows the second example program to produce:
Hello 1
Hello 2
Hello 3
Hello
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91413
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93286
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93286
Bug ID: 93286
Summary: [10 Regression] ICE: tree check: did not expect class
‘type’, have ‘type’ (reference_type) in
convert_from_reference, at cp/cvt.c:550 since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #10 from CVS Commits ---
The master branch has been updated by Andreas Krebbel :
https://gcc.gnu.org/g:3b5757ea87ad2274b841340335bf7536204e615b
commit r10-5996-g3b5757ea87ad2274b841340335bf7536204e615b
Author: Andreas Krebbel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93263
Tobias Burnus changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #27 from Jonathan Wakely ---
> if constexpr (!is_trivial_v)
> if (is_default_constructible_v<_Tp> && (__OPTIMIZE__+0))
That would need to be 'if constexpr'
I'll stop now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #26 from Jonathan Wakely ---
Or maybe that should be:
template
struct __is_bitwise_relocatable
: is_trivially_copyable<_Tp> { };
...
if constexpr (!is_trivial_v)
if (is_default_constructible_v<_Tp>
1 - 100 of 111 matches
Mail list logo
