Use correct names for __ibm128 if long double is IEEE 128-bit.
If you are on a PowerPC system where the default long double is IEEE
128-bit, GCC will use the wrong names for some of the conversion functions
for the __ibm128 type.
What is happening is when the defult long double is IEEE 128-bit,
Weird things are going to happen if you define your std::initializer_list
as a union. In this case, we crash in output_constructor_regular_field.
Let's not allow such a definition in the first place.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/102434
On Linux/x86_64,
c2b610e7c6c89fd422c5c31f01023bcddf3cf4a5 is the first bad commit
commit c2b610e7c6c89fd422c5c31f01023bcddf3cf4a5
Author: Zhao Wei Liew
Date: Fri Jan 28 13:36:39 2022 -0500
match.pd: Simplify 1 / X for integer X [PR95424]
caused
FAIL: gcc.dg/tree-ssa/divide-7.c
On Fri, Jan 28, 2022 at 11:50:21AM -0600, Bill Schmidt wrote:
> When introducing the new built-in support, I tried to match as many
> existing error messages as possible. One common form was "argument X must
> be a Y-bit unsigned literal". Another was "argument X must be a literal
> between X'
param_early_inliner_max_iterations specifies the maximum number
of nested indirect inlining iterations performed by early inliner.
Normally, the default value is 1.
For AutoFDO this parameter was also used as the number of iteration for
its indirect call promotion loop and the default value was
On Fri, Jan 28, 2022 at 03:19:48PM -0600, Bill Schmidt wrote:
> On 1/28/22 1:11 PM, Segher Boessenkool wrote:
> > On Fri, Jan 28, 2022 at 11:50:19AM -0600, Bill Schmidt wrote:
> >> + and the generic code will issue the appropriate error message. Skip
> >> + this test for functions where
On 1/12/2022 2:02 AM, Yoshinori Sato wrote:
sh-linux not supported any SH1 and SH2a little-endian.
Add exceptios it.
gcc/ChangeLog:
* config/sh/t-linux (MULTILIB_EXCEPTIONS): Add m1, mb/m1 and m2a.
Thanks. Technically this is probably too late to make gcc-12 as we're
in stage4
On 1/5/2022 1:12 PM, Navid Rahimi via Gcc-patches wrote:
Hi GCC community,
This patch will add the missed pattern described in bug 103514 [1] to the
match.pd. [1] includes proof of correctness for the patch too.
PR tree-optimization/103514
* match.pd (a & b) ^ (a == b) -> !(a | b):
On Fri, 28 Jan 2022 at 18:17, Jeff Law wrote:
>
>
>
> On 1/24/2022 4:11 AM, Martin Liška wrote:
> > On 1/21/22 17:54, Jonathan Wakely wrote:
> >> Yes, OK (but please CC the libstdc++ list, not just me).
> >
> > Hello.
> >
> > Sorry for that. Anyway, I would like to install the extended version
> >
On Fri, 28 Jan 2022, Richard Biener wrote:
> > that's not what it does. It treats it like
> >
> > float tem = f;
> > return x + { tem, tem, tem, tem };
> >
> > avoiding, like for x + (1.0f + f) creating
> >
> > return x + { 1.0+f, 1.0+f, 1.0+f ...}
> >
> > it's more CSE than volatile
On 1/28/22 2:32 PM, Segher Boessenkool wrote:
> On Fri, Jan 28, 2022 at 11:50:20AM -0600, Bill Schmidt wrote:
>> It was recently pointed out that we get anomalous behavior when using
>> __attribute__((target)) to select a CPU. As an example, when building for
>> -mcpu=power8 but using
On 1/28/22 1:11 PM, Segher Boessenkool wrote:
> On Fri, Jan 28, 2022 at 11:50:19AM -0600, Bill Schmidt wrote:
>> This patch continues the refactoring started with r12-6014.
> ab3f5b71dc6e
>
>> + and the generic code will issue the appropriate error message. Skip
>> + this test for
On Fri, Jan 28, 2022 at 05:12:41PM +0100, Martin Liška wrote:
> On 1/28/22 16:26, Marek Polacek wrote:
> > On Fri, Jan 28, 2022 at 04:08:18PM +0100, Martin Liška wrote:
> > > On 1/28/22 15:59, Marek Polacek wrote:
> > > > On Fri, Jan 28, 2022 at 02:53:16PM +0100, Martin Liška wrote:
> > > > > On
On Thu, Jan 27, 2022 at 10:17:00PM -0500, Jason Merrill wrote:
> On 1/27/22 20:02, Marek Polacek wrote:
> > @@ -11159,8 +11159,16 @@ create_array_type_for_decl (tree name, tree type,
> > tree size, location_t loc)
> > /* Figure out the index type for the array. */
> > if (size)
> > -
On Fri, Jan 28, 2022 at 11:50:20AM -0600, Bill Schmidt wrote:
> It was recently pointed out that we get anomalous behavior when using
> __attribute__((target)) to select a CPU. As an example, when building for
> -mcpu=power8 but using __attribute__((target("mcpu=power10")), it is legal
> to call
> On 25 Jan 2022, at 15:27, David Edelsohn wrote:
>
> This patch broke bootstrap on AIX. It may have broken Darwin.
As you anticipated, it did : fixed as below (tested on powerpc-darwin9,
pushed to master).
thanks
Iain
[pushed] Darwin, PPC: Fix bootstrap after GLIBC version changes.
A
On Fri, Jan 28, 2022 at 11:50:19AM -0600, Bill Schmidt wrote:
> This patch continues the refactoring started with r12-6014.
ab3f5b71dc6e
> + and the generic code will issue the appropriate error message. Skip
> + this test for functions where we don't fully describe all the possible
> +
On 1/21/2022 9:52 AM, Andreas Krebbel via Gcc-patches wrote:
When propagating a multi-word register into an access with a smaller
mode the can_change_mode backend hook is already consulted for the
original register. This however is also required for the intermediate
copy in copy_regno which
On 1/19/2022 11:42 AM, Zhao Wei Liew via Gcc-patches wrote:
This patch implements an optimization for the following C++ code:
int f(int x) {
return 1 / x;
}
int f(unsigned int x) {
return 1 / x;
}
Before this patch, x86-64 gcc -std=c++20 -O3 produces the following assembly:
On 1/24/2022 4:11 AM, Martin Liška wrote:
On 1/21/22 17:54, Jonathan Wakely wrote:
Yes, OK (but please CC the libstdc++ list, not just me).
Hello.
Sorry for that. Anyway, I would like to install the extended version
of the patch
that touches all libraries.
Ready to be installed?
It
On 1/28/22 12:54, Patrick Palka wrote:
Here we're emitting a -Wignored-qualifiers warning for an
intermediate compiler-generated cast of 0 to 'method-type* const'
as part of value initialization of a const pmf. This patch
suppresses the warning by stripping cv-quals from this pointer
type
On 1/24/2022 7:46 AM, Richard Biener via Gcc-patches wrote:
We were passing down the original type to recursive invocations
of multiple_of_p for say (int)(unsigned * unsigned).
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
2022-01-24 Richard Biener
* fold-const.cc
On 1/24/2022 7:45 AM, Richard Biener via Gcc-patches wrote:
There are a few cases where we know we're dealing with (poly-)integer
constants, so remove the use of multiple_of_p in those cases to make
the PR100499 fix less impactful.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK?
> Am 28.01.2022 um 18:36 schrieb Jeff Law :
>
>
>
>> On 1/28/2022 9:31 AM, Jakub Jelinek via Gcc-patches wrote:
>> Hi!
>>
>> As mentioned in the PRthe following testcase fails, because the last
>> stmt of a bb with -g is a debug stmt and get_status_for_store_merging
>> uses
Mark Power10 fusion option undocumented and remove sub-options.
Bootstrapped and regression tested on powerpc64le(Power10).
Ok for master?
-Pat
2022-01-28 Pat Haugen
gcc/
* config/rs6000/rs6000.opt (mpower10-fusion): Mark Undocumented.
(mpower10-fusion-ld-cmpi,
Hi,
PR 100775 ( ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb
-fzero-call-used-regs=used)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
Although the ICE only happens on arm, but this is a bug in the middle end. So,
I think this bug has higher priority,
Need to be
On 1/24/2022 6:31 PM, liuhongt via Gcc-patches wrote:
For i386, it enables optimization like:
vmovd %xmm0, %edx
- vmovd %xmm0, %eax
+ movl%edx, %eax
Bootstrapped and regtested on CLX for both
x86_64-pc-linux-gnu{-m32,} and
x86_64-pc-linux-gnu{-m32\
Here we're emitting a -Wignored-qualifiers warning for an
intermediate compiler-generated cast of 0 to 'method-type* const'
as part of value initialization of a const pmf. This patch
suppresses the warning by stripping cv-quals from this pointer
type before performing the cast.
Bootstrapped and
PR104004 caught some misses on my part in converting to the new built-in
function infrastructure. In particular, I forgot to mark all of the "nosoft"
built-ins, and one of those should also have been marked "no32bit".
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this
As the subject states. Fixing this is accomplished by moving the built-ins
to the correct stanzas, [altivec] and [vsx].
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this okay for trunk?
Thanks,
Bill
2022-01-27 Bill Schmidt
gcc/
*
The -m[no-]fold-gimple flag was really intended primarily for internal
testing while implementing GIMPLE folding for rs6000 vector built-in
functions. It ended up leaking into other places, causing problems such
as PR103686 identifies. Let's remove it.
There are a number of tests in the
These built-ins were misimplemented as always having big-endian semantics.
Bootstrapped and tested on powerpc64le-linux-gnu with no regressions.
Is this okay for trunk?
Thanks,
Bill
2022-01-18 Bill Schmidt
gcc/
PR target/95082
* config/rs6000/rs6000-builtin.cc
When introducing the new built-in support, I tried to match as many
existing error messages as possible. One common form was "argument X must
be a Y-bit unsigned literal". Another was "argument X must be a literal
between X' and Y', inclusive". During reviews, Segher requested that I
It was recently pointed out that we get anomalous behavior when using
__attribute__((target)) to select a CPU. As an example, when building for
-mcpu=power8 but using __attribute__((target("mcpu=power10")), it is legal
to call __builtin_vec_mod, but not vec_mod, even though these are
equivalent.
On 1/26/2022 8:29 AM, Nick Clifton via Gcc-patches wrote:
Hi Guys,
I would like to propose the patch below to fix a couple of sources
of infinite recursion in libiberty's rust demangling code. This patch
is based upon the one submitted for PR 99935, but extended to cope
with the
This patch continues the refactoring started with r12-6014. I had previously
noted that the resolve_vec* routines can be further simplified by processing
the argument list earlier, so that all routines can use the arrays of arguments
and types. I found that this was useful for some of the
Hi!
This is a resubmission of some patches and a new submission of others.
Patches 1, 3, and 4 finish up the pending clean-up work for the new built-in
infrastructure support. Patches 2 and 5-8 fix a variety of bugs not specific
to the new infrastructure. I'm submitting these as a group
On 1/26/2022 6:42 PM, Allan McRae via Gcc-patches wrote:
Configuring with --enable-default-ssp triggers various testsuite
failures. These contain asm statements that are not compatible with
-fstack-protector. Adding -fno-stack-protector to dg-options to
work around this issue.
Tested on
On 1/28/2022 9:31 AM, Jakub Jelinek via Gcc-patches wrote:
Hi!
As mentioned in the PRthe following testcase fails, because the last
stmt of a bb with -g is a debug stmt and get_status_for_store_merging
uses gimple_seq_last_stmt (bb_seq (bb)) when testing if it is valid
for store merging.
Hi,
in r12-2523-g13586172d0b70c ipa-prop tracking of jump functions during
inlining got the ability to remove ADDR references when inlining
discovered that they were not necessary or turn them into LOAD
references when we know that what was a function call argument passed
by reference will end up
Hello
I have backported and committed the patch 'openmp: Add warning when
functions containing metadirectives with 'construct={target}' called
directly' to the devel/omp/gcc-11 development branch:
d6d82af7918 openmp: Add warning when functions containing metadirectives
with
Hello
Regarding this issue which we discussed previously - I have created a
patch that adds a warning when this situation is detected.
When a metadirective in a explicitly marked target function is
gimplified, it is checked to see if it contains a 'construct={target}'
selector - if it does,
Hi!
As mentioned in the PRthe following testcase fails, because the last
stmt of a bb with -g is a debug stmt and get_status_for_store_merging
uses gimple_seq_last_stmt (bb_seq (bb)) when testing if it is valid
for store merging. The debug stmt isn't valid, while a stmt at that
position with -g0
On 1/28/22 16:26, Marek Polacek wrote:
On Fri, Jan 28, 2022 at 04:08:18PM +0100, Martin Liška wrote:
On 1/28/22 15:59, Marek Polacek wrote:
On Fri, Jan 28, 2022 at 02:53:16PM +0100, Martin Liška wrote:
On 1/24/22 23:36, Marek Polacek via Gcc-patches wrote:
|@@ -7820,6 +7820,10 @@ bidi
On Fri, Jan 28, 2022 at 04:08:18PM +0100, Martin Liška wrote:
> On 1/28/22 15:59, Marek Polacek wrote:
> > On Fri, Jan 28, 2022 at 02:53:16PM +0100, Martin Liška wrote:
> > > On 1/24/22 23:36, Marek Polacek via Gcc-patches wrote:
> > > > |@@ -7820,6 +7820,10 @@ bidi contexts.
Revert partially what I did in g:76ef38e3178a11e76a66b4d4c0e10e85fe186a45.
Pushed based on IRC discussion with Jakub.
Martin
gcc/ChangeLog:
* diagnostic.cc (diagnostic_action_after_output): Remove extra
newline.
---
gcc/diagnostic.cc | 4 ++--
1 file changed, 2 insertions(+),
On 1/28/22 15:59, Marek Polacek wrote:
On Fri, Jan 28, 2022 at 02:53:16PM +0100, Martin Liška wrote:
On 1/24/22 23:36, Marek Polacek via Gcc-patches wrote:
|@@ -7820,6 +7820,10 @@ bidi contexts. @option{-Wbidi-chars=none} turns the
warning off. @option{-Wbidi-chars=any} warns about any use of
On Thu, Jan 27, 2022 at 01:40:15PM +0100, Martin Liška wrote:
> That's follow up patch based on the discussion with Jakub.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * config/rs6000/host-darwin.cc (segv_crash_handler):
> Do not use leading capital letter.
>
On Fri, Jan 28, 2022 at 02:53:16PM +0100, Martin Liška wrote:
> On 1/24/22 23:36, Marek Polacek via Gcc-patches wrote:
> > |@@ -7820,6 +7820,10 @@ bidi contexts. @option{-Wbidi-chars=none} turns the
> > warning off. @option{-Wbidi-chars=any} warns about any use of bidirectional
> > control
On 1/24/22 23:36, Marek Polacek via Gcc-patches wrote:
|@@ -7820,6 +7820,10 @@ bidi contexts. @option{-Wbidi-chars=none} turns the
warning off. @option{-Wbidi-chars=any} warns about any use of bidirectional
control characters. +By default, this warning does not warn about UCNs. It is,
* contrib/config-list.mk: Add LoongArch triplet.
* gcc/doc/install.texi: Add LoongArch options section.
* gcc/doc/invoke.texi: Add LoongArch options section.
* gcc/doc/md.texi: Add LoongArch options section.
---
contrib/config-list.mk | 5 +-
gcc/doc/install.texi
gcc/testsuite/
* g++.dg/cpp0x/constexpr-rom.C: Add build options for LoongArch.
* g++.old-deja/g++.abi/ptrmem.C: Add LoongArch support.
* g++.old-deja/g++.pt/ptrmem6.C: xfail for LoongArch.
* gcc.dg/20020312-2.c: Add LoongArch support.
* gcc.dg/loop-8.c:
gcc/
* config/loongarch/larchintrin.h: New file.
* config/loongarch/loongarch-builtins.cc: New file.
---
gcc/config/loongarch/larchintrin.h | 413 +
gcc/config/loongarch/loongarch-builtins.cc | 511 +
2 files changed, 924 insertions(+)
gcc/
* common/config/loongarch/loongarch-common.cc: New file.
* config/loongarch/genopts/genstr.sh: New file.
* config/loongarch/genopts/loongarch-strings: New file.
* config/loongarch/genopts/loongarch.opt.in: New file.
* config/loongarch/loongarch-str.h:
libgcc/
* config/loongarch/crtfastmath.c: New file.
* config/loongarch/crti.S: Like wise.
* config/loongarch/crtn.S: Like wise.
* config/loongarch/linux-unwind.h: Like wise.
* config/loongarch/sfp-machine.h: Like wise.
* config/loongarch/t-crtstuff:
libgomp/
* configure.tgt: Add LoongArch triplet.
---
libgomp/configure.tgt | 4
1 file changed, 4 insertions(+)
diff --git a/libgomp/configure.tgt b/libgomp/configure.tgt
index d4f1e741b5a..2cd7272fcd8 100644
--- a/libgomp/configure.tgt
+++ b/libgomp/configure.tgt
@@ -56,6 +56,10
---
libgcc/configure | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libgcc/configure b/libgcc/configure
index 4919a56f518..ce04c4f529f 100755
--- a/libgcc/configure
+++ b/libgcc/configure
@@ -2412,6 +2412,9 @@ case "${host}" in
# sets the default TLS model and
gcc/
*config/loongarch/loongarch-c.cc
---
gcc/config/loongarch/loongarch-c.cc | 109
1 file changed, 109 insertions(+)
create mode 100644 gcc/config/loongarch/loongarch-c.cc
diff --git a/gcc/config/loongarch/loongarch-c.cc
---
gcc/configure | 66 ++-
1 file changed, 60 insertions(+), 6 deletions(-)
diff --git a/gcc/configure b/gcc/configure
index bd4d4721868..3823bc4e783 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -5442,6 +5442,9 @@ case "${target}" in
The LoongArch architecture (LoongArch) is an Instruction Set
Architecture (ISA) that has a Reduced Instruction Set Computer (RISC)
style.
The documents are on
https://loongson.github.io/LoongArch-Documentation/README-EN.html
The ELF ABI Documents are on:
* config/picflag.m4: Default add build option '-fpic' for LoongArch.
* configure: Add LoongArch tuples.
* configure.ac: Like wise.
---
config/picflag.m4 | 3 +++
configure | 10 +-
configure.ac | 10 +-
3 files changed, 21 insertions(+), 2
The following fixes the vector type registered for external defs
in call arguments when vectorizing with SLP. We assumed uniform
vectype_in types here but with calls like .COND_MUL we also have
mask arguments which, when invariant or external, need to have
a proper mask vector type.
Bootstrapped
On Fri, Jan 28, 2022 at 1:22 PM Richard Biener
wrote:
>
> On Thu, Jan 27, 2022 at 8:14 PM Maciej W. Rozycki wrote:
> >
> > On Thu, 27 Jan 2022, Richard Biener wrote:
> >
> > > > > > Index: gcc/gcc/c/c-typeck.cc
> > > > > > ===
> > >
On Thu, Jan 27, 2022 at 8:14 PM Maciej W. Rozycki wrote:
>
> On Thu, 27 Jan 2022, Richard Biener wrote:
>
> > > > > Index: gcc/gcc/c/c-typeck.cc
> > > > > ===
> > > > > --- gcc.orig/gcc/c/c-typeck.cc
> > > > > +++
On Thu, Jan 27, 2022 at 7:58 PM Martin Sebor via Gcc-patches
wrote:
>
> The indiscriminate PHI handling by -Wuse-after-free has caused
> the false positive reported in PR 104232. The attached patch
> refines the handling to only consider PHIs all of whose operands
> refer to the same object and
On Thu, 27 Jan 2022, Andrew Waterman wrote:
> LGTM, thanks for correcting this oversight in my patch.
Committed, thanks for your review!
Maciej
Hi Tobias,
I don't know why that bootstrapped initially. I fixed the patch (naming a
```
else
/* Prevent warning. */
cdesc = NULL_TREE;
```
obvious) and rerun bootstrap making sure to purge everything beforehand. It did
not break bootstrap on x86_64-linux/f35. Hope it doesn't elsewhere with
On Fri, 28 Jan 2022, Jakub Jelinek wrote:
> On Fri, Jan 28, 2022 at 12:04:00PM +0100, Richard Biener wrote:
> > Still I think assuming there are no abnormal edges when neither
> > of the flag is set is premature (as can be seen here). I also
> > don't think what we do in the function is very
On Fri, Jan 28, 2022 at 12:04:00PM +0100, Richard Biener wrote:
> Still I think assuming there are no abnormal edges when neither
> of the flag is set is premature (as can be seen here). I also
> don't think what we do in the function is very timing critical,
> but sure, we walk all successor
On Fri, 28 Jan 2022 at 00:59, Martin Sebor wrote:
> In practice, I'd expect most calls to atomic functions to be made
> with constant memory models, and code like in the test case above
> to be uncommon, so I think the choice of warning at -O0 was
> the right one.
Some of us consider it a
On Fri, 28 Jan 2022, Jakub Jelinek wrote:
> On Fri, Jan 28, 2022 at 11:29:38AM +0100, Richard Biener wrote:
> > This removes a premature optimization from
> > gimple_purge_dead_abnormal_call_edges which, after eliding the
> > last setjmp (or computed goto) statement from a function and
> > thus
On Fri, Jan 28, 2022 at 11:29:38AM +0100, Richard Biener wrote:
> This removes a premature optimization from
> gimple_purge_dead_abnormal_call_edges which, after eliding the
> last setjmp (or computed goto) statement from a function and
> thus clearing cfun->calls_setjmp, leaves us with the
This removes a premature optimization from
gimple_purge_dead_abnormal_call_edges which, after eliding the
last setjmp (or computed goto) statement from a function and
thus clearing cfun->calls_setjmp, leaves us with the abnormal
edges from other calls that are elided for example via inlining
or
On Fri, 28 Jan 2022, Jakub Jelinek wrote:
> Hi!
>
> The testcase in the PR (not included for the testsuite because we don't
> have an (easy) way to -fcompare-debug LTO, we'd need 2 compilations/linking,
> one with -g and one with -g0 and -fdump-rtl-final= at the end of lto1
> and compare that)
This is a regression present on mainline and 11 branch: the new transformation
applied during expansion by Narrow_Large_Operation would incorrectly perform
name resolution for the operator again.
Tested on x86_64-suse-linux, applied on mainline and 11 branch.
2022-01-28 Eric Botcazou
The following makes dumping of a function as graph work as intended
when specifying a function other than cfun. Unfortunately the loop
and the dominance APIs are not set up to work for other functions
than cfun so you won't get any fancy loop dumps but the non-loop
dump works up to reaching
Hi Tobias,
ups, sorry, reverted immediately.
Regards,
Andre
On Fri, 28 Jan 2022 10:27:26 +0100
Tobias Burnus wrote:
> Hi Andre,
>
> your patch breaks bootstrapping:
>
> ../../repos/gcc/gcc/fortran/trans-array.cc: In function ‘tree_node*
> structure_alloc_comps(gfc_symbol*, tree,
Hi Andre,
your patch breaks bootstrapping:
../../repos/gcc/gcc/fortran/trans-array.cc: In function ‘tree_node*
structure_alloc_comps(gfc_symbol*, tree, tree, int, int, int,
gfc_co_subroutines_args*)’:
../../repos/gcc/gcc/fortran/trans-array.cc:9200:42: error: ‘cdesc’ may be used
Hi!
The testcase in the PR (not included for the testsuite because we don't
have an (easy) way to -fcompare-debug LTO, we'd need 2 compilations/linking,
one with -g and one with -g0 and -fdump-rtl-final= at the end of lto1
and compare that) has different code generation for -g vs. -g0.
The
Hi Harald,
thanks for the fast review. I have submitted as c9c48ab7bad.
Will wait for two weeks (reminder set :-)) before backporting to gcc-11.
Thank you and regards,
Andre
On Tue, 25 Jan 2022 22:30:22 +0100
Harald Anlauf via Fortran wrote:
> Hi Andre',
>
> Am 25.01.22 um 17:32
80 matches
Mail list logo
