https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110588
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
Andrew Pinski changed:
What|Removed |Added
Known to work||12.3.0, 14.0
Summary|[13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #22 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:bbc1a102735c72e3c5a4dede8ab382813d12b058
commit r14-2733-gbbc1a102735c72e3c5a4dede8ab382813d12b058
Author: Andrew Pinski
Date:
Hi Richard,
Bootstrap and regression are passed on X86 and
no new testcases fail on AArch64 with V5 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625293.html
V5 patch is ok for trunk?
Best,
Lehua
From: Ju-Zhe Zhong
PS: Submitted on behalf of Juzhe Zhong
Hi, Richard and Richi.
This patch support floating-point in-order reduction for loop length control.
Consider this following case:
float foo (float *__restrict a, int n)
{
float result = 1.0;
for (int i = 0; i < n; i++)
result
OK for trunk, thanks:)
Andrew Pinski via Gcc-patches 於 2023年7月23日 週日
09:07 寫道：
> The problem -fasynchronous-unwind-tables is on by default for riscv linux
> We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__
> point
> to .eh_frame data from crtbeginT.o instead of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110769
Zhendong Su changed:
What|Removed |Added
CC||zhendong.su at inf dot ethz.ch
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737
--- Comment #3 from Andrew Pinski ---
A C++ front-end does not set the call for deconstructor for the following
testcase:
```
struct s{ ~s(); };
void f()
{
s{};
}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
The problem -fasynchronous-unwind-tables is on by default for aarch64
We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__ point
to .eh_frame data from crtbeginT.o instead of the user-defined object
during static linking.
This turns it off.
OK? Bootstrapped and tested on
The problem -fasynchronous-unwind-tables is on by default for riscv linux
We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__ point
to .eh_frame data from crtbeginT.o instead of the user-defined object
during static linking.
This turns it off.
OK?
libgcc/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107737
--- Comment #2 from Andrew Pinski ---
So far gimplify_vla_decl does not set the location on the call expression it
creates. It should be set to the same as the decl source location.
Testing that ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
This adds a special case of the `(a&~b) | b` pattern where
`b` and `~b` are comparisons.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR tree-optimization/100864
* match.pd ((~x & y) | x -> x | y): Add comparison variant.
Snapshot gcc-13-20230722 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20230722/
and on various mirrors, see http://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
Fixes: ef85d150b5963 ("RISC-V: Enable TARGET_SUPPORTS_WIDE_INT")
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to optimize it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.x fa5,zero
| fsd fa5,0(a0)
| ret
With patch
| sd zero,0(a0)
| ret
The fix updates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #14 from CVS Commits ---
The master branch has been updated by Vineet Gupta :
https://gcc.gnu.org/g:ecfa870ff29d979bd2c3d411643b551f2b6915b0
commit r14-2731-gecfa870ff29d979bd2c3d411643b551f2b6915b0
Author: Vineet Gupta
Date:
On 7/21/23 23:05, Jeff Law wrote:
On 7/21/23 12:30, Vineet Gupta wrote:
Fixes: ef85d150b5963 ("RISC-V: Enable TARGET_SUPPORTS_WIDE_INT")
(gcc-13 regression)
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to
optimize it.
void zd(double *) { *d = 0.0; }
currently:
|
zxuiji via Gcc writes:
> Your site is far too bright and is absolutely painful to the eyes, I
> have a simple invert style that I expected to work on all sites and I
> found your site is undertaking the vile act of blocking user styles. I
> expect that sort of rotten design from microsoft &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587
--- Comment #13 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:8125b12f846b41f26e58c0fe3b218d654f65d1c8
commit r14-2730-g8125b12f846b41f26e58c0fe3b218d654f65d1c8
Author: Roger Sayle
Date: Sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110533
--- Comment #5 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:8125b12f846b41f26e58c0fe3b218d654f65d1c8
commit r14-2730-g8125b12f846b41f26e58c0fe3b218d654f65d1c8
Author: Roger Sayle
Date: Sat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110778
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110778
--- Comment #2 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:659d856e1d424ea8ef634844a7bd08b86ec7344b
commit r14-2729-g659d856e1d424ea8ef634844a7bd08b86ec7344b
Author: Andrew Pinski
Date:
The problem is after r14-2587-gd8105b10fff951, the definition of
extended_count now takes a bool as its last argument but we only
have a declaration for the version which takes an int as the last
argument. This fixes the problem by changing the declaration to be
a bool too.
Committed as obvious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110778
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Summary|Alpha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #20 from Andrew Pinski ---
(In reply to Andreas Schwab from comment #19)
> Probably also needed for aarch64.
Testing that and will submit both patches after that finishes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110778
Bug ID: 110778
Summary: Alpha targets broken since r14-2587-gd8105b10fff951
(undefined reference to extended_count)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110755
--- Comment #7 from Aurelien Jarno ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 55594 [details]
> gcc14-pr110755.patch
>
> Untested patch.
Thanks for the patch, I confirm it works as expected, now the result is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777
David Binderman changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777
--- Comment #4 from David Binderman ---
Current range seems to be g:23ad5ed7432bea7c to g:85a4e4f93ff251f2.
Trying g:b6b72562d116bd0a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777
--- Comment #3 from David Binderman ---
Attempting bisection. Trying g:85a4e4f93ff251f2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777
--- Comment #2 from David Binderman ---
Created attachment 55615
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55615=edit
C source code
Original pre-reduction source code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777
--- Comment #1 from Andrew Pinski ---
Is this reduced from some other code? Because the testcase here depends on an
uninitialized variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777
Andrew Pinski changed:
What|Removed |Added
Summary|ice: SSA corruption |[14 Regression] ice: SSA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110777
Bug ID: 110777
Summary: ice: SSA corruption
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110433
--- Comment #5 from Martin Jambor ---
Indeed, the error is no longer reported. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #19 from Andreas Schwab ---
Probably also needed for aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #18 from Aurelien Jarno ---
(In reply to Andreas Schwab from comment #17)
> I don't think you need -fno-omit-frame-pointer.
I confirm that CRTSTUFF_T_CFLAGS += -fno-asynchronous-unwind-tables
-fno-unwind-tables is enough to fix the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #17 from Andreas Schwab ---
I don't think you need -fno-omit-frame-pointer.
On Sat, Jul 22, 2023 at 4:17 PM Roger Sayle wrote:
>
>
> This patch attempts to help with PR rtl-optimization/110587, a regression
> of -O0 compile time for the pathological pr28071.c. My recent patch helps
> a bit, but hasn't returned -O0 compile-time to where it was before my
>
On Sat, Jul 22, 2023 at 5:37 PM Roger Sayle wrote:
>
>
> As suggested by Uros, this patch changes the ZERO_EXTRACTs and SIGN_EXTRACTs
> in i386.md to consistently use QImode for bit offsets (i.e. third and fourth
> operands), matching the use of QImode for bit counts in shifts and rotates.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #16 from Andrew Pinski ---
(In reply to Aurelien Jarno from comment #15)
> (In reply to Andrew Pinski from comment #14)
> > Created attachment 55614 [details]
> > patch for someone to test out
> >
> > The problem is the similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #15 from Aurelien Jarno ---
(In reply to Andrew Pinski from comment #14)
> Created attachment 55614 [details]
> patch for someone to test out
>
> The problem is the similar across many targets so I basically copied what
> was done
Only run bb-slp-pr95839-v8.c with targets that support vectors of 64
bits, removing regressions with 32-bit x86 targets:
FAIL: gcc.dg/vect/bb-slp-pr95839-v8.c scan-tree-dump slp2 "optimized: basic
block"
FAIL: gcc.dg/vect/bb-slp-pr95839-v8.c -flto -ffat-lto-objects scan-tree-dump
slp2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110677
Martin Jambor changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment
This patch is my attempt to address the compile-time hog issue
in PR rtl-optimization/110587. Richard Biener's analysis shows that
compilation of pr28071.c with -O0 currently spends ~70% in timer
"LRA non-specific" due to return_regno_p failing to filter a large
number of calls to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110766
--- Comment #3 from David Binderman ---
Reduced C++ code seems to be:
template struct _Base_bitset {
unsigned long _M_w[_Nw];
unsigned long &_M_getword() { return _M_w[0]; }
};
struct bitset : _Base_bitset<0> {
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
Andrew Pinski changed:
What|Removed |Added
Keywords||build
Target Milestone|---
Hi Kewen,
This patch breaks bootstrap on powerpc-darwin (which has Altivec, but not VSX)
while building libgfortran.
> On 3 Jul 2023, at 04:19, Kewen.Lin via Gcc-patches
> wrote:
Please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
thanks
Iain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #14 from Andrew Pinski ---
Created attachment 55614
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55614=edit
patch for someone to test out
The problem is the similar across many targets so I basically copied what was
done
The tester seemed to occasionally ping-pong a compilation failure on the
builtin-bitops-1.c test. I long suspected it was something like length
computations.
I finally got a few minutes to dig into it, and sure enough the blackfin
port was claiming the "ones" operation was 2 bytes when it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|[RISC-V] Segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
--- Comment #8 from Roland Illig ---
When I compile the attached code with "ARM GCC 10.5.0" and "-O2 -fPIE -ftrapv"
on godbolt.org, the generated code is correct (you can search for "#327" in the
output and then go back one branch).
The code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
--- Comment #1 from Iain Sandoe ---
Created attachment 55613
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55613=edit
preprocessed (not reduced, but the function is not large)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110741
--- Comment #3 from Peter Bergner ---
(In reply to Kewen Lin from comment #2)
> It exposed one issue on xxeval output vsx operands' format, can be fixed
> with:
>
> diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
> index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
Bug ID: 110776
Summary: [14 Regression] powerpc-darwin bootstrap broken after
r14-2490 with ICE rs6000.cc:5069 building libgfortran
Product: gcc
Version: 14.0
Status:
As suggested by Uros, this patch changes the ZERO_EXTRACTs and SIGN_EXTRACTs
in i386.md to consistently use QImode for bit offsets (i.e. third and fourth
operands), matching the use of QImode for bit counts in shifts and rotates.
There's no change in functionality, and the new patterns simply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #12 from Aurelien Jarno ---
Backtrace with debug symbols in libgcc_eh.a:
Program received signal SIGSEGV, Segmentation fault.
classify_object_over_fdes (ob=0xe2da0 , this_fde=0x1000530e6,
range=0x3ff310) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
--- Comment #7 from Roland Illig ---
Created attachment 55612
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55612=edit
Preprocessed source from comment 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
Roland Illig changed:
What|Removed |Added
Attachment #55598|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
--- Comment #5 from Roland Illig ---
Sorry for the confusing description. Let me try again.
NetBSD lint includes a yacc parser for C code. This parser contains the rules
'block_item_list' and 'block_item':
This adds rudimentary lifetime tracking in C++ constexpr contexts,
allowing the compiler to report errors with using values after their
backing has gone out of scope. We don't yet handle other ways of
accessing values outside their lifetime (e.g. following explicit
destructor calls).
PR
Currently, when typeck discovers that a return statement will refer to a
local variable it rewrites to return a null pointer. This causes the
error messages for using the return value in a constant expression to be
unhelpful, especially for reference return values, and is also a visible
change to
This patch updates 'input_location' during constant evaluation to ensure
that errors in subexpressions that lack location information still
provide accurate diagnostics.
By itself this change causes some small regressions in diagnostic
quality for circumstances where errors used 'input_location'
This is an update of the patch series at
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625050.html
Changes since v4:
- Reordered patches to be more independent from each other (they don't need
to keep updating the new tests)
- Removed workaround for better locations in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #11 from Aurelien Jarno ---
I have bisected the issue, and I found it has been introduced by the following
commit:
commit 3cd08f7168c196d7a481b9ed9f4289fd1f14eea8
Author: Andreas Schwab
Date: Wed Jan 25 12:00:09 2023 +0100
On Fri, 21 Jul 2023 at 21:05, Benjamin Priour via Gcc-patches
wrote:
>
> Hi,
>
> Upon David's request I've joined the in progress patch to the below email.
> I hope it makes more sense now.
>
> Best,
> Benjamin.
>
> -- Forwarded message -
> From: Benjamin Priour
> Date: Tue, Jul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110766
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
This patch attempts to help with PR rtl-optimization/110587, a regression
of -O0 compile time for the pathological pr28071.c. My recent patch helps
a bit, but hasn't returned -O0 compile-time to where it was before my
ix86_expand_move changes. The obvious solution/workaround is to guard
these
On 18/07/2023 08:27, Ken Matsui via Libstdc++ wrote:
This patch implements built-in trait for std::is_arithmetic.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_arithmetic.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_ARITHMETIC.
* semantics.cc
It seems rather logical cause std::disjunction is supposed to avoid
instantiations but in case of:
std::disjunction, std::is_null_pointer<_Tp>>
you'll avoid std::is_null_pointer instantiation only for 'void' type and
at the price of instantiating std::disjunction so 2 instantiations at
best
On 17/07/2023 06:48, Ken Matsui wrote:
On Sun, Jul 16, 2023 at 5:32 AM François Dumont wrote:
On 15/07/2023 06:55, Ken Matsui via Libstdc++ wrote:
This patch optimizes the performance of the is_arithmetic trait by
dispatching to the new __is_arithmetic built-in trait.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #10 from Aurelien Jarno ---
(In reply to Aurelien Jarno from comment #9)
> (In reply to Andrew Pinski from comment #5)
> > Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again?
>
> Yep, I'll do that, but it will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110757
Martin Jambor changed:
What|Removed |Added
CC||lili.cui at intel dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110775
Sebastian Huber changed:
What|Removed |Added
CC||sebastian.huber@embedded-br
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110174
Gaius Mulley changed:
What|Removed |Added
Last reconfirmed||2023-07-22
Ever confirmed|0
在 2023/7/20 下午9:28, Xi Ruoyao 写道:
If the host triple and the target triple are different but the host is
LoongArch, in some cases --with-arch=native can be useful. For example,
if we are bootstrapping a loongarch64-linux-musl toolchain on a
Glibc-based system and we don't intend to use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110631
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110631
--- Comment #3 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:73cc6ce1294ec35e9322b1bbc91009cfc76f732b
commit r14-2725-g73cc6ce1294ec35e9322b1bbc91009cfc76f732b
Author: Gaius Mulley
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109921
--- Comment #12 from Jonathan Wakely ---
Excellent, thanks for checking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #9 from Aurelien Jarno ---
(In reply to Andrew Pinski from comment #5)
> Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again?
Yep, I'll do that, but it will probably take some time to get the results.
(In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #8 from Aurelien Jarno ---
Created attachment 55610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55610=edit
crtbeginT.o GCC 12 version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #7 from Aurelien Jarno ---
Created attachment 55609
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55609=edit
crtbeginT.o GCC 12 version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684
--- Comment #15 from AlexK ---
I have attached all patches I have made to several Makefile.in in different
folders (I created them with `diff` tool)
after that I made building directory:
installdir=/tools/gcc-12.2.0
install -v -d mybuild
cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684
--- Comment #14 from AlexK ---
Created attachment 55608
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55608=edit
applyed patch for gcc/Makefile.in to make shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684
--- Comment #13 from AlexK ---
Created attachment 55607
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55607=edit
applyed patch for libcpp/Makefile.in to make shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684
--- Comment #12 from AlexK ---
Created attachment 55606
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55606=edit
applyed patch for libbacktrace/Makefile.in to make shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684
--- Comment #11 from AlexK ---
Created attachment 55605
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55605=edit
applyed patch for libcody/Makefile.in to make shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684
--- Comment #10 from AlexK ---
Created attachment 55604
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55604=edit
applyed patch for libdecnumber/Makefile.in to make shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684
--- Comment #9 from AlexK ---
Created attachment 55603
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55603=edit
applyed patch for libiberty/Makefile.in to make shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684
--- Comment #8 from AlexK ---
Created attachment 55602
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55602=edit
applyed patch for libgcc/Makefile.in to make shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684
--- Comment #7 from AlexK ---
Created attachment 55601
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55601=edit
applyed patch for Makefile.in to configure with --enable-shared and without
--enable-static options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110631
--- Comment #2 from Gaius Mulley ---
Created attachment 55600
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55600=edit
Proposed fix
Here is a proposed fix - which will be applied (if/when) bootstrapping
completes successfully.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93116
--- Comment #2 from Andrew Pinski ---
So the biggest issue here is that if we use nop_convert here, we will need to
check for vectors and use view_convert instead of convert in the resulting
output for the patterns.
like what is done for:
/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54904
Andrew Pinski changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
On 7/21/23 11:27, Andrew Pinski via Gcc-patches wrote:
On Fri, Jul 21, 2023 at 8:09 AM Drew Ross via Gcc-patches
wrote:
Simplifies (x << c) >> c where x is a signed integral type of
width >= int and c = precision(type) - 1 into -(x & 1). Tested successfully
on x86_64 and x86 targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109921
--- Comment #11 from Andreas Ziegler ---
Tested successfully cross-compiling for
x86_64-buildroot-linux-uclibc w/o locale
Regression tests successful for
i586-buildroot-linux-uclibc w/o locale
aarch64-buildroot-linux-musl w/ locale
On 7/21/23 12:30, Vineet Gupta wrote:
Fixes: ef85d150b5963 ("RISC-V: Enable TARGET_SUPPORTS_WIDE_INT")
(gcc-13 regression)
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to optimize it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.x fa5,zero
| fsd fa5,0(a0)
|
On 7/21/23 12:55, Vineet Gupta wrote:
Apparently this is a regression in gcc-13, introduced by commit
ef85d150b5963 ("RISC-V: Enable TARGET_SUPPORTS_WIDE_INT") and the fix
thus is a partial revert of that change.
Given that it can ICE, we should probably backport it to 13.
FWIW ICE is
100 matches
Mail list logo
