https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646
--- Comment #4 from vishwambhar.rathi at puresoftware dot com ---
I am not using any optimization flag in compiling. Where should I post about
this bug? Thanks.
From: xry111 at gcc dot gnu.org
Sent: 30 September
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111566
--- Comment #6 from CVS Commits ---
The master branch has been updated by Joern Rennecke :
https://gcc.gnu.org/g:f416a3fdbee32ae12b055b8e3e4ee11c3df7c117
commit r14-4353-gf416a3fdbee32ae12b055b8e3e4ee11c3df7c117
Author: Joern Rennecke
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110180
Sam James changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
--- Comment #5 from Andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #4 from Lukas Grätz ---
Sorry, just to clarify, whether I understood your two comments correctly.
Should foo() be inlined in the following example because flatten works
recursively?
void foo (void) {
// CODE
}
int bar_original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
--- Comment #8 from CVS Commits ---
The master branch has been updated by Patrick O'Neill :
https://gcc.gnu.org/g:04e772bbdcbc1cea67cd498c1a45e4360bf5f8e1
commit r14-4351-g04e772bbdcbc1cea67cd498c1a45e4360bf5f8e1
Author: Patrick O'Neill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111650
Bug ID: 111650
Summary: ICE in build_deref, at d/d-codegen.cc:1650
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Sergei Trofimovich changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
--- Comment #10 from Arsen Arsenović ---
ah, yeah, seems that the common thread is checking. my system compiler is
built with --enable-checking=yes,extra,rtl.
'make -j17 CXXFLAGS=-fno-checking' also seems to work around it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
--- Comment #7 from Patrick O'Neill ---
Thanks for the quick fix. Confirmed that changing both safe_grow ->
safe_grow_cleared resolves the bootstrap failure on rv64gc glibc.
Would it be possible to commit this fix as a stopgap (or rollback the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
--- Comment #6 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #4)
> This patch fixes the build for me; have not tested it otherwise.
It will make stuff slower but more correct.
I think it is up to the riscv maintainers to decide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645
--- Comment #3 from Steven Munroe ---
(In reply to Peter Bergner from comment #1)
> I see that we have created built-in overloads for signed and unsigned vector
> char through vector long long. That said, the rs6000-builtins.def only
> seems to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645
Steven Munroe changed:
What|Removed |Added
Attachment #56018|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> This patch fixes the build for me; have not tested it otherwise.
Actually both need to be _cleared:
vector_insn_infos.safe_grow_cleared (get_max_uid ());
ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
--- Comment #4 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #2)
> This is riscv specific.
> As the diagnostics explains, riscv_vector::vector_insn_info has non-trivial
> default
> constructor, so either it should be used only i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
--- Comment #1 from Andrew Pinski ---
What is the host compiler?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
--- Comment #8 from Sergei Trofimovich ---
With https://gcc.gnu.org/PR111647#c1 I'm convinced it's a gcc's source code bug
and we should not try to write calls like `poly_int<1, T>(1, 1)` with
mismatching arity.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111647
--- Comment #1 from Sergei Trofimovich ---
More realistic example extracted from gcc's poly_int:
// $ cat rtl-tests.cc
template struct poly_int {
template constexpr poly_int (const Cs &... cs)
: coeffs { cs... } {}
int coeffs[N];
};
#de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
Bug ID: 111649
Summary: [14 Regression] Bootstrap failure in stage 1 on
riscv*-*-* since r14-4348-g9d249b7e31e
Product: gcc
Version: 14.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639
--- Comment #3 from Jonathan Wakely ---
Ah, good to know, thanks.
Which versions of avr-libc are supported with gcc? The version of avr-libc in
Fedora has the macros, which means I can't build avr-gcc with the patch for pr
79700 applied.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639
--- Comment #2 from Georg-Johann Lay ---
(In reply to Jonathan Wakely from comment #0)
> The in avr-libc does things like this:
>
> extern double acos(double __x) __ATTR_CONST__;
> #define acosf acos/**< The alias for acos().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111648
--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Hi,
Sorry for the breakage, will take a look.
Thanks,
Prathamesh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111645
Peter Bergner changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
--- Comment #7 from Sergei Trofimovich ---
If I try to build the file with `clang++-16` I'm getting the following error:
In file included from /home/slyfox/dev/git/gcc/gcc/rtl-tests.cc:22:
In file included from /home/slyfox/dev/git/gcc/gcc/core
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108851
Pali Rohár changed:
What|Removed |Added
See Also|https://sourceware.org/bugz |https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111648
Bug ID: 111648
Summary: Wrong code at -O2/3 on x86_64-linux-gnu since
r14-3243-ga7dba4a1c05
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111644
Andre Vehreschild changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #2 from Andre V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Sergei Trofimovich changed:
What|Removed |Added
Depends on||111647
--- Comment #6 from Sergei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111647
Bug ID: 111647
Summary: g++ accepts different c++ on -fchecking= anf
checking=2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111644
Andre Vehreschild changed:
What|Removed |Added
Last reconfirmed||2023-09-30
Target|power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
--- Comment #5 from Sergei Trofimovich ---
The default value is `-fchecking=2` there. `-fchecking=0` and `-fchecking=1`
work fine. This means `-fchecking=` slightly alters c++ template instantiation.
I'll try to extract smaller example.
The fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
--- Comment #4 from Sergei Trofimovich ---
Looks like `-fchecking=1` and `-fno-checking` handle c++ a bit differently.
Two commands differing only in `-fno-checking`. One works, one does not:
```
$ /tmp/gb/./prev-gcc/xg++ -B/tmp/gb/./prev-gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111625
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111637
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111637
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:09b512466ce302833d1624045fc5fe5afe040f58
commit r14-4349-g09b512466ce302833d1624045fc5fe5afe040f58
Author: Jakub Jelinek
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111625
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:09b512466ce302833d1624045fc5fe5afe040f58
commit r14-4349-g09b512466ce302833d1624045fc5fe5afe040f58
Author: Jakub Jelinek
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646
--- Comment #2 from vishwambhar.rathi at puresoftware dot com ---
Thanks. I am using Ubuntu 20.04. Could this be related to that? Or should I
post it on qemu?
From: pinskia at gcc dot gnu.org
Sent: 30 September
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
Krister Walfridsson changed:
What|Removed |Added
CC||kristerw at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111646
Bug ID: 111646
Summary: cos function giving different result for the same
input value
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Sergei Trofimovich changed:
What|Removed |Added
Summary|[14 Regression] |[14 Regression] bootstrap4
45 matches
Mail list logo
