https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415
--- Comment #4 from Kewen Lin ---
(In reply to Peter Bergner from comment #3)
> (In reply to Kewen Lin from comment #2)
> > The contradictory thing is that we can have TARGET_VSX and TARGET_SOFT_FLOAT
> > (!TARGET_HARD_FLOAT) together with the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415
--- Comment #3 from Peter Bergner ---
(In reply to Kewen Lin from comment #2)
> The contradictory thing is that we can have TARGET_VSX and TARGET_SOFT_FLOAT
> (!TARGET_HARD_FLOAT) together with the proposed option combination. :)
I'm not sure w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
--- Comment #38 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:159b0f41adc4c8ead45e12a523470381ce716ff2
commit r13-5235-g159b0f41adc4c8ead45e12a523470381ce716ff2
Author: liuhongt
Date: Fri Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415
--- Comment #2 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #1)
> Soft float does not conflict with anything (anything that does not need
> FP registers that is). But yes, we really should neuter -mmodulo.
The contradictory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331
--- Comment #8 from Jerry DeLisle ---
Fixed ChangeLogs PR number referenced.
commit 04d7cc165387d19e1433a4b2157d2bde7b95305b (HEAD -> master, origin/master,
origin/HEAD)
Author: Jerry DeLisle
Date: Tue Jan 17 17:30:49 2023 -0800
Fix bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
--- Comment #13 from Jerry DeLisle ---
I will backport to 12 as it is an ice on Valid.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108276
--- Comment #7 from Himal ---
(In reply to niXman from comment #6)
> I think you don't understand me.
>
> with your patch after preprocessing the `unlink_if_ordinary()` will look
> like:
> ```
> int
> unlink_if_ordinary (const char *name)
> {
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108440
--- Comment #4 from Krister Walfridsson ---
I misread the comment -- it describes a possible future improvement (that I
believe is not allowed). But the committed patch seems to be correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106523
--- Comment #8 from Krister Walfridsson ---
This fixed most of the rotate issues my translation validation tool found. I
assume the remaining issues are due to a different (but similar) bug, so I
opened Bug 108440 for those.
But the issue in B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108440
--- Comment #3 from Krister Walfridsson ---
Hmm. I think this is the "Y equal to B case" from bug 106523. I.e., the bugfix
is not correct...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108440
--- Comment #2 from Krister Walfridsson ---
No, bug 106523 is a different issue (I have tested with a compiler that has
that fixed).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108440
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108440
Bug ID: 108440
Summary: rotate optimization may introduce new UB
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
--- Comment #6 from Andrew Pinski ---
Aliasing rules are NOT a local thing and they are not about what the type of
the pointer is, rather than they are about the access after the casting. They
are also global ...
GCC used to have strict aliasin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
--- Comment #5 from Georg Müller ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Georg Müller from comment #1)
> > Also, this compiler warning and execution error is removed by compiling with
> > -fno-strict-aliasing, but again,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108436
--- Comment #2 from H.J. Lu ---
Created attachment 54294
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54294&action=edit
Issue a warning for the invalid 3rd argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
--- Comment #4 from Andrew Pinski ---
(In reply to Georg Müller from comment #1)
> Also, this compiler warning and execution error is removed by compiling with
> -fno-strict-aliasing, but again, this does not look right.
Why do you think that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
--- Comment #2 from Georg Müller ---
Just a small additional note: The dependency on argc in the loop filling the
array in main() is only there to avoid early optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #1 from niXman ---
unfortunately, this bug is still present on the master branch...
trying to deal with it..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
--- Comment #1 from Georg Müller ---
Created attachment 54293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54293&action=edit
reduced test case to give a compile warning, which seems to be incorrect
While trying to reduce the problem and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108439
Bug ID: 108439
Summary: incorrect optimization with -O2, -O3, -Os
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108437
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108438
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2023-01-17
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #12 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Summary|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107214
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107965
--- Comment #8 from Jason Merrill ---
The compiler could represent this with a location list instead of a single
location. I guess implementing that would involve using NOTE_INSN_VAR_LOCATION
instead of giving the variable DECL_RTL? This sound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108429
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108434
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=108404
--- Comment #6 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #5)
> I've committed the patch above - since the source tree without it definitely
> has a mismatched prototype. The exit issue needs to be resolved before
> this PR ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108421
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108421
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:a75760374ee54768e5fd6a27080698bfbbd041ab
commit r13-5232-ga75760374ee54768e5fd6a27080698bfbbd041ab
Author: Harald Anlauf
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107965
--- Comment #7 from Gustaf Waldemarson ---
Very interesting to see so many people chime in on this. Since I arguably
agree that this looks like a GDB bug than an error in the printers. To that
end, I went ahead and registered this
[ticket](https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107886
--- Comment #18 from niXman ---
Created attachment 54291
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54291&action=edit
confirmation
it works for me. please look at attachment screenshot.
for GCC-master, configured as x86_64-w64-mingw3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730
--- Comment #14 from Gleb Mazovetskiy ---
The patch applies cleanly to the latest gcc-12 release and also fixes the issue
there btw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90826
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101823
--- Comment #4 from niXman ---
> The gcc I compiled generated wrong assembly code on Windows.
> This gcc is Canadian compiled from Ubuntu.
please provide the step-by-step instruction you used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101823
--- Comment #3 from niXman ---
> The gcc I compiled generated wrong assembly code on Windows.
> This gcc is Canadian compiled from Ubuntu.
what GCC version was used on the host?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106395
niXman changed:
What|Removed |Added
CC||i.nixman at autistici dot org
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105730
Lance Fredrickson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67046
--- Comment #5 from Lewis Hyatt ---
The patch was submitted for review here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609951.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108438
Bug ID: 108438
Summary: [10/11/12/13 Regression] ICE in
cxx_eval_constant_expression, at cp/constexpr.cc:7611
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108436
Andrew Pinski changed:
What|Removed |Added
Summary|[13 Regression] ICE in |ICE in gen_prefetch, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108437
Bug ID: 108437
Summary: [13 Regression] ICE in build_min_non_dep_op_overload,
at cp/tree.cc:3710
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108436
Bug ID: 108436
Summary: [13 Regression] ICE in gen_prefetch, at
config/i386/i386.md:24155
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108435
Bug ID: 108435
Summary: [13 Regression] ICE in as_a, at is-a.h:242
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108434
Bug ID: 108434
Summary: [12/13 Regression] ICE in class_allocatable, at
fortran/expr.cc:5000
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475
--- Comment #25 from Jason Merrill ---
This was clarified for C++ last year by http://wg21.link/cwg2535
I notice that C warn_for_null_address also warns about &p->mem; I don't know
where that is justified in the C standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108431
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #10 from Andrew Pinski ---
(In reply to Ian Lance Taylor from comment #9)
> I agree that if the middle-end is going to generate calls to builtin
> functions, it would be nice if the middle-end provided a function to call to
> define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #9 from Ian Lance Taylor ---
I agree that if the middle-end is going to generate calls to builtin functions,
it would be nice if the middle-end provided a function to call to define those
functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108426
--- Comment #7 from CVS Commits ---
The master branch has been updated by Ian Lance Taylor :
https://gcc.gnu.org/g:6d80690132a2f00fae1f619d4ffd950ce8cfdbc7
commit r13-5231-g6d80690132a2f00fae1f619d4ffd950ce8cfdbc7
Author: Ian Lance Taylor
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
Iain Sandoe changed:
What|Removed |Added
Attachment #54261|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102343
--- Comment #2 from Iain Sandoe ---
Created attachment 54289
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54289&action=edit
Patch for discussion
This applies on top of the patch for PR108182 (and will most likely not work
without those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
--- Comment #13 from Kito Cheng ---
Patch posted before, but seems like not everybody agree:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603049.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108404
--- Comment #5 from Gaius Mulley ---
I've committed the patch above - since the source tree without it definitely
has a mismatched prototype. The exit issue needs to be resolved before this
PR can close.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108433
--- Comment #2 from Andreas Schwab ---
The target libraries should not be built in a canadian cross build, they were
already produced while building the cross compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108413
--- Comment #9 from Gaius Mulley ---
I've git pushed some fixes for gcc/m2/mc/mcOptions.mod to obfuscate the
copyright text. The change to mcOptions.mod also includes the removal
of the 'YEAR' constant and it queries the system for the year. A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108433
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108433
Bug ID: 108433
Summary: canadian cross aarch64/x86_64/aarch64 fails to build
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77882
stefan.tauner at gmx dot at changed:
What|Removed |Added
CC||stefan.tauner at gmx dot at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108432
Bug ID: 108432
Summary: Analyzer fails to detect out-of-bounds issues within
loops
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #25 from Richard Biener ---
Andreas - can you backport this please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
Richard Biener changed:
What|Removed |Added
Summary|[12/13 Regression] ICE in |[12 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107629
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102343
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #15 from rguenther at suse dot de ---
On Tue, 17 Jan 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
>
> --- Comment #14 from Jakub Jelinek ---
> Dunno, bet we really want to introduce C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #14 from Jakub Jelinek ---
Dunno, bet we really want to introduce CLOBBER(bol) and only consider bol and
eol clobbers for the stack reuse (or e.g. the tree-ssa-live.cc *live_vars*
handling).
Wonder what amount of work it would be to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #13 from rguenther at suse dot de ---
On Tue, 17 Jan 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
>
> --- Comment #12 from Jakub Jelinek ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #13 from Kewen Lin ---
(In reply to Martin Liška from comment #11)
> One more test-case that started to ICE with the same revision:
>
> ./xgcc -B.
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c
> -mcp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423
Martin Liška changed:
What|Removed |Added
Summary|[12/13 Regression] ICE in |[12/13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108422
Martin Liška changed:
What|Removed |Added
Summary|[13 Regression] ICE: base |[13 Regression] ICE: base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108420
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108419
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2023-01-17
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108431
federico changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108417
--- Comment #7 from m.cencora at gmail dot com ---
Hmm, ok.
So if I wanted to workaround this in generic code, what kind of types should I
exclude from aggregate initialization? Any type that has a base class with a
tail padding? Or just the last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #12 from Segher Boessenkool ---
We really really REALLY should neuter -mmodulo. It is counter-productive
to have command-line flags for separate instructions at all (as opposed to
facilities), and it is downright destructive to have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #12 from Jakub Jelinek ---
(In reply to Richard Biener from comment #10)
> I think that's the usual pattern for the two other stack-slot sharing PRs we
> have. The liveness analysis makes wrong assumptions about CLOBBER and
> CLOBBE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #11 from Jakub Jelinek ---
struct S { S *p; S *q; S () {} ~S (); };
void bar (S *);
void
foo ()
{
S a, b;
bar (nullptr);
{
S c;
c.p = &a;
c.q = &b;
bar (&c);
}
bar (nullptr);
}
at -O2 gets roughly the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #10 from Richard Biener ---
(In reply to Jakub Jelinek from comment #9)
> And just statements that refer to those 3 variables that (incorrectly) share
> the stack slot + basic block boundaries.
> grep 'bias\|D.5698\|D.5681\|:' /tmp/0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
--- Comment #11 from Martin Liška ---
One more test-case that started to ICE with the same revision:
./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c
-mcpu=e300c2 -mmodulo -c
during RTL pass: reload
/home/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
Jakub Jelinek changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108396
--- Comment #5 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #3)
> Is it hard to add one for all (or many) of the legacy builtins? Do we want
> to test more than just if it compiles?
Btw, "legacy"... I thought (from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105769
--- Comment #8 from Jakub Jelinek ---
Using last night's trunk, it is:
#include
#include
#include
template
struct vec {
T dat[n];
vec() {}
explicit vec(const T& x) { for(size_t i = 0; i < n; i++) dat[i] = x; }
T& operator [](size_t i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108431
Bug ID: 108431
Summary: Loop variable reaching integer `huge` causes infinte
loop
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106523
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106523
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:001121e8921d5d1a439ce0e64ab04c5959b0bfd8
commit r13-5223-g001121e8921d5d1a439ce0e64ab04c5959b0bfd8
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430
Bug ID: 108430
Summary: [13 Regression] Wrong code with -msve-vector-bits=512
since r13-707-g68e0063397
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108429
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415
--- Comment #1 from Segher Boessenkool ---
Soft float does not conflict with anything (anything that does not need
FP registers that is). But yes, we really should neuter -mmodulo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108429
Richard Biener changed:
What|Removed |Added
Blocks||53947
--- Comment #2 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108429
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Target Mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108429
Bug ID: 108429
Summary: FAIL: gcc.target/i386/pr89618.c scan-tree-dump vect
"LOOP VECTORIZED"
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106075
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
1 - 100 of 104 matches
Mail list logo
