Hello,
I have received permission to contribute to GCC, but I do not have
commit access. Could one of you please merge these patches for me?
-Alex
Alex Henrie (1):
PR c/65403 - Add tests for -Wno-error=
Manuel López-Ibáñez (1):
PR c/65403 - Ignore -Wno-error=
gcc/opts-common.c
From: Manuel López-Ibáñez
* opts.c: Ignore -Wno-error= except if there are
other diagnostics.
---
gcc/opts-common.c | 2 ++
gcc/opts-global.c | 10 +++---
gcc/opts.c| 5 -
gcc/opts.h| 2 ++
4 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/gcc/opts-common
---
gcc/testsuite/c-c++-common/pr65403-1.c | 10 ++
gcc/testsuite/c-c++-common/pr65403-2.c | 15 +++
2 files changed, 25 insertions(+)
create mode 100644 gcc/testsuite/c-c++-common/pr65403-1.c
create mode 100644 gcc/testsuite/c-c++-common/pr65403-2.c
diff --git a/gcc/testsui
On 3/18/19 6:18 PM, Jonathan Wakely wrote:
On 17/03/19 22:54 -0400, Ed Smith-Rowland via libstdc++ wrote:
Greetings,
This patch implements C++20 p0202 - Add Constexpr Modifiers to
Functions in and Headers
and C++20 p1023 - constexpr comparison operators for std::array.
The patch is large
On Mon, Mar 18, 2019 at 6:58 PM Jeff Law wrote:
>
> On 3/18/19 6:35 PM, James Hilliard wrote:
> > On Mon, Mar 18, 2019 at 5:46 PM Jeff Law wrote:
> >>
> >> On 3/18/19 5:07 PM, James Hilliard wrote:
> >>> On Mon, Mar 18, 2019 at 4:51 PM Jakub Jelinek wrote:
>
> On Mon, Mar 18, 2019 at 0
On 3/18/19 6:35 PM, James Hilliard wrote:
> On Mon, Mar 18, 2019 at 5:46 PM Jeff Law wrote:
>>
>> On 3/18/19 5:07 PM, James Hilliard wrote:
>>> On Mon, Mar 18, 2019 at 4:51 PM Jakub Jelinek wrote:
On Mon, Mar 18, 2019 at 04:41:05PM -0600, James Hilliard wrote:
>> Thanks, but I'm say
On Mon, Mar 18, 2019 at 5:46 PM Jeff Law wrote:
>
> On 3/18/19 5:07 PM, James Hilliard wrote:
> > On Mon, Mar 18, 2019 at 4:51 PM Jakub Jelinek wrote:
> >>
> >> On Mon, Mar 18, 2019 at 04:41:05PM -0600, James Hilliard wrote:
> Thanks, but I'm saying that if you look at the code you can see t
On Mon, 18 Mar 2019, Jakub Jelinek wrote:
> Hi!
>
> The following patch (the second hunk in particular) should fix following
> testcase. c_build_qualified_type used to be called unconditionally at that
> spot, it was just the changes to use quals_used instead of type_quals there
> that made it c
On 3/18/19 5:07 PM, James Hilliard wrote:
> On Mon, Mar 18, 2019 at 4:51 PM Jakub Jelinek wrote:
>>
>> On Mon, Mar 18, 2019 at 04:41:05PM -0600, James Hilliard wrote:
Thanks, but I'm saying that if you look at the code you can see that
st is clearly initialized, by the call to lstat. I
On Mon, Mar 18, 2019 at 4:51 PM Jakub Jelinek wrote:
>
> On Mon, Mar 18, 2019 at 04:41:05PM -0600, James Hilliard wrote:
> > > Thanks, but I'm saying that if you look at the code you can see that
> > > st is clearly initialized, by the call to lstat. I would like to see
> > > an explanation for w
On Mon, Mar 18, 2019 at 04:41:05PM -0600, James Hilliard wrote:
> > Thanks, but I'm saying that if you look at the code you can see that
> > st is clearly initialized, by the call to lstat. I would like to see
> > an explanation for why you are seeing that warning before changing the
> > code to d
On Mon, Mar 18, 2019 at 2:05 PM Ian Lance Taylor wrote:
>
> On Mon, Mar 18, 2019 at 11:57 AM James Hilliard
> wrote:
> >
> > On Mon, Mar 18, 2019 at 11:19 AM Ian Lance Taylor wrote:
> > >
> > > On Sun, Mar 17, 2019 at 6:22 PM wrote:
> > > >
> > > > From: James Hilliard
> > > >
> > > > Fixes er
Hi!
For input arguments, we do:
/* If we can't make copies, we can only accept memory. */
if (TREE_ADDRESSABLE (TREE_TYPE (TREE_VALUE (link
{
if (allows_mem)
allows_reg = 0;
else
{
error ("impossible constraint in %
Hi!
The following patch (the second hunk in particular) should fix following
testcase. c_build_qualified_type used to be called unconditionally at that
spot, it was just the changes to use quals_used instead of type_quals there
that made it conditional, but it needs to be done even if quals_used
On 3/3/19 10:41 AM, Johannes Pfau wrote:
> We set __USE_MINGW_ACCESS for windows hosts to use MinGWs wrapper
> for the access function. The wrapper ensures that access behaves
> in the expected way (e.g. for special files, such as nul).
> However, we now compile most sources with the C++ compiler a
On 17/03/19 22:54 -0400, Ed Smith-Rowland via libstdc++ wrote:
Greetings,
This patch implements C++20 p0202 - Add Constexpr Modifiers to
Functions in and Headers
and C++20 p1023 - constexpr comparison operators for std::array.
The patch is large because of the testsuite additions. Basical
On 18 March 2019 10:58:53 CET, Richard Sandiford
wrote:
>This patch fixes a case in which we vectorised something with a
>fully-predicated loop even after the cost model had rejected it.
>E.g. the loop in the testcase has the costs:
>
> Vector inside of loop cost: 27
> Vector prologue cost: 0
>
On 3/14/19 10:46 PM, JiangNing OS wrote:
> This patch is to fix a missing ifcvt opportunity in back-end. For the simple
> case below,
>
> if (...)
> x = a; /* x is memory */
> /* no else */
>
> We can generate conditional move and remove the branch as below if the target
> cost is acceptab
On 3/18/19 10:59 AM, Martin Sebor wrote:
> On 3/17/19 11:24 AM, Sandra Loosemore wrote:
>> On 3/4/19 5:28 PM, Martin Sebor wrote:
>>> Attached is a patch with (mostly) my changes for GCC 9. To make
>>> things easier to find I grouped related changes together within
>>> the sections I changed. I p
On 3/18/19 1:03 PM, Martin Sebor wrote:
> I the -Warray-bounds enhancement committed at the beginning
> of the GCC 9 window I tried to correctly handle offsets in
> MEM_REFs in the [max, min] kind of a range after converting
> from sizetype to ptrdiff_type, but I did it wrong. The bug
> results in
On 18.03.19 22:22, Jeff Law wrote:
On 3/17/19 2:40 PM, Andreas Tobler wrote:
Hi all,
this patch adds support for multilib on x86_64-unknown-freebsd*
The multilibs are 32-bit.
This patch is functionality tested on gcc8 and gcc9. Test suite testing
is a bit tricky since the FreeBSD dynamic linke
I've merged trunk revision 269780 to the gccgo branch.
Ian
On 3/17/19 2:40 PM, Andreas Tobler wrote:
> Hi all,
>
> this patch adds support for multilib on x86_64-unknown-freebsd*
> The multilibs are 32-bit.
>
> This patch is functionality tested on gcc8 and gcc9. Test suite testing
> is a bit tricky since the FreeBSD dynamic linker handles both, the
> 32
On 3/19/19, H.J. Lu wrote:
> PR c++/89630
> * g++.dg/cpp0x/pr89630.C: New test.
> ---
> gcc/testsuite/g++.dg/cpp0x/pr89630.C | 15 +++
> 1 file changed, 15 insertions(+)
> create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr89630.C
>
> diff --git a/gcc/testsuite/g++.dg/cpp0x/
PR c++/89630
* g++.dg/cpp0x/pr89630.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/pr89630.C | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr89630.C
diff --git a/gcc/testsuite/g++.dg/cpp0x/pr89630.C
b/gcc/testsuite/g++.dg/cpp0x
This patch updates libgo to the 1.12.1 release. Bootstrapped and ran
Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 269713)
+++ gcc/go/gof
On Mon, Mar 18, 2019 at 3:13 AM Kito Cheng wrote:
> gcc/testsuite:
> Kito Cheng
> ChangeLog
> * gcc.target/riscv/arch-1.c: Update testcase.
OK. I committed with the ChangeLog entry reword to more accurately
describe the change.
Jim
Hi!
On Mon, Mar 18, 2019 at 10:59:26AM +0100, Iain Buclaw wrote:
> On Fri, 15 Mar 2019 at 16:50, Robin Dapp wrote:
> > during the last few days I tried to get D running on s390x (apparently
> > the first Big Endian platform to try it?). I did not yet go through the
> > code systematically and ad
On Mon, Mar 18, 2019 at 11:57 AM James Hilliard
wrote:
>
> On Mon, Mar 18, 2019 at 11:19 AM Ian Lance Taylor wrote:
> >
> > On Sun, Mar 17, 2019 at 6:22 PM wrote:
> > >
> > > From: James Hilliard
> > >
> > > Fixes error: ‘st.st_mode’ may be used uninitialized in this function
> > > ---
> > > l
I steered Marek wrong on PR 85976; even though these two using-declarations
have the same effect, they are not the same declaration, and we don't need to
work to treat them as the same like we do for typedefs, so this goes back to
the patch he initially sent.
If we did need to treat them as the sa
In this testcase we get confused when looking at the sizeof... because the
argument pack for 'args' has been wrapped in an ARGUMENT_PACK_SELECT as part
of expanding the fold-expression. We handle this situation a bit lower down
in tsubst_pack_expansion, but that doesn't help the call to
argument_p
My patch for PR 60503 to fix C++11 attribute parsing on lambdas accidentally
removed support for GNU attributes.
Tested x86_64-pc-linux-gnu, applying to trunk.
* parser.c (cp_parser_lambda_declarator_opt): Allow GNU attributes.
---
gcc/cp/parser.c | 15 ++-
I the -Warray-bounds enhancement committed at the beginning
of the GCC 9 window I tried to correctly handle offsets in
MEM_REFs in the [max, min] kind of a range after converting
from sizetype to ptrdiff_type, but I did it wrong. The bug
results in false positives in some unusual use cases that
I
On Mon, Mar 18, 2019 at 11:19 AM Ian Lance Taylor wrote:
>
> On Sun, Mar 17, 2019 at 6:22 PM wrote:
> >
> > From: James Hilliard
> >
> > Fixes error: ‘st.st_mode’ may be used uninitialized in this function
> > ---
> > libbacktrace/elf.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
It currently wants to see lvx insns on AIX, and no lvx insns on Linux.
What is really wanted is lvx insns when no VSX, and lxv* insns if VSX.
This fixes it.
2019-03-18 Segher Boessenkool
gcc/testsuite/
* gcc.target/powerpc/altivec-7.c: Look for lxv* if generating VSX
instructi
For the big stack frame in the test GCC used to say
pr18096-1.c:7:6: error: total size of local objects too large
but now it says
pr18096-1.c:7:6: error: total size of local objects 2147483647 exceeds maximum
2147483392
Let's just allow both in the test.
2019-03-18 Segher Boessenkool
gcc
Currently these bswap testcases use global variables, which causes
problems with -m32: the memory access is a D-form access, and when
combine tries to combine that with the bswap it tries a D-form store
with byte reverse. That instruction does not exist, and since combine
started with only two ins
All of them tested on powerpc64-linux {-m32,-m64}. Committing.
Segher
Segher Boessenkool (3):
rs6000: Fix pr18096-1.c test
rs6000: Use pointers in bswap testcases
rs6000: Fix altivec-7.c testcase
gcc/testsuite/gcc.target/powerpc/altivec-7.c | 6 --
gcc/testsuite/gcc.target/powerpc/
On Sun, Mar 17, 2019 at 6:22 PM wrote:
>
> From: James Hilliard
>
> Fixes error: ‘st.st_mode’ may be used uninitialized in this function
> ---
> libbacktrace/elf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libbacktrace/elf.c b/libbacktrace/elf.c
> index f3988ec02a0
On 3/17/19 11:24 AM, Sandra Loosemore wrote:
On 3/4/19 5:28 PM, Martin Sebor wrote:
Attached is a patch with (mostly) my changes for GCC 9. To make
things easier to find I grouped related changes together within
the sections I changed. I put warnings under the same bullet,
built-ins, and attri
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg02029.html
As an aside, I introduced the same mistake/false positive in
three places: -Wstringop-overflow in builtins.c, -Warray-bounds
in gimple-ssa-warn-restrict.c, and -Warray-bounds in tree-vrp.c.
This patch fixes the first two. I'm working
On 3/18/19 9:48 AM, Gerald Pfeifer wrote:
On Mon, 18 Mar 2019, David Malcolm wrote:
Here's a patch for the website to add my changes for GCC 9 (bearing
a strong resemblance to my recent blog post)
Wow, that. is. a. lot! :-)
-Porting to GCC 8 page and the
+Porting to GCC 9 page and the
Good
Here we were pushing into the right access context, but we were called from
a deferred checking context, so didn't end up doing the checks until after
we left the access context.
Tested x86_64-pc-linux-gnu, applying to trunk.
* pt.c (tsubst_default_argument): Don't defer access checks.
--
On Mon, 18 Mar 2019, David Malcolm wrote:
> Here's a patch for the website to add my changes for GCC 9 (bearing
> a strong resemblance to my recent blog post)
Wow, that. is. a. lot! :-)
> -Porting to GCC 8 page and the
> +Porting to GCC 9 page and the
Good catch!
> +
> + GCC's diagnost
Hi,
these two PRs are about C++ destructors that are not virtual but have
virtual alias. The devirtualization machinery walks from alias to symbol
and is then confused by not knowing the class symbol belongs to.
I think it would make more sense to avoid these walks but that require
more of surgery
Hi,
On Mon, 18 Mar 2019, Richard Biener wrote:
> > Or, because an enum with these properties could be modelled as a struct
> > containing one member of basetype you could also change
> > record_component_aliases(), though that doesn't allow language specific
> > behaviour differences.
>
> No,
Here's a patch for the website to add my changes for GCC 9 (bearing
a strong resemblance to my recent blog post)
OK to commit?
---
htdocs/gcc-9/changes.html | 310 +-
1 file changed, 305 insertions(+), 5 deletions(-)
diff --git a/htdocs/gcc-9/changes.
On Mon, 18 Mar 2019, Richard Biener wrote:
>
> The following adjusts release_ssa_name to not clear TREE_TYPE but set
> it to error_mark_node instead. This avoids ICEs when dumping stmts
> with released SSA names which can easily happen when doing -details
> dumps and blocks being removed during
This patch removes the arbitrary 1000-line output limit imposed in the
stdout/stderr output mechanism.
The implementation is backward compatible with the old counterpart
implementation already present in newlib, but I'll be updating that shortly.
I've run a GCN testrun with no regressions.
A
Richard Biener writes:
> On Mon, Mar 18, 2019 at 10:59 AM Richard Sandiford
> wrote:
>>
>> This patch fixes a case in which we vectorised something with a
>> fully-predicated loop even after the cost model had rejected it.
>> E.g. the loop in the testcase has the costs:
>>
>> Vector inside of l
Hi All,
The attached patch (pr85667.patch) fixes the subjected issue for 32-bit.
Please let me know your thoughts on the patch.
--
Thanks,
Lokesh
85667.patch
Description: Binary data
On Mon, Mar 18, 2019 at 10:59 AM Richard Sandiford
wrote:
>
> This patch fixes a case in which we vectorised something with a
> fully-predicated loop even after the cost model had rejected it.
> E.g. the loop in the testcase has the costs:
>
> Vector inside of loop cost: 27
> Vector prologue c
On Sun, Mar 17, 2019 at 2:04 PM Thomas Koenig wrote:
>
> Hello world,
>
> this fixes a 7/8/9 regression. The problem is that front-end inlining
> of matmul could generate calls to _gfortran_runtime_error which were
> called as non-variadic. This fixes the problem by setting the
> backend_decl on
The following adjusts release_ssa_name to not clear TREE_TYPE but set
it to error_mark_node instead. This avoids ICEs when dumping stmts
with released SSA names which can easily happen when doing -details
dumps and blocks being removed during the PRE-order CFG cleanup
phase which runs before SSA
From: Kito Cheng
gcc.target/riscv/arch-1.c getting failed after r269586, because it
wrapping all option names in gcc internal messages with %< and %>,
it make option name will print with single quote, and then mis-match
the result in the test case.
gcc/testsuite:
Kito Cheng
ChangeLog
On Fri, 15 Mar 2019 at 16:50, Robin Dapp wrote:
>
> Hi,
>
> during the last few days I tried to get D running on s390x (apparently
> the first Big Endian platform to try it?). I did not yet go through the
> code systematically and add a version(SystemZ) in every place where it
> might be needed b
This patch fixes a case in which we vectorised something with a
fully-predicated loop even after the cost model had rejected it.
E.g. the loop in the testcase has the costs:
Vector inside of loop cost: 27
Vector prologue cost: 0
Vector epilogue cost: 0
Scalar iteration cost: 7
Scalar out
> On 18 Mar 2019, at 09:12, Richard Biener wrote:
>
> On Fri, 15 Mar 2019, Jason Merrill wrote:
>
>> On 3/15/19 9:33 AM, Richard Biener wrote:
>>>
>>> The following is an attempt to fix PR71598 where C (and C++?) have
>>> an implementation-defined compatible integer type for each enum
>>> and
Hi Thomas!
On Sun, 17 Mar 2019 13:04:14 +0100, Thomas Koenig wrote:
> this fixes a 7/8/9 regression. The problem is that front-end inlining
> of matmul could generate calls to _gfortran_runtime_error which were
> called as non-variadic. This fixes the problem by setting the
> backend_decl on the
Thanks Andrew for your review,
Claudiu
On Wed, Mar 6, 2019 at 12:20 PM Claudiu Zissulescu wrote:
>
> Hi,
>
> Please find a set of 5 patches as this:
>
> [ARC] Introduce ADJUST_REG_ALLOC_ORDER.
> This patch just cleans the old way of changing the register
> allocation order and uses a g
On Fri, 15 Mar 2019, Jan Hubicka wrote:
> >
> > A previous patch of mine correcting the vectorizer target cost model
> > to properly cost scalar FP ops vs. scalar INT ops regressed
> > 416.gamess by ~10% on all modern x86 archs.
> >
> > The following mitigates this in the cost modeling by notici
On Fri, 15 Mar 2019, Jason Merrill wrote:
> On 3/15/19 9:33 AM, Richard Biener wrote:
> >
> > The following is an attempt to fix PR71598 where C (and C++?) have
> > an implementation-defined compatible integer type for each enum
> > and the TBAA rules mandate that accesses using a compatible type
On Fri, 15 Mar 2019, Michael Matz wrote:
> Hi,
>
> On Fri, 15 Mar 2019, Michael Matz wrote:
>
> > I.e. what you touched is the naming of sets (giving them identifiers),
> > whereas you should have touched where the relations between the sets are
> > established. I _think_ instead of giving en
On Fri, Mar 15, 2019 at 01:25:57PM +0300, Andrey Belevantsev wrote:
> 2019-03-15 Andrey Belevantsev
>
> PR middle-end/89676
There is a typo in the PR number that I've fixed and added a testcase for
this, committed as obvious:
2019-03-18 Jakub Jelinek
PR middle-end/86979
64 matches
Mail list logo
