https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110625
--- Comment #26 from Hao Liu ---
But for now, the patch should fix the regression.(In reply to Tamar Christina
from comment #25)
> Is still pretty inefficient due to all the extends. If we generate better
> code here this may tip the scale back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113147
--- Comment #2 from Jan Dubiec ---
(In reply to Andrew Pinski from comment #1)
> Don't use `--disable-host-shared` basically.
OK, removal of this option seems to solve the problem, but... I had an
impression that the above set of options (inclu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113177
Bug ID: 113177
Summary: GCC 8.5.0 build with libstdcxx gets library versions
mixed up
Product: gcc
Version: 8.5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178
Bug ID: 113178
Summary: ice in find_uses_to_rename_use
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
Bug ID: 113179
Summary: MIPS
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113177
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed||2023-12-30
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113177
Xi Ruoyao changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858
Xi Ruoyao changed:
What|Removed |Added
CC||eyalroz1 at gmx dot com
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113104
Richard Sandiford changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113160
--- Comment #5 from Yihua Liu ---
I see. Previous cppreference notes were misleading. Is there any plan to
support returning a std::valarray or matching a std::valarray? For example, if
it returns a std::valarray, it can be directly put in a pip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180
Bug ID: 113180
Summary: MIPS: bitops on an long long struct uses ins instead
dins
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467
--- Comment #4 from jpakkane at gmail dot com ---
As a build system developer I'd like that the most common usage (i.e. using
Ninja) would be the default and work without extra compiler flags.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467
--- Comment #5 from Andrew Pinski ---
(In reply to jpakkane from comment #4)
> As a build system developer I'd like that the most common usage (i.e. using
> Ninja) would be the default and work without extra compiler flags.
Ninja is not the mos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113181
Bug ID: 113181
Summary: When compiling sanitizer_printf.cc, getting error:
multiple definition of ‘enum fsconfig_command’
Product: gcc
Version: 8.5.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #7 from Daniel Kolesa ---
I just tested this on big-endian ppc64 targeting power4/ppc970; I was able to
successfully bootstrap the compiler. It seems this is really specific to LE
after all (which makes sense I suppose, considering t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112662
--- Comment #2 from gooncreeper ---
I believe I got my initial optimized function wrong, it should actually be this
unsigned opt(unsigned a) {
if (++a > 999) a = 0;
return a;
}
opt:
lea eax, [rdi+1]
xor edx, ed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467
--- Comment #6 from jpakkane at gmail dot com ---
According to C++ foundation's developer survey [1] the most popular build
system for C++ projects is CMake by quite a massive margin. Based on personal
experience almost everybody uses CMake's Nin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
--- Comment #6 from Mikael Pettersson ---
Created attachment 56965
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56965&action=edit
Preliminary patch, only tested on the test case so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175
Hans-Peter Nilsson changed:
What|Removed |Added
Target|mmix-knuth-mmixware |mmix-knuth-mmixware,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
Bug ID: 113182
Summary: [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C
-std=c++14 execution test
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467
--- Comment #7 from Andrew Pinski ---
Anyways gcc should work best with gnu software and cmake is not at all gnu
software and it competes with autoconf and automake which are gnu tools. Cmake
is less portable than the autotools.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113181
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #2 from dave.anglin at bell dot net ---
On 2023-12-30 1:30 p.m., pinskia at gcc dot gnu.org wrote:
> I figured it would be PA RISC which would have issues with this too.
It's only an issue on hpux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113181
--- Comment #2 from Eyal Rozenberg ---
(In reply to Andrew Pinski from comment #1)
Perhaps I should file a separate bug about collecting 'errata' for finalized
release lines, for when users of newer systems want to build them. That could
be pla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467
--- Comment #8 from Ben Boeckel ---
> Some people even claim that properly supporting Make to build C++ modules is
> not possible if you want to make it actually production quality and reliable.
It is possible, but, AFAIK, requires at least on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105467
--- Comment #9 from Ben Boeckel ---
> unless autoconf/automake started relying on the non-GNU `fdep` [1] project.
Gah, editing gone awry. This was about Fortran module support in
autoconf/autotools, not C++ module support (they have similar bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #3 from John David Anglin ---
Created attachment 56966
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56966&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
--- Comment #4 from John David Anglin ---
Created attachment 56967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56967&action=edit
Assembler output
There are no .type directives for _U_* libfuncs.
They are emitted by ASM_OUTPUT_EXTERNAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858
--- Comment #15 from Eyal Rozenberg ---
Note that:
* in apt-based distributions such as Debian, the relevant package would be
lib32stdc++-dev , or a similar name with the GCC version, e.g.
lib32stdc++-11-dev .
* Even when this particular issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
Bug ID: 113183
Summary: LTO crashes with Segmentation fault
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178
--- Comment #2 from David Binderman ---
The bug first seems to occur sometime between git:514ea1df444ca7f6
and git:f19ceb2d49afdfa5, a distance of 83 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #1 from Andrew Pinski ---
GCC trunk fails with:
```
[apinski@xeond2 tt]$ ~/upstream-gcc/bin/gcc -nostartfiles -O2 -flto -T link.ld
tt.cpp -o tt
tt.cpp:18:90: warning: ‘retain’ attribute ignored [-Wattributes]
18 | static void cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #2 from Andrew Pinski ---
But changing env to Ubuntu, upstream GCC produces an ICE:
```
Segmentation fault
0xf370cf crash_signal
/home/apinski/src/upstream-gcc/gcc/gcc/toplev.cc:316
0x7f1bac5a351f ???
./signal/../sysd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #3 from Andrew Pinski ---
LD that causes the crash:
```
GNU ld (GNU Binutils for Ubuntu) 2.38
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #4 from Sebastian Unger ---
I should have mentioned that for my TC I use binutils 2.41.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #5 from Andrew Pinski ---
Note I get the crash with a cross to aarch64 where both gcc and ld are from the
trunk. So this does look like the crash was introduced by a ld change ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #6 from Andrew Pinski ---
Note I suspect this part of the code example you gave:
```
static void const * const leon_init __attribute__((section (".init_array"),
retain, used)) = (void*)leon_initialise;
```
Is broken and should be re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #7 from Sebastian Unger ---
How is it broken and how should it be rewritten?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #8 from Sebastian Unger ---
Not that on my target everything compiles and runs fine without -flto!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #9 from Sebastian Unger ---
(In reply to Sebastian Unger from comment #8)
> Not that on my target everything compiles and runs fine without -flto!
Not -> Note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #10 from Andrew Pinski ---
Changing it into:
static void leon_initialise(void) __attribute__((constructor));
Fixes the ICE and fixes the code to be better and not depened on init_array
there either ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #11 from Sebastian Unger ---
I see. It was the SORT_BY_INIT_PRIORITY with the section name used not actually
having a priority that triggered it, was it?! If I change the section name to
.init_array.1 then it works.
But, yes, you su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #12 from Andrew Pinski ---
(In reply to Sebastian Unger from comment #11)
> I see. It was the SORT_BY_INIT_PRIORITY with the section name used not
> actually having a priority that triggered it, was it?! If I change the
> section nam
n algorithms: zlib zstd
gcc version 14.0.0 20231230 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113184
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113183
--- Comment #13 from Sebastian Unger ---
No worries, the constructor attribute is much better. I was aware of that, but
at the time had already several examples using .preinit_array and couldn't be
bothered to look it up. I later added the sort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178
--- Comment #3 from David Binderman ---
After some bisection, range seems to be g:2902300340928989
to g:ed60b2868abdb793, a range of 21 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178
David Binderman changed:
What|Removed |Added
CC||tamar.christina at arm dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175
--- Comment #2 from Hans-Peter Nilsson ---
Bisecting (native) has progressed beyond the r13 mark, i.e. this is indeed a
"[14 Regression]" only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352
--- Comment #23 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #22)
> (In reply to Sergey Fedorov from comment #21)
> > Any chance of having it fixed in gcc14?
>
> It is too late to be included in GCC 14, GCC is in stage 3 alrea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113185
Bug ID: 113185
Summary: bad performance on big-endian&64bit port for struct 16
16
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113185
--- Comment #1 from Andrew Pinski ---
The issue is with the argument passing. I thought there was a dup of this bug
somewhere ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113185
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-12-31
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180
Andrew Pinski changed:
What|Removed |Added
Target|mips aarch64*-*-* |mips aarch64*-*-* arm*-*
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.5
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|middle-end
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352
--- Comment #24 from Iain Sandoe ---
(In reply to Sergey Fedorov from comment #23)
> (In reply to Andrew Pinski from comment #22)
> > (In reply to Sergey Fedorov from comment #21)
> > > Any chance of having it fixed in gcc14?
> >
> > It is too l
64 matches
Mail list logo
