https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91031
--- Comment #5 from Alexey Makhalov ---
(In reply to Andrew Pinski from comment #1)
> In previous versions of gcc, the compound literal was put in the function
> level scope rather than in the current scope. Which is why it worked
> previously.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94118
--- Comment #2 from Hongtao.liu ---
(In reply to Frédéric Recoules from comment #0)
> The section 6.47.2.8 x86 Operand Modifiers of
> https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html is only about x86.
>
> As it was done for Operand Constrai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91031
Andrew Pinski changed:
What|Removed |Added
CC||makhaloff at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94979
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94979
Bug ID: 94979
Summary: gcc-9 generates incorrect code causing segfault
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978
--- Comment #1 from Fritz Reese ---
The regression is caused by r253156, which introduces the warning in the first
place. The relevant code is in frontend-passes.c (do_subscript). Apparently,
the FE is aware that when there is a conditional it ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978
Bug ID: 94978
Summary: [8/9/10/11 Regression] Bogus warning "Array reference
at (1) out of bounds in loop beginning at (2)"
Product: gcc
Version: 8.4.1
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938
Marek Polacek changed:
What|Removed |Added
Summary|[10/11 Regression] internal |[10 Regression] internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938
--- Comment #4 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:1e89178889741c9c4d6a61e5a01c40a8a182fa68
commit r11-155-g1e89178889741c9c4d6a61e5a01c40a8a182fa68
Author: Marek Polacek
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970
--- Comment #5 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:0af711e1914ab6d88538f1fcf0146757b5608b1d
commit r11-154-g0af711e1914ab6d88538f1fcf0146757b5608b1d
Author: Iain Buclaw
Date: Wed May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950
--- Comment #6 from Jakub Jelinek ---
(In reply to Jim Wilson from comment #5)
> I tested it with an rv64gc-linux cross compiler. The patch fixes these
Thanks.
> I think it should be backported to the gcc-10 release branch.
Sure, but at this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950
--- Comment #5 from Jim Wilson ---
I tested it with an rv64gc-linux cross compiler. The patch fixes these
failures:
FAIL: gcc.dg/pr94780.c (internal compiler error)
FAIL: gcc.dg/pr94780.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94951
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:46fcef99f49cc2d9f28d98f8ecdbf8263e9e0a87
commit r11-153-g46fcef99f49cc2d9f28d98f8ecdbf8263e9e0a87
Author: Jakub Jelinek
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94907
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:25ee2155ead87a5ea1c152a29341ee1e3275d706
commit r11-152-g25ee2155ead87a5ea1c152a29341ee1e3275d706
Author: Jakub Jelinek
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94630
--- Comment #8 from Paul E. Murphy ---
The new libm/libc ABI for ieee128 long double on ppc64le is now committed to
glibc which will be available for the 2.32 release (commit
051be01f6b41a1466b07ae4bd7f5894a8ec5fe67).
TS-18661 does not specify a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94977
Bug ID: 94977
Summary: Some X86 inline assembly modifiers are not documented
in the web documentation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #41 from Niels Möller ---
(In reply to Manuel López-Ibáñez from comment #39)
> You can easily find which pass does something by dumping (-ftree-dump-*)
> all of them and comparing them.
It's -ftree-dump-all, and also -fdump-passes wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Version|10.0|11.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|10.0|9.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946
Marek Polacek changed:
What|Removed |Added
Summary|[10/11 Regression] error: |[9/10/11 Regression] error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946
--- Comment #3 from Jakub Jelinek ---
Isn't 9 branch affected too? The r10-7998 change has been backported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:319eafce3e54c8cb10e3fddce6823a6a558fca8b
commit r11-147-g319eafce3e54c8cb10e3fddce6823a6a558fca8b
Author: Jakub Jelinek
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
--- Comment #9 from CVS Commits ---
The master branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:530b44094354758d0dea5374188caa6863647114
commit r11-146-g530b44094354758d0dea5374188caa6863647114
Author: qing zhao
Date: Wed May 6 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #17 from Jonathan Wakely ---
They're on by default for mingw, for compatibility with the MS compiler (but in
this case it seems the relevant extension is ancient history).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #16 from DB ---
> -fno-ms-extensions will allow you to compile it, as long as you aren't
> relying on any of the other MSVC compatibility quirks.
That indeed fixes the problem, as well as squashing lots of other spurious
warnings (s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #15 from DB ---
Aha, many thanks for the findings.
IMO the MS extensions should really be off by default, esp if compiling in a
Standard mode, until the user actually says they want them... right? They seem
liable to lead to issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #14 from Jonathan Wakely ---
No (see PR 94771 comment 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #13 from Richard Biener ---
Does MSVC still accept that [without diagnostic]? Maybe it's time to remove it
completely...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #12 from Jonathan Wakely ---
-fno-ms-extensions will allow you to compile it, as long as you aren't relying
on any of the other MSVC compatibility quirks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #9 from Jonathan Wakely ---
If it used std::invoke it would compile:
static_assert( std::is_same_v, int> );// OK
static_assert( std::is_same_v, int> ); // ERROR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #8 from DB ---
> I can reproduce it using x86_64-w64-mingw32-g++ 9.2.1
Thanks again for testing!
> I'm not yet convinced this isn't a ranges-v3 bug.
I will of course defer to your expertise! It could well be caused by something
bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #7 from Jonathan Wakely ---
Further reduced:
#include
struct X { };
using F = int (X::*)() const;
using I = X*;
using R1 = ranges::invoke_result_t;
static_assert( std::is_same_v );
This fails because R1 is int (X::)() const whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94976
Bug ID: 94976
Summary: Oddities with -fanalyzer and -flto (SSA names leaking
through)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #6 from Jonathan Wakely ---
(In reply to DB from comment #3)
> I didn't build it. Is there a switch that can get this for you?
As it says on that page, "the first three of which can be obtained from the
output of gcc -v"
But I can r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
Jonathan Wakely changed:
What|Removed |Added
Component|libstdc++ |c++
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94783
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94877
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> I'm not sure why this is considered a simplification, two insns vs. two, and
> on the subtraction it isn't specific to just one target, but I think for
> most the c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #4 from DB ---
Created attachment 48470
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48470&action=edit
test.ii from --save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #3 from DB ---
> Please read https://gcc.gnu.org/bugs and provide the missing information.
Fair point. Let me know if I missed anything still.
the exact version of GCC;
g++.exe (Rev2, Built by MSYS2 project) 9.3.0
the syste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94974
Bill Seurer changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
--- Comment #2 from Jonathan Wakely ---
I can't reproduce this using range-v3 0.10.0 and GCC 9.3.0 on GNU/Linux, the
example compiles fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #39 from Manuel López-Ibáñez ---
I think these questions are more appropriate for the mailing list, since
few people are subscribed to this bug.
You can easily find which pass does something by dumping (-ftree-dump-*)
all of them and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94913
--- Comment #5 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:7c2879301d3b027a1ba427a5d5c7557decb8a7ab
commit r11-145-g7c2879301d3b027a1ba427a5d5c7557decb8a7ab
Author: Uros Bizjak
Date: Wed May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #11)
> (In reply to David Binderman from comment #10)
> > I am still not sure if the new code is ok or not,
>
> Wasn't "This is 400% wrong" clear?
Here's the err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94975
--- Comment #1 from Vladimir Fuka ---
It is probably discussed here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 but that was not possible to
find it by the search as the title is not directly related.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-05-06
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #11 from Jakub Jelinek ---
Related PR is PR89059 though, while we can have a useful range info already in
the early opts from evrp, in many cases we can get much better info after
inlining. So, if we during the first switchconv pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472
--- Comment #11 from Jonathan Wakely ---
(In reply to David Binderman from comment #10)
> > It certainly has an effect on which member functions you can call on the
> > parameter.
>
> Agreed, but does it matter ? These are a bunch of comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
--- Comment #12 from Myron Walker ---
What would be helpful then is if gcno, gcda and source files could all have
separate root file system prefixes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94975
Bug ID: 94975
Summary: Address sanitizations show heap-buffer-overflow with
class(*) allocated to character on assignment
Product: gcc
Version: unknown
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94974
Bug ID: 94974
Summary: [11 regression] Many ICEs on power 7 after r11-59
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472
--- Comment #10 from David Binderman ---
(In reply to Jonathan Wakely from comment #9)
> Or in other words, of course whether a parameter can be const is separate
> from whether a member function can be const.
Agreed.
> But that doesn't mean t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94973
Bug ID: 94973
Summary: compile error when trying to use pointer-to-member
function as invokable projection to ranges::find()
Product: gcc
Version: 9.3.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
--- Comment #11 from Myron Walker ---
Ok. I'll look into it
On Wed, May 6, 2020, 7:25 AM marxin at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
>
> --- Comment #10 from Martin Liška -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94877
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94934
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94972
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-05-06
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94953
--- Comment #2 from Olaf Krzikalla ---
Created attachment 48469
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48469&action=edit
Test case code triggering the warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94967
--- Comment #2 from Rene Rahn ---
Oh, thanks for clarifying this.
Best regards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
CC||markeggleston at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
--- Comment #10 from Martin Liška ---
(In reply to Myron Walker from comment #9)
> How you I process data files from multiple sources and multiple runs with
> gcov.
$ man gcov-tool
$ gcov-tool merge [merge-options] directory1 directory2
So you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
--- Comment #9 from Myron Walker ---
How you I process data files from multiple sources and multiple runs with gcov.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472
--- Comment #9 from Jonathan Wakely ---
Or in other words, of course whether a parameter can be const is separate from
whether a member function can be const. But that doesn't mean that changing a
parameter from non-const to const can't have any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
--- Comment #8 from Martin Liška ---
Or even better: you can merge various .gcda files with:
gcov-tool merge ...
https://gcc.gnu.org/onlinedocs/gcc/Gcov-tool-Intro.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472
--- Comment #8 from Jonathan Wakely ---
(In reply to David Binderman from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > Those parameter can NOT be const, because *__b1 and *__b2 will not
> > compile if they're const, because op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
--- Comment #7 from Martin Liška ---
(In reply to Myron Walker from comment #6)
> I use the gcno file to build a the graph, pull counters from the gcda files
> and then solve the graph for the missing counts.
That's what gcov does itself.
> I a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
--- Comment #6 from Myron Walker ---
I use the gcno file to build a the graph, pull counters from the gcda files and
then solve the graph for the missing counts. I am merging the data from
multiple gcda sources. Multiple nodes running the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #44 from Jan Hubicka ---
Thanks, I am happy we now have real-world use of symver attribute. I have WIP
patch for better control over the symbol visibility, but I have run into
problems with gas limitations which was fixed by HJ about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
--- Comment #5 from Martin Liška ---
(In reply to Myron Walker from comment #4)
> A python tool that can do distributed code coverage analysis. Gcda files
> from cluster nodes from a web interface, gcno from a web interface or file
> share in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94972
Bug ID: 94972
Summary: Function multi-versioning binary may crash dynamic
linker
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
--- Comment #4 from Myron Walker ---
A python tool that can do distributed code coverage analysis. Gcda files from
cluster nodes from a web interface, gcno from a web interface or file share in
a build archive, and source directly from github.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94913
--- Comment #4 from Jakub Jelinek ---
Created attachment 48467
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48467&action=edit
gcc11-pr94913.patch
Untested fix for that part.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
--- Comment #3 from Martin Liška ---
(In reply to Myron Walker from comment #2)
> I am parsinv both gcno and gcda files.
These files are not intended to be parsed :/
Can you please describe your use-case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970
--- Comment #4 from Iain Buclaw ---
(In reply to Iain Buclaw from comment #3)
> Somewhat simplified reduction of test that doesn't depend on operator
> overloading.
>
> struct RegexMatch
> {
> string index() { return null; }
> ~this() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726
José Rui Faustino de Sousa changed:
What|Removed |Added
CC||jrfsousa at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94928
--- Comment #2 from Myron Walker ---
I am parsinv both gcno and gcda files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
CC||markeggleston at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970
--- Comment #3 from Iain Buclaw ---
Somewhat simplified reduction of test that doesn't depend on operator
overloading.
struct RegexMatch
{
string index() { return null; }
~this() { }
}
auto m() { return RegexMatch(); }
void initCommands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960
--- Comment #6 from Erich Keane ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Erich Keane from comment #3)
> > As you know, "extern template" is a hint to the compiler that we don't need
> > to emit the template as a way to sav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970
--- Comment #2 from Iain Buclaw ---
Because RegexMatch needs destruction, a temporary is created that requires
scope destruction. The temporary is wrapped in a TARGET_EXPR, and dtor call
set in TARGET_EXPR_CLEANUP.
TARGET_EXPR
A clean-up p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94865
--- Comment #2 from Richard Biener ---
Missing match.pd patterns also include a no-op comb of insertion of an
extracted element at the same position
(simplify
(bit_insert @0 (BIT_FIELD_REF @0 @size @pos) @pos)
(if (size matches)
@0)
in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10/11 regression] ICE |[8/9/10 regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94964
Richard Biener changed:
What|Removed |Added
Known to fail|11.0|10.0
Summary|[8/9/10/11 Regr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94964
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:6fc00b41e764219e2c88d8892d7c701c0d292a17
commit r11-139-g6fc00b41e764219e2c88d8892d7c701c0d292a17
Author: Richard Biener
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94961
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94961
--- Comment #3 from Martin Liška ---
Created attachment 48465
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48465&action=edit
Partially reduced test-case
Cannot reduce much..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394
--- Comment #10 from Nick Clifton ---
(In reply to Trupti Pardeshi from comment #9)
> May I know, in which version of binutils this fix is available?
2.35. Which should be available in August, all being well.
Cheers
Nick
PS. The fix is alr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970
--- Comment #1 from Iain Buclaw ---
The statement it is balking on is GIMPLE_WITH_CLEANUP_EXPR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472
--- Comment #7 from David Binderman ---
(In reply to Jonathan Wakely from comment #6)
> This is 400% wrong. It doesn't even address what cppcheck is complaining
> about, and cppcheck is drunk anyway.
Thanks for your explanation.
I am a bit con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94968
--- Comment #1 from Jakub Jelinek ---
Created attachment 48464
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48464&action=edit
gcc11-pr94968.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94963
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
1 - 100 of 160 matches
Mail list logo
