https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118196
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a326ecf5411897e975fb24696d3267bbe496627c
commit r15-6451-ga326ecf5411897e975fb24696d3267bbe496627c
Author: Jakub Jelinek
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118216
--- Comment #6 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #5)
> The obvious workaround is just initialize symval to 0.
I actually wanted to initialize it to something like 0xdeadbeef to make it
clear the value shouldn't be used,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118217
Andrew Pinski changed:
What|Removed |Added
Blocks||53947
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
--- Comment #32 from Andrew Pinski ---
(In reply to Rocco Tormenta from comment #31)
> Hello, I have another basic example. I encountered this issue today while
> trying to calculate the squared n-dimensional Euclidean distance between two
> poi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
Rocco Tormenta changed:
What|Removed |Added
CC||rocco at tormenta dot eu
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118225
Andrew Pinski changed:
What|Removed |Added
Known to fail||10.1.0, 11.1.0, 12.1.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118225
Bug ID: 118225
Summary: ICE: in build_class_member_access_expr, at
cp/typeck.cc:2983
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-checking, ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118224
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118224
--- Comment #2 from Andrew Pinski ---
https://inbox.sourceware.org/gcc-patches/zyutc1ifd_kye...@kam.mff.cuni.cz/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118224
--- Comment #1 from Andrew Pinski ---
-fno-malloc-dce ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118224
Bug ID: 118224
Summary: [15 Regression] Incorrect optimization with calloc
when the size exceeds SIZE_MAX
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118223
--- Comment #5 from Andrew Pinski ---
(In reply to Eric Gallager from comment #4)
>
> Because it takes a long time and wastes electricity.
If you are making huge refactoring of code, it will always require a full
rebuild anyways. Especially wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118222
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #4 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118222
Muqi changed:
What|Removed |Added
Resolution|INVALID |FIXED
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118223
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118179
--- Comment #6 from Jürgen Reuter ---
Created attachment 59993
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59993&action=edit
Reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118179
--- Comment #5 from Jürgen Reuter ---
Here is the reproducer:
module lexers
implicit none
private
public :: lexer_t
public :: lexer_init
type :: keyword_list_t
private
end type keyword_list_t
type :: lexer_t
private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118223
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118223
--- Comment #2 from Andrew Pinski ---
here is an example of how GCC handles an auto-generated file which is
definitely not stored in SCM:
```
TARGET_H = $(TM_H) target.h $(TARGET_DEF) insn-modes.h insn-codes.h
FLAGS_H = flags.h flag-types.h $(O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118223
--- Comment #1 from Andrew Pinski ---
GCC itself has auto-generated headers and are handled just fine in its
makefile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118223
Bug ID: 118223
Summary: Improve autodependency generation to avoid full
product build
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118222
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68235
--- Comment #6 from Andrew Pinski ---
(In reply to Martin Liška from comment #3)
> Can the bug be marked as resolved?
The testcases in PR 110906 are good examples of the issue here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110906
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68235
Andrew Pinski changed:
What|Removed |Added
CC||cassio.neri at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118216
--- Comment #5 from Andrew Pinski ---
The obvious workaround is just initialize symval to 0. Basically the missed
optimization is causing the uninitialized variable warning to become confused
when it comes dealing with sym_sec and not seeing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118216
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Created attachment 59992 [details]
> Semi-reduced
>
> The `h(&hasb);` here is important.
> That is from:
> ```
> symval = _bfd_merged_section_offset (abfd,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118216
Andrew Pinski changed:
What|Removed |Added
Known to fail||13.1.0
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118216
--- Comment #2 from Andrew Pinski ---
Created attachment 59992
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59992&action=edit
Semi-reduced
The `h(&hasb);` here is important.
That is from:
```
symval = _bfd_merged_section_offset (ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118216
Andrew Pinski changed:
What|Removed |Added
Keywords||false-positive
--- Comment #1 from Andr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118206
--- Comment #2 from Andrew Pinski ---
wait ifcombine is being run at -O0, that should not happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #22 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #21)
> diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc
> index 580f8c8407d..759eb99a645 100644
> --- a/gcc/fortran/iresolve.cc
> +++ b/gcc/fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118196
Arsen Arsenović changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118022
Arsen Arsenović changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118196
--- Comment #2 from Arsen Arsenović ---
fixed, thanks for the report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118221
--- Comment #6 from Trampas Stern ---
I have requested access to bugzilla for the binutils and can create a bug
report there.
Thanks
Trampas
On Fri, Dec 27, 2024 at 3:55 PM pinskia at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:
> https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #21 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #20)
Replying to myself:
> So if I come from the other side, which code to accept and which to diagnose,
> I tried:
>
> if (string->ts.type != BT_CHARACTER
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118218
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-12-27
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102170
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118221
--- Comment #5 from Trampas Stern ---
The project in attachment is a makefile project.
The readme.md has instructions on how to build in windows, by installing xpack
utility.
If you build in linux then just edit the path to the arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118221
--- Comment #4 from Trampas Stern ---
Created attachment 59991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59991&action=edit
sample makefile project demonstrating the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100779
Hubert Tong changed:
What|Removed |Added
CC||hstong at ca dot ibm.com
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #19)
> (In reply to kargls from comment #17)
> > I suppose the error in check.cc(gfc_check_f_c_string) that starts
> > with
> >
> > if (string->ts.typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118222
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #16 from Andrew Pinski ---
(In reply to Robin Dapp from comment #15)
> For me this fails even without -fsigned-char or -fwrapv on riscv.
Oh you know what I didn't test aarch64 originally, I was trying to avoid the
need of r15-3992-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118222
Bug ID: 118222
Summary: When adding fno-inline, the register does not follow
abi
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118221
--- Comment #3 from Andrew Pinski ---
GCC does not include objdump/assembler/linker, that is a seperate project
called binutils (https://sourceware.org/binutils/) which has its own versioning
and release scheme.
GCC also does not include the li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118221
--- Comment #2 from Trampas Stern ---
Yes!
I typically use xpack to install cross compiler with binutils.
I have verified that this issue does not exist before GCC 11. I have tested
that it exists with the latest version of arm-none-eabi 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80641
--- Comment #18 from Jan Hubicka ---
With -O3 we now get:
int main ()
{
[local count: 114863531]:
return 0;
}
-O2 offlines destructors which prevents us from optimizing away new()
int main ()
{
void * D.27676;
int * c$_M_finish;
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813
--- Comment #6 from Jan Hubicka ---
Patch to optimize operator[] to be again branchless posted
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672286.html
Main problem with auto-generating bt is that it needs change of conditional
from C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118221
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118221
Bug ID: 118221
Summary: gdb and objdump referencing functions that do no exist
in binary
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #15 from Robin Dapp ---
(In reply to Andrew Pinski from comment #14)
> (In reply to Robin Dapp from comment #13)
> > The #if 0 shouldn't be necessary, right?
>
> Correct, it is the same testcase as comment #7 except the plain char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #14 from Andrew Pinski ---
(In reply to Robin Dapp from comment #13)
> The #if 0 shouldn't be necessary, right?
Correct, it is the same testcase as comment #7 except the plain char is changed
to include signed explictly, e.g. `sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #13 from Robin Dapp ---
(In reply to Andrew Pinski from comment #11)
> I see sometimes we check the return value of maybe_resimplify_conditional_op
> and sometimes does not.
>
> E.g. in try_conditional_simplification we don't check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #12 from Andrew Pinski ---
Created attachment 59989
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59989&action=edit
testcase that fails on aarch64 with -O3 -march=armv9-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
Andrew Pinski changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
|a/show_bug.cgi?id=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47928
--- Comment #5 from Jerry DeLisle ---
I was not thinking about rewriting the whole thing, but rearranging enmasse may
be helpful if you know how to do that. I think we need to hear from others
though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88284
--- Comment #7 from sandra at gcc dot gnu.org ---
While Intel has revived the "Altera" name, the Nios II processor is still
listed as discontinued. I see they are offering ARM-based FPGA products again
instead.
For many years Altera (and later I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118220
Sam James changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
efined behavior.
On all nonzero optimization levels, GCC generates (x86_64, Intel syntax)
assembly similar to the following:
test:
movabs rax, -9223372036854775808
ret
Host system type: Arch Linux, x86_64 (with glibc, of course).
GCC information:
gcc version: 15.0.0 2024122
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88284
--- Comment #6 from Andrew Pinski ---
(In reply to Michael_S from comment #4)
> Deprecation of Nios2 was pushed by Intel that appears to have a love affair
> with RISC-V. But now Altera is spun off. Intel is no longer involved in
> technical side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26388
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
--- Comment #9 from Robin Dapp ---
Already during ifcvt we do
Setting value number of _46 to 1 (changed)
Replaced _44 <= 1 with 1 in all uses of _46 = _44 <= 1;
Value numbering stmt = _41 = _3;
Setting value number of _41 to _3 (changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117638
--- Comment #4 from Jan Hubicka ---
Both with assertions or without we offline _M_default_append which would be
better inlined. It is because main is known to be called once.
One difference is that non-assertion clobbers the vectors prior const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86276
--- Comment #2 from Jan Hubicka ---
With -O3 we now do quite well.
_Z4goodv:
.LFB1248:
.cfi_startproc
ret
.cfi_endproc
.LFE1248:
.size _Z4goodv, .-_Z4goodv
.p2align 4
.globl _Z3badv
.typ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117639
--- Comment #3 from Jan Hubicka ---
With -O3 -std=c++20
https://godbolt.org/z/3WKnn8rax
we inline but still get stuck on loop calling log and modifying errno.
Without -std=c++20 we reach --param max-inline-insns-auto. We need --param
max-inlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118219
Bug ID: 118219
Summary: Weird error: type of a component cannot be abstract.
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118214
--- Comment #7 from Sam James ---
Thank you jakub. Keeping trunk working is appreciated and makes things a lot
easier for testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118214
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #6 from Jakub Jelinek -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118124
--- Comment #4 from Jakub Jelinek ---
I've reverted the r15-6339-g40f243e91796671701ded90919d1ca32ba9076ad
commit for now in r15-6448-gd09628742bb17719360ff447a8e604f5c6801bdf
because it could take a week or two before the fix for this PR is app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118207
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118129
--- Comment #1 from Antony Polukhin ---
Division by zero is UB in C++ https://eel.is/c++draft/expr.mul#4 so looks like
the proposed optimization could be done even if `y` is not known to be
non-zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118207
--- Comment #6 from Jakub Jelinek ---
ICEs even in C:
struct A { unsigned char a; };
struct B { struct A b; };
static const unsigned char c[160] = {
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16,
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88284
--- Comment #5 from Sam James ---
(In reply to Michael_S from comment #4)
> Deprecation of Nios2 was pushed by Intel that appears to have a love affair
> with RISC-V. But now Altera is spun off. Intel is no longer involved in
> technical side of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88284
--- Comment #4 from Michael_S ---
Deprecation of Nios2 was pushed by Intel that appears to have a love affair
with RISC-V. But now Altera is spun off. Intel is no longer involved in
technical side of their business.
So, may be, before purging all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118214
--- Comment #5 from Jakub Jelinek ---
I see add_function_candidate calling
2570 t = implicit_conversion (parmtype, argtype, arg,
2571 /*c_cast_p=*/false, lflags,
complain);
where arg is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118218
Bug ID: 118218
Summary: GCC allows the instantiation of private nested classes
in a base class from a derived class in a multi-level
inheritance chain
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118214
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-12-27
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118196
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Arsen Arsenovic :
https://gcc.gnu.org/g:9a1cb52cae2d48d2fc18d01b534bf4e3203f0cc1
commit r15-6447-g9a1cb52cae2d48d2fc18d01b534bf4e3203f0cc1
Author: Arsen ArsenoviÄ
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118022
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Arsen Arsenovic :
https://gcc.gnu.org/g:5a41ab8da087617d785f563b76f5c2fd6600b4c0
commit r15-6446-g5a41ab8da087617d785f563b76f5c2fd6600b4c0
Author: Arsen ArsenoviÄ
Date:
Hello,
Samuel Thibault, le dim. 24 nov. 2024 15:18:31 +0100, a ecrit:
> Andreas Schwab, le dim. 24 nov. 2024 15:15:43 +0100, a ecrit:
> > On Nov 24 2024, Sergey Bugaev wrote:
> > > So are you saying that we always must mark any asm statement that
> > > might transfer control somewhere else w/o ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117941
--- Comment #6 from Mathieu Othacehe ---
(In reply to Richard Earnshaw from comment #5)
> > Is it then possible to have dwarf data on ARM in addition to the EABI
> > defined unwind section?
>
> I don't know, honesty, because I've not tried it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118217
Bug ID: 118217
Summary: Dot-product for square on difference of two small type
integers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #22 from ptomsich at gcc dot gnu.org ---
Agreed. It would be ideal not to have to deal with this in the store-forward
avoidance pass (i.e., catching it before or during lowering).
Given that the store-forward avoidance pass (mostly) c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118215
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118216
Bug ID: 118216
Summary: -Wmaybe-uninitialized false positive with -O1 or above
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118215
Bug ID: 118215
Summary: Miss runtime alias check for vectorization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tr
89 matches
Mail list logo
