https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478
--- Comment #26 from Martin Liška ---
> Looking good! It fixes the testcase. Full build and check started.
Great, then I'm going to send the patch to mailing list. Thanks a lot for the
testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #4 from rdapp at linux dot ibm.com ---
Would this be ok?
diff --git a/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
b/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
index 44d85c04bfb..0d83384cd0a 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90519
G. Steinmetz changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #2 from G.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528
--- Comment #9 from Uroš Bizjak ---
(In reply to Richard Biener from comment #8)
> (In reply to Uroš Bizjak from comment #5)
> > Created attachment 46753 [details]
> > Conditionally generate DRAP reg for realigned stack
> >
> > This should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91553
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #5 from Uroš Bizjak ---
(In reply to rdapp from comment #4)
> Would this be ok?
>
> diff --git a/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
> b/gcc/testsuite/gcc.dg/wrapped-binop-simplify.c
> index 44d85c04bfb..0d83384cd0a 100644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88944
--- Comment #4 from Jonathan Wakely ---
The patch is pending, not committed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #7 from Jonathan Wakely ---
I can't believe that this has ever caused a real problem, or ever will cause a
real problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528
--- Comment #8 from Richard Biener ---
(In reply to Uroš Bizjak from comment #5)
> Created attachment 46753 [details]
> Conditionally generate DRAP reg for realigned stack
>
> This should be the correct patch, we call targetm.calls.get_drap_rtx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91552
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528
--- Comment #11 from Uroš Bizjak ---
(In reply to Richard Biener from comment #10)
> Will you apply it?
Sure, later today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528
--- Comment #7 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #6)
> (In reply to Uroš Bizjak from comment #3)
> > (In reply to Richard Biener from comment #1)
> >
> > HJ, can you please take the patch from here? Realignment stuff is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91557
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #8 from Richard Biener ---
Happens all over SPEC sources as well :/ Tacking more -std=legacy into
FFLAGS...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91531
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806
--- Comment #9 from Jonathan Wakely ---
**But**, as I said, I think it's OK to change the pb_ds types. We can use
inline namespaces to change the mangled names of the affected types, and the
user base of pb_ds is probably so tiny that it won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #7 from Uroš Bizjak ---
(In reply to rdapp from comment #6)
> (In reply to Uroš Bizjak from comment #5)
> > This approach is not OK, you should use lp64 effective target instead of
> > -m64 option. Please see many examples in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #8 from rdapp at linux dot ibm.com ---
> Yes, I think so.
Is this an OK to commit? :)
I checked it on s390 and x86_64 with -m64 and -m31/-m32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91530
--- Comment #5 from Jakub Jelinek ---
Created attachment 46764
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46764=edit
gcc10-pr91530-sse2.patch
Patch to hopefully fix the scan-{13,17}.c FAILs without avx_runtime.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #6 from rdapp at linux dot ibm.com ---
(In reply to Uroš Bizjak from comment #5)
> This approach is not OK, you should use lp64 effective target instead of
> -m64 option. Please see many examples in testsuite/gcc.dg.
>
> Also, x86 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #10 from Jonathan Wakely ---
I don't think it's possible to construct an example where this would misbehave.
If allocator_traits::is_always_equal is true for X then it implies that
operator== will return true for all values of X,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478
Martin Liška changed:
What|Removed |Added
Keywords||patch
--- Comment #27 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #10 from rdapp at gcc dot gnu.org ---
Author: rdapp
Date: Tue Aug 27 12:08:58 2019
New Revision: 274951
URL: https://gcc.gnu.org/viewcvs?rev=274951=gcc=rev
Log:
PR testsuite/91549
gcc/testsuite/ChangeLog:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91550
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91551
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91530
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Aug 27 10:45:55 2019
New Revision: 274947
URL: https://gcc.gnu.org/viewcvs?rev=274947=gcc=rev
Log:
PR libgomp/91530
* testsuite/libgomp.c/scan-11.c: Add -msse2 option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41731
--- Comment #2 from joseph at codesourcery dot com ---
https://gcc.gnu.org/ml/gcc-patches/2009-10/msg01016.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Tue Aug 27 12:37:30 2019
New Revision: 274952
URL: https://gcc.gnu.org/viewcvs?rev=274952=gcc=rev
Log:
PR c++/91415
* c-common.c (verify_tree): For LSHIFT_EXPR,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
--- Comment #3 from rguenther at suse dot de ---
On Tue, 27 Aug 2019, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
>
> Martin Liška changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806
--- Comment #8 from Jonathan Wakely ---
(In reply to Xi Ruoyao from comment #7)
> Oh I didn't expect an ABI breakage. I thought "pb_ds is a source code
> library so there is no ABI in libstdc++.so". Now I understand that we
> should not break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #9 from Uroš Bizjak ---
(In reply to rdapp from comment #8)
> > Yes, I think so.
>
> Is this an OK to commit? :)
>
> I checked it on s390 and x86_64 with -m64 and -m31/-m32.
OK. Please go ahead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558
Bug ID: 91558
Summary: [C++11] should not be constexpr until C++14
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415
--- Comment #10 from Jakub Jelinek ---
Partially fixed, needs more work, so keeping this open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #5 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #4)
> This might strictly conform to the requirements, but it's stupid. Why would
> you do that?
>
> Allocator equality doesn't care about the value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91549
--- Comment #3 from rdapp at linux dot ibm.com ---
This fails a lot more than it should. I'm looking into it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91541
--- Comment #6 from frankhb1989 at gmail dot com ---
(In reply to frankhb1989 from comment #5)
>
> And the noexcept exceptions provided in the current implementations are
> really inconsistent, for instance, between move operator= of std::list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91547
--- Comment #3 from Mateusz Szychowski ---
> The behaviour of that function is perfectly well defined.
> Yes because it is not useful and causes to print when there is no bug at all
> and wrapping behavior is expected. It was a decison that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528
--- Comment #10 from Richard Biener ---
(In reply to Uroš Bizjak from comment #9)
> (In reply to Richard Biener from comment #8)
> > (In reply to Uroš Bizjak from comment #5)
> > > Created attachment 46753 [details]
> > > Conditionally generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91562
--- Comment #1 from Martin Sebor ---
Author: msebor
Date: Tue Aug 27 16:18:27 2019
New Revision: 274961
URL: https://gcc.gnu.org/viewcvs?rev=274961=gcc=rev
Log:
gcc/testsuite/ChangeLog:
PR c++/83431
PR testsuite/91562
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91562
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83431
--- Comment #8 from Martin Sebor ---
Author: msebor
Date: Tue Aug 27 16:18:27 2019
New Revision: 274961
URL: https://gcc.gnu.org/viewcvs?rev=274961=gcc=rev
Log:
gcc/testsuite/ChangeLog:
PR c++/83431
PR testsuite/91562
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563
--- Comment #1 from Jonathan Wakely ---
The program's behaviour is undefined, because memset can't be used for writing
to non-trivially copyable types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91468
--- Comment #3 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01820.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478
--- Comment #28 from Martin Liška ---
Author: marxin
Date: Tue Aug 27 13:36:15 2019
New Revision: 274955
URL: https://gcc.gnu.org/viewcvs?rev=274955=gcc=rev
Log:
Share a prevailing name for remove debug info symbols w/ LTO.
2019-08-27 Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91559
Bug ID: 91559
Summary: math/x2y2m1q.c assumes FE_TONEAREST defined
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91560
Bug ID: 91560
Summary: Try harder for AVX non-AVX2 cross-lane permutations
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91560
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #10 from Jan Hubicka ---
> >
> > They aren't in the anonymous namespace, but they are themselves anonymous,
> > so they have no linkage. The standard says,
> >
> > A type without linkage shall not be used as the type of a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213
--- Comment #6 from Richard Biener ---
Hmm, I think I eventually wanted to backport it...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88652
--- Comment #5 from Martin Liška ---
>
> Looks like you're right :) I'll fix that, then.
>
Any update on this, please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554
--- Comment #2 from Zack Weinberg ---
Additional fun detail:
```
static inline int
thefun (void *a, void *b)
{
if (!__builtin_constant_p((__UINTPTR_TYPE__)b) || b != 0)
thefun_called_with_nonnull_arg();
return real_thefun(a, b);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90970
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558
Jonathan Wakely changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #2 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #9 from Martin Liška ---
(In reply to Jason Merrill from comment #8)
> (In reply to Jan Hubicka from comment #2)
> > 2.ii:62:3: warning: ‘ml_bssnrest_’ violates the C++ One Definition Rule
> > [-Wodr]
> >62 | } ml_bssnrest_;
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558
--- Comment #3 from Yichen Yan ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Yichen Yan from comment #0)
> > Detail:
> > Constexpr for is in C++14 if I don't misunderstand. But a lot of
> > testcases under
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554
--- Comment #3 from Richard Biener ---
It's obviously
8462 /* If this expression has side effects, show we don't know it to be a
8463 constant. Likewise if it's a pointer or aggregate type since in
8464 those case we only want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91554
--- Comment #4 from Zack Weinberg ---
(In reply to Richard Biener from comment #3)
> I guess you want to use
>
> __builtin_constant_p (b != 0)
>
> instead.
That wouldn't do what I want. The goal is to warn for any argument _other
than_ a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90613
--- Comment #1 from Martin Liška ---
@Nathan: May I please remind this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89623
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213
--- Comment #5 from Martin Liška ---
@Richi: Can we close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
--- Comment #10 from Martin Liška ---
@David: May I please remind this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88617
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91564
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91262
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91565
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> (In reply to G. Steinmetz from comment #0)
> > ICE hits gfortran-8 and higher - this changed just before 20180525.
> > Starting with correct code z0.f90, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Wed Aug 28 02:03:48 2019
New Revision: 274981
URL: https://gcc.gnu.org/viewcvs?rev=274981=gcc=rev
Log:
PR c++/91428 - warn about std::is_constant_evaluated in if constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81676
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180
Bug 89180 depends on bug 81676, which changed state.
Bug 81676 Summary: Wrong warning with unused-but-set-parameter within 'if
constexpr'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81676
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88082
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91570
Bug ID: 91570
Summary: [10 Regression] ICE in get_range_strlen_dynamic on a
conditional of two strings
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91570
Martin Sebor changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567
--- Comment #2 from Martin Sebor ---
Author: msebor
Date: Tue Aug 27 23:31:44 2019
New Revision: 274976
URL: https://gcc.gnu.org/viewcvs?rev=274976=gcc=rev
Log:
PR tree-optimization/91567 - Spurious -Wformat-overflow warnings building glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
Bug 85741 depends on bug 91567, which changed state.
Bug 91567 Summary: [10 Regression] Spurious -Wformat-overflow warnings building
glibc (32-bit only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567
Martin Sebor changed:
What|Removed |Added
Keywords||patch
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #15 from Jason Merrill ---
(In reply to Jason Merrill from comment #13)
> But that still doesn't make the types the same, and the use of the variable
> in 2.ii has undefined behavior because it is accessing the value of the
> object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83543
--- Comment #7 from Martin Sebor ---
Author: msebor
Date: Tue Aug 27 23:31:44 2019
New Revision: 274976
URL: https://gcc.gnu.org/viewcvs?rev=274976=gcc=rev
Log:
PR tree-optimization/91567 - Spurious -Wformat-overflow warnings building glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88617
--- Comment #3 from Daniel Santos ---
(In reply to Martin Liška from comment #2)
> @Daniel: Can you please take a look?
My apologies for missing this one! I'll take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563
--- Comment #5 from Guillaume Morin ---
Jakub mentioned that r273135 fixed the abort() in the trunk. I noticed that
this revision had already been backported to the gcc-9 branch as r274532. So I
built the gcc-9 branch and I can confirm that it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 91428, which changed state.
Bug 91428 Summary: Please warn on if constexpr (std::is_constant_evaluated())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91428
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81676
--- Comment #6 from Marek Polacek ---
Author: mpolacek
Date: Wed Aug 28 02:22:29 2019
New Revision: 274982
URL: https://gcc.gnu.org/viewcvs?rev=274982=gcc=rev
Log:
PR c++/81676 - bogus -Wunused warnings in constexpr if.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256
Eric Gallager changed:
What|Removed |Added
CC||ignat.loskutov at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994
Bug 16994 depends on bug 91002, which changed state.
Bug 91002 Summary: ICE in make_ssa_name_fn, at tree-ssanames.c:271 with VLA
type in reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91002
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91002
Eric Gallager changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91515
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91206
--- Comment #5 from Eric Gallager ---
(In reply to Nick Desaulniers from comment #4)
> Thanks for the feedback, in https://reviews.llvm.org/rL369791, Nathan made
> [unsigned] char -> [unsigned]short warn only for -Wformat-pedantic, not
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91571
Bug ID: 91571
Summary: TBAA does not work for ao_ref created by
ao_ref_init_from_ptr_and_size()
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91206
--- Comment #6 from Eric Gallager ---
(In reply to Eric Gallager from comment #5)
> (In reply to Nick Desaulniers from comment #4)
> > Thanks for the feedback, in https://reviews.llvm.org/rL369791, Nathan made
> > [unsigned] char ->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91568
Bug ID: 91568
Summary: internal compiler error: in
vect_schedule_slp_instance, at tree-vect-slp.c:3922
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91568
--- Comment #1 from Matt Wala ---
Created attachment 46768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46768=edit
Full compiler output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #13 from Jason Merrill ---
Ah, I was reading the passage a bit wrong: where the extern "C" matters is not
on the type, but on the variable (ml_bssnrest_). Because it's extern "C",
declarations in different translation units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
Jason Merrill changed:
What|Removed |Added
Attachment #46765|0 |1
is obsolete|
1 - 100 of 133 matches
Mail list logo
