https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #23 from Daniel Marjamäki ---
> If the user expects C to provide tests for "mathematically different", the
user has some learning to do.
I believe most users can appreciate this. But few users fully understand the
integer conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92731
--- Comment #4 from Lasse Reinhold ---
Some simplifications, and also tried with atomics instead of mutexes, to no
avail:
#include
#include
#include
#include
std::function job;
std::atomic has_job{ false };
int main() {
std::thread t =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736
Bug ID: 92736
Summary: Error when using a variable from a module in a
submodule and its parent module.
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90647
--- Comment #1 from Eric Gallager ---
(In reply to Antony Polukhin from comment #0)
> Consider the example:
>
> auto test(int s) {
> return [&s] { return s; };
> }
>
>
> `s` is a local variable, so we return a lambda that has a dangling re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70196
--- Comment #5 from Eric Gallager ---
(In reply to Nathan Sidwell from comment #4)
> ordering comparison of pointers is only well-defined when the two pointers
> point into the same object (including one-past-the-end). [expr.ref]/4
>
Right, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92700
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92696
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92688
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92735
Bug ID: 92735
Summary: unused member variable causes code to compile for
member to function for undefined function
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #22 from Vincent Lefèvre ---
(In reply to Segher Boessenkool from comment #21)
> If, as I said, the user uses explicit casts, that's not good. Much better
> already is to use implicit casts, as I said;
There's no such thing as impli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #27 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Nov 29 22:04:21 2019
New Revision: 278865
URL: https://gcc.gnu.org/viewcvs?rev=278865&root=gcc&view=rev
Log:
2019-11-29 Vladimir Makarov
PR rtl-optimization/92283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71196
--- Comment #8 from anlauf at gcc dot gnu.org ---
The issue seems to be related to the depth of DT nesting.
If there is only one level, the issue does not occur. E.g.
program p
type t
integer :: k
integer :: j
integer :: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71196
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #7 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92734
--- Comment #1 from Jakub Jelinek ---
Of course we have reassoc, but in there we punt on the non-wrapping integral
types, because reassociation is generally unsafe for them. There are just
special cases that can be handled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71196
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92629
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92629
--- Comment #6 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Fri Nov 29 20:58:39 2019
New Revision: 278863
URL: https://gcc.gnu.org/viewcvs?rev=278863&root=gcc&view=rev
Log:
2019-11-29 Harald Anlauf
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92629
--- Comment #5 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Fri Nov 29 20:56:11 2019
New Revision: 278862
URL: https://gcc.gnu.org/viewcvs?rev=278862&root=gcc&view=rev
Log:
2019-11-29 Harald Anlauf
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92732
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92698
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #20 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #19)
> Created attachment 47398 [details]
> gcc10-pr92712.patch
>
> Full untested patch.
The patch looks very good to me :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91003
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91003
--- Comment #8 from Richard Biener ---
Author: rguenth
Date: Fri Nov 29 19:54:25 2019
New Revision: 278860
URL: https://gcc.gnu.org/viewcvs?rev=278860&root=gcc&view=rev
Log:
2019-11-29 Richard Biener
PR tree-optimization/91003
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92718
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92734
Bug ID: 92734
Summary: Missing match.pd simplification done by
fold_binary_loc on generic
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #19 from Jakub Jelinek ---
Created attachment 47398
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47398&action=edit
gcc10-pr92712.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #21 from Segher Boessenkool ---
(In reply to Daniel Marjamäki from comment #20)
> Ping. Your "much better" code does not work.
I said that this is much better than an explicit cast. It is. And it behaves
identically.
If the user e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92731
--- Comment #3 from Jonathan Wakely ---
(In reply to Lasse Reinhold from comment #2)
> As far as I remember I could only add a single file when I created the bug
> report, and the option to add more showed up after completion.
As I said, you can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92732
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
the local machine (which is probably wrong).
You may need to set your DEJAGNU environment variable.
Running /src/gcc/svn/gcc/testsuite/gcc.dg/dg.exp ...
=== gcc Summary ===
# of expected passes4
/ssd/build/sparc-sun-solaris2.11/gcc-svn/gcc/xgcc version 10.0.0 20191129
(e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92733
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
Theodore.Papadopoulo at inria dot fr changed:
What|Removed |Added
CC||Theodore.Papadopoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92733
--- Comment #1 from Andrew Pinski ---
This error message does not make sense. Xgcc/xg++ should not be used to link
cc1. For a cross.
Can you provide how you configured?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 92683, which changed state.
Bug 92683 Summary: [10 Regression] strncmp incorrect result with equal
substrings and non-const bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92683
Martin Sebor changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #18 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #16)
> (In reply to Jakub Jelinek from comment #15)
> > I guess we could handle those cases by using something like
> > check_for_binary_op_overflow, except that for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92733
Bug ID: 92733
Summary: linker errors for missing std::__alloc_on_move with a
cross-compiler
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #17 from Jakub Jelinek ---
Untested patch:
--- gcc/match.pd.jj 2019-11-05 14:59:22.546873967 +0100
+++ gcc/match.pd2019-11-29 18:17:27.472002727 +0100
@@ -2480,18 +2480,42 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92731
--- Comment #2 from Lasse Reinhold ---
As far as I remember I could only add a single file when I created the bug
report, and the option to add more showed up after completion.
Anyway, the c++ code isn't very idiomatic, but I can't see why it wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #16 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #15)
> I guess we could handle those cases by using something like
> check_for_binary_op_overflow, except that for the case where A might be -1
> and plusminus equal to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #11 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #10)
> The bug in this example is that the push_back call needs to make a copy and
> the type is not copyable. It's not a bug that the copy constructor is
> implictly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #15 from Jakub Jelinek ---
For
A*B+A*C -> (B+C)*A
the problematic cases are
A==-1 and B > 0 and C==(max-B)+1 (i.e. when B+C overflows to min)
or A==0 and B < 0 and C 0 and C>max-B
(last two cases cover when B+C overflows)
For
A*B-A*C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92732
Bug ID: 92732
Summary: Bit-field with std::byte as member type cannot be
initialized
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92731
--- Comment #1 from Jonathan Wakely ---
(You can add as many attachments as you like, but only one at a time.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89014
--- Comment #9 from Wilco ---
Author: wilco
Date: Fri Nov 29 17:22:30 2019
New Revision: 278854
URL: https://gcc.gnu.org/viewcvs?rev=278854&root=gcc&view=rev
Log:
aarch64: fix use-after-free in -march=native (PR driver/89014)
Running:
$ valgr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #10 from Jonathan Wakely ---
For this specific call, yes. For the general case of "arguments do not meet the
function's requirements" there are no such notes from the compiler.
For example, v.emplace_back("blah") won't tell you anyth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92731
Bug ID: 92731
Summary: Data race on exception object thrown from std::future
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #14 from rguenther at suse dot de ---
On November 29, 2019 4:59:35 PM GMT+01:00, "jakub at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
>
>--- Comment #12 from Jakub Jelinek ---
>(In reply to Marc Glis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #9 from Marc Glisse ---
(In reply to Jonathan Wakely from comment #7)
> I disagree. The static assert contains all you need to know, expert or not.
> The benefit of seeing all the gory details is to figure out why something
> didn't c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #13 from Jakub Jelinek ---
Ok, so match.pd does the following transformations:
A*B+A -> (B+1)*A
A*B-A -> (B-1)*A
A-A*B -> (1-B)*A
A*B+A*C -> (B+C)*A
A*B-A*C -> (B-C)*A
(ignoring equivalent expressions with commutative + or *).
Let's c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #8 from David Brown ---
I don't think there is anything more I can add at the moment. Thank you for
your efforts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92728
--- Comment #1 from Tobias Burnus ---
See also PR 92730 for a related issue (OpenMP's map() does not handle /common/)
Remark, as I only just remembered:
"Named common blocks of the same name shall be of the same size in all scoping
units of a p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #7 from Jonathan Wakely ---
(In reply to David Brown from comment #6)
> I can see it is a challenge to get enough detail in the messages to be good
> for the more advanced users, and still simple enough and clear enough for
> more cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92730
Bug ID: 92730
Summary: [OpenMP] Common blocks in map() clause not accepted
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #6 from David Brown ---
I can see it is a challenge to get enough detail in the messages to be good for
the more advanced users, and still simple enough and clear enough for more
casual or inexperienced users.
The static assertion lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92193
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #12 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > I know, it will be a small complication, sure, but it can be handled.
>
> Ah, I think I understand now. But stil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #5 from Jonathan Wakely ---
The downside of this (and your suggestion to remove push_back from the overload
set) is that you no longer get told the copy constructor is deleted and why.
That note is only printed when the copy construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #4 from Jonathan Wakely ---
(In reply to David Brown from comment #3)
> Perhaps this could be better handled using concepts?
Yes, ideally. That stops compilation as soon as you try to call something that
fails to satisfy the constrai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #11 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #10)
> I know, it will be a small complication, sure, but it can be handled.
Ah, I think I understand now. But still
x=-1
a=INT_MAX
a*x+x gives INT_MIN without overflo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #3 from David Brown ---
I may not have been very clear here. Let me try and take a step back here.
>From the user's viewpoint, the problem is that they have made a class that
can't be copied, and they have written code that tries to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92677
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92596
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92710
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[9/10 Regression] |[9 Regression] Vectoriser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #26 from Vladimir Makarov ---
I think I find the problem root. We have
** Local #2: **
Choosing alt 0 in insn 1804: (0) =v (1) %0 (2) vm (3) v
{*fma_fmadd_df}
Creating newreg=4707 from oldreg=1801,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92286
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #10 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #8)
> (In reply to Jakub Jelinek from comment #6)
> > The suggestion I'll try to work on is to check if C isn't a plus/minus expr
> > with constant second operand that d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #9 from rguenther at suse dot de ---
On November 29, 2019 3:25:45 PM GMT+01:00, "glisse at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
>
>--- Comment #5 from Marc Glisse ---
>a*x+x -> (a+1)*x is unsaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|10.0|8.4
--- Comment #8 from Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #8 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #6)
> The suggestion I'll try to work on is to check if C isn't a plus/minus expr
> with constant second operand that doesn't go in the other direction and thus
> where t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379
--- Comment #5 from Segher Boessenkool ---
It's not top priority; it is fine for stage 4, too. Patches welcome.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92677
--- Comment #2 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Fri Nov 29 14:48:30 2019
New Revision: 278852
URL: https://gcc.gnu.org/viewcvs?rev=278852&root=gcc&view=rev
Log:
Fix DR_GROUP_GAP for strided accesses (PR 92677)
When d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #7 from Marc Glisse ---
The first question could be why SCCP produces
(const int) ((unsigned int) t_2(D) + 4294967295) * v_3(D) + v_3(D)
and not directly t*v. Several loop passes do have this tendency to split out
the last (or first)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92710
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Fri Nov 29 14:47:44 2019
New Revision: 278851
URL: https://gcc.gnu.org/viewcvs?rev=278851&root=gcc&view=rev
Log:
Don't defer choice of vector type for bools (PR 92596)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92596
--- Comment #11 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Fri Nov 29 14:47:44 2019
New Revision: 278851
URL: https://gcc.gnu.org/viewcvs?rev=278851&root=gcc&view=rev
Log:
Don't defer choice of vector type for bools (PR 92596)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997
--- Comment #7 from Jonathan Wakely ---
Author: redi
Date: Fri Nov 29 14:47:03 2019
New Revision: 278846
URL: https://gcc.gnu.org/viewcvs?rev=278846&root=gcc&view=rev
Log:
libstdc++:: improve how pretty printers find node types (PR 91997)
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92379
--- Comment #4 from Martin Liška ---
Any update about this Segher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92725
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #2 from Jonathan Wakely ---
Are you suggesting that everything inside libstdc++ code should be treated as a
black box for the purposes of diagnostics, so that the location of the actual
problem:
error: use of deleted function ‘X::X(c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89280
--- Comment #15 from Martin Liška ---
*** Bug 92725 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
Bug ID: 92729
Summary: [avr] Convert the backend to MODE_CC so it can be kept
in future releases
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92510
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #6 from Jakub Jelinek ---
At least from the comments it seems fold_plusminus_mult_expr only handles
(A * C) +- (B * C) -> (A +- B) * C
(A * C) +- A -> A * (C +- 1)
so for the testcases in question that is the latter and we p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391
Rainer Orth changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79592
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> If the expression is (void*)1 rather than (void*)1LL then it is incorrectly
> accepted.
And that was the same problem, fixed by r257161.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #5 from Marc Glisse ---
a*x+x -> (a+1)*x is unsafe (a=INT_MAX, x=0), but there are cases where we could
prove that it is safe, in particular when a is actually b-1 (more generally for
a*x+b*x when we can prove (with VRP?) that a+b can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92697
Martin Jambor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79592
Jonathan Wakely changed:
What|Removed |Added
Keywords|accepts-invalid |
Last reconfirmed|2017-08-21 00:00:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92728
Bug ID: 92728
Summary: [OpenMP][OpenACC] Common-block name clause matching
issues: common block needs to be defined before +
blank common not supported
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #4 from rguenther at suse dot de ---
On Fri, 29 Nov 2019, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
>
> --- Comment #3 from Jakub Jelinek ---
> Before the first revision mentioned above *.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92712
--- Comment #3 from Jakub Jelinek ---
Before the first revision mentioned above *.optimized dump contained just t *
v, the second one doesn't change anything in *.optimized and is a RTL costing
matter.
_4 = (unsigned int) t_1(D);
_10 = _4 + 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711
--- Comment #7 from Martin Liška ---
(In reply to Jan Hubicka from comment #6)
> With GCC9 like inliner parameters I get 308MB binary, so it is still
> somehwat bigger.
>
> Honza
I would try to set:
#define GCOV_TOPN_VALUES 1
then you should se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92391
--- Comment #13 from Joel Hutton ---
This appears to no longer be failing in the latest 'gcc-testresults' can this
be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711
--- Comment #6 from Jan Hubicka ---
With GCC9 like inliner parameters I get 308MB binary, so it is still
somehwat bigger.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91003
--- Comment #7 from Richard Biener ---
Created attachment 47396
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47396&action=edit
untested patch
The following fixes the testcase but possibly makes the issue just harder to
trigger.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92476
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92711
--- Comment #5 from Martin Liška ---
One particular change that has happened in the GCC 10 devel cycle is that we
started using TOP N counters for indirect calls and value profiling. Right now,
we track 4 key:value pairs for each counter plus one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92476
--- Comment #6 from Martin Jambor ---
Author: jamborm
Date: Fri Nov 29 13:36:47 2019
New Revision: 278842
URL: https://gcc.gnu.org/viewcvs?rev=278842&root=gcc&view=rev
Log:
Add an x86_64 test for PR 92476
2019-11-29 Martin Jambor
PR
1 - 100 of 150 matches
Mail list logo
