Second link this week that actually shorter - wooo...
Pushed.
Gerald
---
htdocs/readings.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/readings.html b/htdocs/readings.html
index 29368a9a..34ba508c 100644
--- a/htdocs/readings.html
+++ b/htdocs/readings.html
@@
On 2/9/23 01:10, Jan Hubicka wrote:
>>> On 2/1/23 15:26, Martin Jambor wrote:
Hi,
On Fri, Dec 02 2022, Martin Liška wrote:
> If -w is used, warn_odr properly sets *warned = false and
> so it should be preserved when calling warn_types_mismatch.
>
> Noticed that
On Tue, Feb 7, 2023 at 7:04 PM Hans-Peter Nilsson via Gcc-patches
wrote:
>
> > From: Aldy Hernandez
> > Date: Tue, 7 Feb 2023 17:52:02 +0100
>
> > Up to the release managers, but I have no objections.
>
> I take it that's for both patches. Thanks!
> (Potential reviewers: these patches are local
On Sun, Dec 18, 2022 at 10:06 PM Dan Li wrote:
>
> This series of patches is mainly used to support the control flow
> integrity protection of the linux kernel [1], which is similar to
> -fsanitize=kcfi in clang 16.0 [2,3].
>
> I hope that this feature will also support user-mode CFI in the
>
ping
On Sat, Jan 28, 2023 at 1:16 PM Jonathan Yong <10wa...@gmail.com> wrote:
>
> Patch OK?
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/pr65658.c: fix LLP64 test.
ping.
BR
Fei
On 2023-02-03 16:52 Fei Gao wrote:
>
>
>Gentle ping.
>
>The patch I previously submitted:
>| Date: Wed, 30 Nov 2022 00:38:08 -0800
>| Subject: [PATCH] RISC-V: optimize stack manipulation in save-restore
>| Message-ID:
>
>I split the patches as per Palmer's review comment.
>
>BR
On Wed, Feb 08, 2023 at 04:00:25PM -0800, Jason Merrill wrote:
> On 2/8/23 13:01, Marek Polacek wrote:
> > (This may not be a complete fix but I got stuck so I'm posting what
> > I have, which at least fixes the ICE.)
> >
> > We ICE on the simple:
> >
> >struct X { const X* x = this; };
> >
Thanks Kewen!
Ping this again @Segher.
Maybe we could also merge this patch if no objections from Segher as
several reviews and tests taken on this already...
BR,
Xionghu
On 2023/1/18 17:11, Kewen.Lin wrote:
Hi Segher,
I guessed that this patch escaped from your radar. :)
As Jakub asked
On Mon, Dec 19, 2022 at 3:59 PM Dan Li via Gcc-patches
wrote:
>
> This series of patches is mainly used to support the control flow
> integrity protection of the linux kernel [1], which is similar to
> -fsanitize=kcfi in clang 16.0 [2,3].
>
> I hope that this feature will also support user-mode
> > On 2/1/23 15:26, Martin Jambor wrote:
> > > Hi,
> > >
> > > On Fri, Dec 02 2022, Martin Liška wrote:
> > > > If -w is used, warn_odr properly sets *warned = false and
> > > > so it should be preserved when calling warn_types_mismatch.
> > > >
> > > > Noticed that during a LTO reduction where
On 2/8/23 13:01, Marek Polacek wrote:
(This may not be a complete fix but I got stuck so I'm posting what
I have, which at least fixes the ICE.)
We ICE on the simple:
struct X { const X* x = this; };
constexpr const X& x = X{};
where store_init_value initializes 'x' with
_EXPR }>
On 2/8/23 00:59, Jakub Jelinek wrote:
Hi!
For standard excess precision, like the C FE we parse floating
point constants as EXCESS_PRECISION_EXPR of promoted REAL_CST
rather than the nominal REAL_CST, and as the following testcase
shows the constants might need mangling.
The following patch
WG14 has agreed a change of the rules on constexpr pointer
initializers, so that a (constant) null value that is not a null
pointer constant is accepted in that context, rather than only
accepting null pointer constants. (In particular, this means that a
constexpr variable of pointer type can be
libstdc++-v3/ChangeLog:
* testsuite/22_locale/codecvt/codecvt_unicode.cc: Rename
functions.
* testsuite/22_locale/codecvt/codecvt_unicode.h: Make more
generic so it accepts char8_t.
* testsuite/22_locale/codecvt/codecvt_unicode_wchar_t.cc: Rename
> On Feb 8, 2023, at 2:09 PM, Joseph Myers wrote:
>
> On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> But I noticed that “flexible_array_type_p” later was moved from FE to
>> middle-end and put into tree.cc, tree.h as a general utility routine, and to
>>
>> /* Determine whether
> On Feb 8, 2023, at 2:20 PM, Siddhesh Poyarekar wrote:
>
> On 2023-02-08 14:09, Joseph Myers wrote:
>> What must be avoided is -pedantic diagnostics for
>> struct flex1 { int n; int data[1]; };
>> struct out_flex_end1 { int m; struct flex1 flex_data; };
>> regardless of whether considered
fsf.org has been serving a 301 (permanent redirect) http response for
a long while.
gcc/ChangeLog:
* doc/include/gpl_v3.texi: Change fsf.org to www.fsf.org.
---
gcc/doc/include/gpl_v3.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/include/gpl_v3.texi
The same problem as PR 88739 has crept in but
this time in match.pd when simplifying bit_field_ref of
an bit_insert. That is we are generating a BIT_FIELD_REF
of a non-mode-precision integral type.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR
(This may not be a complete fix but I got stuck so I'm posting what
I have, which at least fixes the ICE.)
We ICE on the simple:
struct X { const X* x = this; };
constexpr const X& x = X{};
where store_init_value initializes 'x' with
_EXPR }>
but we must lifetime-extend via
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc (class vmadc): New class.
(class vmsbc): Ditto.
(BASE): Define new class.
* config/riscv/riscv-vector-builtins-bases.h: Ditto.
*
On Wed, 8 Feb 2023, Siddhesh Poyarekar wrote:
> On 2023-02-08 14:09, Joseph Myers wrote:
> > What must be avoided is -pedantic diagnostics for
> >
> > struct flex1 { int n; int data[1]; };
> > struct out_flex_end1 { int m; struct flex1 flex_data; };
> >
> > regardless of whether considered
Sanity-checked for cris-elf with the
check_effective_target_lra correction in
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611531.html
Committed as obvious.
--- 8< ---
These tests spuriously lacked a "lra" limiter. Code using
"asm goto" with outputs gets a:
error: the target does not
On 2023-02-08 14:09, Joseph Myers wrote:
What must be avoided is -pedantic diagnostics for
struct flex1 { int n; int data[1]; };
struct out_flex_end1 { int m; struct flex1 flex_data; };
regardless of whether considered flexible or not, since that's clearly
valid in standard C.
Are you sure
In simple_dce_from_worklist, we were removing an inline-asm which had a vdef
(due to clobbering memory) but not unlinking the statement's vdef.
This fixes that oversight. This was a latent bug exposed recently
by both VRP and removal of stores to static starting to use
simple_dce_from_worklist.
On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote:
> But I noticed that “flexible_array_type_p” later was moved from FE to
> middle-end and put into tree.cc, tree.h as a general utility routine, and to
>
> /* Determine whether TYPE is a structure with a flexible array member,
>or a union
PR analyzer/108704 reports many false positives seen from
-Wanalyzer-use-of-uninitialized-value on qemu's softfloat.c on code like
the following:
struct st s;
s = foo ();
s = bar (s); // bogusly reports that s is uninitialized here
where e.g. "struct st" is "floatx80" in the qemu
Is it too soon to ping again? :) I think Nixman needs some feedback as to
whether he's on the right track in addressing your concerns.
On Sun, Feb 5, 2023, 12:39 NightStrike wrote:
> Jakub, ping
>
> On Thu, Jan 26, 2023, 12:50 i.nixman--- via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
---
htdocs/gcc-13/changes.html | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 8c0201f2..d70ac1de 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -153,7 +153,17 @@ a
---
htdocs/gcc-13/changes.html | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index a48ac220..8c0201f2 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -128,6
---
htdocs/gcc-13/changes.html | 58 ++
1 file changed, 58 insertions(+)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index d70ac1de..5dbcc229 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -50,6 +50,9 @@ a
---
htdocs/gcc-13/changes.html | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 9ecd115c..a48ac220 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -45,7
> On Wed, Feb 08, 2023 at 06:10:08PM +0100, Jan Hubicka wrote:
> > My understanding of simd clones is bit limited, but I think you are
> > right that they should have the same semantics as their caller.
> >
> > I think const may be one that makes compiler to ICE, but
> > there are many other
> From: Richard Sandiford
> Date: Wed, 8 Feb 2023 17:54:15 +0100
> Hans-Peter Nilsson via Gcc-patches writes:
> > Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and
> > also hacked to switch to LRA).
>
> Since !LRA is hopefully not long for this world, I'd personally
> prefer to keep
On Wed, Feb 08, 2023 at 06:10:08PM +0100, Jan Hubicka wrote:
> My understanding of simd clones is bit limited, but I think you are
> right that they should have the same semantics as their caller.
>
> I think const may be one that makes compiler to ICE, but
> there are many other places where
> Hi!
>
> The following testcase ICEs, because we determine only in late pure const
> pass that bar is const (the content of the function loses a store to a
> global var during dse3 and read from it during cddce2) and local-pure-const2
> makes it const. The cgraph ordering is that post IPA (in
> Hi!
>
> As discussed in the PR, returns_twice functions are rare/special beasts
> that need special treatment in the cfg, and inside of their bodies
> we don't know which part actually works the weird returns twice way
> (either in the fork/vfork sense, or in the setjmp) and aren't updating
>
Hans-Peter Nilsson via Gcc-patches writes:
> Tested native x86_64-pc-linux-gnu and cris-elf (non-LRA and
> also hacked to switch to LRA).
Since !LRA is hopefully not long for this world, I'd personally
prefer to keep it simple & obvious (at least for most targets).
There's a risk that we could
Jakub Jelinek writes:
> Hi!
>
> The following testcase is miscompiled on aarch64-linux since r11-5160.
> Given
>[local count: 955630225]:
> # i_22 = PHI
> # r_23 = PHI
> ...
> a.0_5 = (unsigned char) a_15;
> _6 = (int) a.0_5;
> b.1_7 = (unsigned char) b_17;
> _8 = (int) b.1_7;
>
I found a bug with this patch, will fix it and send out the updated patch.
Please ignore this one.
sorry.
Qing
> On Feb 6, 2023, at 8:47 AM, Qing Zhao wrote:
>
> This is the 2nd version of the patch, compare to the first version, the major
> changes are:
>
> 1. Add a new IR bit in
> On Feb 7, 2023, at 6:37 PM, Joseph Myers wrote:
>
> On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> Then, this routine (flexible_array_type_p) is mainly for diagnostic purpose.
>> It cannot be used to determine whether the structure/union type recursively
>> include a flexible
Andrea Corallo writes:
> gcc/
>
> * config/arm/arm.cc (arm_valid_target_attribute_rec): Add ARM function
> attribute 'branch-protection' and parse its options.
> * doc/extend.texi: Document ARM Function attribute 'branch-protection'.
>
> gcc/testsuite/
>
> *
Richard Sandiford writes:
> Andrea Corallo via Gcc-patches writes:
>> Hi all,
>>
>> this is to fix the regression of
>> g++.target/aarch64/return_address_sign_ab_exception.C that I
>> introduced with d8dadbc9a5199bf7bac1ab7376b0f84f45e94350.
>>
>> 'aarch_ra_sign_key' for aarch64 ended up being
The GCC-local definition of gcc-dg-prune removes extra error messages,
such as one from the linker warning about executable stacks. This is
then used by tool-specific pruners like objc-dg-prune, defined in
objc-dg.exp. However, objc/execute/execute.exp didn't include
objc-dg.exp, meaning that
On 2/7/23 22:48, Andrew Pinski wrote:
On Tue, Feb 7, 2023 at 6:08 AM Vladimir Makarov via Gcc-patches
wrote:
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103541
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
What languages
Hi!
Seems when committing the PR108525 fix I've missed that a test with
the same name had been added a few hours before for PR108526.
This patch separates the PR108525 test into a new file.
Tested on x86_64-linux, committed to trunk as obvious.
2023-02-08 Jakub Jelinek
PR
Here is a fix for PR107557 and PR108423.
Bootstrapped and regression tested on x86-64.
Gimplify more size expression in parameters [PR107557] and [PR108234]
gimplify_parm_type only recursives into pointer type and
size expressions in other types (e.g. function types) were
> The commit "ada: Add PIE support to backtraces on Linux" [1] use
> _r_debug under Linux unconditionally. It is incorrect since musl[2]
> libc not defined _r_debug like glibc [3]:
>
> extern struct r_debug _r_debug;
>
> As far as I know, only glibc and uClibc [4] define the global variable
>
> Am 08.02.2023 um 10:17 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> While looking at PR108692, I've noticed SAD_EXPR comment mentions that
> WIDEN_MINUS_EXPR is missing, which is not true anymore since r11-5160.
>
> The following patch just removes that part of the comment.
>
>
> Am 08.02.2023 um 10:00 schrieb Richard Sandiford via Gcc-patches
> :
>
> The gather/scatter support can over-widen an offset if the target
> requires it, but this relies on using a pattern sequence to add
> the widening conversion. That failed in the testcase because an
> earlier pattern
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/vector.md: Fix indent.
---
gcc/config/riscv/vector.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index aaac32efcce..7da95013156 100644
---
On 27/01/2023 17:44, Srinath Parvathaneni via Gcc-patches wrote:
Hello,
I have committed a fix [1] into gcc trunk for a build issue mentioned in
pr108505 and
latter received few upstream comments proposing more robust fix for this issue.
In this patch I'm addressing those comments and
The commit "ada: Add PIE support to backtraces on Linux" [1] use
_r_debug under Linux unconditionally. It is incorrect since musl[2]
libc not defined _r_debug like glibc [3]:
extern struct r_debug _r_debug;
As far as I know, only glibc and uClibc [4] define the global variable
_r_debug.
[1]
Hi!
While looking at PR108692, I've noticed SAD_EXPR comment mentions that
WIDEN_MINUS_EXPR is missing, which is not true anymore since r11-5160.
The following patch just removes that part of the comment.
Ok for trunk?
2023-02-08 Jakub Jelinek
* tree.def (SAD_EXPR): Remove outdated
The gather/scatter support can over-widen an offset if the target
requires it, but this relies on using a pattern sequence to add
the widening conversion. That failed in the testcase because an
earlier pattern (bool) took priority.
I think we should allow patterns to be applied to other
Hi!
For standard excess precision, like the C FE we parse floating
point constants as EXCESS_PRECISION_EXPR of promoted REAL_CST
rather than the nominal REAL_CST, and as the following testcase
shows the constants might need mangling.
The following patch mangles those as fold_convert of the
Hi!
The following testcase is miscompiled on aarch64-linux since r11-5160.
Given
[local count: 955630225]:
# i_22 = PHI
# r_23 = PHI
...
a.0_5 = (unsigned char) a_15;
_6 = (int) a.0_5;
b.1_7 = (unsigned char) b_17;
_8 = (int) b.1_7;
c_18 = _6 - _8;
_9 = ABS_EXPR ;
r_19 = _9
56 matches
Mail list logo
