https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105040
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105040
--- Comment #1 from Andrew Pinski ---
https://stackoverflow.com/questions/70791879/im-getting-a-type-error-while-building-snfit-2-4-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105040
Bug ID: 105040
Summary: snfit-2.4.0 fails to build because of
/usr/include/c++/7/ostream:682:5: error: no type named
'type' in 'struct std::enable_if&>'
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104984
Den changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105030
--- Comment #3 from HaoChen Gui ---
(In reply to Richard Biener from comment #2)
> That occured to me as well - I think the answer is maybe. In principle
> foo() could launch a thread and make the 'atemp' available to it. As long
> as foo()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102598
--- Comment #2 from Johel Ernesto Guerrero Peña ---
Another test case: https://godbolt.org/z/Gsfx56GM9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104564
Alexandre Oliva changed:
What|Removed |Added
Last reconfirmed||2022-03-24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104967
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105002
--- Comment #5 from Kewen Lin ---
Patch was just posted at
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592204.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104967
--- Comment #3 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:497bde3ab92b2c292f78672db341bbb7cc1bcf1f
commit r12-7792-g497bde3ab92b2c292f78672db341bbb7cc1bcf1f
Author: Kewen Lin
Date: Wed Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105039
Bug ID: 105039
Summary: rust demangler stack overflow
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #13 from Piotr Kubaj ---
Is it possible there's an underlying bug in GCC and it only works on Linux
because the default for Linux for 32-bits is POWER7?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104975
Alexandre Oliva changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #12 from Segher Boessenkool ---
What I still cannot figure out is how you get TARGET_MFCRF with your
configuration and command line, so, ISA 2.01 . This is -m32 so *should*
default to -mcpu=7450. But apparently it uses the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100687
--- Comment #2 from Johel Ernesto Guerrero Peña ---
Another use case (Clang: https://godbolt.org/z/hTPsPbEhe) (GCC:
https://godbolt.org/z/96MqTvrKv):
`mod.cpp`:
```C++
export module mod;
export template
inline constexpr bool is_same_v = false;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104979
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104979
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:4cebae0924248beb2077894c6dc725c306fc0a69
commit r12-7790-g4cebae0924248beb2077894c6dc725c306fc0a69
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #11 from Piotr Kubaj ---
Unfortunately, this fails with the original issue:
/wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/xgcc
-B/wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105029
--- Comment #3 from Eyal Rozenberg ---
(In reply to Andrew Pinski from comment #2)
> You could backport the fix if you want.
I'd like to trouble you for a little more guidance, so that I can apply the fix
to 6.5.0.
Now, I understand the fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985
--- Comment #6 from Jakub Jelinek ---
Still can't reproduce.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105038
Bug ID: 105038
Summary: Improve error message for recursive type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105028
--- Comment #5 from seurer at gcc dot gnu.org ---
Thanks, that patch really improved things!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103337
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:2cd0c9a5310420e1039be5e514a818b6d381d89f
commit r12-7789-g2cd0c9a5310420e1039be5e514a818b6d381d89f
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
Segher Boessenkool changed:
What|Removed |Added
Attachment #52670|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620
--- Comment #2 from Marek Polacek ---
FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors, line 80)
FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors, line 84)
After r12-7264-gc19f317a78c0e4 these two errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104831
--- Comment #9 from Patrick O'Neill ---
Adding this comment to summarize why LR.aq/SC.rl doesn't appear to be
an issue.
The re-orderings shown in the previous litmus tests are allowed by the
C++/GCC definition of SEQ_CST. My reasoning in prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067
--- Comment #6 from Jonathan Wakely ---
(In reply to Jason Merrill from comment #4)
> Do other standard library implementations depend on the compiler to diagnose
> this?
I don't think they enforce it at all (it's IFNDR).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 104999, which changed state.
Bug 104999 Summary: [12 Regression] runtime error: pointer index expression
with base 0x0cf67720 overflowed to 0xea627728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104999
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104999
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620
Marek Polacek changed:
What|Removed |Added
Host|hppa*-*-linux* |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105037
Bug ID: 105037
Summary: gfortran emits incorrect debug information if compiled
with -finit-real=snan
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105023
--- Comment #6 from Segher Boessenkool ---
BLKmode is *not* valid for registers. reg:BLK at one time was a special
marker for invalid asm operands, apparently.
:BLK is for mem, and for parallel as well in some cases, but not for reg.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #9 from Piotr Kubaj ---
Now libgcc fails to configure.
>From config.log:
configure:3789: checking for suffix of object files
configure:3811: /wrkdirs/usr/ports/lang/gcc12-devel/work/.build/./gcc/xgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #10 from Aldy Hernandez ---
(In reply to Richard Biener from comment #9)
> I think threading unlikely paths is never worth it and usually NULL pointer
> checks are statically predicted.
>
> I guess one idea would be to scale BB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105006
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:e8cd3edc0fc6c02a732dcecf519c22d835e5f422
commit r12-7788-ge8cd3edc0fc6c02a732dcecf519c22d835e5f422
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987
--- Comment #5 from Jakub Jelinek ---
And it is unclear to me how it could get the sign of the multiplication wrong,
it is a normal SImode mul which multiplies the values of SImode r6 and r7
registers.
As it isn't hipart multiply or something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104987
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067
--- Comment #5 from Jason Merrill ---
Created attachment 52674
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52674=edit
patch
Like so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067
--- Comment #4 from Jason Merrill ---
(In reply to Jason Merrill from comment #3)
> Hmm? but the standard says that a precondition for std::is_constructible is
> the type being complete, and we enforce that with a static_assert (since
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
--- Comment #5 from Martin Jambor ---
(In reply to Richard Biener from comment #4)
> Does this still happen after the last fiddling?
Unfortunately yes, the run-time is still 27% worse than when compiled with the
commit previous to the one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105023
--- Comment #5 from Jakub Jelinek ---
BLKmode is valid mode for larger aggregate arguments and return values.
As documented:
"The return value is usually either a @code{reg} RTX for the hard
register in which to pass the argument, or zero to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103560
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103560
--- Comment #8 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:5e33fea21957c97d63e3738be6056ae2a94e3284
commit r12-7787-g5e33fea21957c97d63e3738be6056ae2a94e3284
Author: Tobias Burnus
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105023
--- Comment #4 from Segher Boessenkool ---
It never even executes rs6000_function_arg for that testcase. What are you
doing differently? ... Oh, C++. Duh.
It happens because we do
return gen_rtx_REG (mode, gregno);
which is perfectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105019
--- Comment #6 from Tom de Vries ---
(In reply to Tom de Vries from comment #4)
> OK, I think this is the pattern:
> ...
> $ cat gcc/testsuite/gcc.target/nvptx/alias-5.c
FTR, same thing if I use static functions:
...
static void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
--- Comment #10 from Martin Sebor ---
The purpose of the internal_p flag documented in the attr_access class is more
general than to tell a VLA-like argument from an ordinary array/pointer form
("Set for an attribute added internally rather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104285
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
--- Comment #8 from Richard Biener ---
(In reply to Andrew Macleod from comment #5)
> Looking at the strlen1 output, it only ever asks ranger about 6 names:
>
> 334 range_of_expr(_36) at stmt _52 = iftmp.1_17 + _36;
> TRUE :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
--- Comment #7 from Andrew Macleod ---
and I forgot to show to dom3 output which did the transformation:
j.c.195t.dom3:Match-and-simplified (sizetype) nb_66 to 18446744073709551615
j.c.195t.dom3:Optimizing statement _2 = (sizetype) nb_66;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125
--- Comment #11 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:d9792f8d227cdd409c2b082ef0685b47ccfaa334
commit r12-7786-gd9792f8d227cdd409c2b082ef0685b47ccfaa334
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105028
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:1daa198aafd72925ca8dd8616385f523ff180d4a
commit r12-7785-g1daa198aafd72925ca8dd8616385f523ff180d4a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #8 from Piotr Kubaj ---
Testing.
FYI, on 12-20220227, .machine power4 is used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
--- Comment #6 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #4)
> (In reply to Richard Biener from comment #3)
> > This is peeling leaving us with unreachable code we warn on and somehow
> > while figuring prephitmp_30 + -6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
--- Comment #5 from Andrew Macleod ---
(In reply to Richard Biener from comment #3)
> This is peeling leaving us with unreachable code we warn on and somehow
> while figuring prephitmp_30 + -6 is -1 we don't figure nb_58 is zero on
> the path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> This is peeling leaving us with unreachable code we warn on and somehow
> while figuring prephitmp_30 + -6 is -1 we don't figure nb_58 is zero on
> the path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105013
Martin Liška changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105013
--- Comment #4 from James Allwright ---
I have re-run with the suggested options --track-origins=yes and -s :
$ valgrind --track-origins=yes -s ./bug
==16956== Memcheck, a memory error detector
==16956== Copyright (C) 2002-2017, and GNU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985
--- Comment #5 from Martin Liška ---
Created attachment 52673
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52673=edit
auto-host.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #20 from Jakub Jelinek ---
Note, for ntpoff the listed instructions are:
movl %gs:0,%eax
leal x@ntpoff(%eax),%eax
rather than addl. But certainly this one was never meant to be taken
pedantically as that instruction sequence only,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985
--- Comment #3 from Martin Liška ---
No, it's still there and you will likely need cross GAS to reproduce it:
~/Programming/gcc/configure --enable-languages=c,c++
--prefix=/home/marxin/bin/gcc --disable-multilib --enable-host-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #19 from Jakub Jelinek ---
If it is the linker, you can always objdump -dr the binary to see what is in
there after linking. s@ntpoff in my understanding is a relocation that should
supply at link time the offset from the TLS base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103769
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101636
Richard Biener changed:
What|Removed |Added
Known to work||11.2.1
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104782
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:893cb28a22f86281ca9ce1e045da7b8840ceb121
commit r11-9689-g893cb28a22f86281ca9ce1e045da7b8840ceb121
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101636
--- Comment #18 from CVS Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:893cb28a22f86281ca9ce1e045da7b8840ceb121
commit r11-9689-g893cb28a22f86281ca9ce1e045da7b8840ceb121
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104931
--- Comment #11 from CVS Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:d1f4dfd409dedf4d00ca7be001cf757d0d6e82f4
commit r11-9688-gd1f4dfd409dedf4d00ca7be001cf757d0d6e82f4
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #16)
>> I've wrapped that in a small test programming, calling foo both from the
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105028
--- Comment #3 from seurer at gcc dot gnu.org ---
Thanks for looking at this. It has been bugging me at a low level for months.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
--- Comment #7 from Jakub Jelinek ---
Consider e.g.
void bar (int *);
int
foo (int *a, int *b, int *c, int *d)
{
for (int i = 0; i < 1024; i++)
a[i] = a[i] * b[i] + (c[i] - d[i]);
bar (a);
return 42;
}
with -m32 -O3 -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035
--- Comment #7 from Patrick Palka ---
(In reply to Patrick Palka from comment #6)
> (In reply to Jakub Jelinek from comment #3)
> > Another option is to make sure we don't call
> > warn_duplicated_cond_add_or_warn
> > when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92067
--- Comment #3 from Jason Merrill ---
(In reply to Jonathan Wakely from comment #2)
> We need to be careful about this in SFINAE contexts. It can't be a hard
> error, because it's extremely common for constructors to be constrained with
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
--- Comment #20 from Jason Merrill ---
Created attachment 52672
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52672=edit
patch to make it an error for __is_constructible
Thus.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
--- Comment #6 from Ammar Faizi ---
(In reply to Jakub Jelinek from comment #4)
> If this is a macro that users should use in arbitrary user code, there is
> another problem, if something is vectorized in the function, either using
> AVX or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105017
--- Comment #4 from Martin Liška ---
(In reply to David Malcolm from comment #3)
> I'm assuming that this was a clang warning, and that this is fixed by the
> above commit; please reopen if it's still affected.
Thanks, it fixed the clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032
--- Comment #5 from Ammar Faizi ---
(In reply to Jakub Jelinek from comment #3)
> This has been hanging or ICEing on and off since forever.
> E.g. even r105000 ICEs, r20 works, r21 ICEs, r10-5912 works, r11-1
> hangs, so does current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105036
Bug ID: 105036
Summary: Missing variables when debugging due to overlapping
ranges after unrolling, instruction scheduling, and
inlining at -O3
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65891
James Legg changed:
What|Removed |Added
CC||jlegg at feralinteractive dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104985
Richard Biener changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104996
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105006
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a3f78748fab6b24e3d4a8b319afd3f8afa17248f
commit r12-7784-ga3f78748fab6b24e3d4a8b319afd3f8afa17248f
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105019
--- Comment #5 from Tom de Vries ---
Creating a CUDA example is hampered by the fact that there's no symbol alias
support, AFAICT.
I'd like to write something like:
...
__device__ void __foo ()
{
printf ("__foo\n");
}
__device__ void foo ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105017
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104997
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #7 from Segher Boessenkool ---
Created attachment 52670
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52670=edit
proposed patch
Does this help? The 7450 (which is what freebsd64 defaults to) indeed does
not support these
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105017
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:e6a3991ea15c0b14117b5693d77e15fd0477ce51
commit r12-7783-ge6a3991ea15c0b14117b5693d77e15fd0477ce51
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104271
Richard Biener changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #4 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035
--- Comment #4 from rguenther at suse dot de ---
On Wed, 23 Mar 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035
>
> Jakub Jelinek changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104997
--- Comment #3 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:160b095fc9ded4eaa2bf4d49bd97319f4aabff0a
commit r12-7782-g160b095fc9ded4eaa2bf4d49bd97319f4aabff0a
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105035
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162
Richard Biener changed:
What|Removed |Added
Target Milestone|12.0|13.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103775
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
1 - 100 of 158 matches
Mail list logo
