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:
Richard Biener 于2023年9月27日周三 15:30写道：
>
> On Wed, Sep 27, 2023 at 7:21 AM Hanke Zhang via Gcc wrote:
> >
> > Thanks! I understand what you mean, then can I think that if the
> > function here is not an external function, but a function visible to
> > the compiler and the function doesn't modify
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
Andrew Pinski changed:
What|Removed |Added
Keywords||documentation
--- Comment #5 from
Hi David,
Sorry for the half-year delay! I have some update. :)
On Fri, Mar 24, 2023 at 10:53:22AM -0400, David Malcolm wrote:
> On Fri, 2023-03-24 at 14:39 +0100, Alejandro Colomar via Gcc-patches
> wrote:
> > Warn about the following:
> >
> > char s[3] = "foo";
> >
> > Initializing a
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
On Fri, Sep 29, 2023 at 02:09:12PM -0400, Michael Meissner wrote:
> * config/rs6000/rs6000.md (UNSPEC_COPYSIGN): Delete.
> (copysign3_fcpsg): Use copysign RTL instead of UNSPEC.
(typo, it is _fcpsgn)
Nice to see unnecessary unspecs going away :-)
Segher
Committed. Thanks Juzhe!
I had to adjust the changelog's PR formatting to get the pre-commit
hooks to accept it.
Here's the committed patch:
From f446cf5d58568e406cc81f434a63b3045942e9a9 Mon Sep 17 00:00:00 2001
From: Patrick O'Neill
Date: Sat, 30 Sep 2023 15:50:11 -0700
Subject: [PATCH]
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
LGTM.
juzhe.zh...@rivai.ai
From: Patrick O'Neill
Date: 2023-10-01 07:00
To: gcc-patches; juzhe.zhong
CC: jakub; pinskia; JeffreyALaw; gnu-toolchain; Patrick O'Neill
Subject: [PATCH] RISC-V: Use safe_grow_cleared for vector info [PR111469]
Resolves a riscv*-*-* bootstrap failure due to a
Resolves a riscv*-*-* bootstrap failure due to a newly-turned-on assert.
2023-09-30 Jakub Jelinek
PR target/111649
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc
(vector_infos_manager::vector_infos_manager):
Replace safe_grow with safe_grow_cleared.
---
Trunk GCC still has some bugs need to be addressed.
A few issues are middld-end related to COND_LEN_xxx (Robin has sent a patch but
waiting for Richard's review).
A few issues are VSETVL PASS (Lehua is working on refactoring and cleanup up
the VSETVL PASS to address all potential issues of
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
Great! Thanks for fixing it.
LGTM.
juzhe.zh...@rivai.ai
From: Joern Rennecke
Date: 2023-10-01 04:30
To: GCC Patches
CC: Jeff Law; 钟居哲
Subject: RFA: RISC-V: Make riscv_vector::legitimize_move adjust SRC in the
caller. (Was: Remove mem-to-mem VLS move pattern[PR111566])
>On 9/27/23 03:38,
On 9/11/23 06:12, Jeff Law via Gcc-patches wrote:
On 9/10/23 21:42, juzhe.zh...@rivai.ai wrote:
Ping this patch.
I think it's time to enable scalable vectorization by default and do
the whole regression every time (except vect.exp that we didn't
enable yet)
Update current FAILs
Snapshot gcc-13-20230930 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20230930/
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
On Fri, 29 Sept 2023 at 14:54, Jeff Law wrote:
> So I recommend we go forward with Joern's approach (so consider that an
> ACK for the trunk). Joern can you post a follow-up manual twiddle so
> that other ports can follow your example and avoid this problem?
The manual... so not in the
From: Sergei Trofimovich
Before the change `make bootstrap4` (or `make profiledbootstrap`) failed
as:
gcc/rtl-tests.cc:249:25: in ‘constexpr’ expansion of ‘poly_int<1, long
int>(1, 1)’
gcc/poly-int.h:453:5: error: too many initializers for ‘long int [1]’
The failure happened only in
On Tue, Jul 19, 2022 at 02:21:05PM -0600, lancethepants wrote:
> The commit mirros code from aarch64 to handle -static-pie.
> Tested with uclibc-ng and musl c-standard libraries.
>
> Signed-off-by: Lance Fredrickson
> ---
> gcc/config/arm/linux-elf.h | 5 +++--
> 1 file changed, 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Sergei Trofimovich changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
---
On Sep 30 2023, Sergei Trofimovich wrote:
> @@ -263,7 +253,7 @@ const_poly_int_tests::run ()
>ASSERT_KNOWN_EQ (rtx_to_poly_int64 (x255), poly_int64 (1, -1));
>ASSERT_MAYBE_NE (rtx_to_poly_int64 (x255), poly_int64 (1, 255));
>
> - /* Test plus_constant of a symbol. */
> + /* Test
From: Sergei Trofimovich
Before the change `make bootstrap4` (or `make profiledbootstrap`) failed
as:
gcc/rtl-tests.cc:249:25: in ‘constexpr’ expansion of ‘poly_int<1, long
int>(1, 1)’
gcc/poly-int.h:453:5: error: too many initializers for ‘long int [1]’
The failure happened only in
Hi,
On Sun, Sep 17, 2023 at 10:04:37PM +0200, Mark Wielaard wrote:
> On Tue, Sep 12, 2023 at 05:00:07PM +0200, Mark Wielaard wrote:
> > We (Jeff or anyone else with mailman admin privs) could use the same
> > settings for gcc-patches. The settings that need to be set are in that
> > bug:
> >
> >
+ linaro-toolchain as I don't understand the CI issues on patchwork.
On Wed, Sep 27, 2023 at 8:40 PM Wilco Dijkstra wrote:
>
> Hi Ramana,
>
> > Hope this helps.
>
> Yes definitely!
>
> >> Passes regress/bootstrap, OK for commit?
> >
> > Target ? armhf ? --with-arch , -with-fpu , -with-float
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
On Mon, Sep 25, 2023 at 10:52 PM Jiufu Guo wrote:
> Hi,
>
> Gentle ping...
>
> BR,
> Jeff (Jiufu Guo)
>
This is okay.
Thanks, David
>
> Jiufu Guo via Gcc-patches writes:
>
> > Hi,
> >
> > Gentle ping...
> >
> > BR,
> > Jeff (Jiufu Guo)
> >
> > Jiufu Guo writes:
> >
> >> Hi,
> >>
> >> If a
>On 9/27/23 03:38, juzhe.zh...@rivai.ai wrote:
>> >> Why add `can_create_pseudo_p ()` here? this will split after reload,
but we forbid that pattern between reload and split2?
>>
>> I have no ideal. Some fortran tests just need recognization of
>> mem-to-mem pattern before RA
>> I don't know
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
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
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 ());
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
--- Comment #1 from Andrew Pinski ---
What is the host compiler?
Hi Jakub,
A follow-up commit of yours (9d249b7e31e) is causing bootstrap failures
for riscv*-*-* targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111649
Patrick
On 9/29/23 03:42, Jakub Jelinek wrote:
Hi!
As reported by Jonathan on IRC, my vec.h patch broke build with GCC 4.8.x
or
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];
};
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
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
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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111644
Andre Vehreschild changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #2 from Andre
Hi all,
back porting to gcc-13 unfortunately caused a regression due to
gfc_deallocate_with_status() having a different parameter count. This is fixed
as obvious by 874b895fffd921659b37dc05bc94eea48e9a0157.
Sorry for breaking gfortran-13. I still don't know why it checkout fine on my
system in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Sergei Trofimovich changed:
What|Removed |Added
Depends on||111647
--- Comment #6 from Sergei
When pthread is used by default, _REENTRANT should be defined in all
cases except -no-pthread. When pthread is not used by default,
_REENTRANT should only be defined with -pthread.
The current spec for mingw-w64 for default pthread is
%{!no-pthread:-D_REENTRANT} %{pthread:-U_REENTRANT}
and
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
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
Helene Chelin
gcc/ChangeLog:
*
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
Helene Chelin
gcc/ChangeLog:
*
Thank you for reviewing this patch.
v1->v2:
* Add XCValu RTL.
* Change assembly mnemonics from mixed case to lower case.
v2->v3:
* Change commit message from past tense to present.
* Add documentation for new dg-effective-targets.
This patch series presents the comprehensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111644
Andre Vehreschild changed:
What|Removed |Added
Last reconfirmed||2023-09-30
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
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++
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
On Sat, Sep 30, 2023 at 11:44:59AM +0200, Jakub Jelinek wrote:
> I really can't figure out why one would need to add extra casts.
> type must be an integral type which has BIT_NOT_EXPR applied on it
> which yields all ones and we need a type in which negating 0 or 1
> range will yield 0 or all
Hi!
I really can't figure out why one would need to add extra casts.
type must be an integral type which has BIT_NOT_EXPR applied on it
which yields all ones and we need a type in which negating 0 or 1
range will yield 0 or all ones, I think all integral types satisfy
that.
This fixes PR111369,
Hi!
This function comment has been pasted from gimple_bitwise_equal_p and haven't
been adjusted for different function name.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2023-09-30 Jakub Jelinek
* gimple-match-head.cc
I have now released the new implementation for translation validation I
talked about at the GNU Tools Cauldron last week:
https://github.com/kristerw/smtgcc
/Krister
Hi!
This patch fixes 2 issues. One is when we want to get address of
an uninitialized large/huge bitint SSA_NAME for multiplication/division/modulo
or conversion to floating point (binary or decimal), the code just creates
an uninitialized limb sized variable and passes address of that, but I
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:
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:
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
---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111642
Rolf Eike Beer changed:
What|Removed |Added
CC||e...@sf-mail.de
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #3 from Lukas Grätz ---
(In reply to Marc Glisse from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I am 99% sure this is falls under don't do this as flatten inlines
> > everything it can that the function calls ...
77 matches
Mail list logo
