https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962
--- Comment #9 from Hongtao.liu ---
Fixed in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962
--- Comment #8 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:a282f086ef26d90e9785e992cd09a0d118b24695
commit r13-2804-ga282f086ef26d90e9785e992cd09a0d118b24695
Author: Hu, Lin1
Date: Tue Sep
On Fri, Sep 23, 2022 at 11:07 AM Hu, Lin1 wrote:
>
> Hi, Hongtao
>
> I have modefied this patch and regtested on x86_64-pc-linux-gnu.
>
Ok.
> BRs.
> Lin
>
> -Original Message-
> From: Hongtao Liu
> Sent: Friday, September 23, 2022 9:48 AM
> To: Hu, Lin1
> Cc: gcc-patches@gcc.gnu.org;
Hi, Hongtao
I have modefied this patch and regtested on x86_64-pc-linux-gnu.
BRs.
Lin
-Original Message-
From: Hongtao Liu
Sent: Friday, September 23, 2022 9:48 AM
To: Hu, Lin1
Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao
Subject: Re: [PATCH] i386: Optimize code generation of
Hi,
Gentle ping:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601190.html
BR,
Jeff (Jiufu)
Jiufu Guo writes:
> Hi,
>
> As the issue in PR106460, a rtx 'high:DI (symbol_ref:DI ("var_48")' is tried
> to store into constant pool and ICE occur. But actually, this rtx represents
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107013
Bug ID: 107013
Summary: Add fmin/fmax to RTL codes
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
On Thu, Sep 22, 2022 at 3:20 PM Hu, Lin1 via Gcc-patches
wrote:
>
> Hi all,
>
> This patch aims to optimize code generation of
> __mm256_zextsi128_si256(__mm_set1_epi8(-1)). Reduce the number of
> instructions required to achieve the final result.
>
> Regtested on x86_64-pc-linux-gnu. Ok for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106983
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Thu, Sep 22, 2022 at 11:56 PM Jakub Jelinek wrote:
>
> On Tue, Sep 20, 2022 at 10:51:18AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Tue, Sep 20, 2022 at 11:35:07AM +0800, Hongtao Liu wrote:
> > > > The question is (mainly for aarch64, arm and x86 backend maintainers)
> > > > if we
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106983
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:8b449dcd84334068c769a2f427812dadb95e61de
commit r13-2803-g8b449dcd84334068c769a2f427812dadb95e61de
Author: Marek Polacek
Date:
On Thu, 22 Sept 2022 at 15:26, Jonathan Wakely via Libstdc++
wrote:
>
> Tested x86_64-linux. Pushed to trunk.
>
> -- >8 --
>
> Also add _GLIBCXX_HOSTED checks to simplify making
> freestanding in the near future.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/bitset (bitset): Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107011
--- Comment #2 from AK ---
ah ok. sorry for the noise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107012
--- Comment #1 from gandalf at winds dot org ---
Created attachment 53615
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53615=edit
objdump output for dwarf-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107012
Bug ID: 107012
Summary: [debug, dwarf-5] Missing line information for
evaluating macros
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
On Thu, 22 Sep 2022, Torbjörn SVENSSON via Gcc-patches wrote:
> This patch stops reporting fails for Arm targets with single
> precision floating point unit for types wider than 32 bits (the width
> of float on arm-none-eabi).
>
> As reported in PR102017, fenv is reported as supported in recent
Snapshot gcc-10-20220922 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20220922/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On 9/19/22 12:20, Thomas Neumann wrote:
In some scenarios (e.g., when mixing gcc and clang code), it can
happen that frames are deregistered after the lookup structure
has already been destroyed. That in itself would be fine, but
it triggers an assert in __deregister_frame_info_bases that
On 9/20/22 17:05, Marek Polacek wrote:
We ICE in the code added in r12-7117: type_build_dtor_call gets
the error_mark_node because the type of 'prev' wasn't declared.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
PR c++/106983
gcc/cp/ChangeLog:
*
On 9/22/22 09:39, Marek Polacek wrote:
To improve compile times, the C++ library could use compiler built-ins
rather than implementing std::is_convertible (and _nothrow) as class
templates. This patch adds the built-ins. We already have
__is_constructible and __is_assignable, and the nothrow
Hi!
On Thu, Sep 22, 2022 at 09:41:42AM +0800, Kewen.Lin wrote:
> * config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): Update the
> condition for adding REG_CFA_DEF_CFA reg note with
> frame_pointer_needed_indeed.
> --- a/gcc/config/rs6000/rs6000-logue.cc
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104883
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-09-22
Ever confirmed|0
Hi!
Heh, I first thought I had mistyped thgew PR #, but it is this one after
all :-)
On Thu, Sep 22, 2022 at 09:41:34AM +0800, Kewen.Lin wrote:
> PR100645 exposes one latent bug in define_expand vec_shr_
> that the current condition TARGET_ALTIVEC is too loose. The
> mode iterator VEC_L
On Fri, 16 Sept 2022 at 19:49, Sergei Trofimovich wrote:
>
> From: Sergei Trofimovich
>
> i386-builtin-types.inc is included indirectly via i386-builtins.h
> into 4 files: i386.cc i386-builtins.cc i386-expand.cc i386-features.cc
>
> Only i386.cc dependency was present in gcc/config/t-i386
On Thu, Sep 22, 2022 at 06:49:10PM +0200, Aldy Hernandez wrote:
> It has been suggested that if we start bumping numbers by an ULP when
> calculating open ranges (for example the numbers less than 3.0) that
> dumping these will become increasingly harder to read, and instead we
> should opt for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919
--- Comment #7 from Martin Liška ---
Fixed with:
diff --git a/gcc/config/s390/s390.cc b/gcc/config/s390/s390.cc
index 076c97a8b22..869847ab3d7 100644
--- a/gcc/config/s390/s390.cc
+++ b/gcc/config/s390/s390.cc
@@ -3669,7 +3669,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919
Martin Liška changed:
What|Removed |Added
Summary|[13 Regression] RTL check: |[13 Regression] RTL check:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107005
--- Comment #4 from Andrew Pinski ---
*** Bug 107011 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107011
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
--- Comment #2 from Aldy Hernandez ---
(In reply to Marek Polacek from comment #1)
> Looks like it was caused by r13-1268-g8c99e307b20c50:
>
> commit 8c99e307b20c502e55c425897fb3884ba8f05882
> Author: Aldy Hernandez
> Date: Sat Jun 25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107011
Bug ID: 107011
Summary: instruction with undefined behavior not optimized away
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107010
--- Comment #2 from Stian Skjelstad ---
Thank you for an amazing fast usefull reply.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919
--- Comment #5 from Martin Liška ---
Confirmed, bisecting right now.
On 9/22/22 10:49, Aldy Hernandez via Gcc-patches wrote:
It has been suggested that if we start bumping numbers by an ULP when
calculating open ranges (for example the numbers less than 3.0) that
dumping these will become increasingly harder to read, and instead we
should opt for the hex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106939
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107002
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
If it's not too cumbersome, I suggest dumping both.
In my neck-of-the-woods (meteorology) I have seen this done just to
ensure that algorithms that are supposed to be bit-reproducable actually
are - and that it can be checked visually.
Kind regards,
Toon.
On 9/22/22 18:49, Aldy Hernandez
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106999
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107003
Martin Liška changed:
What|Removed |Added
Summary|ICE in mangle_decl, at |ICE in mangle_decl, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107010
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
On 9/22/22 14:25, Patrick Palka wrote:
index 80467c19254..722b64793ed 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -18235,9 +18235,11 @@ maybe_register_incomplete_var (tree var)
{
/* When the outermost open class is complete we can resolve any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107010
Bug ID: 107010
Summary: iterate section("mysection") struct mystruct fails if
first node is const and compiling with O2 or greater
Product: gcc
Version: 12.1.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107001
Martin Liška changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
Also, as the last builtin remaining, also remove the builtin
infrastructure routines from fold_using_range.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 5608e410914ebb7c8cc9fa50afc8ada3b22cbf2c Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
AndrewFrom e7f035f66aa25e0537a0e3a76d43c71fe9531724 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 19:19:30 -0400
Subject: [PATCH 16/17] Convert CFN_BUILT_IN_GOACC_DIM_* to range-ops.
*
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From c750e675cb77f283ff991682db7740bc5f6d4cf4 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 19:05:03 -0400
Subject: [PATCH 15/17] Convert CFN_BUILT_IN_STRLEN to range-ops.
* gimple-range-fold.cc
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
AndrewFrom f7e62b09300b6935bceaffb4c42f6edab80f52dc Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:21:04 -0400
Subject: [PATCH 13/17] Convert CFN_BUILT_IN_CLRSB to range-ops.
* gimple-range-fold.cc
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From b6f670ff706e35dc51a62db4206cb241dcac4963 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:48:05 -0400
Subject: [PATCH 14/17] Convert CFN_BUILT_IN_UBSAN_CHECK_* to range-ops.
*
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 55738d8d96bb4f39a72cf5e3739d35b39fc2146a Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:19:30 -0400
Subject: [PATCH 12/17] Convert CFN_CTZ builtins to range-ops.
* gimple-range-fold.cc
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From ae1669a98656cca594fcd2fef6bd2cd7308a361f Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:12:25 -0400
Subject: [PATCH 11/17] Convert CFN_CLZ builtins to range-ops.
* gimple-range-fold.cc
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
AndrewFrom 5f730c650184d4c8bfad513a9e0e593f87a5bf0c Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 18:07:14 -0400
Subject: [PATCH 10/17] Convert CFN_BUILT_FFS and CFN_POPCOUNT to range-ops.
*
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 2f5da730f159de238500c82b0c6ef6c9ab91b1c2 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022 17:14:30 -0400
Subject: [PATCH 09/17] Convert CFN_BUILT_IN_TOUPPER and TOLOWER to range-ops.
*
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From eb82b9f68eb8d0cc65a1a022154c8e729860ea59 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Wed, 21 Sep 2022 09:29:40 -0400
Subject: [PATCH 08/17] Convert CFN_BUILT_IN_SIGNBIT to range-ops.
* gimple-range-fold.cc
Check for builtins that can be a range-op entry and Convert
CFN_BUILT_IN_CONSTANT_P as first POC.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From b40b3035879cf695b72010858b9705a344292bdb Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Tue, 20 Sep 2022
The fold_range routine in range-ops returns FALSE if the operation
fails. There are a few places which assume the operation was
successful. Fix those.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 2f92f685da2ef9e82ee6262519919180df8f2dd9 Mon Sep 17 00:00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |13.0
Ever confirmed|0
Unary operations require op2 to be the range of the type of the LHS.
This is so the type for the LHS can be properly set. There are is a
missing prototype for this combination.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From
Unary operations pass the type of operand 1 into op1_range. If that
range is undefined, the routine blindly picks the type of operand
2,which in the case of a unary op, does not exist and traps.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
AndrewFrom
Range-ops is meant to be IL independent. Some gimple processing has
be placed in range-ops, and some is located in gori. Split it all into
a file and isolate it in a new class gimple_range_op_handler.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From
Range_op_handler currently stores a tree code and a type. It defers
checking to see if there is a valid handler until asked.
This change checks at constructor time and store a pointer to the
handler if there is one.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
When the original patch was applied, I missed a spot which could
also be rewritten to use gimple_range_ssa_names.
Bootstrapped on x86_64-pc-linux-gnu with no regressions. Pushed.
Andrew
From 3cba5cd6e019182dbff756f621af048d55cdda98 Mon Sep 17 00:00:00 2001
From: Andrew MacLeod
Date: Wed, 31
Builtin functions have been handled until now as special cases in
gimple-range-fold.cc. This set of patches makes the changes required to
create a range_operator for those functions. This allows them to behave
like a normal unary/binary operation through out the ranger ecosystem.
In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107009
Bug ID: 107009
Summary: massive unnecessary code blowup in vectorizer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106986
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:84a34d76a76f27feabd4523e388068c90c2bb2e4
commit r12-8782-g84a34d76a76f27feabd4523e388068c90c2bb2e4
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857
--- Comment #7 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:cf172d0cdf355042223a3b1ebc04b472386a954e
commit r10-10998-gcf172d0cdf355042223a3b1ebc04b472386a954e
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106857
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:f954e0531beb8cbb128cc4ab70d65a92c5ac9a7d
commit r11-10268-gf954e0531beb8cbb128cc4ab70d65a92c5ac9a7d
Author: Harald Anlauf
When streaming in the artificial VAR_DECL synthesized for a class NTTP
argument, we end up crashing from complete_vars because the call to
maybe_register_incomplete_var from add_module_namespace_decl for this
VAR_DECL pushes an unexpected NULL_TREE type onto the incomplete_vars
vector.
This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100103
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:12b537b9b7fd50f4b2fbfcb7ccf45f8d66085577
commit r13-2782-g12b537b9b7fd50f4b2fbfcb7ccf45f8d66085577
Author: José Rui Faustino de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82868
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:bc71318a91286b5f00e88f07aab818ac82510692
commit r13-2781-gbc71318a91286b5f00e88f07aab818ac82510692
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106998
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.5
Summary|libsanitizer
Hi
This patch fix failures when _GLIBCXX_INLINE_VERSION mode and running:
make check-debug RUNTESTFLAGS=prettyprinters.exp
libstdc++: [_GLIBCXX_INLINE_VERSION] Add gdb pretty print for
_GLIBCXX_DEBUG
In _GLIBCXX_DEBUG mode containers are in std::__debug namespace but
not
On Mon, Sep 5, 2022, 23:51 Charles-Francois Natali
wrote:
> `basic_filebuf::xsputn` would bypass the buffer when passed a chunk of
> size 1024 and above, seemingly as an optimisation.
>
> This can have a significant performance impact if the overhead of a
> `write` syscall is non-negligible,
It has been suggested that if we start bumping numbers by an ULP when
calculating open ranges (for example the numbers less than 3.0) that
dumping these will become increasingly harder to read, and instead we
should opt for the hex representation. I still find the floating
point representation
Similarly to how we drop NANs to UNDEFINED when -ffinite-math-only, I
think we can drop the numbers outside of the min/max representable
numbers to the representable number.
This means the endpoings to VR_VARYING for -ffinite-math-only can now
be the min/max representable, instead of -INF and
We currently have no way of dumping REAL_VALUE_TYPEs when debugging.
Tested on a gdb session examining the real value 10.0:
(gdb) p min
$9 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 4,
sig = {0, 0, 11529215046068469760}}
(gdb) p debug (min)
0x0.ap+4
OK for trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102017
Torbjörn SVENSSON changed:
What|Removed |Added
CC||torbjorn.svensson at foss dot
st.c
This patch stops reporting fails for Arm targets with single
precision floating point unit for types wider than 32 bits (the width
of float on arm-none-eabi).
As reported in PR102017, fenv is reported as supported in recent
versions of newlib. At the same time, for some Arm targets, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106988
Martin Sebor changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
On Tue, Sep 20, 2022 at 10:51:18AM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Sep 20, 2022 at 11:35:07AM +0800, Hongtao Liu wrote:
> > > The question is (mainly for aarch64, arm and x86 backend maintainers) if
> > > we
> > > shouldn't support it, in the PR there is a partial patch to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407
Andrew Pinski changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 106989, which changed state.
Bug 106989 Summary: GCC fail to vectorize and clang succeed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106989
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106989
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
On Thu, Sep 22, 2022 at 5:22 PM Jakub Jelinek wrote:
>
> On Thu, Sep 22, 2022 at 05:02:19PM +0200, Aldy Hernandez wrote:
> > It has always irritated me that we don't have TYPE_MIN_VALUE and
> > TYPE_MAX_VALUE for floats (and for pointers for that matter). This
> > means, we have to recalculate
I've merged trunk revision f35be1268c996d993ab0b4ff329734d467474445 to
the gccgo branch.
Ian
On 2022-09-22 09:02, Jakub Jelinek wrote:
On Mon, Aug 15, 2022 at 03:23:11PM -0400, Siddhesh Poyarekar wrote:
--- a/gcc/tree-object-size.cc
+++ b/gcc/tree-object-size.cc
@@ -495,6 +495,18 @@ decl_init_size (tree decl, bool min)
return size;
}
+/* Get the outermost object that PTR may
On Thu, Sep 22, 2022 at 05:02:19PM +0200, Aldy Hernandez wrote:
> It has always irritated me that we don't have TYPE_MIN_VALUE and
> TYPE_MAX_VALUE for floats (and for pointers for that matter). This
> means, we have to recalculate it ad-nauseum in vrp_val_min and
> vrp_val_max.
>
> I know we
It has always irritated me that we don't have TYPE_MIN_VALUE and
TYPE_MAX_VALUE for floats (and for pointers for that matter). This
means, we have to recalculate it ad-nauseum in vrp_val_min and
vrp_val_max.
I know we have dconstinf and dconstninf for floats, which we can just
wrap around a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107006
--- Comment #11 from H. Peter Anvin ---
If you look at the output, you see that the loops are already fully unrolled
(at considerable code size cost.)
Unfortunately, since the issue at hand is dealing with code written to be
portable, adding
Approved by Richi on IRC. Pushed to trunk.
-- >8 --
We want bugs reported to Bugzilla, not emailed to gcc-bugs.
libiberty/ChangeLog:
* README: Replace gcc-bugs email address with Bugzilla URL.
---
libiberty/README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Also add _GLIBCXX_HOSTED checks to simplify making
freestanding in the near future.
libstdc++-v3/ChangeLog:
* include/std/bitset (bitset): Add constexpr for C++23. Guard
members using std::string with _GLIBCXX_HOSTED.
*
Tested x86_64-linux. Pushed to trunk.
-- >8 --
In C++03 std::bitset was in the Container clause, but since C++11 it has
been in the Utilties clause. This moves the tests to the 20_util
directory, where most people probably expect to find them.
Also create 'access', 'observers', and 'io'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106826
--- Comment #7 from Johel Ernesto Guerrero Peña ---
Thank you very much! This was a real blocker.
Hi!
On Thu, Sep 22, 2022 at 10:28:23AM +0800, Kewen.Lin wrote:
> on 2022/9/22 05:56, Segher Boessenkool wrote:
> > On Fri, Jun 24, 2022 at 10:02:19AM +0800, HAO CHEN GUI wrote:
> > In the other direction I am worried that the unspecs will degrade
> > performance (relative to smin/smax) when
Fixes -flto-compression option:
- -flto-compression-level= Use z Use zlib/zstd compression level
for IL.
+ -flto-compression-level=<0,19> Use zlib/zstd compression level for
IL.
Ready for master?
Thanks,
Martin
---
gcc/common.opt | 2 +-
gcc/opts.cc| 2 +-
2 files changed, 2
Hi!
On Thu, Sep 22, 2022 at 05:59:07PM +0800, HAO CHEN GUI wrote:
> >> I still think we should get RTL codes for this, to have access to proper
> >> floating point min/max semantics always and everywhere. "fmin" and
> >> "fmax" seem to be good names :-)
> >
> > It would be good, especially if
A passing build has been detected on builder gccrust-debian-testing-x86_64
while building gccrust.
Full details are available at:
https://builder.sourceware.org/buildbot/#builders/146/builds/171
Build state: build successful
Revision: 5f01d6c53734802955568771e75df68ffc2fd0d8
Worker: bb3
To improve compile times, the C++ library could use compiler built-ins
rather than implementing std::is_convertible (and _nothrow) as class
templates. This patch adds the built-ins. We already have
__is_constructible and __is_assignable, and the nothrow forms of those.
Microsoft (and clang, for
This libgo patch changes the cgo command to use runtime/cgo.Incomplete
instead of //go:notinheap, and to define the new type in the
runtime/cgo package. This ports https://go.dev/cl/421879 to libgo.
This is a quick port to update libgo to work with the version of cgo
in gc mainline. A more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105749
Richard Biener changed:
What|Removed |Added
Known to fail||12.2.1, 13.0
Last reconfirmed|
On Mon, Sep 19, 2022 at 08:40:34PM +0100, Julian Brown wrote:
> On Wed, 14 Sep 2022 15:24:12 +0200
> Jakub Jelinek wrote:
>
> > On Tue, Sep 13, 2022 at 02:03:18PM -0700, Julian Brown wrote:
> > > This patch is an extension and rewrite/rethink of the following two
> > > patches:
> > >
> > >
1 - 100 of 189 matches
Mail list logo
