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 Vietnamese team of translators. The file is available at:
http://translationproject.org/latest/gcc/vi.po
(This file, 'gcc-6.1-b20160131.vi.po
Hi,
as almost expected r233572 needs to be back-ported to gcc-5 and gcc-4.9
branches in order to be built by gcc-6. It applies cleanly to both
branches. But unfortunately PR 69881 prevents boot-strapping gcc-4.9
in the moment.
Boot-strap and regression-test of gcc-5 on x86_64-pc-linux-gnu.
OK f
My change to tsubst_pack_expansion to handle the special case of T...
revealed a latent bug whereby we were considering the trailing "void"
when comparing two variadic templates. When we then try to deduce one
from the other we get a parameter of type "void", which results in
substitution fail
Keith Seitz reported we were missing debug information for cdtors.
E.g., we emit a specification for the unified ctor and dtor, but then,
if we emit one of the in-charge and not-in-charge versions as an alias
to the other, from the debug info PoV it's as if one of them didn't
exist. If we emit dec
On 2/13/2016 8:00 PM, David Wohlferd wrote:
Fair enough. Committing what we can right now sounds like a good plan.
Attached is the doc patch, minus the proposed warning.
ChangeLog:
2016-02-19 David Wohlferd
Bernd Schmidt
* doc/extend.texi: Doc basic asm behavior re clobbers
On Fri, 19 Feb 2016, Martin Sebor wrote:
> > ... 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 t
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 inv can be propagated into mem ref
with additional addr expr canonical
On 02/16/2016 08:24 AM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, %{ftree-parallelize-loops=*} expands to
all -ftree-parallelize-loops= options, not just the last one.
So greater_than_spec_func is actually called say for
-ftree-parallelize-loops=0 -ftree-parallelize-loops=2 with
- ftree-p
On 02/17/2016 07:24 AM, Nick Clifton wrote:
Hi Guys,
Redefining a previously defined static function as both public and
weak triggers an ICE in ipa-visibility.c:
internal compiler error: in function_and_variable_visibility, at
ipa-visibility.c:518
This bug has been discussed and patc
In this PR, we generate unnecessarily bad code for code that declares a
global register var. Since global regs get added to fixed_regs, IRA
never considers them as candidates. However, we do seem to have proper
data flow information for them. In the testcase, the global reg dies,
some operation
On 02/17/2016 09:06 AM, 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 extension support in the assembler.
This is done in a similar way we autogenerate the arm_arch_*_ok checks
for arm.
So in
On Mon, Nov 16, 2015 at 3:56 PM, Pedro Alves wrote:
> On 11/10/2015 01:10 PM, 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 t
PR 49095 requested the following optimization:
- movl-120(%rax), %ecx
- leal-1(%rcx), %edx
- movl%edx, -120(%rax)
- testl %edx, %edx
+ subl$1, -120(%rax)
jne .L92
The PR was fixed by adding a peephole, but it doesn't actually trigger
f
On 02/17/2016 10:18 AM, Jakub Jelinek wrote:
Hi!
The following testcase works unless -save-temps or ccache is used
(or manually performing -E and compilation separately). The problem
is that #pragma cilk grainsize is supposed to have macro expansion
(except for the grainsize keyword), but we we
On 02/18/2016 08:39 PM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00809.html
On 02/11/2016 02:58 PM, Martin Sebor wrote:
The more than decennnial rtl-optimization/19705 - -fno-branch-count-reg
doesn't prevent decrement and branch instructions on a count register
p
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.
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
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: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
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 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:
>
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 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/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
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 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
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 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 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 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: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 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 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
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 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
> 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 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
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 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
OK.
Jason
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
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 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 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 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
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
> 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
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
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
> 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 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
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 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/
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 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
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 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
... 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 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
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 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
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 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: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
> >
> > 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 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
OK.
Jason
OK.
Jason
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
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
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 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
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 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
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 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
> $
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
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
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
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
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
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, 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
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 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 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
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 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
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 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: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
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 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
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 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 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
> 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
1 - 100 of 115 matches
Mail list logo
