On Sun, 15 Nov 2020, Jan Hubicka wrote:
> > See PR97840.
> Thanks,
> this is a false positive where we fail to discover that pointed-to type
> is empty on non-x86_64 targets. This is triggered by better alias
> analysis caused by non-escape discovery.
>
> While this is not a full fix (I hope som
On Fri, 13 Nov 2020, Jakub Jelinek wrote:
> Hi!
>
> Apparently older GDB versions didn't handle this test right and so while
> it has been properly printing 42 on line 14 (e.g. on x86_64), it issued
> a weird error on line 17 (and because it didn't print any value, guality
> testsuite wasn't mark
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html
Thanks.
Gui Haochen
On 6/11/2020 上午 9:02, HAO CHEN GUI wrote:
Hi,
Gentle ping this:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556236.html
Thanks.
Gui Haochen
On 15/10/2020 下午 4:46, HAO
On 11/14/20 12:29 PM, Liu Hao via Gcc-patches wrote:
This is the third revision of my patch:
1. Two typos in the commit message have been fixed.
2. Support for `%a` and `%A` has been added. Documentation can be
found on the same page in the commit message.
3. GCC will no longer warn about 'I
Power10: Add IEEE 128-bit fp conditional move.
This patch adds the support for power10 IEEE 128-bit floating point conditional
move and for automatically generating min/max. Unlike the previous patch, I
decided to keep two separate patterns for fpmask before splitting (one pattern
for normal comp
Power10: Add IEEE 128-bit xsmaxcqp and xsmincqp support.
This patch adds the support for the IEEE 128-bit floating point C minimum and
maximum instructions. The next patch will add the support for using the
compare and set mask instruction to implement conditional moves.
Originally, I tried to a
These two patches add support for the XSMAXCQP, XSMINCQP, XSCMP{EQ,GT,GE}QP
instructions in the Power10. These instructions allow the compiler to generate
minimum, maxmimum, and conditional move support for IEEE 128-bit floating point
type.
I have posted versions of these patches before, going ba
[ This year's end-of-stage1 I'm working virtually from American Samoa. ]
This patch finishes the second half of -Wrange-loop-construct I promised
to implement: it warns when a loop variable in a range-based for-loop is
initialized with a value of a different type resulting in a copy. For
instance
Hi,
this patch implements the logic to drop base alias sets (and thus also access
paths) from memory operands when doing so helps merging. This is done
by extending func_checker::compare_operand to record mismatched pairs
and then processing this in sem_function::equals_private when comparsion
suc
This patch implements the long-desired -Wuninitialized warning for
member initializer lists, so that the front end can detect bugs like
struct A {
int a;
int b;
A() : b(1), a(b) { }
};
where the field 'b' is used uninitialized because the order of member
initializers in the member
On Tue, 2020-09-29 at 15:56 +0200, Mark Wielaard wrote:
> On Thu, 2020-09-10 at 13:16 +0200, Jakub Jelinek wrote:
> > On Wed, Sep 09, 2020 at 09:57:54PM +0200, Mark Wielaard wrote:
> > > --- a/gcc/doc/invoke.texi
> > > +++ b/gcc/doc/invoke.texi
> > > @@ -9057,13 +9057,14 @@ possible.
> > > @opinde
The naming scheme used by GCC to reference MSP430 hardware multiply
library functions is inconsistent.
Sometimes the "GCC" names (e.g. mulsi2) are used, other times the
"MSPABI" names (e.g. __mspabi_mpyl) are used. The __mspabi names should
always be used.
Also, sometimes an identifier for the ha
Rather than inferring 16-bit hwmult support from lack of
32-bit/f5series/none hwmult support, define a function which explicitly
checks for 16-bit hwmult support.
Successfully regtested for msp430-elf.
Committed as obvious.
>From 814949ddceaef59725c84fe8ef7c6c617fb5d049 Mon Sep 17 00:00:00 2001
F
The "persistent" attribute is used for variables that are initialized
by the program loader, but are not initialized by the runtime startup
code. "persistent" variables are placed in a non-volatile area of
memory, which allows their value to "persist" between processor resets.
Successfully regtest
Attribute handlers may want to examine DECL_INITIAL for a decl, to
validate the attribute being applied. For C++, DECL_INITIAL is currently
not set until cp_finish_decl, by which time attribute validation has
already been performed.
For msp430-elf this causes the "persistent" attribute to always b
This patch series is version 2 of
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557184.html
The implementation is now simplified so as to not use a symtab flag for
"noinit" variables, instead we just check whether the decl has the
attribute set.
This patch series fixes behavior related
Variables with the "noinit" attribute are ignored at -O0 because they
are treated like a regular bss variable and placed in the .bss section.
With -fdata-sections they are ignored because they are not handled in
resolve_unique_section.
Successfully regtested for arm-none-eabi.
Ok for trunk?
>Fro
Hi Harald,
Feedback, such as comments for improvement, are welcome.
It feels a bit strange to have a check for an allocatable
behind -fcheck=pointer, but I'm not sure that introducing
a special check option would really be worth it.
Regarding pointers: They are usually not nullified (unless
th
Hardware multipliers that support widening 32-bit multiplication can
be used to perform a 64-bit * 64-bit multiplication more efficiently
than a software implementation.
The following equation is used to perform 64-bit multiplication for
devices with "32bit" or "f5series" hardware multiply version
GCC generates better code when multiplication operations, which require
library functions to perform, are caught in early in RTL, rather than
leaving the operation to be mapped to a library function later on.
When there is hardware multiply support, it is more efficient to perform
widening multipl
The attached patch series improves MSP430 hardware multiply support, by
improving code generation when setting up the 16-bit and 32-bit hardware
multiply functions, and adding a 64-bit hardware multiply library
function for devices that have a 32-bit hardware multiplier.
Successfully regtested GCC
On Tue, 10 Nov 2020, Jeff Law via Gcc-patches wrote:
> >>> This patch reduce reservation of model do not more than 10 cycles. The
> >>> memory of genautomata down to 1GB.
> >> How bad is the memory consumption before this change?
> >>
> > almost 2.4GB.
> > see bugzilla comment #4.
> > https://gcc.
Thomas,
I am seeing a number of new failures on AIX related to the OpenACC
kernels patches.
c-c++-common/goacc/kernels-decompose-1.c
c-c++-common/goacc/kernels-decompose-2.c
gfortran.dg/goacc/kernels-decompose-1.f95
gfortran.dg/goacc/kernels-decompose-2.f95
libgomp.oacc-c++/../libgomp.oacc-c-c++-
Am Montag, den 09.11.2020, 23:41 + schrieb Joseph Myers:
> On Sat, 7 Nov 2020, Uecker, Martin wrote:
> > t = (const T) { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } };
> > test (&t);
> > }
> >
> > Not sure what to do about it, maybe 'convert' is not
> > the right function to use.
>
> I think 'co
Hi,
one of common cases why we lose track on SSA name in modref propagation
is the situation where name is passed to funtion call and we then thus
continue by propagating through return value.
This patch adds simple logic to track arguments that does not escape to
return value. On cc1plus the imp
> gcc/ada/
> * adaint.c (__gnat_number_of_cpus): Check for the presence of
> _SC_NPROCESSORS_ONLN before using it.
> ---
> NB we could probably replace the list of OS #ifdefs with just a check for
> _SC_NPROCESSORS_ONLN, making use of it automagically with any new OS that
> sup
> See PR97840.
Thanks,
this is a false positive where we fail to discover that pointed-to type
is empty on non-x86_64 targets. This is triggered by better alias
analysis caused by non-escape discovery.
While this is not a full fix (I hope someone with more experience on
C++ types and warnings wil
Hello world,
this patch makes sure that we pass the correct fn decls for
some of our library functions. cshift and others still remain
to be implemented.
This is a step in our voyage to stop lying to the middle end :-)
Regression-tested. OK for trunk?
Best regards
Thomas
Generate cor
Use `enum rtx_code' rather than `int' to hold the the RTL expression
code in `vax_rtx_costs', matching the type these codes have been defined
with and making debugging just a tiny little bit easier.
gcc/
* config/vax/vax.c (vax_rtx_costs): Use `rtx_code' rather than
`int
Correct a regression in `vax-netbsdelf' gcc testing:
.../gcc/testsuite/gcc.target/vax/bswapdi-1.c: In function '__bswapdi2':
.../gcc/testsuite/gcc.target/vax/bswapdi-1.c:5:19: error: use of C99 long long
integer constant [-Wlong-long]
.../gcc/testsuite/gcc.target/vax/bswapdi-1.c:6:14: error: use
Hi,
In the course of my recent VAX backend modernisation effort I originally
tried the initial version of the VAX/NetBSD port that provided ELF file
format support, specifically 1.6.2, which at least in theory we aim to
support with the `vax-netbsdelf' target. That indeed turned out to be a
Check for the presence of _SC_NPROCESSORS_ONLN rather than using it
unconditionally with `sysconf', fixing a compilation error:
adaint.c: In function '__gnat_number_of_cpus':
adaint.c:2398:26: error: '_SC_NPROCESSORS_ONLN' undeclared (first use in this
function)
2398 | cores = (int) sysconf (
Disable USE_PT_GNU_EH_FRAME frame unwinder support for old OS versions,
fixing compilation errors:
.../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr'
75 | # define ElfW(type) Elf_##type
| ^~~~
.../libgcc/unwind-dw2-fde-dip.c:132:9: note: in exp
Fix a typo in a NO_EXTERNAL_INDIRECT_ADDRESS macro check around an
assertion verifying DImode addition operands to be valid for PIC.
gcc/
* config/vax/vax.c (vax_output_int_add) : Fix a typo
in NO_EXTERNAL_INDIRECT_ADDRESS.
---
Hi,
No regressions in `vax-netbsdelf' test
Fix a typo and check both SImode addition operands for being incorrectly
symbolic in PIC mode before issuing a diagnostic dump of the offending
RTL expression.
gcc/
* config/vax/vax.c (vax_output_int_add) : Also check
`operands[2]' for being symbolic with PIC rather than
PowerPC: Restrict long double test to use IBM long double.
I posted this patch previously as a set of 3 testsuite patches. I have
separated them into separate patches. This patch marks the convert-bfp-11.c
patch as needing IBM extended double. If you look at the code, it is
specifically designe
>From 698d9fd8a5701fa4ed9690ddf71d57765921778c Mon Sep 17 00:00:00 2001
From: Michael Meissner
Date: Sun, 15 Nov 2020 00:48:23 -0500
Subject: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.
This patch was previously posted as a combined patch with 2 other testsuite
patches. I moved it to
Include math.h in nextafter-2.c test.
I previously posted this with two other patches. I've separated this into its
own patch. What happens is because the nextafter-2.c test uses -fno-builtin,
and it does not include math.h, the wrong nextafterl and nextforwardl gets
called when long double is n
My last patch implementing output reloads in asm goto resulted in LRA
crash in compiling kernel on s390x. Jeff Law reported it recently. The
culprit was in incorrect emitting reload insns in last empty BB. The
emitted insns got null BB which is wrong. Actually in this case we do
not need to
Abstract checking has been problematic for a while; when I implemented an
earlier issue resolution to do more checking it led to undesirable
instantiations, and so backed some of it out. During the C++20 process we
decided with P0929R2 that we should go the other way, and only check
abstractness w
Since Jeff says that the latest Fedora build went fine, we can safely
remove the duplicated code in vr_values.
Here is the original proposal rebased for latest trunk.
Tested on x86-64 Linux.
Pushed.
commit 82b6d25d289195d41e53fc91f63325864e3e28d0
Author: Aldy Hernandez
Date: Wed Oct 28 16:
See PR97840.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Hi Jan,
>> > When I configure with ../configure --enable-languages=go my build
>> > eventually finishes fine on curren trunk:
>> [...]
>> > On Debian SLES machines. Having preprocessed go-diagnostics.cc and
>> > .uninit1 dump would probably help.
>>
>> apart from go/diagnostics.cc, I see the war
On Fri, Oct 30, 2020 at 2:46 AM Richard Biener wrote:
>
> On Fri, 30 Oct 2020, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > On Wed, 28 Oct 2020, Christophe Lyon wrote:
> > >
> > >> On Wed, 28 Oct 2020 at 11:27, Christophe Lyon
> > >> wrote:
> > >> >
> > >> > On Tue, 27 Oct 2020 at
> On Fri, Nov 13, 2020 at 12:07 AM Richard Biener wrote:
> >
> > On Tue, 10 Nov 2020, Jan Hubicka wrote:
> >
> > > Hi,
> > > here is updaed patch.
> > >
> > > Honza
> > >
> > > Bootstrapped/regtested x86_64-linux, OK (after the fnspec fixes)?
> >
> > OK.
> >
> > Thanks,
> > Richard.
> >
>
> This
On Fri, Nov 13, 2020 at 12:07 AM Richard Biener wrote:
>
> On Tue, 10 Nov 2020, Jan Hubicka wrote:
>
> > Hi,
> > here is updaed patch.
> >
> > Honza
> >
> > Bootstrapped/regtested x86_64-linux, OK (after the fnspec fixes)?
>
> OK.
>
> Thanks,
> Richard.
>
This caused:
https://gcc.gnu.org/bugzill
On 2020-11-13 09:41, Richard Biener wrote:
> On Thu, Mar 12, 2020 at 1:41 AM J.W. Jagersma via Gcc-patches
> wrote:
>> diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
>> index 2a409dcaffe..58b16aa763a 100644
>> --- a/gcc/tree-eh.c
>> +++ b/gcc/tree-eh.c
>> @@ -2077,6 +2077,8 @@ lower_eh_constructs_2 (s
> Hi Jan,
>
> >> I'm seeing the same on both i386-pc-solaris2.11 and
> >> sparc-sun-solaris2.11, so I don't think there are special configure
> >> flags involved.
> >
> > When I configure with ../configure --enable-languages=go my build
> > eventually finishes fine on curren trunk:
> [...]
> > On
On 2020-11-12 16:51, Jeff Law wrote:
>
> On 3/11/20 6:38 PM, J.W. Jagersma via Gcc-patches wrote:
>> The following patch extends the generation of exception handling
>> information, so that it is possible to catch exceptions thrown from
>> volatile asm statements, when -fnon-call-exceptions is ena
Hi Jan,
>> I'm seeing the same on both i386-pc-solaris2.11 and
>> sparc-sun-solaris2.11, so I don't think there are special configure
>> flags involved.
>
> When I configure with ../configure --enable-languages=go my build
> eventually finishes fine on curren trunk:
[...]
> On Debian SLES machines
> Hi Jan,
>
> >> This breaks bootstrap with go.
> >>
> >> ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
> >> expand_message(const char*, va_list)':
> >> ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may
> >> be used uninitialized [-Werror=maybe-uninitialized]
Hi Jan,
>> This breaks bootstrap with go.
>>
>> ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
>> expand_message(const char*, va_list)':
>> ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may
>> be used uninitialized [-Werror=maybe-uninitialized]
>> 110 |
> This breaks bootstrap with go.
>
> ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
> expand_message(const char*, va_list)':
> ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may be
> used uninitialized [-Werror=maybe-uninitialized]
> 110 |
This breaks bootstrap with go.
../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
expand_message(const char*, va_list)':
../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may be
used uninitialized [-Werror=maybe-uninitialized]
110 | "memory alloc
Hi,
this patch implements the IPA propagation part of EAF flags handling in
ipa-modref. It extends the local analysis to collect lattice consisting of
flags and escape points (SSA name escapes if it is passed directly or
indirectly to a function call)
If useful flags are found for parameter its e
Hi Thomas,
regarding the new option:
+fopenacc-kernels=
+C ObjC C++ ObjC++ RejectNegative Joined Enum(openacc_kernels)
Var(flag_openacc_kernels) Init(OPENACC_KERNELS_PARLOOPS)
+-fopenacc-kernels=[decompose|parloops] Specify mode of OpenACC 'kernels'
constructs handling.
+
and
On 13.11.20 23:
56 matches
Mail list logo