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
>
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,
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
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
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
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
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.
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
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
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
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
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
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/
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,
> 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/
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
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 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 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/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
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
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
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
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, 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 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
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/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 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
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'
-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
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
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
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++
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
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
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
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/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 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 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:
> > >
- 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
42 matches
Mail list logo
