ppc configurations that have -mstrict-align enabled by default fail
gcc.dg/strlenopt-80.c, because some memcpy calls don't get turned into
MEM_REFs, which defeats the tested-for strlen optimization.
This was regstrapped on x86_64-linux-gnu, tested with a cross to a
ppc64-vxworks7r2 configured
The test expects shrink-wrapping of the fsqrt call, but that will only
occur when there is a usable sqrt insn.
Arrange for dejagnu to add the options that enable the sqrt insn, if
one is available, and to skip the test otherwise.
H-P, this *should* obviate the mmix-specific dg-skip-if. Would
On Mar 9, 2021, Segher Boessenkool wrote:
> +return [check_no_compiler_messages powerpc_sqrt object {
I don't think you really need to assemble this. s/object/assembly/
would do. Even preprocessing alone would do, but I don't think
check_compiler can do that.
--
Alexandre Oliva, happy
On Mar 9, 2021, Segher Boessenkool wrote:
> Hi!
> On Wed, Mar 03, 2021 at 06:07:29PM -0300, Alexandre Oliva wrote:
>> On Mar 3, 2021, Segher Boessenkool wrote:
>> It's skipping the test, as the change you propose, that reduces testing
>> surface, when testing only a configuration that ends up
When execute libstdc++ testcases on mips, I notice that last_write_time
alawys failed, and the failed VERIFY is "VERIFY(
approx_equal(last_write_time(f.path), time) );" where testing time before
than epoch.
Below is the minimal case:
```
// gcc a.c
int main()
{
struct timespec
This fixes an ICE on invalid code where one of the parameters was
error_mark_node and thus resetting its DECL_CONTEXT crashed.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
PR c++/99500
* parser.c (cp_parser_requirement_parameter_list): Handle
In GCC 10, I introduced cp_warn_deprecated_use_scopes so that we can
handle attribute deprecated on a namespace declaration. This
function walks the decl's contexts so that we warn for code like
namespace [[deprecated]] N { struct S { }; }
N::S s;
We call cp_warn_deprecated_use_scopes when
When DWARF_FRAME_REGISTERS isn't defined, the default is
FIRST_PSEUDO_REGISTER which means that if you add faked
registers to the port, used for frame-context related
elimination, room is allocated for them in the register
context used for frame-unwinding, which is wasteful because
they're
On Wed, Mar 10, 2021 at 02:28:15AM +0100, David Lamparter wrote:
> The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
> resulting in all information about the typedef's involvement getting
> lost. This drops necessary information for warnings and can make them
> confusing or
The TYPE_MAIN_VARIANT() here was, for casts to a typedef'd type name,
resulting in all information about the typedef's involvement getting
lost. This drops necessary information for warnings and can make them
confusing or even misleading. It also makes specialized warnings for
unspecified-size
On 3/9/21 2:27 PM, Dave Anglin wrote:
> Okay?
>
> Add LRA target selector.
>
> gcc/testsuite/ChangeLog:
>
> PR testsuite/99292
> * lib/target-supports.exp (check_effective_target_lra): New.
> * gcc.c-torture/compile/asmgoto-2.c: Use LRA target selector.
> *
While working on PR99454 I found that IR incorrectly processes
constraints starting with '0'..'9' and containing more one digit. It is
probably a rare event and it does not result in wrong code generation.
Simply, the generated code will be more efficient.
In any case the following patch
The gimple_call_alloc_size() function is documented to "return null
when STMT is not a call to a valid allocation function" but the code
assumes STMT is a call statement, causing the function to ICE when
it isn't.
The attached patch changes the function to fulfill its contract and
return null
Okay?
Add LRA target selector.
gcc/testsuite/ChangeLog:
PR testsuite/99292
* lib/target-supports.exp (check_effective_target_lra): New.
* gcc.c-torture/compile/asmgoto-2.c: Use LRA target selector.
* gcc.c-torture/compile/asmgoto-5.c: Likewise.
*
Thanks for the pointer!
I think Eric was a little bit too generous last time and formatted the
commit log for me =P.
I have added the appropriate entries to the Changelog's, and have included
those in the patch (attached), which is also updated to master/HEAD,
hopefully that is the most helpful
Richard Biener wrote:
>I don't think removing all code is OK since it would
>allow combining x == y || x > y to x >= y which may
>trap. The bugreport suggests to alter the last
>test to something like
>
> if (trap && !ltrap && !rtrap)
> return NULL_TREE;
>
>thus if we manage to remove a trap
Dear all,
character variables with undefined length are not allowed as
objects in DATA statements. We better reject them.
Regtested on x86_64-pc-linux-gnu. OK for master / backport?
Thanks,
Harald
PR fortran/99205 - Out of memory with undefined character length
A variable that is a data
> On Mon, Mar 1, 2021 at 12:17 PM Jose E. Marchesi via Gcc-patches
> wrote:
>
> I think I've already said this at some point but you shouldn't need
> this. There's no
> "GIMPLE language", the user wrote C or C++ or Fortran or ...
Ok we will drop this patch from the series.
Hi!
On Wed, Mar 03, 2021 at 02:12:56PM -0500, Michael Meissner wrote:
> On Tue, Mar 02, 2021 at 03:53:06PM -0600, Segher Boessenkool wrote:
> > If you want to make decimal and/or QP float work only on 64-bit LE Linux
> > you should say so. And in that case, that is certainly not acceptable
> >
On 3/9/21 8:40 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> Before my PR97690 changes, conditional_replacement would not set neg
> when the nonzero arg was boolean true.
> I've simplified the testing, so that it first finds the zero argument
> and then checks the other argument for all
Hi!
On Wed, Mar 03, 2021 at 06:07:29PM -0300, Alexandre Oliva wrote:
> On Mar 3, 2021, Segher Boessenkool wrote:
> It's skipping the test, as the change you propose, that reduces testing
> surface, when testing only a configuration that ends up skipping it.
Not at all. There are very many
On March 9, 2021 4:40:22 PM GMT+01:00, Jakub Jelinek wrote:
>Hi!
>
>Before my PR97690 changes, conditional_replacement would not set neg
>when the nonzero arg was boolean true.
>I've simplified the testing, so that it first finds the zero argument
>and then checks the other argument for all the
Fix a signed vs unsigned comparison in last change.
gcc:
* common/config/arm/arm-common.c (arm_config_default): Change type
of 'i' to unsigned.
---
gcc/common/config/arm/arm-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The previous version returned true for all PowerPC. This is incorrect.
We only support floating point square root instructions if a) we support
floating point instructions at all, and b) we have _ARCH_PPCSQ defined.
2020-03-09 Segher Boessenkool
* testsuite/lib/target-supports.exp
> We should still test that we get the warning if the target doesn't have
> the attribute. I'll fix the test, thanks.
You probably need to do the same on the 10 branch since it fails there too.
--
Eric Botcazou
Here is the patch taking all the proposals into account.
Successfully bootstrapped on x86-64.
commit 7ad6b73421e3599628bf52fb175f004ce13f2ae9 (HEAD -> master)
Author: Vladimir N. Makarov
Date: Tue Mar 9 10:57:21 2021 -0500
[PR99454] LRA: Process separately 'g' and digital constraints >
On 3/8/21 3:21 PM, Eric Botcazou wrote:
>> This one worked. Is that what you had in mind?
>>
>> * raise-gcc.c: On Cygwin include mingw32.h to prevent
>> windows.h from including x86intrin.h or emmintrin.h.
> Yep, exactly, thanks, you may put it on whichever branch you need.
I've
> Oops, I wrote "effected" when I meant "affected". Of course, despite reading
> it several times before sending, I only noticed it after sending.
>
> Edited version:
>
> ---
>
> * libgnat/a-cohase.ads, libgnat/a-cohase.adb, libgnat/a-cohama.ads,
> libgnat/a-cohama.adb, libgnat/a-cihama.ads,
Hi all,
Here is a v2 patch which provides a more obviously fake answer to
TARGET_BUILTIN_DECL: this can hopefully go in for GCC 11. For GCC 12, it
seems that we should consider removing the target hook.
Original patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566405.html
---
As
Hi!
Before my PR97690 changes, conditional_replacement would not set neg
when the nonzero arg was boolean true.
I've simplified the testing, so that it first finds the zero argument
and then checks the other argument for all the handled cases
(1, -1 and 1 << X, where the last case is what the
On 3/9/21 3:53 AM, Claudiu Zissulescu via Gcc-patches wrote:
> Remove unused function.
>
> gcc/
> 2021-03-09 Claudiu Zissulescu
>
> * config/arc/arc.c (arc_attr_type): Remove function.
OK
jeff
Oops, I wrote "effected" when I meant "affected". Of course, despite reading
it several times before sending, I only noticed it after sending.
Edited version:
---
* libgnat/a-cohase.ads, libgnat/a-cohase.adb, libgnat/a-cohama.ads,
libgnat/a-cohama.adb, libgnat/a-cihama.ads,
On 3/9/21 10:23 AM, Jakub Jelinek wrote:
On Tue, Mar 09, 2021 at 08:01:26AM -0500, Nathan Sidwell wrote:
thanks for digging into this. Looks good, but could you take the
opportunity to rewrite the conditionals to a single
if (dummy) { ... do the non-null things ... }
?
So like this?
Hey Arno,
I forgot that last time as well! How about this:
---
* libgnat/a-cohase.ads, libgnat/a-cohase.adb,
libgnat/a-cohama.ads, libgnat/a-cohama.adb,
libgnat/a-cihama.ads, libgnat/a-cihama.adb:
Ensure that Cursor objects always have their "Position" component set to
ensure predefined
Hi!
My PR82304/PR95307 fix moved reinterpret cast from pointer to integer
diagnostics from cxx_eval_outermost_constant_expr where it caught
invalid code only at the outermost level down into
cxx_eval_constant_expression.
Unfortunately, it regressed following testcase, we emit worse code
including
On 2021-03-09 9:53 a.m., Martin Liška wrote:
On 3/9/21 3:12 PM, Vladimir Makarov via Gcc-patches wrote:
The patch was successfully bootstrapped and tested on x86-64,
ppc64le, and arm64. Unfortunately, I did not manage to reduce the
test (whose size is 5MB).
I've just reduced test-case
On Tue, Mar 09, 2021 at 08:01:26AM -0500, Nathan Sidwell wrote:
> thanks for digging into this. Looks good, but could you take the
> opportunity to rewrite the conditionals to a single
>
> if (dummy) { ... do the non-null things ... }
>
> ?
So like this? Bootstrapped/regtested on x86_64-linux
First, gcc.dg/array-quals-1.c does not pass if the compiler is configured with
--enable-default-pie because the section names change, so force -fno-pie.
Second, replace *-*-solaris* with sparc*-*-* for gfortran.dg/pr95690.f90
because this depends on the architecture rather than the OS. Third
Hi Guys,
I am applying the patch below to fix a problem building the rx port.
The rx.h header file defines PREFERRED_DEBUGGING_TYPE but it was not
defining the types of debugging it preferred. This results in the
definition in defaults.h being triggered and the compiler complaining
On 3/9/21 3:12 PM, Vladimir Makarov via Gcc-patches wrote:
The patch was successfully bootstrapped and tested on x86-64, ppc64le, and
arm64. Unfortunately, I did not manage to reduce the test (whose size is 5MB).
I've just reduced test-case from it:
$ cat a.c
struct skb_shared_info {
On 2021-03-09 9:26 a.m., Jakub Jelinek wrote:
On Tue, Mar 09, 2021 at 09:12:36AM -0500, Vladimir Makarov via Gcc-patches
wrote:
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 76e3ff7efe6..feff766c590 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -3452,6
On Tue, Mar 09, 2021 at 03:26:12PM +0100, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Mar 09, 2021 at 09:12:36AM -0500, Vladimir Makarov via Gcc-patches
> wrote:
> > diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
> > index 76e3ff7efe6..feff766c590 100644
> > ---
On Tue, Mar 09, 2021 at 09:12:36AM -0500, Vladimir Makarov via Gcc-patches
wrote:
> diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
> index 76e3ff7efe6..feff766c590 100644
> --- a/gcc/lra-constraints.c
> +++ b/gcc/lra-constraints.c
> @@ -3452,6 +3452,10 @@ process_address_1 (int nop,
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99454
The patch was successfully bootstrapped and tested on x86-64, ppc64le,
and arm64. Unfortunately, I did not manage to reduce the test (whose
size is 5MB).
commit 9725df0233b6fb6e761875968b3b8e9fd9f522ac (HEAD ->
On Mär 09 2021, Jose E. Marchesi via Gcc-patches wrote:
> remote: error: hook declined to update refs/heads/users/jemarch/ctf-v4
User branches are located under refs/users.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA
gcc/ChangeLog:
* config/s390/s390.c (struct s390_processor processor_table):
Binutils name string must not be empty.
---
gcc/config/s390/s390.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index
Hi!
Not all OSes have regex.h and not all OSes that do have REG_STARTEND macro
support.
Conditionalize the test on that.
Tested on x86_64-linux without/with Martin's libsanitizer fix, committed to
trunk as obvious.
2021-03-09 Jakub Jelinek
PR sanitizer/98920
*
This clarifies that c++2[03] intentionally does not enable c++20 modules.
PR c++/99472
gcc/cp/
parser.c (cp_parser_diagnose_invalid_type_name): Clarify
that C++20 does not yet imply modules.
--
Nathan Sidwell
diff --git c/gcc/cp/parser.c w/gcc/cp/parser.c
index
On 3/9/21 4:51 AM, Jakub Jelinek wrote:
Hi!
The r11-7528 build_co_await changes broke coroutines on arm*-linux-gnuabi,
2780 ^FAIL.*coroutines/ in total.
The problem is that arm is targetm.cxx.cdtor_return_this target where
both ctors and dtors in the ABI return this pointer rather than
void,
> On Tue, Mar 9, 2021 at 11:46 AM Jose E. Marchesi
> wrote:
>>
>>
>> >> It probably should define BTF_DEBUGGING_INFO and that should
>> >> enable parts guarded with DWARF2_DEBUGGING_INFO as well.
>> >
>> > BTW, is there a git branch one can more easily browse the new code?
>>
>> I can push the
> On Mon, Mar 8, 2021 at 6:19 PM Eric Botcazou wrote:
> >
> > Hi,
> >
> > this is a regression present on the mainline and 10 branch for architectures
> > that pass all structure types by reference, e.g. 32-bit PowerPC or SPARC.
> >
> > Jakub posted a detailed analysis in the audit trail and this
On Tue, Mar 9, 2021 at 12:29 PM Jose E. Marchesi
wrote:
>
>
> Hi Richard.
> Thanks for looking at this :)
>
> [Today I sent a V4 of the series containing a couple of fixes to the BTF
> code. It doesn't contain big changes so the discussion below still
> applies.]
>
> >> In turn,
Hi Richard.
Thanks for looking at this :)
[Today I sent a V4 of the series containing a couple of fixes to the BTF
code. It doesn't contain big changes so the discussion below still
applies.]
>> In turn, debug_format_do_cu traverses the tree of DIEs passed to it calling
>> ctf_do_die on
On Tue, Mar 9, 2021 at 11:46 AM Jose E. Marchesi
wrote:
>
>
> >> It probably should define BTF_DEBUGGING_INFO and that should
> >> enable parts guarded with DWARF2_DEBUGGING_INFO as well.
> >
> > BTW, is there a git branch one can more easily browse the new code?
>
> I can push the branch to
Remove unused function.
gcc/
2021-03-09 Claudiu Zissulescu
* config/arc/arc.c (arc_attr_type): Remove function.
Signed-off-by: Claudiu Zissulescu
---
gcc/config/arc/arc.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/gcc/config/arc/arc.c
>> It probably should define BTF_DEBUGGING_INFO and that should
>> enable parts guarded with DWARF2_DEBUGGING_INFO as well.
>
> BTW, is there a git branch one can more easily browse the new code?
I can push the branch to users/jemarch/ctf-v4 if thats ok?
On Tue, Mar 9, 2021 at 11:15 AM Richard Biener
wrote:
>
> On Mon, Mar 1, 2021 at 12:18 PM Jose E. Marchesi via Gcc-patches
> wrote:
> >
> > [Changes from V2:
> > - Rebased to latest master.
> > - Several bug fixes in the CTF support.
> > - Several bug fixes in the BTF support.
> > - New tests
On Mon, Mar 1, 2021 at 12:17 PM Jose E. Marchesi via Gcc-patches
wrote:
I think I've already said this at some point but you shouldn't need
this. There's no
"GIMPLE language", the user wrote C or C++ or Fortran or ...
> 2021-02-18 Indu Bhagat
>
> * langhooks.c (lang_GNU_GIMPLE): New
On Mon, Mar 1, 2021 at 12:18 PM Jose E. Marchesi via Gcc-patches
wrote:
>
> [Changes from V2:
> - Rebased to latest master.
> - Several bug fixes in the CTF support.
> - Several bug fixes in the BTF support.
> - New tests for BTF.
> - Fix a couple of tests in the CTF testsuite.
> - More testing:
This commit adds a new testsuite for the CTF debug format.
2021-02-18 Indu Bhagat
David Faust
gcc/testsuite/
* gcc.dg/debug/btf/btf-1.c: New test.
* gcc.dg/debug/btf/btf-2.c: Likewise.
* gcc.dg/debug/btf/btf-anonymous-struct-1.c: Likewise.
*
This patch changes the BPF GCC backend in order to use the DWARF debug
hooks and therefore enables the user to generate BTF debugging
information with -gbtf. Generating BTF is crucial when compiling BPF
programs, since the CO-RE (compile-once, run-everwhere) mechanism
used by the kernel BPF
This commit documents the new command line options introduced by the
CTF and BTF debug formats.
2021-02-18 Indu Bhagat
* doc/invoke.texi: Document the CTF and BTF debug info options.
---
gcc/doc/invoke.texi | 20
1 file changed, 20 insertions(+)
diff --git
[Changes from V3:
- Rebased to latest master.
- Several bug fixes in the BTF support.
- More testing: 860 Gentoo packages built with -gctf activated by
default.]
Hi people!
Last year we submitted a first patch series introducing support for
the CTF debugging format in GCC [1]. We got a lot of
2021-02-18 Indu Bhagat
* langhooks.c (lang_GNU_GIMPLE): New Function.
* langhooks.h: New Prototype.
---
gcc/langhooks.c | 9 +
gcc/langhooks.h | 1 +
2 files changed, 10 insertions(+)
diff --git a/gcc/langhooks.c b/gcc/langhooks.c
index 2354386f7b4..0082ee9f350 100644
Hi!
The r11-7528 build_co_await changes broke coroutines on arm*-linux-gnuabi,
2780 ^FAIL.*coroutines/ in total.
The problem is that arm is targetm.cxx.cdtor_return_this target where
both ctors and dtors in the ABI return this pointer rather than
void, and build_new_method_call_1 does:
On Tue, Mar 9, 2021 at 10:18 AM Eric Botcazou wrote:
>
> > The whole point of thunks is that they do not require things like copying
> > ... is this case somehow IPA-SRA/CPed in an odd way? Otherwise it seems
> > like the passed through reference was mishandled on the GIMPLE level?
>
> Maybe,
> The whole point of thunks is that they do not require things like copying
> ... is this case somehow IPA-SRA/CPed in an odd way? Otherwise it seems
> like the passed through reference was mishandled on the GIMPLE level?
Maybe, but the change looks correct on its own and nobody has cared about
On Mon, Mar 8, 2021 at 6:19 PM Eric Botcazou wrote:
>
> Hi,
>
> this is a regression present on the mainline and 10 branch for architectures
> that pass all structure types by reference, e.g. 32-bit PowerPC or SPARC.
>
> Jakub posted a detailed analysis in the audit trail and this boils down to
>
On Mon, Mar 8, 2021 at 4:46 PM Alex Coplan wrote:
>
> On 08/03/2021 16:21, Richard Biener wrote:
> > On Mon, Mar 8, 2021 at 4:14 PM Alex Coplan wrote:
> > >
> > > On 08/03/2021 14:57, Richard Biener wrote:
> > > > On Mon, Mar 8, 2021 at 12:44 PM Alex Coplan via Gcc-patches
> > > > wrote:
> > >
Richard,
Your patch is missing a corresponding commit log.
Can you please add it to your submission? Otherwise your test and patch
look good so far, thanks!
Arno
> We discovered an issue with the GNAT implementation of the hashed container
> types.
70 matches
Mail list logo
