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 ty
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 #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=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=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 an
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 th
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
--- a/gcc/testsuite/gcc.dg/wrapp
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=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=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=91557
Bug ID: 91557
Summary: [7/8/9/10 Regression] Bogus warning about unused dummy
argument _formal_*
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
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 D
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 GC
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=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=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=91541
--- Comment #8 from frankhb1989 at gmail dot com ---
(In reply to frankhb1989 from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > This might strictly conform to the requirements, but it's stupid. Why would
> > you do that?
> >
>
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=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=91557
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
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, **a
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=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 o
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=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 ac
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=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&root=gcc&view=rev
Log:
PR libgomp/91530
* testsuite/libgomp.c/scan-11.c: Add -mss
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 testsuit
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=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=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=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&root=gcc&view=rev
Log:
PR testsuite/91549
gcc/testsuite/ChangeLog:
* gcc.dg/w
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&action=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=91470
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
Status|UNCONFIRMED
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&root=gcc&view=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=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: li
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=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=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=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 liter
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&root=gcc&view=rev
Log:
Share a prevailing name for remove debug info symbols w/ LTO.
2019-08-27
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=91559
Bug ID: 91559
Summary: math/x2y2m1q.c assumes FE_TONEAREST defined
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lib
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 comp
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
Componen
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=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 W
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=90613
--- Comment #1 from Martin Liška ---
@Nathan: May I please remind this?
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=89623
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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 libstdc++-v3/testsu
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=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=88615
Martin Liška changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140
--- Comment #13 from Martin Liška ---
@Honza: Can we close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88083
--- Comment #2 from Martin Liška ---
@Ilya: Can we close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88081
--- Comment #6 from Martin Liška ---
@Honza: Reminder.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69572
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87501
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69571
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88140
--- Comment #14 from Jan Hubicka ---
> @Honza: Can we close this?
Array simplification is still disabled - we need to figure how how to
represent them...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87500
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88082
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91561
Bug ID: 91561
Summary: [Regression] Internal Compiler Error: type ‘ubyte[]’
can not be mapped to C++
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88082
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection
Status|UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #11 from Jason Merrill ---
Created attachment 46765
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46765&action=edit
clear TYPE_NAME in free_lang_data for anonymous types
Perhaps like this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91222
--- Comment #12 from Jan Hubicka ---
> Created attachment 46765
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46765&action=edit
> clear TYPE_NAME in free_lang_data for anonymous types
>
> Perhaps like this?
It seems that this will disa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91562
Bug ID: 91562
Summary: [10 regression] gcc.dg/strlenopt-8.c fails starting
with r274933
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91558
--- Comment #4 from Jonathan Wakely ---
(In reply to Yichen Yan from comment #3)
> (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563
Bug ID: 91563
Summary: [9 regression] wrong code
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
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&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:
PR c++/83431
PR testsuite/91562
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&root=gcc&view=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=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=91563
--- Comment #2 from Jakub Jelinek ---
Just a note from bisection, stopped aborting on trunk with r273135, and started
to abort in r260318.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91563
--- Comment #3 from Guillaume Morin ---
Jonathan,
Are you sure? I modified the code to print std::is_trivially_copyable::value
and it does print "1". Am I missing something obvious?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91564
Bug ID: 91564
Summary: [8/9/10 Regression] ICE in gimplify_expr, at
gimplify.c:14147
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528
--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Aug 27 17:23:59 2019
New Revision: 274962
URL: https://gcc.gnu.org/viewcvs?rev=274962&root=gcc&view=rev
Log:
PR target/91528
* config/i386/i386-features.c (co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91528
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91565
Bug ID: 91565
Summary: [8/9/10 Regression] ICE in gfc_simplify_reshape, at
fortran/simplify.c:6707 etc.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91566
Bug ID: 91566
Summary: [9/10 Regression] ICE in gfc_constructor_copy, at
fortran/constructor.c:103
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91567
Bug ID: 91567
Summary: [10 Regression] Spurious -Wformat-overflow warnings
building glibc (32-bit only)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords:
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
Severity:
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&action=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 correspon
1 - 100 of 141 matches
Mail list logo
