https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110515
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110528
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-07-03
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110529
Bug ID: 110529
Summary: -Wanalyzer-null-dereference false nagetive with
`*arr[0] = 10086`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110527
--- Comment #2 from Jakub Jelinek ---
As mentioned, ASan can reliably detect out of bounds accesses into the fairly
small redzone around variables, for out of bounds accesses with larger distance
it is a lottery whether one hits some other varia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110529
--- Comment #1 from mengli ming ---
It's a little odd that there is no output (https://godbolt.org/z/GhshzvaTq) for
`_analyzer_eval(1)` in line 9 and line 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #17 from Christophe Lyon ---
Thanks Andrew, I wasn't aware of vect_float_strict.
I confirm it makes the test UNSUPPORTED.
Can you commit the fix or do you want me to do it on your behalf?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #18 from Andrew Pinski ---
(In reply to Christophe Lyon from comment #17)
> Thanks Andrew, I wasn't aware of vect_float_strict.
> I confirm it makes the test UNSUPPORTED.
>
> Can you commit the fix or do you want me to do it on your
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110530
Bug ID: 110530
Summary: Local variable unexpectedly assigned to zero during
passing as an argument
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #19 from CVS Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:8cb087d869be698a86b082a7248d03e468ef1eb1
commit r14-2254-g8cb087d869be698a86b082a7248d03e468ef1eb1
Author: Christophe Lyon
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
--- Comment #20 from Christophe Lyon ---
Sorry for the typo in the date in the commit message :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110506
--- Comment #7 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:000590c074615cbfffb6ad854a6474e623801460
commit r14-2256-g000590c074615cbfffb6ad854a6474e623801460
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110506
--- Comment #6 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:bd7e9856fe5bbeb487797476c4fffb660f63cf4f
commit r14-2255-gbd7e9856fe5bbeb487797476c4fffb660f63cf4f
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110506
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110495
--- Comment #2 from rsandifo at gcc dot gnu.org
---
The point of the builder is that, if you know the pattern,
you don't need to supply every element value to the builder.
(And indeed you can't when the vector is variable length.)
So something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110530
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110528
--- Comment #3 from CTC <19373742 at buaa dot edu.cn> ---
Created attachment 55463
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55463&action=edit
The preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110495
--- Comment #3 from Richard Biener ---
OK, that's a reasonable stance give we have VL vectors. I'll note that
previously build_vector looked like the following, so TREE_OVERFLOW was
set according to the encoded elements. Now that's no longer t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110528
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110495
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110485
--- Comment #2 from Richard Biener ---
Btw, the math.h header declares
__attribute__ ((__simd__ ("notinbranch"))) extern double pow (double __x,
double __y) __attribute__ ((__nothrow__ , __leaf__));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110310
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
Bug ID: 110531
Summary: Vect: slp_done_for_suggested_uf is not initialized in
tree-vect-loop.cc
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110125
--- Comment #5 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:b0762d4c7e7894845e70e839c8513ae4c9e9d42e
commit r14-2263-gb0762d4c7e7894845e70e839c8513ae4c9e9d42e
Author: Gaius Mulley
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
Kewen Lin changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110125
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
LTO compression algorithms: zlib
gcc version 14.0.0 20230703 (experimental) [master r14-2244-g1ebf37ece3] (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110524
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|Internal compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252
--- Comment #13 from Andrew Pinski ---
*** Bug 110532 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110532
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110530
--- Comment #2 from Haiqing Zhao ---
(In reply to Andrew Pinski from comment #1)
> This code is undefined for 2 reasons.
>
> First is unsigned int and unsigned long are 2 different sizes on LP64
> targets (x86_64-linux-gnu is one of those, whil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680
--- Comment #11 from David Sicilia ---
Does anyone know which version of gcc this fix will be available in? Will it
be merged into 13.1 or does it have to wait until 13.2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110533
Bug ID: 110533
Summary: [x86-64] naked with -O0 and register-passed
struct/int128 clobbers parameters/callee-saved regs
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109680
--- Comment #12 from Jonathan Wakely ---
13.1 has already been released, it can't be changed now.
As comment 10 says, the fix is only on trunk so far and has not been backported
to the gcc-13 branch. It will be in the next 13.x release after it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
Costas Argyris changed:
What|Removed |Added
CC||costas.argyris at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110534
Bug ID: 110534
Summary: confusing -Wuninitialized when strict aliasing is
violated
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|NEW
Summary|[13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973
--- Comment #12 from Jakub Jelinek ---
Wrong-code issues like this shouldn't be just closed.
I think you should ping Uros on this, or another option would be to revert on
the branch the change that caused the regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110522
--- Comment #1 from Roman Lebedev ---
To spell it out explicitly, not storing the resulting `.sarif`
next to the produced object file itself, like it's done in (all?)
other cases, very much looks like a not-a-feature,
basically making the featur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108835
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:e79c65331190bef99c88062c77d557d161caf380
commit r13-7525-ge79c65331190bef99c88062c77d557d161caf380
Author: Iain Sandoe
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944
--- Comment #14 from CVS Commits ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:025a3f417899577710eb88527897fc571a0280ff
commit r13-7526-g025a3f417899577710eb88527897fc571a0280ff
Author: Iain Sandoe
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108743
--- Comment #11 from CVS Commits ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:12897414d309d9cf398259c212923aa7b031a3af
commit r13-7528-g12897414d309d9cf398259c212923aa7b031a3af
Author: Iain Sandoe
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #6 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #5)
> Constraints are completely the wrong tool for this. Just use modes, which
> *are* the right tool?
Well you cannot specify modes in the asm, so I think you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110534
--- Comment #1 from Andrew Pinski ---
There are different levels of -Wstrict-aliasing and iirc level 3 will warn.
Note I don't think the uninitialized warning is a bad thing here. Because it
does point out gcc is thinking it is uninitialized du
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110534
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99768
Andrew Pinski changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 110534, which changed state.
Bug 110534 Summary: confusing -Wuninitialized when strict aliasing is violated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110534
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110535
Bug ID: 110535
Summary: Internal error when performing a surrogate call with
unsatisfied constraints
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106895
--- Comment #7 from Andreas Schwab ---
You are probably looking for a constraint that mirrors the quad_int_reg_operand
predicate.
cxx::__normal_iterator > >; _UnaryOperation =
make_type_param_vector(const
std::initializer_list&)::]',
inlined from 'std::vector make_type_param_vector(const
std::initializer_list&) [with TypeParam = unsigned char; T = int]' at
:10:17:
/opt/compiler-explorer/gcc-trunk-2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
--- Comment #6 from Costas Argyris ---
Part of this may be because the driver::finalize function introduced here:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9376dd63e6a2d94823f6faf8212c9f37bef5a656
is not called from main:
int
main (i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110536
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110535
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-07-03
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110533
--- Comment #1 from Andrew Pinski ---
>clobbering other parameters and callee-saved registers.
(insn 2 8 3 2 (set (reg:DI 84)
(reg:DI 5 di [ aD.2522 ])) "/app/example.cpp":3:25 -1
(nil))
(insn 3 2 4 2 (set (reg:DI 85)
(reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110534
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
Sergei Trofimovich changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110510
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:d0a333612bfb7faf8d61210c831165388e758768
commit r14-2270-gd0a333612bfb7faf8d61210c831165388e758768
Author: Andrew Pinski
Date: Sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110510
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #25 from Sergei Trofimovich ---
Specifically this bug.c.034t.ccp1's bit looks fishy:
...
Folding statement: LookupFlags_14 = 1;
Queued stmt for removal. Folds to: 1
Folding statement: LookupFlags_15 = 0;
Queued stmt for removal. F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110528
Andrew Pinski changed:
What|Removed |Added
Summary|Timeout with with specific |selective scheduling seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110528
--- Comment #5 from Andrew Pinski ---
Here is a testcase which does not go into an infinite loop but takes a little
more than 4 seconds to compile which is a lot:
```
static unsigned short g_231 = 1UL;
void func_61(unsigned p_62) {
unsigned ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110528
--- Comment #6 from Andrew Pinski ---
With selective scheduling on my reduced testcase:
```
Time variable usr sys wall
GGC
phase setup: 0.00 ( 0%) 0.01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #2 from Hao Liu ---
> Is the warning from some static analyzer?
No. I just find it maybe a bug while looking at the code.
> slp should be true always (always do analyze slp), it doesn't care what's in
> slp_done_for_suggested_uf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #3 from Kewen Lin ---
(In reply to Hao Liu from comment #2)
> > Is the warning from some static analyzer?
>
> No. I just find it maybe a bug while looking at the code.
>
> > slp should be true always (always do analyze slp), it doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #4 from Hao Liu ---
> IMHO, the initialization with false is unnecessary and very likely it isn't
> able to get optimized, it seems worse from this point of view.
Sorry. I don't think so. See more at
https://www.oreilly.com/library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #5 from Hao Liu ---
BTW, there is no warning is probably because the original code is too
complicated and not inlined.
Compile the simple case by "g++ -O3 -S -Wall hello.c":
int foo(bool a) {
bool b;
if (a || b)
return 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170
--- Comment #10 from Hongtao.liu ---
There're couple of other issues.
1. rtx_cost for and/ior/xor:SF/DF is not right, it actually generate vector
instructions.
2. branch_cost is COSTS_N_INSN(1) instead of BRANCH_COST ().
which make noce more con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110537
Bug ID: 110537
Summary: ICE for OpenMP loop with SVE (aarch64) intrinsics
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018
Andrew Pinski changed:
What|Removed |Added
CC||pgodbole at nvidia dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110537
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #26 from Richard Biener ---
(In reply to Sergei Trofimovich from comment #24)
> Trying to understand the failure mode here:
>
> In bug.c.033t.early_objsz I still see the explicit stores to LocalFlags:
>
>:
> LookupFlags_15 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
YunQiang Su changed:
What|Removed |Added
CC||syq at gcc dot gnu.org
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110531
--- Comment #6 from Kewen Lin ---
It's an arguable topic, I can't find the thread that previously some reviewers
told me it's not always good to initialize the local variable. IIRC, the case
is that I initialized one variable at the top, but the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
74 matches
Mail list logo
