On Sat, Dec 30, 2023 at 11:26 PM YunQiang Su wrote:
>
> make: *** No rule to make target 'check-g++'. Stop.
>
> gcc
>
> * doc/install.texi (Testing): Correct check-g++ to
> check-gcc-c++.
Actually these targets exist in the gcc subdirectory.
Which is mentioned slightly above:
make: *** No rule to make target 'check-g++'. Stop.
gcc
* doc/install.texi (Testing): Correct check-g++ to
check-gcc-c++.
---
gcc/doc/install.texi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index
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
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=113179
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.5
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180
Andrew Pinski changed:
What|Removed |Added
Target|mips aarch64*-*-* |mips aarch64*-*-* arm*-*
--- Comment
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
Ever confirmed|0 |1
Component|target
> Right. But that's the whole point behind avoiding the narrowing subreg
> and forcing use of a truncate operation.
>
> So basically the question becomes is there a way to modify those bits in
> a way that GCC doesn't know that it needs to to truncate/extend?
>
I guess that this code may cause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113185
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-12-31
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
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=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
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.
Snapshot gcc-13-20231230 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20231230/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
When I enable cgen rebuilding in the binutils-gdb tree, the default is
to run cgen using 'guile'. However, on my host, guile is guile 2.2,
which doesn't work for me -- I have to use guile3.0.
This patch arranges to pass "GUILE" down to subdirectories, so I can
use 'make GUILE=guile3.0'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178
David Binderman changed:
What|Removed |Added
CC||tamar.christina at arm dot com
---
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=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=113184
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
CC|
zstd
gcc version 14.0.0 20231230 (experimental) (GCC)
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
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
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 #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 #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 #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 #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
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 #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 #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
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 ???
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
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
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=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=113182
--- Comment #4 from John David Anglin ---
Created attachment 56967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56967=edit
Assembler output
There are no .type directives for _U_* libfuncs.
They are emitted by
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=edit
Preprocessed source
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
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
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
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=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
CC||pinskia at gcc dot gnu.org
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=113182
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
CC|
Hi!
On Tue, Oct 24, 2023 at 07:49:10PM +0100, Richard Sandiford wrote:
> This patch adds a combine pass that runs late in the pipeline.
But it is not. It is a completely new thing, and much closer to
fwprop than to combine, too.
Could you rename it to something else, please? Something less
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.
On Sat, 30 Dec 2023, Jonathan Wakely wrote:
> On Sat, 30 Dec 2023, 01:41 Hans-Peter Nilsson, wrote:
> > Or perhaps the cause is known?
>
> Not to me. It probably is a target codegen bug, since all this test really
> does is emulate a wide integer type using masks and shifts.
If so, a generic
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
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=108640
--- Comment #6 from Mikael Pettersson ---
Created attachment 56965
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56965=edit
Preliminary patch, only tested on the test case so far.
On Fri, Dec 29, 2023 at 09:14:52PM -0700, Jeff Law wrote:
> On 12/29/23 10:46, YunQiang Su wrote:
> >When we try to combine RTLs, the result may be very complex,
> >and `rtx_cost` may think that it need lots of costs. But in
> >fact, it may match a pattern in machine descriptions, which
> >may
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
---
This match pattern allows combination (zero_extract:DI 8, 24, QI)
with an sign-extend to 32bit INS instruction on TARGET_64BIT.
For SI mode, if the sign-bit is modified by bitops, we will need a
sign-extend operation. Since 32bit INS instruction can be sure that
result is sign-extended, and the
Dear GCC Community,
I hope this email finds you well. My name is Arpit and I am writing to
express my interest in participating in GSoC, specifically for the
Rust Front-End project at GCC. Having completed an internship in
Compiler Design at IIT Hyderabad in my IInd Year , where I gained
hands-on
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
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,
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
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:
Ping^3
---
This patch adds a combine pass that runs late in the pipeline.
There are two instances: one between combine and split1, and one
after postreload.
The pass currently has a single objective: remove definitions by
substituting into all uses. The pre-RA version tries to restrict
itself
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
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=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=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
在 2023/12/30 下午8:25, Xi Ruoyao 写道:
On Sat, 2023-12-30 at 12:15 +, Richard Sandiford wrote:
This shouldn't be necessary. The test does:
for (int i = 0; i < n; i += 2)
{
x0 = __builtin_fmin (x0, ptr[i + 0]);
x1 = __builtin_fmin (x1, ptr[i + 1]);
}
res[0] =
On Sat, 2023-12-30 at 20:25 +0800, Xi Ruoyao wrote:
> On Sat, 2023-12-30 at 12:15 +, Richard Sandiford wrote:
> > This shouldn't be necessary. The test does:
> >
> > for (int i = 0; i < n; i += 2)
> > {
> > x0 = __builtin_fmin (x0, ptr[i + 0]);
> > x1 = __builtin_fmin (x1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113104
Richard Sandiford changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
On Sat, 2023-12-30 at 12:15 +, Richard Sandiford wrote:
> This shouldn't be necessary. The test does:
>
> for (int i = 0; i < n; i += 2)
> {
> x0 = __builtin_fmin (x0, ptr[i + 0]);
> x1 = __builtin_fmin (x1, ptr[i + 1]);
> }
> res[0] = x0;
> res[1] = x1;
>
>
Hi,
Ping on this patch.
TIA, have a lovely day and happy holidays!
--
Arsen Arsenović
signature.asc
Description: PGP signature
chenxiaolong writes:
> After the detection of maximum reduction is enabled on LoongArch architecture,
> the regression test of GCC finds that vect-fmin-3.c fails. Currently, in the
> target-supports.exp file, only aarch64,arm,riscv, and LoongArch architectures
> are supported. Through analysis,
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=87858
Xi Ruoyao changed:
What|Removed |Added
CC||eyalroz1 at gmx dot com
--- Comment #13
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=113177
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed||2023-12-30
CC|
Replying to myself...
I think this also desevers a mention in changes.html. Here is something
that I came up with. OK? Or does anybody have suggestions for a better
wording?
Or maybe this is better:
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index
Hi Rimvydas,
Documentation part.
The makeinfo gcc/fortran/gfortran.texi does not seem to have any new warnings.
Thanks for your work on this!
I think this also desevers a mention in changes.html. Here is something
that I came up with. OK? Or does anybody have suggestions for a better
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
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++
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
On Sat, 30 Dec 2023, 01:41 Hans-Peter Nilsson, wrote:
> I'm not completely sure I got the intent of the "log2_limit",
> or whether "limit" is sane to decrease like this; it just
> looked like an obvious and safe reduction. Also, I verified
> the 10+ minute runtime, on this same host (clocked at
On Sat, 30 Dec 2023, 01:24 Hans-Peter Nilsson, wrote:
> Tested for mmix and observing the increased timeout in the .log
> file - and the test passing.
>
> Ok to commit? Or better suggestions?
>
OK to commit, thanks.
> -- >8 --
> Testing for mmix (a 64-bit target using Knuth's simulator).
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
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
84 matches
Mail list logo
