> So you simply assume that exp_type is naturally aligned here. I think
> you should test align < TYPE_ALIGN (TYPE_MAIN_VARIANT (exp_type)) here,
> no?
No strong opinion, but the patch is only intended to mitigate the effects of
the PR65310 one-liner, including on the 5 branch, so it's minimal.
> The following experiment resulted from looking at making
> array_ref_low_bound and array_ref_element_size non-mutating. Again
> I wondered why we do this strange scaling by offset/element alignment.
I personally never really grasped it either...
> So - I hope somebody from Adacore can evaluate
On Fri, 19 Feb 2016, Eric Botcazou wrote:
> > So you simply assume that exp_type is naturally aligned here. I think
> > you should test align < TYPE_ALIGN (TYPE_MAIN_VARIANT (exp_type)) here,
> > no?
>
> No strong opinion, but the patch is only intended to mitigate the effects of
> the PR65310
Dear All,
This has proven to be a rather vexatious bug to fix. On the face of
it, using the indirect reference to the passed string length for
deferred character length functions should have worked at all levels
of optimization. However, setting the string length within a do loop
resulted in the c
On Thu, 18 Feb 2016, Richard Biener wrote:
> On Thu, 18 Feb 2016, Jan Hubicka wrote:
>
> > >
> > > This fixes the IPA inline analysis quadraticness that arises when we
> > > inline functions into the same function many times via
> > > inline_to_all_callers as we do in the testcase for PR37448.
On Thu, Feb 18, 2016 at 8:41 PM, David Malcolm wrote:
> On Thu, 2016-02-18 at 18:26 +0100, Tom de Vries wrote:
>> On 18/02/16 16:43, Tom de Vries wrote:
>> > On 18/02/16 16:27, Richard Biener wrote:
>> > > > > > I would be nice if we could avoid the ${1,2,3} printouts
>> > > > > > and value
>> > >
On Fri, Feb 19, 2016 at 1:37 AM, Tom de Vries wrote:
> On 18/02/16 16:27, Richard Biener wrote:
>>
>> Attached is what I have for now, it works if you call it like
>>
>> (gdb) dot-fn cfun
>> (gdb) dot-fn cfun, 1<<6
>>
>> w/o that arg parsing;)
>>
>> I'll play with it some more tomorrow.
>
>
> This
For some modifications combine does it changes the mode of a pseudo
because of SELECT_CC_MODE. For example, it changes "unsigned >= 0" to
"unsigned != 0", and on some targets GTU and NE use different CC_MODEs.
Changing the mode of a pseudo has effect globally, so this changes any
REG_EQUAL and RE
On Fri, 19 Feb 2016, Richard Biener wrote:
> On Thu, 18 Feb 2016, Richard Biener wrote:
>
> > On Thu, 18 Feb 2016, Jan Hubicka wrote:
> >
> > > >
> > > > This fixes the IPA inline analysis quadraticness that arises when we
> > > > inline functions into the same function many times via
> > > > i
On 02/07/2016 01:22 PM, Marcin Kościelnicki wrote:
> gcc/testsuite/ChangeLog:
>
> * gcc.target/s390/morestack.c: New test.
Applied. Thanks!
-Andreas-
On 02/09/2016 02:18 PM, Dominik Vogt wrote:
> On Fri, Feb 05, 2016 at 05:07:57PM +0100, Dominik Vogt wrote:
>> The attached patch adds a testcase for PR 69625.
>
> Version 2 also runs with -m31.
Applied. Thanks!
-Andreas-
> 2016-02-19 Segher Boessenkool
>
> PR 60818/rtl-optimization
> * combine.c (combine_remove_reg_equal_equiv_notes_for_regno):
> New function.
> (try_combine): Call it when SELECT_CC_MODE makes us change the
> mode of a pseudo.
This looks like a big hammer to me th
On Fri, Feb 19, 2016 at 11:27:48AM +0100, Eric Botcazou wrote:
> > 2016-02-19 Segher Boessenkool
> >
> > PR 60818/rtl-optimization
> > * combine.c (combine_remove_reg_equal_equiv_notes_for_regno):
> > New function.
> > (try_combine): Call it when SELECT_CC_MODE makes us change t
Hi,
as described in the PR 69865, some bits are not properly initialized when the
-std=gnu++14
option is not present on the command line. That includes the options
-trigraphs and
-fno-extended-identifiers which are effectively overridden by the default
handling.
Also the define __GNUC_GNU_INL
On Fri, Feb 19, 2016 at 10:50:34AM +, Bernd Edlinger wrote:
> While I think that we should probably not define __GNUC_GNU_INLINE__ at all
> for C++,
> because it is meaningless, I am warned that this could break (already broken)
> header files.
It is not meaningless. The various headers nee
> Do you have something smaller in mind that still works? I'm all ears.
Try to adjust the notes instead of dropping them?
> But it never adds or moves these notes. It even says so :-)
Right, but try_combine can do it, see line 4294 and below.
--
Eric Botcazou
On 19.02.2016 11:56, Jakub Jelinek wrote:
>
> On Fri, Feb 19, 2016 at 10:50:34AM +, Bernd Edlinger wrote:
> > While I think that we should probably not define __GNUC_GNU_INLINE__ at all
> > for C++,
> > because it is meaningless, I am warned that this could break (already
> > broken) header f
On Fri, Feb 19, 2016 at 11:08:48AM +, Bernd Edlinger wrote:
> On 19.02.2016 11:56, Jakub Jelinek wrote:
> >
> > On Fri, Feb 19, 2016 at 10:50:34AM +, Bernd Edlinger wrote:
> > > While I think that we should probably not define __GNUC_GNU_INLINE__ at
> > > all for C++,
> > > because it is m
On 18/02/16 20:41, David Malcolm wrote:
On Thu, 2016-02-18 at 18:26 +0100, Tom de Vries wrote:
On 18/02/16 16:43, Tom de Vries wrote:
On 18/02/16 16:27, Richard Biener wrote:
I would be nice if we could avoid the ${1,2,3} printouts
and value
history
assignments, but I'm not sure how to do tha
On Fri, Feb 19, 2016 at 12:04:17PM +0100, Eric Botcazou wrote:
> > Do you have something smaller in mind that still works? I'm all ears.
>
> Try to adjust the notes instead of dropping them?
As far as I can see that is very hard to do though, and not really worth
it -- the notes can contain an a
Any (global or platform) maintainer willing to approve this for GCC6?
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01458.html
We switched to SSE2 by default on Windows 32-bit at AdaCore and we ran into
really nasty stability issues before applying this patch.
--
Eric Botcazou
On 19.02.2016 12:31, Jakub Jelinek wrote:
> On Fri, Feb 19, 2016 at 11:08:48AM +, Bernd Edlinger wrote:
> > On 19.02.2016 11:56, Jakub Jelinek wrote:
> > >
> > > On Fri, Feb 19, 2016 at 10:50:34AM +, Bernd Edlinger wrote:
> > > > While I think that we should probably not define __GNUC_GNU_I
On Fri, Feb 19, 2016 at 11:53:03AM +, Bernd Edlinger wrote:
> > #ifdef __GNUC__
> > __inline
> > -#ifdef __GNUC_STDC_INLINE__
> > +#if defined __GNUC_STDC_INLINE__ || defined __GNUC_GNU_INLINE__
> > __attribute__ ((__gnu_inline__))
> > #endif
> > #endif
> >
> > Jakub
>
> Damnit!!
On 19.02.2016 12:59, Jakub Jelinek wrote:
>
> Of course not, and that would be the wrong thing to do.
> The definition spot of libc_name_p comes from gperf itself, the prototype
> from cfns.gperf, which we can of course adjust.
>
Yes, now I understand. Thanks.
>
> IMNSHO we should just keep it
On Fri, Feb 19, 2016 at 12:50 PM, Eric Botcazou wrote:
> Any (global or platform) maintainer willing to approve this for GCC6?
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01458.html
>
> We switched to SSE2 by default on Windows 32-bit at AdaCore and we ran into
> really nasty stability issue
Hi!
On Fri, Feb 19, 2016 at 12:59:45PM +0100, Jakub Jelinek wrote:
> Of course not, and that would be the wrong thing to do.
> The definition spot of libc_name_p comes from gperf itself, the prototype
> from cfns.gperf, which we can of course adjust.
This is related to
https://gcc.gnu.org/ml/gcc-
On Fri, Feb 19, 2016 at 01:22:12PM +0100, Jakub Jelinek wrote:
> wants the C inline __attribute__((gnu_inline)) semantics.
> IMHO gperf should be fixed to only use __attribute__((gnu_inline)) for C++.
For C of course.
Thus emit
#ifndef __cplusplus
#if defined __GNUC_STDC_INLINE__ || defined __GNUC
On 02/19/2016 09:36 AM, Richard Biener wrote:
Yup, so we should make sure we don't (even not "out of nowhere"). See
my attempts on adding some SSA verification for this (needs to be
restricted to overaligned, then it doesn't trigger that often...).
One issue is that we've often got DECLs that ar
On 19/02/16 10:44, Richard Biener wrote:
On Fri, Feb 19, 2016 at 1:37 AM, Tom de Vries wrote:
On 18/02/16 16:27, Richard Biener wrote:
Attached is what I have for now, it works if you call it like
(gdb) dot-fn cfun
(gdb) dot-fn cfun, 1<<6
w/o that arg parsing;)
I'll play with it some more
On Fri, 19 Feb 2016, Bernd Schmidt wrote:
> On 02/19/2016 09:36 AM, Richard Biener wrote:
> > Yup, so we should make sure we don't (even not "out of nowhere"). See
> > my attempts on adding some SSA verification for this (needs to be
> > restricted to overaligned, then it doesn't trigger that oft
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 clarify how it interacts with
-std. Specifically that the effect of -Wnarrowing listed first in the
manual *only* applies to C++98 modes, For all lat
On Fri, Feb 19, 2016 at 01:42:20PM +0100, Richard Biener wrote:
> On Fri, 19 Feb 2016, Bernd Schmidt wrote:
>
> > On 02/19/2016 09:36 AM, Richard Biener wrote:
> > > Yup, so we should make sure we don't (even not "out of nowhere"). See
> > > my attempts on adding some SSA verification for this (n
On 19.02.2016 13:22, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Feb 19, 2016 at 12:59:45PM +0100, Jakub Jelinek wrote:
>> Of course not, and that would be the wrong thing to do.
>> The definition spot of libc_name_p comes from gperf itself, the prototype
>> from cfns.gperf, which we can of course adjus
Hi Jakub!
On 15 Feb 22:00, Jakub Jelinek wrote:
> Hi!
>
> We ICE on the following testcase, because vcondv32hiv32hi pattern
> really needs avx512bw, but it is enabled for avx512f.
> As VI_512 iterator is only used in vcond* patterns which need the
> avx512bw ISA for the V64QI and V32HI modes, I've
Hi!
As described in the PR, in C++ we can have assignments
where both the lhs and rhs are COMPONENT_REFs with TREE_ADDRESSABLE types,
including padding, but the FIELD_DECLs are artificial fields that have
narrower bit sizes.
store_field in this case takes the path of bit-field handling (even when
On 18/02/16 14:24, James Greenhalgh wrote:
On Thu, Feb 18, 2016 at 11:31:02AM +0100, Christophe Lyon wrote:
On 17 February 2016 at 17:06, Kyrill Tkachov
wrote:
Hi all,
I've thought about this check a bit more and I think we can compactly
auto-generate checks
for any aarch64 architecture exte
On Wed, Feb 10, 2016 at 08:19:34PM +0300, Ilya Verbin wrote:
> This patch adds crtoffload{begin,end}.o to all -fopenmp programs, if they
> exist.
> I couldn't think of a better solution...
> Tested using the testcase from the previous mail, e.g.:
>
> $ gcc -DNUM=1 -c -fopenmp test.c -o obj1.o
> $
Hi!
For -fnon-call-exceptions, if an instruction with REG_EH_REGION note is
reloaded, we should copy or move it to the instruction(s) corresponding to
the original one that could throw. reload1.c apparently does this, but LRA
does not, so we can end up with REG_EH_REGION notes being dropped, or n
On 19.02.2016 13:26, Jakub Jelinek wrote:
> On Fri, Feb 19, 2016 at 01:22:12PM +0100, Jakub Jelinek wrote:
>> wants the C inline __attribute__((gnu_inline)) semantics.
>> IMHO gperf should be fixed to only use __attribute__((gnu_inline)) for C++.
>
> For C of course.
> Thus emit
> #ifndef __cpluspl
On 19.02.2016 13:26, Jakub Jelinek wrote:
> On Fri, Feb 19, 2016 at 01:22:12PM +0100, Jakub Jelinek wrote:
>> wants the C inline __attribute__((gnu_inline)) semantics.
>> IMHO gperf should be fixed to only use __attribute__((gnu_inline)) for C++.
>
> For C of course.
> Thus emit
> #ifndef __cpluspl
On Fri, Feb 19, 2016 at 03:09:25PM +, Bernd Edlinger wrote:
> Hmm... wait a moment.
> How about that?
Guess it is mostly reasonable (still, this is C++ FE, so I'd prefer
Jason to ack it), except for:
> +#define libc_name_p Perfect_Hash::libc_name_p
this. Doesn't that cause
Perfect_Hash::lib
On Fri, Feb 19, 2016 at 04:08:37PM +0100, Jakub Jelinek wrote:
> For -fnon-call-exceptions, if an instruction with REG_EH_REGION note is
> reloaded, we should copy or move it to the instruction(s) corresponding to
> the original one that could throw. reload1.c apparently does this, but LRA
> does
Hi all,
The atomic_loaddi expander on arm has some issues and can benefit from a
rewrite to properly
perform double-word atomic loads on various architecture levels.
Consider the code:
--
#include
atomic_ullong foo;
int glob;
int main(void) {
atomic_load_explicit(&fo
On 19.02.2016 16:22, Jakub Jelinek wrote:
> On Fri, Feb 19, 2016 at 03:09:25PM +, Bernd Edlinger wrote:
>> Hmm... wait a moment.
>> How about that?
>
> Guess it is mostly reasonable (still, this is C++ FE, so I'd prefer
> Jason to ack it), except for:
>
>> +#define libc_name_p Perfect_Hash::lib
On 02/18/2016 01:25 PM, Patrick Palka wrote:
On Wed, Feb 17, 2016 at 10:51 PM, Jason Merrill wrote:
OK.
Is this an approval of the 2nd patch for next stage 1?
Actually, I've been looking at this area a lot recently in the context
of the 10200 fix, and now I think we can go ahead with the 2
OK.
Jason
OK.
Jason
On 19.02.2016 16:22, Jakub Jelinek wrote:
>
> Guess it is mostly reasonable (still, this is C++ FE, so I'd prefer
> Jason to ack it), except for:
>
Here are updated versions of the cfns-patch and the pr69856-patch.
Are they OK for trunk when boot-strap and reg-testing succeeds?
Thanks
Bernd.
2016
> >
> > Are you sure? I thought we compute that up-front ... at least
> > we make sure we can_inline_edge_p all calls before even trying
> > to inline all calls - that looks somewhat redundant then if it
> > can happen that we give up anyway. Ah, so can_inline_edge_p has
> >
> > /* Check if c
On 02/19/2016 10:51 AM, Bernd Edlinger wrote:
+ flag_isoc94 = 0;
+ flag_isoc99 = 0;
Why? These flags are global variables, so they're already zero-initialized.
Otherwise the changes look good to me.
Jason
On Fri, Feb 19, 2016 at 11:03:23AM -0500, Jason Merrill wrote:
> On 02/19/2016 10:51 AM, Bernd Edlinger wrote:
> >+ flag_isoc94 = 0;
> >+ flag_isoc99 = 0;
>
> Why? These flags are global variables, so they're already zero-initialized.
That is true, but those global variables could have changed
On 02/19/2016 10:08 AM, Jakub Jelinek wrote:
Hi!
For -fnon-call-exceptions, if an instruction with REG_EH_REGION note is
reloaded, we should copy or move it to the instruction(s) corresponding to
the original one that could throw. reload1.c apparently does this, but LRA
does not, so we can end
On 19.02.2016 17:09, Jakub Jelinek wrote:
> On Fri, Feb 19, 2016 at 11:03:23AM -0500, Jason Merrill wrote:
>> On 02/19/2016 10:51 AM, Bernd Edlinger wrote:
>>> + flag_isoc94 = 0;
>>> + flag_isoc99 = 0;
>>
>> Why? These flags are global variables, so they're already zero-initialized.
>
> That is
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 using an access structure which is
representable with __int128 when th
On Fri, Feb 19, 2016 at 03:51:08PM +, Bernd Edlinger wrote:
> --- gcc/cp/except.c (revision 233557)
> +++ gcc/cp/except.c (working copy)
> @@ -1040,7 +1040,7 @@ nothrow_libfn_p (const_tree fn)
> unless the system headers are playing rename tricks, and if
> they are, we don't wan
... Here I'd like to get my updated patch reviewed so that I
can move on to my other GCC 6 tasks.
I integrated the documentation update into the coding patch for bug
69780 - [4.9/5/6 Regression] ICE on __builtin_alloca_with_align, to
keep the two in sync.
Jakub has reviewed and approved the cod
On February 19, 2016 5:21:56 PM GMT+01:00, 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 s
On Fri, Feb 19, 2016 at 10:41 AM, Jason Merrill wrote:
> On 02/18/2016 01:25 PM, Patrick Palka wrote:
>>
>> On Wed, Feb 17, 2016 at 10:51 PM, Jason Merrill wrote:
>>>
>>> OK.
>>
>>
>> Is this an approval of the 2nd patch for next stage 1?
>
>
> Actually, I've been looking at this area a lot recen
On 19.02.2016 17:38, Jakub Jelinek wrote:
> > - return !!libc_name_p (IDENTIFIER_POINTER (id), IDENTIFIER_LENGTH (id));
> > + return !!libc_name::libc_name_p (IDENTIFIER_POINTER (id),
> > IDENTIFIER_LENGTH (id));
>
> Too long line.
>
> Jakub
Oh, thanks. Consider it fixed.
Also the ty
On 17/11/15 11:49, Ilya Enkovich wrote:
Hi,
Default hook for get_mask_mode is supposed to return integer vector modes.
This means it should reject calar modes returned by mode_for_vector.
Bootstrapped and regtested on x86_64-unknown-linux-gnu, regtested on
aarch64-unknown-linux-gnu. OK for
This relates to FORTRAN code where different modules give different sizes to the
same array in a COMMON block (contrary to the fortran language specification).
SPEC have refused to patch the source code
(https://www.spec.org/cpu2006/Docs/faq.html#Run.05).
Hence, this patch provides a Fortran-speci
On Fri, Feb 19, 2016 at 05:42:34PM +, Alan Lawrence wrote:
> This relates to FORTRAN code where different modules give different sizes to
> the
> same array in a COMMON block (contrary to the fortran language specification).
> SPEC have refused to patch the source code
> (https://www.spec.org/
On Feb 19, 2016, at 6:53 AM, Jakub Jelinek wrote:
> Looking at this, I think I have no problem with crtoffloadbegin.o being
> included in all -fopenmp/-fopenacc linked programs/shared libraries,
:-) I have a problem with just the normal init path in most executables. It
adds a ton of stuff tha
On 02/19/2016 09:03 AM, Jakub Jelinek wrote:
As described in the PR, in C++ we can have assignments
where both the lhs and rhs are COMPONENT_REFs with TREE_ADDRESSABLE types,
including padding, but the FIELD_DECLs are artificial fields that have
narrower bit sizes.
store_field in this case takes
> As far as I can see that is very hard to do though, and not really worth
> it -- the notes can contain an arbitrary expression in general.
OK, your call.
> Not for stage 4 certainly.
If we go this way, is the bug a regression? If no, why rushing the fix?
> That moves those notes to i2notes,
On Fri, Feb 19, 2016 at 01:30:52PM -0500, Jason Merrill wrote:
> On 02/19/2016 09:03 AM, Jakub Jelinek wrote:
> >As described in the PR, in C++ we can have assignments
> >where both the lhs and rhs are COMPONENT_REFs with TREE_ADDRESSABLE types,
> >including padding, but the FIELD_DECLs are artific
Hi,
> --- gcc/expr.c.jj 2016-02-12 00:50:55.0 +0100
> +++ gcc/expr.c2016-02-19 10:43:59.639162531 +0100
> @@ -6643,14 +6643,24 @@ store_field (rtx target, HOST_WIDE_INT b
> /* Except for initialization of full bytes from a CONSTRUCTOR, which
>we will handle
> Not sure - why doesn't mingw properly specify the default incoming
> stack boundary?
> If it does, why isn't there an issue elsewhere even on non-mingw if you use
> -mincoming-stack-boundary=2?
Wouldn't that pessimize over -mstackrealign? That's my reading of the manual.
Note that the issue is
Hello world,
in the fix for PR 47674, there was a piece of unnecessary
code which meant that allocatable string assignments did
not get their temporary within IF statements (and others).
This patch is really simple and obvious. If we weren't in
tstage 4, I would simply commit it.
Because alloc
On 02/19/2016 01:41 PM, Jakub Jelinek wrote:
On Fri, Feb 19, 2016 at 01:30:52PM -0500, Jason Merrill wrote:
On 02/19/2016 09:03 AM, Jakub Jelinek wrote:
As described in the PR, in C++ we can have assignments
where both the lhs and rhs are COMPONENT_REFs with TREE_ADDRESSABLE types,
including pa
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 clarify how it interacts with
-std. Specifically that the effect of -Wnarrowing listed first in the
m
On Fri, Feb 19, 2016 at 06:42:32PM +, Bernd Edlinger wrote:
> Hi,
>
>
> > --- gcc/expr.c.jj 2016-02-12 00:50:55.0 +0100
> > +++ gcc/expr.c 2016-02-19 10:43:59.639162531 +0100
> > @@ -6643,14 +6643,24 @@ store_field (rtx target, HOST_WIDE_INT b
> > /* Except for initializa
On 02/19/2016 11:56 AM, Patrick Palka wrote:
On Fri, Feb 19, 2016 at 10:41 AM, Jason Merrill wrote:
On 02/18/2016 01:25 PM, Patrick Palka wrote:
On Wed, Feb 17, 2016 at 10:51 PM, Jason Merrill wrote:
OK.
Is this an approval of the 2nd patch for next stage 1?
Actually, I've been looking
On Fri, Feb 19, 2016 at 02:00:07PM -0500, Jason Merrill wrote:
> On 02/19/2016 01:41 PM, Jakub Jelinek wrote:
> >On Fri, Feb 19, 2016 at 01:30:52PM -0500, Jason Merrill wrote:
> >>On 02/19/2016 09:03 AM, Jakub Jelinek wrote:
> >>>As described in the PR, in C++ we can have assignments
> >>>where bot
OK.
Jason
On 02/19/2016 02:07 PM, Jakub Jelinek wrote:
On Fri, Feb 19, 2016 at 02:00:07PM -0500, Jason Merrill wrote:
On 02/19/2016 01:41 PM, Jakub Jelinek wrote:
On Fri, Feb 19, 2016 at 01:30:52PM -0500, Jason Merrill wrote:
On 02/19/2016 09:03 AM, Jakub Jelinek wrote:
As described in the PR, in C++ w
With the patch I get an ICE when compiling gfortran.dg/allocate_error_5.f90
(lldb) target create
"/opt/gcc/gcc6p-233563p2/libexec/gcc/x86_64-apple-darwin15.3.0/6.0.0/f951"
Current executable set to
'/opt/gcc/gcc6p-233563p2/libexec/gcc/x86_64-apple-darwin15.3.0/6.0.0/f951'
(x86_64).
(lldb) run /
On Fri, Feb 19, 2016 at 07:39:03PM +0100, Eric Botcazou wrote:
> > Not for stage 4 certainly.
>
> If we go this way, is the bug a regression? If no, why rushing the fix?
It is not a regression (it is in all open release branches already).
I can postpone it if you think that is wiser?
> > That m
> It is not a regression (it is in all open release branches already).
> I can postpone it if you think that is wiser?
I do think that the combiner is one of those pieces of code that you ought not
to touch unless you really need to.
> I misread it as moving the notes from i3 to i2, ugh. It loo
On 19.02.2016 17:03, Jason Merrill wrote:
> On 02/19/2016 10:51 AM, Bernd Edlinger wrote:
>> + flag_isoc94 = 0;
>> + flag_isoc99 = 0;
>
> Why? These flags are global variables, so they're already
> zero-initialized.
>
> Otherwise the changes look good to me.
>
> Jason
>
Hi Jason,
This hunk is
Hi!
On Thu, 2 Oct 2014 19:14:57 +0400, Ilya Verbin wrote:
> With this patch lto-wrapper performs invocation of mkoffload tool for each
> offload target. This tool [...]
> will compile IR from .gnu.offload_lto_* sections into offload
> target code and embed the resultant code (offload image) into
On 02/19/2016 02:37 PM, Bernd Edlinger wrote:
On 19.02.2016 17:03, Jason Merrill wrote:
On 02/19/2016 10:51 AM, Bernd Edlinger wrote:
+ flag_isoc94 = 0;
+ flag_isoc99 = 0;
Why? These flags are global variables, so they're already
zero-initialized.
Otherwise the changes look good to me.
J
On Fri, Feb 19, 2016 at 20:41:58 +0100, Thomas Schwinge wrote:
> Hi!
>
> On Thu, 2 Oct 2014 19:14:57 +0400, Ilya Verbin wrote:
> > With this patch lto-wrapper performs invocation of mkoffload tool for each
> > offload target. This tool [...]
> > will compile IR from .gnu.offload_lto_* sections i
On Fri, Feb 19, 2016 at 08:34:03PM +0100, Eric Botcazou wrote:
> > It is not a regression (it is in all open release branches already).
> > I can postpone it if you think that is wiser?
>
> I do think that the combiner is one of those pieces of code that you ought
> not
> to touch unless you rea
On 19.02.2016 20:04, Jakub Jelinek wrote:
> On Fri, Feb 19, 2016 at 06:42:32PM +, Bernd Edlinger wrote:
>> Hi,
>>
>>
>>> --- gcc/expr.c.jj 2016-02-12 00:50:55.0 +0100
>>> +++ gcc/expr.c 2016-02-19 10:43:59.639162531 +0100
>>> @@ -6643,14 +6643,24 @@ store_field (rtx target, HOST_
On Fri, Feb 19, 2016 at 08:04:39PM +, Bernd Edlinger wrote:
> but you are just adding another term to this expression:
> !(TREE_CODE (exp) == CONSTRUCTOR
> && bitsize % BITS_PER_UNIT == 0)
No. Please read the code again. I'm adding another case
after this one.
> so the result should l
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 clarify how it interacts with
-std. Specifically that t
On 19.02.2016 21:08, Jakub Jelinek wrote:
> On Fri, Feb 19, 2016 at 08:04:39PM +, Bernd Edlinger wrote:
>> but you are just adding another term to this expression:
>>!(TREE_CODE (exp) == CONSTRUCTOR
>> && bitsize % BITS_PER_UNIT == 0)
>
> No. Please read the code again. I'm adding an
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
Excuse me,
I have still another question.
Why are you adding braces here?
+ || (bitsize % BITS_PER_UNIT != 0)
+ || (bitpos % BITS_PER_UNIT != 0)
+ || (compare_tree_int (DECL_SIZE (TREE_OPERAND (exp, 1)), bitsize)
+ != 0)))
I think everywhere i
Excuse me,
I have still another question.
Why are you adding braces here?
+ || (bitsize % BITS_PER_UNIT != 0)
+ || (bitpos % BITS_PER_UNIT != 0)
+ || (compare_tree_int (DECL_SIZE (TREE_OPERAND (exp, 1)), bitsize)
+ != 0)))
I think everywhere i
On 02/17/2016 08:37 PM, Alan Modra wrote:
>> +/* A set bit indicates an exception is trapping. */
>> +# define FP_TRAPPING_EXCEPTIONS ((_fpscr.i << 22) & FP_EX_ALL)
>
> why then a shift here, since FP_EX_* are defined as the actual
> register bits? Oh, I see. FP_EX_* are the status bits, and
On Fri, Feb 19, 2016 at 08:45:09PM +, Bernd Edlinger wrote:
> I have still another question.
>
> Why are you adding braces here?
>
> + || (bitsize % BITS_PER_UNIT != 0)
> + || (bitpos % BITS_PER_UNIT != 0)
These two are not really needed, but I've already committed the pa
On 02/18/2016 02:56 AM, Richard Biener wrote:
Just a short quick comment - the above means you only handle partial
stores
with no interveaning uses. You don't handle, say
struct S { struct R { int x; int y; } r; int z; } s;
s = { {1, 2}, 3 };
s.r.x = 1;
s.r.y = 2;
struct R r = s.r;
On Fri, Feb 19, 2016 at 2:06 PM, Jason Merrill wrote:
> On 02/19/2016 11:56 AM, Patrick Palka wrote:
>>
>> On Fri, Feb 19, 2016 at 10:41 AM, Jason Merrill wrote:
>>>
>>> On 02/18/2016 01:25 PM, Patrick Palka wrote:
On Wed, Feb 17, 2016 at 10:51 PM, Jason Merrill
wrote:
>
The testcase in this PR causes gcc to abort with
internal compiler error: Maximum number of LRA constraint passes is
achieved (30)
[in theory - I've not managed to reproduce this on my system with any
compiler]
The abort is premature, allowing LRA to continue would allow the
testcase to co
On 02/19/2016 02:32 PM, Bernd Schmidt wrote:
The testcase in this PR causes gcc to abort with
internal compiler error: Maximum number of LRA constraint passes is
achieved (30)
[in theory - I've not managed to reproduce this on my system with any
compiler]
The abort is premature, allowing LRA t
I'm working on some IRA cost fixes, and I've had the lzcnt-1.c test fail
because the register allocator started making different decisions. In
both cases we end up generating two instructions, but with slightly
different register assignments. Hence, this patch, which relaxes the
test slightly.
On 02/19/2016 02:36 PM, Bernd Schmidt wrote:
I'm working on some IRA cost fixes, and I've had the lzcnt-1.c test fail
because the register allocator started making different decisions. In
both cases we end up generating two instructions, but with slightly
different register assignments. Hence, th
On Tue, Nov 10, 2015 at 10:10 AM, Jonathan Wakely wrote:
> On 06/11/15 09:59 +, Pedro Alves wrote:
>>
>> On 11/06/2015 01:56 AM, Jonathan Wakely wrote:
>>>
>>> On 5 November 2015 at 23:31, Daniel Gutson
>>
>>
The issue is, as I understand it, to do the actual work of operator
new, i.
1 - 100 of 115 matches
Mail list logo
