https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706
Jakub Jelinek changed:
What|Removed |Added
CC||schwab at gcc dot gnu.org
--- Comment #1
Keywords: ABI, wrong-code
Severity: blocker
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, ktkachov at gcc dot gnu.org,
matmal01
Milestone|--- |8.5
Last reconfirmed||2020-04-22
CC||jakub at gcc dot gnu.org
Priority|P3 |P4
--- Comment #1 from Jakub Jelinek ---
Started with r8-5161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94705
--- Comment #2 from Jakub Jelinek ---
Slightly reduced:
void foo ();
int
bar (void)
{
foo (baz);
void __attribute__ ((noinline)) baz (void);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94705
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=94707
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-04-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
--- Comment #2 from Jakub Jelinek ---
With -std=c++14, the structure is passed in floating point registers 1, 2, 3,
4, 5 (SFmode each elt), with -std=c++17 the structure is passed in gprs 3, 4, 5
(where the first two contain 64-bits each, the las
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
--- Comment #3 from Jakub Jelinek ---
--- gcc/config/rs6000/rs6000-call.c.jj 2020-03-30 22:53:40.746640328 +0200
+++ gcc/config/rs6000/rs6000-call.c 2020-04-22 11:07:05.507723606 +0200
@@ -5636,6 +5636,16 @@ rs6000_aggregate_candidate (const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
--- Comment #4 from Jakub Jelinek ---
Updated incomplete patch on top of
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544276.html
I've handled one rs6000_discover_homogeneous_aggregate caller where it wasn't
that hard to figure out
how t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706
--- Comment #16 from Jakub Jelinek ---
Would:
--- gcc/config/ia64/ia64.c.jj 2020-01-12 11:54:36.338414540 +0100
+++ gcc/config/ia64/ia64.c 2020-04-22 12:49:59.627563114 +0200
@@ -4665,7 +4665,7 @@ hfa_element_mode (const_tree type, bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|8.5 |10.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
Jakub Jelinek changed:
What|Removed |Added
Priority|P2 |P1
Target Milestone|8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Keywords: ABI, wrong-code
Severity: blocker
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, ktkachov at gcc dot gnu.org,
matmal01 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Blocks|94704, 94706, 9470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
--- Comment #1 from Jakub Jelinek ---
Completely untested guess:
--- gcc/config/s390/s390.c.jj 2020-03-14 08:14:47.097741411 +0100
+++ gcc/config/s390/s390.c 2020-04-22 14:24:17.980091105 +0200
@@ -11917,7 +11917,8 @@ s390_function_arg_vec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
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=94694
--- Comment #24 from Jakub Jelinek ---
The dec_math.f90 FAILs are at all opt levels:
( ) qsind( 60.00) 0.866025403784438646763723170753
0.866025403784438596588302061718
Note: The following floating-point exceptions a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #27 from Jakub Jelinek ---
(In reply to Fritz Reese from comment #26)
> Created attachment 48351 [details]
> Patch to protect trigd functions based on system availability (v2)
>
> I've attached a new patch for trigd. Below is the del
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94647
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
--- Comment #3 from Jakub Jelinek ---
The first arg doesn't have to be constant:
typedef int __attribute__ ((__vector_size__ (16))) V;
typedef long __attribute__ ((__vector_size__ (16))) W;
void
foo (W *x)
{
*x = __builtin_shuffle (*x, (W){},
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
--- Comment #4 from Jakub Jelinek ---
I guess there are two issues, one is a backend issue that vec_shr_optab
expander doesn't handle shift amount 0 correctly, and another in the
middle-end, that it shouldn't be dumb and for shift_amt == const0_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10 Regression] class |[8/9 Regression] class with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94705
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10 Regression] |[8/9 Regression] internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94724
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=94724
--- Comment #2 from Jakub Jelinek ---
Created attachment 48359
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48359&action=edit
gcc10-pr94724.patch
Untested fix. Wanted to create it efficiently, but by building the
COMPONENT_REFs with non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710
--- Comment #5 from Jakub Jelinek ---
For the middle-end side, I think we can do:
2020-04-23 Jakub Jelinek
PR target/94710
* optabs.c (expand_vec_perm_const): For shift_amt const0_rtx
just return v2.
--- gcc/optabs.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94715
--- Comment #4 from Jakub Jelinek ---
The GIMPLE transformation is correct and should stay as is.
User could have written int t = x * x; return t; instead.
What you are asking for is a new RTL optimization somewhere (dunno if in
expander, or wher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94715
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94717
--- Comment #4 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #3)
> > The compiler is apparently not prepared for new trapping loads. Fixing...
>
> No, just a missing check on landing pads:
>
> index a6687cd9c98..4ab8e0250ab 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94717
--- Comment #6 from Jakub Jelinek ---
Even the
&& info->ins_stmt != NULL
in coalesce_immediate_stores is redundant, because try_coalesce_bswap is called
with first = i - 1 and starts with i = first + 1 and thus caller's i and
info in the caller i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94718
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
-const.c:2435
Last reconfirmed||2020-04-23
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Priority|P3 |P4
CC||jakub at gcc dot gnu.org
|1
CC||jakub at gcc dot gnu.org
Summary|[10 Regression] internal|[8/9/10 Regression]
|compiler error: in |internal compiler error: in
|fold_convert_loc, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94730
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94706
Bug 94706 depends on bug 94383, which changed state.
Bug 94383 Summary: [8/9/10 Regression] class with empty base passed incorrectly
with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711
Bug 94711 depends on bug 94383, which changed state.
Bug 94383 Summary: [8/9/10 Regression] class with empty base passed incorrectly
with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94707
Bug 94707 depends on bug 94383, which changed state.
Bug 94383 Summary: [8/9/10 Regression] class with empty base passed incorrectly
with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
Bug 94586 depends on bug 94694, which changed state.
Bug 94694 Summary: [10 Regression][libgfortran] libgfortran does not compile on
bare-metal aarch64-none-elf (newlib)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
What|Remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
Bug 94704 depends on bug 94383, which changed state.
Bug 94383 Summary: [8/9/10 Regression] class with empty base passed incorrectly
with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94718
--- Comment #3 from Jakub Jelinek ---
In fold-const.c this is optimized by
fold_binary case EQ_EXPR: case NE_EXPR:
/* Fold (X & C) op (Y & C) as (X ^ Y) & C op 0", and symmetries. */
Of course, the (x op 0) op2 (y op 0) for op < or >= and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94718
--- Comment #4 from Jakub Jelinek ---
--- gcc/fold-const.c.jj 2020-03-31 11:06:14.063512214 +0200
+++ gcc/fold-const.c2020-04-23 18:39:15.399738420 +0200
@@ -11631,50 +11631,6 @@ fold_binary_loc (location_t loc, enum tr
return omit_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448
--- Comment #5 from Jakub Jelinek ---
The testcase ICEs on powerpc64-linux with -m32:
lambda-generic-variadic20.C:5:12: internal compiler error: in
expand_expr_addr_expr_1, at expr.c:8075
5 | auto L = [](auto ... a) {
|^~~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94724
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|jakub at red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #5 from Jakub Jelinek ---
All the PR89430 testcases have such a load.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #7 from Jakub Jelinek ---
(In reply to Jeffrey A. Law from comment #6)
> THe whole point of that change is to not require a dominating load if the
> object comes from the stack.
Yeah, but I find that flawed. One can do it after perf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #10 from Jakub Jelinek ---
Yeah.
add_or_mark_expr could be extended to handle more complex addresses (perhaps
get_inner_reference and hash on the decl + offset expression and taking into
account the bitpos/bitsize then?
Further testc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #11 from Jakub Jelinek ---
If we don't want to revert the change completely, could we perhaps do:
--- gcc/tree-ssa-phiopt.c.jj2020-03-19 10:23:50.542872359 +0100
+++ gcc/tree-ssa-phiopt.c 2020-04-24 10:54:10.341716841 +0200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #13 from Jakub Jelinek ---
Even better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #14 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #10)
> bar is still miscompiled by some other optimization though
> (and GCC 9 didn't do that), so we have some other regression.
Sorry for the false alarm, the testc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #16 from Jakub Jelinek ---
Created attachment 48366
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48366&action=edit
gcc10-pr94734.patch
So like this? The store data races thing can be covered by the non-addressable
auto var c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #17 from Jakub Jelinek ---
Created attachment 48367
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48367&action=edit
gcc10-pr94734.patch
Updated patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94726
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milestone|--- |8.5
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Started with r8-4349-g1b6fa695ab5e6f6fd57ed9264b336f06f440125b when
-Wreturn-type has been enabled by default, but with explicit -Wreturn-type and
__attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
--- Comment #42 from Jakub Jelinek ---
I think this one is not fixed yet, there is some pa hpux specific patch. See
e.g. #c39.
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
Created attachment 48368
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48368&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
||jakub at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from Jakub Jelinek ---
Assuming fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
at gcc dot gnu.org |jakub at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #19 from Jakub Jelinek ---
Fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10 Regression] |[8/9 Regression] Incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 89430, which changed state.
Bug 89430 Summary: A missing ifcvt optimization to generate csel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430
What|Removed |Added
--
||jakub at gcc dot gnu.org
Status|RESOLVED|REOPENED
--- Comment #13 from Jakub Jelinek ---
The testcases for which this has been filed are no longer optimized, that needs
more work for GCC11.
||jakub at gcc dot gnu.org
Last reconfirmed||2020-04-25
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Created attachment 48371
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48371&action=edit
gcc10-pr94755.patch
Untested fix.
|UNCONFIRMED |NEW
Target Milestone|--- |10.0
Ever confirmed|0 |1
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #5 from Jakub Jelinek ---
(In reply to Bence Szabó from comment #4)
> As a remark for 'same code with -std=c++14 and -std=c++17 here', I can
> confirm, the example you provided also produces same assembly for me in
> c++14 and c++17.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711
--- Comment #1 from Jakub Jelinek ---
So, what exactly needs changing on ARM?
>From quick skimming, maybe arm_return_in_memory, very likely
aapcs_vfp_sub_candidate, and maybe arm_needs_doubleword_align.
What about comp_not_to_clear_mask_str_un ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #7 from Jakub Jelinek ---
So, does:
struct empty_base {};
struct S : public empty_base { struct{}a[1]; };
S s, a[5];
__attribute__((noipa)) void
foo (int x, ...)
{
__builtin_va_list ap;
__builtin_va_start (ap, x);
if (x != 1 &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #10 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #9)
> At least, when using:
> gcc version 9.2.1 20190827 (Fedora MinGW 9.2.1-1.fc31) (GCC)
> and executing with Wine.
Yeah, I can clearly see it in the assembly th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
Jakub Jelinek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #12 from Jakub Jelinek ---
Another interesting test is:
struct S {};
void foo (int, int, int, int, int, int, int, int, int, S, S, S, S, int);
void baz (int, int, int, int, int, int, int, int, int, int);
int
bar ()
{
foo (1, 2, 3, 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #13 from Jakub Jelinek ---
Completely untested WIP patch:
--- gcc/config/i386/i386.c.jj 2020-04-27 13:50:39.529692389 +0200
+++ gcc/config/i386/i386.c 2020-04-27 14:03:12.479322957 +0200
@@ -16550,6 +16550,23 @@ ix86_is_empty_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780
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=94780
--- Comment #4 from Jakub Jelinek ---
Created attachment 48382
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48382&action=edit
gcc10-pr94780.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94783
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94663
--- Comment #3 from Jakub Jelinek ---
(In reply to Vladimir Makarov from comment #2)
> The best way to fix is to avoid to generate such code. But I don't know is
> it possible for this case.
I'm afraid that is hard, because the Intel intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
||easyhack,
||missed-optimization
Last reconfirmed||2020-04-27
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94800
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801
--- Comment #5 from Jakub Jelinek ---
In the source yes, but by the time the optimizer sees it on some targets x == 0
? 32 : __builtin_clz (x) could have been already optimized into just
__builtin_clz (x) depending on what the target macros say.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94798
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
at gcc dot gnu.org |jakub at gcc dot gnu.org
CC||jakub at gcc dot gnu.org
Last reconfirmed||2020-04-27
Version|unknown |10.0
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94797
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10 Regression] ICE in |[8/9 Regression] ICE in
||jakub at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Target Milestone|--- |8.5
--- Comment #3 from Jakub Jelinek ---
That folds it into
IMAGPART_EXPR <.MUL_OVERFLOW ((long long unsigned int) a++ ,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94809
--- Comment #4 from Jakub Jelinek ---
Created attachment 48390
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48390&action=edit
gcc10-pr94809.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94472
--- Comment #5 from Jakub Jelinek ---
No, we can't block GCC 10 release indefinitely, we are already behind the usual
schedule. We need to resolve the C++ ABI issues and get the release out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94809
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10 Regression] |[8/9 Regression] Different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94832
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94826
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
801 - 900 of 42688 matches
Mail list logo
