The attached patch removes the assumption that the initializer for
a flexible array member is an array of the same cv-qualified type
as the array, avoiding the ICE.
Martin
PR c++/69912 - [6 regression] ICE in build_ctor_subob_ref initializing
a flexible array member
gcc/testsuite/ChangeLog:
201
Hi, Richard,
Thanks for the feedback. I'm afraid I can't quite figure out what
you're getting at. Please see below.
On Feb 22, 2016, Richard Biener wrote:
> I think this breaks early-debug assumptions in creating new decl DIEs
> rather than just annotating old ones.
Can you elaborate on it,
On 02/23/2016 06:56 AM, Richard Biener wrote:
On Mon, Feb 22, 2016 at 4:34 PM, Jeff Law wrote:
On 02/22/2016 07:34 AM, Richard Biener wrote:
Hum, but then you get to "inifinite" compiles again when LRA is buggy
or the user presents it with an impossible to handle asm.
Neither should be happe
On 23/02/16 22:03 +0100, Eelis wrote:
The std::min, std::max, and std::minmax overloads that take a
std::initializer_list all require that the list is not empty. The attached
patch adds debug mode checks for this.
Nice, thanks for the patch.
Thanks,
Eelis
Index: libstdc++-v3/include/deb
Anton reported a latent bug in the rs6000 port discovered with csmith.
Splitters for extendqihi2 and zero_extendqihi2 can generate invalid
compare RTL. PowerPC can load and store bytes or halfwords, but
computations operate on registers. Currently the extend patterns
exist for HImode, although no
Minor tweaks to the cost and scheduling models for Exynos M1.
Committed as r233646 and r233647.
--
Evandro Menezes
>From ab6127823e706361315f1c8b87fb4c32bc299b65 Mon Sep 17 00:00:00 2001
From: evandro
Date: Tue, 23 Feb 2016 20:21:23 +
Subject: [PATCH 1/2] * gcc/config/aarch64/aarch
The std::min, std::max, and std::minmax overloads that take a
std::initializer_list all require that the list is not empty. The attached
patch adds debug mode checks for this.
Thanks,
Eelis
Index: libstdc++-v3/include/debug/formatter.h
==
Hi!
As mentioned in the PR, the builtin-integral-1.c testcase fails on
i?86 Solaris. The problem is that on Solaris the dg-add-options c99_runtime
adds -std=c99, which turns -fexcess-precision=standard, and that on some
arches changes
_388 = (double) i1_63(D);
_389 = (double) i2_335(D);
_3
Hi!
This function has changed last year to support embedded VECTOR_CSTs in the
ctor elements. Before that change, there was no pos var and idx used to
match exactly the indices in the new vector, but if there is any VECTOR_CST,
it will fill in more positions.
Unfortunately, the final loop which z
Committed to trunk.
commit 6da32ab58d56e2909ed39e5fc2170717ad26e895
Author: Jonathan Wakely
Date: Tue Feb 23 20:01:35 2016 +
Document __STDCPP_WANT_MATH_SPEC_FUNCS__ macro
* doc/xml/manual/using.xml: Document __STDCPP_WANT_MATH_SPEC_FUNCS__.
* doc/html/*: Regenerate.
d
The header was implicitly relying on the fact that the
additional overloads defined by C++11 were not added to the global
namespace, so that it could do "using ::acosh;" to get the C library's
acosh(double) declaration only, and not the C++11 overloads.
With the new in GCC 6 that no longer work
On Tue, Feb 23, 2016 at 08:24:06PM +0100, Marek Polacek wrote:
> > --- gcc/c/c-parser.c.jj 2016-02-16 16:29:54.0 +0100
> > +++ gcc/c/c-parser.c2016-02-18 17:36:55.025067859 +0100
> > @@ -5887,12 +5887,27 @@ c_parser_for_statement (c_parser *parser
> > {
> >c_token *
On Tue, Nov 3, 2015 at 9:09 AM, Andres Tiraboschi
wrote:
> Hi
> This patch adds two plugins events when evaluated call expression and
> an init or modify expression in constexpr.
> The goal of this patch is to allow the plugins to analyze and or
> modify the evaluation of constant expressions.
On Thu, Feb 18, 2016 at 10:39:02PM +0100, Jakub Jelinek wrote:
> Hi!
>
> Here is an attempt to fix up the token reclassification after for statement,
> where we lexed the next token with the declaration from for in scope and
> need to undo that if it wasn't else.
>
> If token->id_kind is C_ID_CLA
On 19/02/16 13:17 -0700, Sandra Loosemore wrote:
On 02/19/2016 12:01 PM, Jason Merrill wrote:
On 02/19/2016 07:42 AM, Jonathan Wakely wrote:
In PR69864 Manu suggests improving the docs to explain that
-Wnarrowing sometimes produces errors not warnings.
I think the right way to do that is clari
The addition of named address spaces to the i386 backend is new for gcc6.
I had invented __seg_tls while thinking about how it might be used within
glibc. But during the last couple of weeks I've had occasion to attempt to use
the feature within the linux kernel. There, things weren't quite so e
On Wed, Feb 17, 2016 at 12:29:34AM +, Stuart Brady wrote:
> > - should __array_size (b) be an integer constant (size_t)2, or should it
> > be non-constant (size_t)2 because the argument is a VLA (albeit a VLA
> > whose top-level dimension is an integer constant expression)?
>
> Ouch. I woul
On 02/23/16 11:04, Aaron Conole wrote:
Before I start cooking up this change, is it possible I need to worry about
gcov_error being invoked from multiple threads? If so, I'll need some
kind of mutex which I think is not needed with the current design.
As I recall the main entry points to the g
Bump.
From: Faraz Shahbazker [faraz.shahbaz...@imgtec.com]
Sent: 05 February 2016 10:36
To: gcc-patches@gcc.gnu.org
Cc: Matthew Fortune
Subject: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support
Enable non-executable stack mode if assembler and linker
On Tue, 23 Feb 2016, Patrick Palka wrote:
On Tue, 23 Feb 2016, Marek Polacek wrote:
On Tue, Feb 23, 2016 at 09:58:41AM -0500, Patrick Palka wrote:
finish_call_expr thinks that a call to a function which has been
obfuscated by force_paren_expr is a call to an unknown function. This
eventually
Nathan Sidwell writes:
> On 02/22/16 14:35, Aaron Conole wrote:
>
>> D'oh, you're probably right. In my excitement to contribute, I forgot
>> this was shared. I think 'w' should be correct, since this isn't
>> intended to be read at all, but I could be convinced otherwise.
>
> sorry, I misremembe
On Tue, 23 Feb 2016, Marek Polacek wrote:
On Tue, Feb 23, 2016 at 09:58:41AM -0500, Patrick Palka wrote:
finish_call_expr thinks that a call to a function which has been
obfuscated by force_paren_expr is a call to an unknown function. This
eventually leads us to not make use of the function's
Hi!
When the base of a handled component (BIT_FIELD_REF in the testcase)
is SSA_NAME which happens to be expanded as some MEM (on the testcase
it is SSA_NAME set to VIEW_CONVERT_EXPR of an SSA_NAME that has MEM as
DECL_RTL), expand_expr_real_1 can try to update the MEM attributes from
exp, but tha
On Tue, Feb 23, 2016 at 09:58:41AM -0500, Patrick Palka wrote:
> finish_call_expr thinks that a call to a function which has been
> obfuscated by force_paren_expr is a call to an unknown function. This
> eventually leads us to not make use of the function's default arguments
> when processing the
On Wed, Nov 4, 2015 at 4:03 PM, Mikhail Maltsev wrote:
> On 11/03/2015 02:35 AM, Jeff Law wrote:
>> This is good fore the trunk too. Please install.
>>
>> Thanks!
>>
>> jeff
>
> Committed as r229758.
> grep ENABLE_CHECKING *.[ch]
dwarf2out.c:#if ENABLE_CHECKING
dwarf2out.c:#if ENABLE_CHECKING
dw
Hi!
On Mon, 15 Feb 2016 17:53:58 +0100, Tom de Vries wrote:
> On 10/02/16 15:40, Thomas Schwinge wrote:
> > On Fri, 5 Feb 2016 13:06:17 +0100, I wrote:
> >> On Mon, 9 Nov 2015 18:39:19 +0100, Tom de Vries
> >> wrote:
> >>> On 09/11/15 16:35, Tom de Vries wrote:
> this patch series for stag
On Fri, Feb 19, 2016 at 10:24 PM, Jeff Law wrote:
> On 02/16/2016 11:43 AM, Bin Cheng wrote:
>>
>>
>> From: Jeff Law
>> Sent: 11 February 2016 23:26
>> To: Bin.Cheng
>> Cc: Bin Cheng; gcc-patches@gcc.gnu.org; nd
>> Subject: Re: [PATCH PR69052]Check if loop
finish_call_expr thinks that a call to a function which has been
obfuscated by force_paren_expr is a call to an unknown function. This
eventually leads us to not make use of the function's default arguments
when processing the argument list. So a function call like f() may
compile and yet (f)() m
Hi Jerry,
> Let me no if any objections.
The test gfortran.dg/include_6.f90 should be updated:
before the patch
f951: Warning: 'gfortran.log' is not a directory
after
f951: Fatal Error: 'gfortran.log' is not a directory
Thanks,
Dominique
On Fri, Feb 19, 2016 at 8:21 AM, Martin Jambor wrote:
> Hi,
>
> in PR 69666, SRA attempts to turn a load from an aggregate that is
> uninitialized into a load from a default definition SSA name (which
> something it does to generate an appropriate warning later) but
> unfortunately it does so usin
This finally removes the Y constraint from the vector patterns while
folding some of them using a code iterator.
gcc/ChangeLog:
* config/s390/subst.md (SUBST mode iterator): Add ashiftrt.
(DSI_VI): New mode iterator.
("addr_style_op_subst"): Use DSI_VI instead of DSI.
This patch introduces substitution patterns to add PLUS const_int, and
AND operands to patterns and uses this to rewrite the existing rotate
pattern.
gcc/ChangeLog:
* config/s390/predicates.md (const_int_6bitset_operand): New
predicates.
* config/s390/s390.md: Include subs
After Y is never used anymore with SImode operands we can finally
disallow SImode (if != Pmode) in s390_decompose_address. In fact that
was the whole point of the patch series.
gcc/ChangeLog:
* config/s390/s390.c (s390_decompose_address): Don't accept SImode
anymore.
---
gcc/con
With this patch the substitution patterns added earlier are used for
the logical right shift and all the left shift patterns.
* config/s390/s390.md ("3"): Change predicate of
op2 to nonmemory_operand.
("*di3_31", "*di3_31_and"):
Merge into single pattern definition
The arithmetic shift patterns set also the condition code. This adds
more substitution potential. Depending on whether the actual result
or the CC output will be used 3 different variants of each of these
patterns are needed. This multiplied with the PLUS and the AND
operands from the earlier su
While trying to get rid of the Y constraint in the setmem patterns I
noticed that for these patterns it isn't even a problem since these
always only use the constraint with a Pmode match_operand. But while
being at it I've tried to fold some of the patterns a bit.
gcc/ChangeLog:
* config
This is an updated version of the shift count rework in the S/390
backend. I think I've addressed most of the feedback from Ulrich and
Bernd (gensupport patch).
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00940.html
Andreas Krebbel (9):
gensupport: Fix define_subst operand renumbering.
S/3
When processing substitutions the operands are renumbered. To find a
free operand number the array used_operands_numbers is used.
Currently this array is used to assign new numbers before all the
RTXes in the vector have been processed. I did run into problems with
this for insns where a match_du
So far whenever we wanted to disable an alternative we have used mode
attributes emitting constraints matching an earlier alternative
assuming that due to this the later alternative will never be chosen.
With this patch the `enabled' attribute, which so far is only set from
`cpu_facility', is over
This removes the Y constraint from the tabort pattern definition. In
this case it is easier without using substitutions.
gcc/ChangeLog:
* config/s390/s390.md ("*tabort_1"): Change predicate to
nonmemory_operand. Add a second alternative to cover
register as well as const
The following patch reverts an earlier decision of me to make the id
member unconditional. On PR26854 we can see
df_chain_block pool df-problems.c:2398 (df_chain_alloc)
152 0: 0.0% 937593072 61860737: 90.1% 24
thus a peak of 900MB used for df cha
On 02/01/2016 02:36 PM, Ulrich Weigand wrote:
> Andreas Krebbel wrote:
>
>> (define_insn "*tabort_1"
>> - [(unspec_volatile [(match_operand:SI 0 "shift_count_or_setmem_operand"
>> "Y")]
>> + [(unspec_volatile [(match_operand:SI 0 "addrreg_or_constint_operand"
>> "a,n")]
>> UN
On 02/01/2016 02:35 PM, Ulrich Weigand wrote:
> Andreas Krebbel wrote:
>
>> +; This is like the addr_style_op substitution above but with a CC clobber.
>> +(define_subst "addr_style_op_cc_subst"
>
>> +; This is like the masked_op substitution but with a CC clobber.
>> +(define_subst "masked_op_cc
On 20/02/16 09:29, Ilya Enkovich wrote:
2016-02-19 20:36 GMT+03:00 Alan Lawrence :
Mostly this is fairly straightforward, relatively little midend code is
required, and the backend cleans up quite a bit. However, I get stuck on the
case of singleton vectors (64x1). No surprises there, then...
T
gcc.target/i386/chkp-hidden-def.c currently FAILs on Solaris/x86. When
investigating, I found that on Darwin/x86 the test fails in a different
way:
FAIL: gcc.target/i386/chkp-hidden-def.c (test for excess errors)
UNRESOLVED: gcc.target/i386/chkp-hidden-def.c scan-assembler-not test.chkp
Excess e
The following fixes
df-problems.c:4405 (df_md_alloc)
-39759960:4741239668736.0% -40520627: 0.6% 0
0 heap
df-problems.c:225 (df_rd_alloc)
-17948440:4741239668736.0% -40284572: 0.3% 0
0 he
Hi Jerry,
The patch works as advertised without regression.
Just one nit, I am puzzled by the comment in the line of
gfortran.dg/namelist_89.f90
+write(99,*) " c1=(1-,1+1)" ! Treated as 1e-1?!
Should not it be
+write(99,*) " c1=(1-,1+1)" ! Should give error on item number 5
or something els
On Tue, 2016-02-23 at 09:51 +, Manuel López-Ibáñez wrote:
> On 23/02/16 08:56, Jakub Jelinek wrote:
> > On Tue, Feb 23, 2016@09:53:57AM +0100, Mark Wielaard wrote:
> >> --- a/gcc/ChangeLog
> >> +++ b/gcc/ChangeLog
> >> @@ -1,3 +1,10 @@
> >> +2016-02-23 Mark Wielaard
> >> + Jakub Jelinek
On Mon, Feb 22, 2016 at 4:34 PM, Jeff Law wrote:
> On 02/22/2016 07:34 AM, Richard Biener wrote:
>
>> Hum, but then you get to "inifinite" compiles again when LRA is buggy
>> or the user presents it with an impossible to handle asm.
>
> Neither should be happening in practice, even an impossible a
On Mon, Feb 22, 2016 at 10:30 PM, Jakub Jelinek wrote:
> Hi!
>
> Here is a fix for another -Wnonnull-compare false positive - the problem
> is that during folding the NE_EXPR of a nonnull_arg_p with NULL (on which
> the C++ FE set TREE_NO_WARNING, because it is an artificial comparison
> for dynam
On Mon, Feb 22, 2016 at 10:18 PM, Jakub Jelinek wrote:
> Hi!
>
> While we ignore -Wunreachable-code option now, as we require
> that GCC diagnostic options are CL_WARNING only, we should remember
> that this is a former Warning option (similarly for -Werror=).
>
> Bootstrapped/regtested on x86_64-
On 22/02/16 12:03, Jakub Jelinek wrote:
(f) A global command-line option, which we check alongside DECL_COMMON and
further tests (basically, we want only DECL_COMMON decls that either have
ARRAY_TYPE, or some other aggregate type with flexible array member or some
other trailing array in the str
On Mon, Feb 22, 2016 at 5:32 PM, Jeff Law wrote:
> On 02/22/2016 07:32 AM, Richard Biener wrote:
>
>>> Presumably DOM is not looking at r = s.r and realizing it could look s.r
>>> piece-wise in the available expression table. If it did, it would
>>> effectively turn that fragment into:
>>>
>>>
Hi Christian,
On 17/02/16 12:50, Christian Bruel wrote:
target_option_current_node, used in c-pragma.c to check if a state
should be popped or reseted to the previous value, was not set when
switching state with #pragma GCC target (I missed to see that, since it
is done for pop,reset). So in som
On Tue, 23 Feb 2016, Jan Hubicka wrote:
> >
> > Ok, so maybe a better question to symtab would be if there is an
> > actual definition for what __builtin_FOO will call. Not really
> > whether that definition is cfun. Of course all the fortify
> > always-inline wrappers should not count as such
Hi Jeff,
> My inclination would be to defer to gcc-7. Richi, Jakub or Joseph, as
> release managers, would have the final say though.
It's OK. I will resubmit after gcc 6 branches.
Cheers
Nick
Hi Paul,
thanks for the review. Committed as r233625.
Regards,
Andre
On Wed, 17 Feb 2016 14:13:48 +0100
Paul Richard Thomas wrote:
> Dear Andre,
>
> I had left this to somebody else, since I am travelling!
>
> The patch is verging on 'obvious' and so it is OK for trunk.
>
> Could yo
>
> Ok, so maybe a better question to symtab would be if there is an
> actual definition for what __builtin_FOO will call. Not really
> whether that definition is cfun. Of course all the fortify
> always-inline wrappers should not count as such (just in case
> the symtab code is confused about t
> On Mon, 22 Feb 2016, Jakub Jelinek wrote:
>
> > On Mon, Feb 22, 2016 at 01:44:09PM +0100, Richard Biener wrote:
> > > --- 1079,1086
> > > || !dominated_by_p (CDI_DOMINATORS,
> > > loop->latch, gimple_bb (stmt)))
> > > return;
> > > +
gcc/testsuite/ChangeLog:
* gcc.target/s390/md/movstr-1.c: Turn into compile test.
---
gcc/testsuite/gcc.target/s390/md/movstr-1.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/gcc/testsuite/gcc.target/s390/md/movstr-1.c
b/gcc/testsuite/gcc.target/s
gcc/testsuite/ChangeLog:
* gcc.target/s390/vcond-shift.c: Move to ...
* gcc.target/s390/vector/vcond-shift.c: ... here.
---
gcc/testsuite/gcc.target/s390/vcond-shift.c| 61 --
gcc/testsuite/gcc.target/s390/vector/vcond-shift.c | 61 +
On 23/02/16 11:09 +0100, Jakub Jelinek wrote:
On Tue, Feb 23, 2016 at 10:00:58AM +, Bernd Edlinger wrote:
Previously the g++ default was --std=gnu++98,
but gcc-6 changed the default to --std=gnu++14.
And when building gcc-4.9, stage1 does not override that with
--std=gnu++98.
That has chan
gcc/testsuite/ChangeLog:
* gcc.target/s390/md/movstr-2.c: Move and rename to ...
* gcc.target/s390/vector/stpcpy-1.c: ... this one.
---
gcc/testsuite/gcc.target/s390/md/movstr-2.c | 98 ---
gcc/testsuite/gcc.target/s390/vector/stpcpy-1.c | 100
Andreas Krebbel (3):
S/390: Turn movstr-1.c into compile only test.
S/390: Move movstr-2.c into vector subdir.
S/390: Move vcond-shift.c to vector subdir.
gcc/testsuite/gcc.target/s390/md/movstr-1.c| 16 +---
gcc/testsuite/gcc.target/s390/md/movstr-2.c| 98
On 23/02/16 10:00 +, Bernd Edlinger wrote:
On 23/02/15 10:42, Jonathan Wakely wrote:
On 23/02/16 07:15 +, Bernd Edlinger wrote:
as described in the PR 69881 it happens quite often that cstddef is
called with __need_size_t because we still support gmp-4.3.2 which
is installed by contrib/
Committed.
Index: porting_to.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/porting_to.html,v
retrieving revision 1.14
diff -u -r1.14 porting_to.html
--- porting_to.html 14 Feb 2016 13:13:43 - 1.14
+++ porting_to.html
On Tue, Feb 23, 2016 at 10:00:58AM +, Bernd Edlinger wrote:
> Previously the g++ default was --std=gnu++98,
> but gcc-6 changed the default to --std=gnu++14.
>
> And when building gcc-4.9, stage1 does not override that with
> --std=gnu++98.
>
> That has changed, and that triggers the latent b
On Feb 22, 2016, at 11:52 PM, Senthil Kumar Selvaraj
wrote:
>
> Yes that works
Ok.
Committed revision 233621.
Scream if anything goes wrong. Thanks for testing.
On 23/02/15 10:42, Jonathan Wakely wrote:
>On 23/02/16 07:15 +, Bernd Edlinger wrote:
>>as described in the PR 69881 it happens quite often that cstddef is
>>called with __need_size_t because we still support gmp-4.3.2 which
>>is installed by contrib/download_prerequisites. This causes a kind
On Tue, Feb 23, 2016 at 09:51:05AM +, Manuel López-Ibáñez wrote:
> >>diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
> >>index 27a073a..8b3fddc 100644
> >>--- a/gcc/cgraphunit.c
> >>+++ b/gcc/cgraphunit.c
> >>@@ -917,6 +917,7 @@ walk_polymorphic_call_targets (hash_set
> >>*reachable_call_targ
On 23/02/16 08:56, Jakub Jelinek wrote:
On Tue, Feb 23, 2016@09:53:57AM +0100, Mark Wielaard wrote:
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2016-02-23 Mark Wielaard
+ Jakub Jelinek
+
+ PR c/69911
+ * cgraphunit.c (check_global_declaration): Check main
On 23/02/16 07:15 +, Bernd Edlinger wrote:
as described in the PR 69881 it happens quite often that cstddef is
called with __need_size_t because we still support gmp-4.3.2 which
is installed by contrib/download_prerequisites. This causes a kind
of undefined behavior. It is just by chance th
Woon yung Liu wries
> Bump! Sorry, but could I please get an answer? I'm willing to update the
> patch without
> credit, if necessary.
Hi WY,
Apologies for exceptionally slow response.
The patch you referenced is mostly OK but I would like to get the MIPS16 check
changed to a configure time ch
On Tue, Feb 23, 2016 at 09:53:57AM +0100, Mark Wielaard wrote:
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,10 @@
> +2016-02-23 Mark Wielaard
> + Jakub Jelinek
> +
> + PR c/69911
> + * cgraphunit.c (check_global_declaration): Check main_input_filename
> + and DE
On Tue, 2016-02-23 at 09:26 +0100, Jakub Jelinek wrote:
> On Tue, Feb 23, 2016 at 08:55:40AM +0100, Mark Wielaard wrote:
> > On Mon, 2016-02-22 at 19:20 -0800, H.J. Lu wrote:
> > > It caused:
> > >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69911
> >
> > Apologies. Apparently main_input_f
On Tue, Feb 23, 2016 at 08:55:40AM +0100, Mark Wielaard wrote:
> On Mon, 2016-02-22 at 19:20 -0800, H.J. Lu wrote:
> > It caused:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69911
>
> Apologies. Apparently main_input_filename can be NULL. I am not entirely
> sure when that happens. Or ho
76 matches
Mail list logo
