https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
--- Comment #7 from Jakub Jelinek ---
I guess that is reasonable thing to do, if the two vector types aren't really
compatible one will get an error.
But then, for trunk, won't the stripping of the attributes from vector types
still mean that com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96393
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
--- Comment #13 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #12)
> > So with the attached 'updated patch' I see
> >
> > === gnat tests ===
> >
> >
> > Running target unix/
> > FAIL: gnat.dg/debug11_pkg.adb sc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
--- Comment #15 from Jakub Jelinek ---
Unless we want for C/C++ to emit DW_AT_external DIEs for all function
prototypes that appear in the TU, we need ME help, because only there we
analyze the callgraph and prune cgraph nodes that are unreachab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
--- Comment #18 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #17)
> Well, not sure - FEs do quite a good job with unused warnings by
> simply tracking things with TREE_USED so I guess global extern decls
> can be tracked as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
--- Comment #20 from Jakub Jelinek ---
lang_hooks.finalize_early_debug_info ?
In the default definition move there just the
/* Emit early debug for reachable functions, and by consequence,
locally scoped symbols. */
struct c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96399
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
--- Comment #23 from Jakub Jelinek ---
I guess one question is what will e.g. LTO do when merging a DECL_IGNORED
DECL_EXTERNAL FUNCTION_DECL with !DECL_IGNORED definition.
||jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-08-03
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Created attachment 48985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96354
--- Comment #21 from Jakub Jelinek ---
Created attachment 48987
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48987&action=edit
gcc11-pr96354.patch
So like this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96415
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
,
||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Or handle that during VRP with symbolic ranges. But am not sure to what extent
symbolic ranges are going to stay.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96402
--- Comment #9 from Jakub Jelinek ---
Should be fixed now for 10.3+ and 11+. If -moutline-atomics has been
backported to older releases, it should go there too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96450
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.0
: go
Assignee: ian at airs dot com
Reporter: jakub at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
libgo doesn't build for me anymore on i686-linux on the trunk, last good build
was July 30, and last night's build failed with:
/
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r11-2453-gc89366b12ff4f36253bae125b794cbe687f7e40b the pr68766.c testcase
ICEs on x86_64-linux, with:
./cc1 -quiet -O2 -ftree-vectorize -fdbg-cnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96451
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |11.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95731
--- Comment #4 from Jakub Jelinek ---
I think doing it only in the last reassoc would have the advantage that it
wouldn't break other optimizations done by reassoc.
E.g.
if (a >= 0 && b >= 0 && a < 32 && b < 128)
which can be now optimized into a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||jakub at gcc dot gnu.org
Summary|[11 Regression] wrong code |[11 Regression] wrong code
|with -Og -march=cascadelake |with -Og -march=cascadelake
||since r11-1445
Last reconfirmed
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
#include
int
main ()
{
int niters = 0, i, j, k;
#pragma omp teams reduction(+:niters)
{
#pragma omp distribute collapse(3)
for (i = 0; i < 3; i++)
for (j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96459
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=96459
--- Comment #2 from Jakub Jelinek ---
Created attachment 48994
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48994&action=edit
gcc11-pr96459.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96459
--- Comment #3 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #0)
> if (niters != 96)
if (niters != 108)
Can't count, sorry.
Last reconfirmed||2020-08-05
CC||jakub at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from Jakub Jelinek ---
Started with r8-565-g7581ce9a1ad6df9c8998a3c74256837a1ff6f7cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96480
--- Comment #2 from Jakub Jelinek ---
That commit changes the pre-reassoc2 dump like:
--- pr96480.ii.172t.printf-return-value2_ 2020-08-05 07:22:42.0
-0400
+++ pr96480.ii.172t.printf-return-value22020-08-05 07:23:32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96480
--- Comment #3 from Jakub Jelinek ---
Simplified testcase:
int v[4];
int
foo (int x)
{
int *p;
if (x == 0)
p = &v[0];
else if (x == 1)
p = &v[1];
else if (x == 2)
p = &v[2];
else if (x == 3)
p = &v[3];
else
p = &v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96480
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=96485
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96485
--- Comment #2 from Jakub Jelinek ---
[[gnu::no_sanitize_undefined]] instead of the GNU __attribute__ is accepted,
but as the C++ specification requires it applies to the type not the
declaration and therefore it is ignored.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96492
--- Comment #3 from Jakub Jelinek ---
Can you run
gdb --args ./cc1 -quiet -fself-test=../../gcc/gcc/testsuite/selftests /dev/null
-o /dev/null
and do
run
bt
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82004
--- Comment #44 from Jakub Jelinek ---
Sorry if my comment sounded harsh.
Anyway, the older issue I was referring to was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53073 with SPEC2k6 464.h264ref.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96480
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10/11 Regression] |[8/9/10 Regression] missed
dot gnu.org |jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2020-08-07
--- Comment #1 from Jakub Jelinek ---
Created attachment 49018
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49018&acti
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Created attachment 49019
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49019&action=edit
gcc11-pr96497.patch
Untested fix.
|NEW
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
Summary|Incorrect with with -O |[9/10/11 Regression]
|-fno-tree-pta |Incorrect with with -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96522
--- Comment #2 from Jakub Jelinek ---
Slightly adjusted testcase that aborts if miscompiled:
/* { dg-do run } */
/* { dg-options "-O -fno-tree-pta" } */
__attribute__((noipa)) void
bar (void)
{
volatile int v = 1;
if (v)
__builtin_abort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96522
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
||jakub at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Jakub Jelinek ---
The error is correct. __builtin_va_arg_pack_len or __builtin_va_arg_pack can't
work in functions that are not inlined.
And the documentation you refer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96527
--- Comment #3 from Jakub Jelinek ---
The extern inline __attribute__((__gnu_inline__)) usecase comes from actual
code (e.g. glibc) where it is used this way a lot, I'm not aware of anybody
using static inline __attribute__((__always_inline__)) t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96424
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96549
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=96549
--- Comment #2 from Jakub Jelinek ---
Created attachment 49033
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49033&action=edit
gcc11-pr96549.patch
Untested fix.
||jakub at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-08-10
--- Comment #1 from Jakub Jelinek ---
unsigned char
foo (unsigned int x)
{
_Bool y = x;
return (((unsigned char) ~0) >> y) * 2;
}
unsigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96545
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=96542
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542
--- Comment #4 from Jakub Jelinek ---
As for COND_EXPR, if we do it that way, it should be rather keyed on a range
with only two possible values in the range.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #2 from Jakub Jelinek ---
If FAIL is defined, your myfunc will always trigger undefined behavior if
called, and as such anything can happen.
Derefencing NULL is UB.
If you are on an embedded system where there is memory mapped, you ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96539
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96550
--- Comment #7 from Jakub Jelinek ---
The compiler can't diagnose this as an error (unless -Werror* is used), because
it is only an error if such code is ever called at runtime, which the compiler
can't determine at compile time.
That is why it i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96554
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96497
--- Comment #4 from Jakub Jelinek ---
Should be fixed for 11, I think we should backport to 10.3 too eventually.
|--- |11.0
Status|UNCONFIRMED |NEW
CC||jakub at gcc dot gnu.org,
||msebor at gcc dot gnu.org
Summary|New maybe use of|[11 Regression] New
||guojiufu at gcc dot gnu.org,
||jakub at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Target Milestone|--- |10.3
Ever confirmed|0 |1
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96535
--- Comment #4 from Jakub Jelinek ---
Created attachment 49039
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49039&action=edit
gcc11-pr96535.patch
Ugh, process_options is called only once and thus I believe processing of
options with Opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96535
Jakub Jelinek changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96549
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11 Regression] Wrong|[10 Regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96539
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #3 from Jakub Jelinek ---
Either the test can be skipped on nvptx or any targets that don't emit
something like a .zero similar directive, or we should after the size of
variable is too large diagnostic throw the initializer away (set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96566
--- Comment #4 from Jakub Jelinek ---
Note, on x86_64-linux we'd likely time out on the adjusted testcase during
assembly (unless it would will up the disks before that).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96535
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=96566
--- Comment #7 from Jakub Jelinek ---
I'm not sure a target specific option is the way to go here, the only
difference is that nvptx spends all the time on this (adjusted) testcase at
compile time (and eats all disk space there too), while on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96545
--- Comment #4 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95450
--- Comment #6 from Jakub Jelinek ---
The problem is that this gl_LDBL_MAX.ld is really the right maximum normalized
double double number, but is one ulp larger than GCC's __LDBL_MAX__.
The former is:
0x1.f7c000p+1023
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95450
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95450
--- Comment #8 from Jakub Jelinek ---
Or as an ugly hack for floating types with MODE_COMPOSITE_P (TYPE_MODE (mode))
in that spot, after using native_interpret_expr do native_encode_expr again and
compare if the bits are identical (or perhaps do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95450
--- Comment #9 from Jakub Jelinek ---
Created attachment 49045
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49045&action=edit
gcc11-pr95450.patch
Untested fix. Or as I said, it could be limited to
&& COMPOSITE_MODE_P (element_mode (type
||2020-08-11
Status|UNCONFIRMED |NEW
Target Milestone|--- |10.3
CC||jakub at gcc dot gnu.org
Component|c |tree-optimization
Summary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94077
--- Comment #4 from Jakub Jelinek ---
So add -fcommon to the gcc8/gcc9 version then?
What the test wants to test is whether the optimize attribute is propagated
properly...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94077
--- Comment #5 from Jakub Jelinek ---
I mean -fno-common, sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96571
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96587
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96558
Jakub Jelinek changed:
What|Removed |Added
CC||zsojka at seznam dot cz
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96587
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96539
--- Comment #6 from Jakub Jelinek ---
But it doesn't have to kick everywhere, it depends on lots of target details
whether it will do a noop copy or not.
|RESOLVED
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
That is just a user error, you didn't read the XChangeProperty man page.
"If the specified format is 16, the property data must be a short
arra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
--- Comment #4 from Jakub Jelinek ---
Printing the numbers in detail (for all of them the long double and the two
double portions after that)):
a -0x1.f1d5d27f89914ab924b2cd0995p+69 -0x1.f1d5d27f89915000p+69
0x1.51b6d34cbd9ac000p+15
b -0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
--- Comment #5 from Jakub Jelinek ---
Actually, I think this is a glibc bug rather than gcc, because the values
computed at compile time look right, rather than those at runtime.
Consider:
int e = 69;
int main() {
long double a =
-__builtin_lde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
Jakub Jelinek changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96600
Jakub Jelinek changed:
What|Removed |Added
URL||https://sourceware.org/bugz
|1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Created attachment 49057
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49057&acti
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r10-6087-g991b91497fd50f6e70e5f2c0cfa96e1b74157bdc
the following testcase (distilled from firefox) ICEs with -flto
-flto-fat-objects -g:
struct A { A (int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690
--- Comment #2 from Jakub Jelinek ---
Maybe related to or same as PR93028, but that one is missing a test, so hard to
say.
||2020-08-20
CC||jakub at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #3 from Jakub Jelinek ---
The __builtin_trap is there because of:
if (isEmptyBucket(oldEntry)) {
do { if
-bisection, needs-reduction
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, slyfox at gcc dot gnu.org,
unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96721
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96722
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, slyfox at gcc dot gnu.org,
unassigned at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96717
--- Comment #4 from Jakub Jelinek ---
I've moved the #c3 issues into PR96721 and PR96722 as they are separate. And
either this bug turns a dup of the former, or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96721
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96721
--- Comment #1 from Jakub Jelinek ---
More reduced testcase:
typedef int *T;
int
main ()
{
T a = nullptr;
a.~T ();
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96721
--- Comment #2 from Jakub Jelinek ---
build_trivial_dtor_call has:
if (INDIRECT_TYPE_P (TREE_TYPE (instance)))
{
if (VOID_TYPE_P (TREE_TYPE (TREE_TYPE (instance
goto no_clobber;
instance = cp_build_fold_indirect_ref
|P2
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96758
--- Comment #2 from Jakub Jelinek ---
Created attachment 49109
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49109&action=edit
gcc11-pr96758.patch
Untested fix. cmpsiz has been computed incorrectly and while the code had the
intent to ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96721
--- Comment #3 from Jakub Jelinek ---
Created attachment 49110
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49110&action=edit
gcc11-pr96721.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96722
--- Comment #3 from Jakub Jelinek ---
Created attachment 49111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49111&action=edit
gcc11-pr96722.patch
If *0 ={v} {CLOBBER}; is supposed to be a fancy nop, then we should ignore it
during path i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96690
--- Comment #6 from Jakub Jelinek ---
Without LTO, gen_remaining_tmpl_value_param_die_attribute will try to get it,
and will mangle the foo decl, but shortly after will throw it away due to
const_ok_for_output failing on it.
Your patch makes sens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96761
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
1401 - 1500 of 36563 matches
Mail list logo
