https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96886
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #13 from Richard Biener ---
Note we can still overflow locations so I wonder if we can have a more
forgiving failure mode? Return UNKNOWN_LOCATION maybe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #12 from Richard Biener ---
For PHIs we could use the cache but I see we're simply dropping the BLOCKs
there (now that block location is encoded in the location we _do_ have
a location BLOCK there as well).
At least
/* Do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96885
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #14 from Richard Biener ---
so
void
lto_location_cache::input_location_and_block (location_t *loc, tree *block,
struct bitpack_d *bp,
class lto_input_block *ib,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96834
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96892
Bug ID: 96892
Summary: wrong __stack_chk_guard for comparison
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96881
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-09-02
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96886
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.3
Priority|P3
f4(); }
void f2() {printf("2\n"); f3(); }
void f1() {printf("1\n"); f2(); }
int main(int argc, char** argv){ f1(); }
This produces the error on aarch64:
gcc test.c -S -w
gcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96894
Bug ID: 96894
Summary: Analyzer assumes pointer is NULL, even if pointer was
tested to be non-null before
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96834
--- Comment #7 from z.zhanghaijian at huawei dot com ---
(In reply to Richard Biener from comment #5)
> (In reply to z.zhanghaij...@huawei.com from comment #4)
> > The case like:
> > test.c:
> > int f31() { }
> > void f30() { print
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96886
Martin Liška changed:
What|Removed |Added
Known to fail||10.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96886
--- Comment #3 from Tobias Burnus ---
(In reply to Andy May from comment #0)
> Looks like a regression between 10.1.0 and 10.2.0. test.f90:
I think that's the same issue as reported in PR 94672 comment 12 last week –
which has been fixed very re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #5 from emilie.feral at numworks dot com ---
When compiling without the lto using the command:
arm-none-eabi-gcc main.c -Os -mfloat-abi=hard -mthumb -mcpu=cortex-m4
-ffreestanding -nostdlib -lgcc -save-temps -o a.elf
I get the followi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96888
Richard Biener changed:
What|Removed |Added
Blocks||53947
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96893
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-09-02
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
Bug ID: 96895
Summary: ABI of returning V1DF differs between GCC and clang
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608
Pekka S changed:
What|Removed |Added
CC||p...@gcc-bugzilla.mail.kaps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96877
--- Comment #5 from Jonathan Wakely ---
(In reply to Ian Henriksen from comment #3)
> The goal of doing it that way was get the exception specification onto the
> pointer type in C++11 and C++14. The intent was to get the equivalent of
>
> typed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #15 from Jakub Jelinek ---
Short reproducer:
$ cat pr94311.c
#line 210
static inline __attribute__((always_inline)) void
foo (void)
{
int a = 23;
}
#line 65570
volatile int v;
#define A { int b = 42; foo (); }
#define B A A A A A A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94301
--- Comment #2 from Richard Biener ---
OK, so the ICE is the vectorizers fault in generating BLKmode vectors.
What remains is the missed optimization on __VEC_PERM:
typedef double v2df __attribute__((vector_size(16)));
typedef double v4df __att
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96759
--- Comment #2 from Kito Cheng ---
It work on GCC 9, GCC will split that into two plain move instead of move from
a (subreg (parallel [(reg) (reg)])).
(insn 23 22 24 (set (reg:SI 83)
(reg:SI 10 a0)) "g++.target/riscv/pr96759.C":8:38 -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851
--- Comment #2 from Jonathan Wakely ---
The instructions at https://gcc.gnu.org/bugs are clear about providing the
commands used to compile, please remember to state that you used -std=c++20 (a
godbolt URL is not sufficient).
The branch using me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96893
--- Comment #2 from z.zhanghaijian at huawei dot com ---
(In reply to Richard Biener from comment #1)
> Please provide a script to generate the testcase. A backtrace would be nice
> as well, likely the stack blows up.
cat gen.sh
#!/bin/bash
ech
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #16 from Jakub Jelinek ---
One possible way at the libcpp side is to make sure we don't deplete the
location_t stuff too much once we are above highest >
LINE_MAP_MAX_LOCATION_WITH_COLS. I mean, the comment above this if block says:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
Eric Botcazou changed:
What|Removed |Added
CC|ebotcazou at gcc dot gnu.org |
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96882
--- Comment #6 from Richard Earnshaw ---
Yes, the problem is related to returning values in memory and the ABI variants
we have. If we have hardware floating-point we generally use registers to
return values; if we don't, then we have to return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96896
Bug ID: 96896
Summary: Bogus 'Different ranks in pointer assignment' with
'array-variable = scalar' if LHS is a function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b567d3bd302933adb253aba9069fd8120c485441
commit r11-2978-gb567d3bd302933adb253aba9069fd8120c485441
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93689
bastien penavayre changed:
What|Removed |Added
CC||bastien.penavayre at epitech
dot e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96896
--- Comment #1 from Tobias Burnus ---
The error occurs for the LHS of:
myshape(b) = 0.0
reshape_test:_F.DA0 => myshape[[((reshape_test:b(FULL)))]]
(gfc_debug_expr output)
(gdb) p lvalue->rank
$9 = 0
(gdb) p rvalue->rank
$10 = 2
Maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93689
--- Comment #7 from bastien penavayre ---
somewhat related 93595 ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93595 )
is still in UNCONFIRMED state.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96897
Bug ID: 96897
Summary: Failure to optimize not+not+dec+and+not to add+or
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96897
--- Comment #1 from Marc Glisse ---
We already transform to
return ~(-2 - x) | x;
so this is really asking for
~(-2 - x) --> x + 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96898
Bug ID: 96898
Summary: [nvptx] libatomic support
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96893
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96893
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Martin Liška ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
--- Comment #2 from Michael Matz ---
The psABI doesn't say anything about such types, no. Maybe it could in some
additional info pages, but it's always a problem to codify behaviour
retroactively
in it, when conflicting implementations already e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
H.J. Lu changed:
What|Removed |Added
URL||https://gitlab.com/x86-psAB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
--- Comment #4 from H.J. Lu ---
(In reply to Michael Matz from comment #2)
> The psABI doesn't say anything about such types, no. Maybe it could in some
> additional info pages, but it's always a problem to codify behaviour
> retroactively
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899
Bug ID: 96899
Summary: [10.2 Regression] [SH] Bootstrap fails when building
libgomp
Product: gcc
Version: 10.2.0
URL: https://buildd.debian.org/status/fetch.php?pkg=gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #17 from Jakub Jelinek ---
Created attachment 49175
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49175&action=edit
gcc11-pr94311.patch
Untested patch which implements location and block caching and the above test
passes with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #8 from acsawdey at gcc dot gnu.org ---
Another small test case, reduced from my compile failure of c/c-typeck.c and
modified to provoke truncation from POImode to various other modes:
typedef int *a;
struct b { a ba; };
enum c { c1=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
--- Comment #5 from Richard Biener ---
(In reply to Michael Matz from comment #2)
> The psABI doesn't say anything about such types, no. Maybe it could in some
> additional info pages, but it's always a problem to codify behaviour
> retroactivel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
--- Comment #6 from Richard Biener ---
(In reply to Richard Biener from comment #5)
> (In reply to Michael Matz from comment #2)
> > The psABI doesn't say anything about such types, no. Maybe it could in some
> > additional info pages, but it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899
Richard Biener changed:
What|Removed |Added
Summary|[10.2 Regression] [SH] |[10 Regression] [SH]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96897
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96899
--- Comment #2 from John Paul Adrian Glaubitz ---
(In reply to Richard Biener from comment #1)
> Did it work with GCC 10.1?
Yes. I'm currently performing some test builds and will hopefully start
bisecting soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895
--- Comment #7 from Michael Matz ---
(In reply to Richard Biener from comment #5)
> So vector types with element type T and N, a power-of-two, not otherwise
> specified are passes the same as
>
> struct S { T a[N] };
>
> ?
No. structs, if the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96822
seurer at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:2f983fa69005b603ea1758a013b4134d5b0f24a8
commit r11-2981-g2f983fa69005b603ea1758a013b4134d5b0f24a8
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #46 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:2f983fa69005b603ea1758a013b4134d5b0f24a8
commit r11-2981-g2f983fa69005b603ea1758a013b4134d5b0f24a8
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96814
Martin Liška changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851
--- Comment #4 from milasudril at gmail dot com ---
Actually, I did not even try without the c++20 flag:
template< class T, std::size_t N >
bool operator<( const std::array& lhs,
const std::array& rhs );
(3) (until C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851
--- Comment #5 from Jonathan Wakely ---
(In reply to milasudril from comment #4)
> Actually, I did not even try without the c++20 flag:
That's irrelevant. The bug happens when using c++20, so the bug report should
include the options necessary t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96897
Gabriel Ravier changed:
What|Removed |Added
Summary|Failure to optimize |Failure to optimize sub+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #26 from Jonathan Wakely ---
(In reply to Manuel López-Ibáñez from comment #22)
> My point is that the fix cannot be only limited to tweaking stdbool.h, as
> long as any C++ mode still defines false as a macro.
As I said in comment 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:33c34c4c2466fd4fd050ed8e2d5996c35ebdeef6
commit r10-8702-g33c34c4c2466fd4fd050ed8e2d5996c35ebdeef6
Author: Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96851
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #27 from Jonathan Wakely ---
The original testcase gets a warning even for -std=c++98 now, thanks to
dmalcolm's r268589 (included in GCC 9.1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
Jonathan Wakely changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93317
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69194
Jonathan Wakely changed:
What|Removed |Added
CC||max.kan...@nu-cost.com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92978
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:c71644776f4e8477289a4de16239dbb420db6945
commit r11-2983-gc71644776f4e8477289a4de16239dbb420db6945
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92978
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:31782bd45331ef3006f624d7b1cc9cd11b4abb84
commit r10-8703-g31782bd45331ef3006f624d7b1cc9cd11b4abb84
Author: Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194
Jonathan Wakely changed:
What|Removed |Added
CC||max.kan...@nu-cost.com
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93317
--- Comment #3 from Jonathan Wakely ---
Oops, wrong bug number, I meant PR 64194
*** This bug has been marked as a duplicate of bug 64194 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96900
Bug ID: 96900
Summary: bogus -Warray-bounds on strlen with valid pointer
obtained from just-past-the-end
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96877
--- Comment #6 from Ian Henriksen
---
Thanks, this makes sense. I originally got this idea from
https://stackoverflow.com/a/27489923. The discussion there implied there was
some kind of ambiguity in the standard and showed some examples where ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96901
Bug ID: 96901
Summary: [11 Regression] Many libstdc++ tests FAIL on
i686-linux due to a PCH FE bug
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96900
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96901
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56109
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96901
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86419
--- Comment #6 from Jonathan Wakely ---
Thanks for the analysis.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96902
Bug ID: 96902
Summary: internal compiler error in gimplify_scan_omp_clauses
with "!$omp target enter data" directive
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96902
Jakub Jelinek changed:
What|Removed |Added
Component|libgomp |fortran
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96903
Bug ID: 96903
Summary: [11 regression] excess errors from gcc.dg/pr89350.c
after r11-2973
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96904
Bug ID: 96904
Summary: [11 regression] excess errors from
old-deja.exp=g++.old-deja/g++.abi/cxa_vec.C after
r11-2979
Product: gcc
Version: 11.0
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96900
--- Comment #2 from Martin Sebor ---
The underlying cause is fold_nonarray_ctor_reference() returning a scalar zero
for apparently out-of-bounds references when determining the initializer for
s.a from &s.a[sizeof s.a]. Its caller, constant_byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96904
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96894
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905
Bug ID: 96905
Summary: ICE with consteval function: internal compiler error:
in cp_gimplify_expr, at cp/cp-gimplify.c:827
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #29 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:f049cda373d29ea1bce4065b24cbb392cdc5b172
commit r11-2985-gf049cda373d29ea1bce4065b24cbb392cdc5b172
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96904
--- Comment #2 from seurer at gcc dot gnu.org ---
Yup, thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96906
Bug ID: 96906
Summary: Failure to optimize __builtin_ia32_psubusw128 compared
to 0 to __builtin_ia32_pminuw128 compared to operand
Product: gcc
Version: 11.0
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907
Bug ID: 96907
Summary: [docs] document builtins for fputc and putc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905
--- Comment #2 from Marek Polacek ---
It looks like we've never cp_genericized the consteval function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81999
bastien penavayre changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96907
--- Comment #1 from Andrew Pinski ---
putc was added by g-b53b5aa509
fputc has been there since before 2003.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96869
--- Comment #3 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:f0a3bab43fda3084eaf1bdaac58936757f30ea35
commit r11-2988-gf0a3bab43fda3084eaf1bdaac58936757f30ea35
Author: Iain Buclaw
Date: Mon Au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96869
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905
--- Comment #3 from Jakub Jelinek ---
Yeah, we certainly never want to genericize them.
1 - 100 of 127 matches
Mail list logo
