https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105041
Surya Kumari Jangala changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
LGTM, thanks!
On Wed, Jun 15, 2022 at 7:48 PM Christoph Muellner
wrote:
>
> From: Christoph Müllner
>
> This adds T-Head's XuanTie C906 to the list of known cores as "thead-c906".
> The C906 is shipped for quite some time (it is the core of the Allwinner D1).
> Note, that the tuning struct for
LGTM, thanks for correcting the comments !
On Wed, Jun 15, 2022 at 7:47 PM Christoph Muellner
wrote:
>
> From: Christoph Müllner
>
> The current description of RISCV_CORE() does not match the
> implementation. This commit provides a fix for that.
>
> gcc/ChangeLog:
>
> *
Committed with a minor commit log fix, thanks!
>
> In rv32 regression test, this cases will report an error:
>
> "cc1: error: ABI requires '-march=rv32'"
>
> Add '-mabi' option will fix this.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/pr105666.c: New options.
^^^ here should be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #50 from Hongtao.liu ---
>
> On the RTL level likely simplify-rtx (or the variants used by combine)
> only have limited support for vector operations.
Instruction sequence window(more than 20 shift instructions) is too big for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533
--- Comment #49 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:1089d083117f28f3518f5ec3c7a153236cb92334
commit r13-1126-g1089d083117f28f3518f5ec3c7a153236cb92334
Author: liuhongt
Date: Tue May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105993
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105994
--- Comment #6 from Andrew Pinski ---
Note with -fsanitize=address at runtime, GCC does detect this:
Program returned: 1
=
==1==ERROR: AddressSanitizer: stack-use-after-scope on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105994
--- Comment #5 from Andrew Pinski ---
const bar& test = h(foo{t})
The temporary for foo here since it is not bound directly to the variable bar,
goes out of scope after the statement is finished.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105994
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105994
--- Comment #2 from Andrew Pinski ---
Hmm, but at -O1, strict aliasing is off so this should work ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105994
--- Comment #1 from Andrew Pinski ---
Since bar and foo are not the same/compatible types this violates aliasing
rules. They might be layout compatible but they are compatible. Two different
things.
Also
int a = g(foo{5});
int b = g(foo{99});
return a + b;
}
It happens with -O1 - and more specifically, as long as `-finline -ftree-ccp
-ftree-sra` are enabled.
Version: gcc version 13.0.0 20220615 (experimental) (GCC)
On Mon, Jun 13, 2022 at 8:54 PM Takayuki 'January June' Suwa
wrote:
>
>
> gcc/ChangeLog:
> * doc/invoke.texi: Document -mextra-l32r-costs= option.
> ---
> gcc/doc/invoke.texi | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
Committed to master.
--
Thanks.
-- Max
On Mon, Jun 13, 2022 at 8:54 PM Takayuki 'January June' Suwa
wrote:
>
> RTL expansion of substitution to [DS]Cmode hard register includes obstructive
> register clobber.
>
> A simplest example:
>
> double _Complex test(double _Complex c) {
> return c;
> }
>
> will be converted to:
>
On Mon, Jun 13, 2022 at 8:54 PM Takayuki 'January June' Suwa
wrote:
>
> When spilled DFmode registers are reloaded in, once loaded into a pair of
> SImode regs and then copied from that regs. Such unwanted reg-reg moves
> seems not to be eliminated at the "cprop_hardreg" stage, despite no
On Mon, Jun 13, 2022 at 8:54 PM Takayuki 'January June' Suwa
wrote:
>
> This patch offers better RTL representations against straightforward
> derivations from some tree optimizers' canonicalized forms.
>
> - rounding up to even, such as '(x + (x & 1))', is canonicalized to
> '((x + 1) & -2)',
On Wed, Jun 15, 2022 at 5:23 AM Takayuki 'January June' Suwa
wrote:
>
> On 2022/06/15 5:17, Max Filippov wrote:
> > Hi Suwa-san,
> hi!
>
> > This change results in a bunch of new regression test failures:
> > The code generated for e.g. gcc.c-torture/execute/921208-2.c looks like
> > this:
> oh,
On Wed, Jun 15, 2022 at 2:44 PM H.J. Lu via Gcc-patches
wrote:
>
> On Mon, Jun 13, 2022 at 9:01 AM Richard Biener
> wrote:
> >
> >
> >
> > > Am 13.06.2022 um 16:36 schrieb H.J. Lu :
> > >
> > > On Mon, Jun 13, 2022 at 3:11 AM Richard Biener
> > > wrote:
> > >>
> > >>> On Tue, Jun 7, 2022 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105860
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.4
On Wed, 15 Jun 2022 10:35:36 PDT (-0700), Vineet Gupta wrote:
Hi Wei,
On 6/8/22 02:35, jiawei wrote:
From: Jia-wei Chen
In rv32 regression test, this cases will report an error:
"cc1: error: ABI requires '-march=rv32'"
Add '-mabi' option will fix this.
gcc/testsuite/ChangeLog:
*
On 6/15/22 1:57 PM, David Faust wrote:
On 6/14/22 22:53, Yonghong Song wrote:
On 6/7/22 2:43 PM, David Faust wrote:
Hello,
This patch series adds support for:
- Two new C-language-level attributes that allow to associate (to "annotate" or
to "tag") particular declarations and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105962
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
-fanalyzer runs late compared to other code analysis tools, in that in
runs on the partially-optimized gimple-ssa representation. I chose this
point to run in the hope of easy integration with LTO.
As PR analyzer/105962 notes, this means that function inlining can occur
before the -fanalyzer
On Wed, 2022-06-15 at 09:33 -0400, Andrew MacLeod wrote:
> On 6/13/22 21:24, David Malcolm wrote:
> > On Mon, 2022-06-13 at 20:45 -0400, Aldy Hernandez wrote:
> > > Final implies we can't further derive from the derived class,
> > > right?
> > "final" on a vfunc implies that nothing overrides that
I've been using this tweak to the output of
-fdump-analyzer-exploded-graph in my working copies for a while;
the extra red nodes make it *much* easier to find the places where
diagnostics are being emitted (or rejected by the diagnostic_manager).
Successfully bootstrapped & regrtested on
Tested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1116-g44681d45473883.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/uninit-1.c: Add test coverage of attempts
to jump through an uninitialized function pointer, and of attempts
to pass an uninitialized value to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105962
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:63c073199491b7ec2261d39af51c02147c2f0daf
commit r13-1119-g63c073199491b7ec2261d39af51c02147c2f0daf
Author: David Malcolm
Date:
On Mon, Jun 13, 2022 at 9:01 AM Richard Biener
wrote:
>
>
>
> > Am 13.06.2022 um 16:36 schrieb H.J. Lu :
> >
> > On Mon, Jun 13, 2022 at 3:11 AM Richard Biener
> > wrote:
> >>
> >>> On Tue, Jun 7, 2022 at 9:02 PM H.J. Lu via Gcc-patches
> >>> wrote:
> >>>
> >>> Add
Hi Tom!
On 2022-05-13T16:20:14+0200, I wrote:
> On 2022-02-04T13:09:29+0100, Tom de Vries via Gcc wrote:
>> On 2/4/22 08:21, Thomas Schwinge wrote:
>>> On 2022-02-03T13:35:55+, "vries at gcc dot gnu.org via Gcc-bugs"
>>> wrote:
I've tested this using (recommended) driver 470.94 on
Hi,
This patch adds the `@no_sanitize' attribute to the D front-end.
The `@no_sanitize` attribute disables a particular sanitizer for this
function, analogous to `__attribute__((no_sanitize))'. The library also
defines `@noSanitize' to be compatible with the LLVM D compiler's
`ldc.attributes'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105975
--- Comment #7 from Thomas Schwinge ---
(In reply to rsand...@gcc.gnu.org from comment #4)
> Thanks for the reproducer.
Glad that this approach did work.
(In reply to rsand...@gcc.gnu.org from comment #6)
> Should be fixed now.
ACK, thanks.
Hi Jakub!
On 2022-06-15T10:46:30+0200, Jakub Jelinek wrote:
> On Tue, Jun 14, 2022 at 06:41:37PM +0200, Thomas Schwinge wrote:
>> On 2022-06-13T14:06:39+0200, Jakub Jelinek via Gcc-patches
>> wrote:
>> > OpenMP 5.2 changed once more what device numbers are allowed.
>>
>> > libgomp/
>>
>> >
On 6/14/22 22:53, Yonghong Song wrote:
>
>
> On 6/7/22 2:43 PM, David Faust wrote:
>> Hello,
>>
>> This patch series adds support for:
>>
>> - Two new C-language-level attributes that allow to associate (to "annotate"
>> or
>>to "tag") particular declarations and types with arbitrary
On 6/14/22 07:44, Jakub Jelinek wrote:
On Mon, Jun 13, 2022 at 03:53:13PM -0400, Jason Merrill via Gcc-patches wrote:
When not optimizing, we can't do anything useful with unreachability in
terms of code performance, so we might as well improve debugging by turning
__builtin_unreachable into a
k//binary-trunk-r13-1112-20220615134935-g49d14a841fd-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220615 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105986
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Dear all,
we need to check the POS (and LEN) arguments of bit intrinsics
when simplifying, e.g. when used in array constructors.
Otherwise we ICE. Found by Gerhard.
The fix is straightforward, see attached.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104871
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:82b771fd6cab421d92cc074a79f98389ac8569c3
commit r10-10848-g82b771fd6cab421d92cc074a79f98389ac8569c3
Author: Simon Wright
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105599
--- Comment #6 from Iain Sandoe ---
needed on 11.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104871
--- Comment #2 from CVS Commits ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:64f5efce03c248af7f51d600b5519f46f64eea48
commit r12-8486-g64f5efce03c248af7f51d600b5519f46f64eea48
Author: Simon Wright
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105599
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:58c0bc2b62cdbbe9d9677b448fe52a8c54044276
commit r12-8484-g58c0bc2b62cdbbe9d9677b448fe52a8c54044276
Author: Iain Sandoe
On Tue, Jun 14, 2022 at 05:26:49PM -0400, Lewis Hyatt wrote:
> Hello-
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902
>
> The attached patch resolves PR preprocessor/103902 as described in the patch
> message inline below. bootstrap + regtest all languages was successful on
> x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105986
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105986
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105923
--- Comment #7 from H.J. Lu ---
(In reply to Hongtao.liu from comment #6)
> > .L3:
> > subl%r13d, %r12d
> > cmpl$1, %r12d
> > je .L6
> > salq$4, %r13
> > vmovapd a(%r13), %xmm0
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105717
François Dumont changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|10.4
Hi,
This patch adds the visibility attribute to the D compiler, and library
helpers `@visibility' and `@hidden' to the run-time library.
The `@visibility' attribute is functionality the same as
`__attribute__((visibility))', and `@hidden' is a convenience alias to
`@visibility("hidden")' defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105992
Bug ID: 105992
Summary: memcmp(p, q, 7) == 0 can be optimized better on x86
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hi!
On Wed, Jun 15, 2022 at 04:19:41PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > Have you tried with different limits?
> I drafted cases(C code, and updated asm code) to test runtime costs for
> different code sequences: building constants with 5 insns; with 3
> insns and 2
Hi Wei,
On 6/8/22 02:35, jiawei wrote:
From: Jia-wei Chen
In rv32 regression test, this cases will report an error:
"cc1: error: ABI requires '-march=rv32'"
Add '-mabi' option will fix this.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr105666.c: New options.
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105989
--- Comment #2 from Michal Jankovič ---
Reading through gcc/cp/coroutines.cc, it seems like the coroutine frame is
indeed composed as a flat struct with fields for all the local variables,
temps, and special stuff needed by the actor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991
Marek Polacek changed:
What|Removed |Added
Host||powerpc64le-unknown-linux-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991
Bug ID: 105991
Summary: rldicl+sldi+add generated instead of rldimi
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105975
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
The recent internal-fn “clean-ups” triggered problems on nvptx
because some of the omp_simt_* patterns had modeless operands.
I wondered about adapting expand_fn_using_insn to cope with that,
but then the problem becomes: what should the mode of operand 0
be when there is no lhs? The answer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105975
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:9d2fe6d427b37755410bb4eb4ecce8382f2ebfc5
commit r13--g9d2fe6d427b37755410bb4eb4ecce8382f2ebfc5
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105969
--- Comment #3 from joseph at codesourcery dot com ---
Overlapping elements is simply a consequence of the zero-sized-objects
extension, I don't see anything invalid here to reject (though there might
be undefined behavior at runtime when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981
Richard Earnshaw changed:
What|Removed |Added
Summary|[10/11/12/13 regression]|[10/11/12 regression] Wrong
The code in gen_cpymem_ldrd_strd has been incorrect for big-endian
since r230663. The problem is that we use gen_lowpart, etc. to split
the 64-bit quantity, but fail to account for the fact that these
routines are really dealing with 64-bit /values/ and in big-endian the
ordering of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3
commit r13-1110-g8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3
Author: Richard Earnshaw
It turns out that 'implementation partition' is not a term used in the
std, and is confusing to users. Let's use the better term 'internal
partition'. While there, adjust header unit naming.
nathan
--
Nathan SidwellFrom 052d89537a4c09e1e1437042e2d1ea215656325f Mon Sep 17 00:00:00 2001
From:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983
--- Comment #7 from Jakub Jelinek ---
Created attachment 53146
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53146=edit
gcc13-pr105983.patch
Full untested patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #39 from Jakub Jelinek ---
GCC didn't crash with SIGILL. GCC was asked to compile a program with AVX2
instruction set, it has done that. When such a program is run on a hardware
that doesn't support some of its instructions, it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #38 from John Kanapes ---
(In reply to Jakub Jelinek from comment #37)
> User error.
True. But gcc should complain and handle user errors, not crash with SIGILL:(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983
--- Comment #6 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > --- gcc/match.pd.jj 2022-06-15 12:52:04.640981511 +0200
> > +++ gcc/match.pd2022-06-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983
--- Comment #5 from Richard Earnshaw ---
(In reply to Jakub Jelinek from comment #4)
> --- gcc/match.pd.jj 2022-06-15 12:52:04.640981511 +0200
> +++ gcc/match.pd 2022-06-15 15:28:55.916225336 +0200
> @@ -2379,14 +2379,14 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105938
--- Comment #3 from Richard Biener ---
That had a followup fix for nvptx, r13-285-ge7d9fdf5e0ee4c, which wasn't
backported yet it seems?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105938
Matthias Klose changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981
Richard Earnshaw changed:
What|Removed |Added
Target Milestone|--- |10.5
Summary|Wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105990
--- Comment #1 from Hongtao.liu ---
Another case
static short a;
static int b;
void foo(void);
void bar9_(void);
int main() {
char c;
b = a = 23;
for (; b <= 1;)
a = 1;
bar9_();
c = a >= 18 || 2 > 2 >> a ? 1 : 1 <<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105990
Bug ID: 105990
Summary: Dead code elimination failed at -O3
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
Hi all,
Tomorrow meeting will cancel since there are few new topics to discuss.
The next meeting will be two weeks later.
Regrads,
PLCT Jiawei
On 6/13/22 21:24, David Malcolm wrote:
On Mon, 2022-06-13 at 20:45 -0400, Aldy Hernandez wrote:
Final implies we can't further derive from the derived class, right?
"final" on a vfunc implies that nothing overrides that vfunc, but you
could still have further derived classes.
You can think of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
On 6/15/22 04:24, Richard Biener wrote:
diff --git a/gcc/match.pd b/gcc/match.pd
index 44a385b912d..54f53a1f988 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -489,6 +489,88 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (!overflow || TYPE_OVERFLOW_WRAPS (type))
(mult @0 {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981
Richard Earnshaw changed:
What|Removed |Added
Last reconfirmed||2022-06-15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105962
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #36 from John Kanapes ---
That's great news. Thank you so much:)
I have to ask: How did you come up with avx? You couldn't even reproduce the
problem in your new gccs on newer cpus...
I could live with a little better gcc
I clearly wasn't thinking straight when I wrote the arm_bfi_1_p
function and used XUINT rather than UINTVAL when extracting CONST_INT
values. It seemed to work in testing, but was incorrect and failed
RTL checking.
Fixed thusly:
gcc/ChangeLog:
PR target/105974
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105860
Martin Liška changed:
What|Removed |Added
Keywords||wrong-code
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #35 from John Kanapes ---
Changed all my Makefiles to use -mavx acceleration...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105870
--- Comment #7 from JUN SHA ---
Ping.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105974
Richard Earnshaw changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105974
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Earnshaw :
https://gcc.gnu.org/g:dc8071da0e89eab4935751f3b16745c95cbc0d30
commit r13-1108-gdc8071da0e89eab4935751f3b16745c95cbc0d30
Author: Richard Earnshaw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105917
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #34 from John Kanapes ---
You must be right. I checked in the web and found one more reference that says
it has only avx acceleration...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78492
--- Comment #6 from federico ---
I've attached a simple test program that confirms ICE on gfortran 11.3.0.
ICE is returned only if
- the non_overridable procedure is part of a generic type-bound interface
- that same generic is being called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #33 from Sam James ---
As far as I can tell, that CPU might have AVX, but not AVX2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78492
--- Comment #5 from federico ---
Created attachment 53145
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53145=edit
test program: call non_overridable function from generic interface within
polymorphic procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #32 from John Kanapes ---
AMD FX(tm)-8320 Eight-Core Processor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #31 from Sam James ---
What CPU do you have?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #30 from John Kanapes ---
I checked without the -mavx2 option, and it worked with -O3 optimization, even
with gcc 9.4.0:)
It seems that whatever problem is related to that option.
Have you tried it with -mavx2 option in 9.5 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105983
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
On 2022/06/15 5:17, Max Filippov wrote:
> Hi Suwa-san,
hi!
> This change results in a bunch of new regression test failures:
> The code generated for e.g. gcc.c-torture/execute/921208-2.c looks like this:
oh, PICed...
indirect (incl. via function pointer, virtual functions and of course PIC ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105950
--- Comment #29 from John Kanapes ---
Thx for trying it so fast.
I assume you have downloaded it, and no longer need the link:)
I have no problem with the -mavx2 option.
I have gcc 9.4.0, though. Have you tried it with it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732
--- Comment #22 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:b2f5dc82400fe04511b85caa8c80677f81eee415
commit r10-10846-gb2f5dc82400fe04511b85caa8c80677f81eee415
Author: Jakub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105860
--- Comment #2 from John Hodge ---
Created attachment 53144
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53144=edit
Reproduction, partially minimised and including assertion
Attached is an updated reproduction, that includes asserts.
1 - 100 of 185 matches
Mail list logo
