- The alignment for local variable was adjust during estimate_stack_frame_size,
however it seems wrong spot to adjust that, expand phase will adjust that
but it little too late to some gimple optimization, which rely on certain
target hooks need to check alignment, forwprop is an example
On Mon, 13 Apr 2020, Jason Merrill wrote:
> On 4/13/20 2:49 PM, Patrick Palka wrote:
> > On Mon, 13 Apr 2020, Jason Merrill wrote:
> >
> > > On 4/12/20 9:43 AM, Patrick Palka wrote:
> > > > On Sat, 11 Apr 2020, Jason Merrill wrote:
> > > >
> > > > > On 4/10/20 5:47 PM, Patrick Palka wrote:
> > >
On Mon, 6 Apr 2020, Gustavo Romero via Gcc-patches wrote:
> Currently an use of get() method of dump_context singleton in optinfo
> framework causes a new class to be instantiated, which calls the singleton
> dtor when the class is destroyed, freeing memory that is referenced after
> free() is cal
On 4/13/20 7:43 PM, Marek Polacek wrote:
While reviewing [basic.scope.param] I noticed we don't show the location
of the previous declaration when giving an error about "A parameter name
shall not be redeclared in the outermost block of the function definition".
Bootstrapped/regtested on x86_64-
On 4/13/20 2:49 PM, Patrick Palka wrote:
On Mon, 13 Apr 2020, Jason Merrill wrote:
On 4/12/20 9:43 AM, Patrick Palka wrote:
On Sat, 11 Apr 2020, Jason Merrill wrote:
On 4/10/20 5:47 PM, Patrick Palka wrote:
On Fri, 10 Apr 2020, Jason Merrill wrote:
On 4/10/20 2:15 PM, Patrick Palka wrote:
On 4/12/20 5:49 PM, Martin Sebor wrote:
On 4/10/20 8:52 AM, Jason Merrill wrote:
On 4/9/20 4:23 PM, Martin Sebor wrote:
On 4/9/20 1:32 PM, Jason Merrill wrote:
On 4/9/20 3:24 PM, Martin Sebor wrote:
On 4/9/20 1:03 PM, Jason Merrill wrote:
On 4/8/20 1:23 PM, Martin Sebor wrote:
On 4/7/20 3:3
This patch fixes PR target/94557, on PowerPC. It was a regression on the GCC 9
branch caused by my recent patch for PR target/93932.
The patch for 93932 was a back port from the master branch of a fix for the
vec_extract built-in function. This patch fixes the case where we are
optimizing a vect
I believe set_rtx_cost is meant to handle a SET, not a PLUS as is
passed in these two locations. Using the proper function for a PLUS
doesn't make a huge difference: the only arg change to rtx_cost of any
consequence is outer_code of SET rather than INSN. A mode of
word_mode rather than VOIDmode
While reviewing [basic.scope.param] I noticed we don't show the location
of the previous declaration when giving an error about "A parameter name
shall not be redeclared in the outermost block of the function definition".
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++
Patterns zero_extendhisi2, zero_extendqisi2 and extendhisi2_internal can
load value from memory, but they don't treat volatile memory correctly.
Add %v1 before load instructions to emit 'memw' instruction when
-mserialize-volatile is in effect.
2020-04-13 Max Filippov
gcc/
* config/xten
On 2020-04-13 10:08, will schmidt wrote:
On Fri, 2020-04-10 at 18:00 -0500, acsawdey via Gcc-patches wrote:
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 2b6613bcb7e..c77e60a718f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -24824,15 +2
-Wall was missing a couple of options and -Wrestrict mentioned
its negative form as if was enabled by default (it's in -Wall).
I just pushed the patch below to correct these minor mistakes:
https://gcc.gnu.org/pipermail/gcc-cvs/2020-April/279540.html
Martin
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-10.1-b20200322.sv.po'
Hi Duanbo,
> This is a simple fix for pr94577.
> The option -mabi=ilp32 should not be used in large code model. Like x86,
> using -mx32 and -mcmodel=large together will result in an error message.
> On aarch64, there is no error message for this option conflict.
> A solution to this problem can b
On 4/12/20 9:48 AM, Patrick Palka wrote:
We are hitting a recursive loop when printing the signature of a function
containing a decltype([]{}) type. The loop is
dump_function_decl -> dump_substitution
-> dump_template_bindings
-> dump_type
Hi,
this is a small piece of housekeeping:
The current standard draft (n4861) renamed the cpp builtin for
coroutines to ‘__cpp_impl_coroutine’. No other change.
(NOTE; there are other defines to be added to and but
that’s
a separate issue from this renaming).
tested on x86_64-darw
On 4/13/20 1:25 PM, Jeff Law wrote:
On Mon, 2020-04-13 at 12:39 -0600, Martin Sebor via Gcc-patches wrote:
GCC 10 has changed the formatting of zero-length arrays in diagnostics
to include their bound, but it also inadvertently added the zero bound
to flexible array members which are confusingly
On Mon, 2020-04-13 at 06:25 -0600, Zackery Spytz via Gcc-patches wrote:
> Hello,
>
> The realloc() function was missing from parts of the documentation!
THanks. Applied.
jeff
>
On Mon, 2020-04-13 at 12:39 -0600, Martin Sebor via Gcc-patches wrote:
> GCC 10 has changed the formatting of zero-length arrays in diagnostics
> to include their bound, but it also inadvertently added the zero bound
> to flexible array members which are confusingly represented differently
> betwee
On Mon, 13 Apr 2020, Jason Merrill wrote:
> On 4/12/20 9:43 AM, Patrick Palka wrote:
> > On Sat, 11 Apr 2020, Jason Merrill wrote:
> >
> > > On 4/10/20 5:47 PM, Patrick Palka wrote:
> > > > On Fri, 10 Apr 2020, Jason Merrill wrote:
> > > > > On 4/10/20 2:15 PM, Patrick Palka wrote:
> > > > > > On
GCC 10 has changed the formatting of zero-length arrays in diagnostics
to include their bound, but it also inadvertently added the zero bound
to flexible array members which are confusingly represented differently
between the C and C++ front ends.
The attached patch corrects the problem so both z
Hi,
>From XCode 11.4 on 10.14/15 use of 10.6 and 10.7 is deprecated.
The tools issue diagnostics if -mmacosx-version-min= < 10.8
Adjust the testcase to avoid that usage on 10.14, 10.15 for now.
tested on x86_64-darwin10, 19
applied to master
thanks
Iain
gcc/testsuite/ChangeLog:
2020-04-13 Iai
On 4/13/20 9:18 AM, Patrick Palka wrote:
In this PR we're incorrectly rejecting a self-modifying constexpr initializer as
a consequence of the fix for PR78572.
It looks like however that the fix for PR78572 is obsoleted by the fix for
PR89336: the testcase from the former PR successfully compile
On Mon, Apr 13, 2020 at 10:20 AM Thomas Koenig via Fortran
wrote:
>
> Hello world,
>
> the attached patch fixes an ICE on invalid: When the return type of
> a function was misdeclared with a wrong rank, we issued a warning,
> but not an error (unless with -pedantic); later on, an ICE ensued.
>
> N
On 4/12/20 9:43 AM, Patrick Palka wrote:
On Sat, 11 Apr 2020, Jason Merrill wrote:
On 4/10/20 5:47 PM, Patrick Palka wrote:
On Fri, 10 Apr 2020, Jason Merrill wrote:
On 4/10/20 2:15 PM, Patrick Palka wrote:
On Fri, 10 Apr 2020, Patrick Palka wrote:
On Fri, 10 Apr 2020, Jason Merrill wrote:
On Sat, Apr 11, 2020 at 10:27 AM Linus König wrote:
>
> Hi,
>
> Here is the patch with some of the null pointer tests removed.
>
> This is regression-tested. ChangeLog and test case are as in
> https://gcc.gnu.org/pipermail/fortran/2020-April/054193.html .
Thanks. Sorry I missed the ChangeLog ent
On Fri, 2020-04-10 at 18:00 -0500, acsawdey via Gcc-patches wrote:
> One of the things that address_to_insn_form() is used for is
> determining
> whether a PC-relative addressing instruction could be used. In
> particular predicate pcrel_external_address and function
> prefixed_paddi_p() both us
Hi Iain,
> Rainer Orth wrote:
>
>>> diff --git
>>> a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
>>> b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
>>> index 864846e365c..8211e8250ff 100644
>>> ---
>>> a/gcc/testsuite/g++.dg/coroutines/torture/
Hi Rainer,
Rainer Orth wrote:
diff --git
a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
index 864846e365c..8211e8250ff 100644
---
a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-
Hi Iain,
> diff --git
> a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
> b/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
> index 864846e365c..8211e8250ff 100644
> --- a/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
> +++ b/
Hello world,
the attached patch fixes an ICE on invalid: When the return type of
a function was misdeclared with a wrong rank, we issued a warning,
but not an error (unless with -pedantic); later on, an ICE ensued.
Nothing good can come from wrongly declaring a function type
(considering the ABI
On 4/11/20 10:46 AM, Iain Sandoe wrote:
Hi Folks,
sorry for the long CC list - please feel free to ignore if you don’t care :)
I propose that this PR should be re-categorized as a “C++” one.
The reason is that this is not an oversight in the GCC implementation,
but a problem present in the gene
On 08/04/2020 10:14, Iain Buclaw via Gcc-patches wrote:
> On 28/01/2020 05:00, Mathias Lang wrote:
>> diff -Nurp a/libphobos/configure.ac b/libphobos/configure.ac
>> --- a/libphobos/configure.ac
>> +++ b/libphobos/configure.ac
>> @@ -140,6 +140,14 @@ case ${host} in
>> esac
>> AC_MSG_RESULT($LIBP
In this PR we're incorrectly rejecting a self-modifying constexpr initializer as
a consequence of the fix for PR78572.
It looks like however that the fix for PR78572 is obsoleted by the fix for
PR89336: the testcase from the former PR successfully compiles even with its fix
reverted.
But then fur
Hi
This is a simple fix for pr94577.
The option -mabi=ilp32 should not be used in large code model. Like x86, using
-mx32 and -mcmodel=large together will result in an error message.
On aarch64, there is no error message for this option conflict.
A solution to this problem can be found in the att
Hello,
The realloc() function was missing from parts of the documentation!
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 79e2c8cb87f..81bb7a47de2 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -12434,6 +12434,7 @@ is called and the @var{flag} argument passed to it.
Some insns, which operate on SImode operands, output assembler template
that comprise of multiple instructions using HImode operands. To access
the high word of an SImode operand, an operand selector '%H' is used to
offset the operand value by a constant amount.
When one of these HImode operands i
The %C and %D operand modifiers are supposed to access the 3rd and 4th
words of a 64-bit value, so for memory references they need to offset
the given address by 4 and 6 bytes respectively. Currently they incorrectly
offset the address by 3 and 4 bytes respectively.
Committed the attached patch as
Hi,
This is a simple fix for pr94574.
testcase testsuite/gcc.target/aarch64/sve/acle/general/deref_1.c ICEs when
testing GCC trunk with -O2 -msve-vector-bits=256 -march=armv8.2-a+sve.
There is a gimple statement before the ccp pass as follow:
MEM[(svuint32_t *)&res] = _2;
The ccp p
Hi,
This patch merges the D front-end implementation with upstream dmd
d0d4f02a0.
Removes the implementation of __traits(argTypes), which only supported
x86_64 targets. The only use of this trait is an unused va_arg()
function, this has been removed as well.
Bootstrapped and regression tested o
On Sun, Apr 12, 2020 at 11:28 PM H.J. Lu wrote:
>
> We must restore the frame pointer in word_mode for eh_return epilogues
> since the upper 32 bits of RBP register can have any values.
>
> Tested on Linux/x32 and Linux/x86-64. OK for master and backport to
> GCC 8/9 branches?
>
> Thanks.
>
> H.J
Hi!
On 2020-04-10T16:44:42+0200, I wrote:
> On 2020-01-17T12:18:18-0800, Julian Brown wrote:
>> This patch series provides fixes for some cases of mixing static and
>
> (It's "structured", not "static".) ;-)
Of course, that should be reflected...
> libgomp/
> PR libgomp/92843
>
42 matches
Mail list logo
