[PATCH] PR middle-end/60281

[lin zuojian]

Without aligning the asan stack base,base will only 64-bit aligned in
ARM machines.
But asan require 256-bit aligned base because of this:
1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
2.store multiple/load multiple instructions require the other 2 bits are
zeros

that add up lowest 5 bits should be zeros.That means 32 bytes or 256
bits aligned.

* asan.c (asan_emit_stack_protection): Forcing the base to align to 256 bits
* cfgexpand.c (expand_used_vars): Leaving a space in the stack frame for
alignment



Signed-off-by: lin zuojian 
---
gcc/asan.c | 6 ++
gcc/cfgexpand.c | 2 ++
2 files changed, 8 insertions(+)

diff --git a/gcc/asan.c b/gcc/asan.c
index 53992a8..455e484 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1019,6 +1019,12 @@ asan_emit_stack_protection (rtx base, rtx pbase,
unsigned int alignb,
}
if (use_after_return_class == -1 && pbase)
emit_move_insn (pbase, base);
+
+ /* align base */
+ base = expand_binop (Pmode, and_optab, base,
+ gen_int_mode (-ASAN_RED_ZONE_SIZE, Pmode),
+ NULL_RTX, 1, OPTAB_DIRECT);
+
base = expand_binop (Pmode, add_optab, base,
gen_int_mode (base_offset - base_align_bias, Pmode),
NULL_RTX, 1, OPTAB_DIRECT);
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 06d494c..9e887f7 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -1843,6 +1843,8 @@ expand_used_vars (void)
= alloc_stack_frame_space (redzonesz, ASAN_RED_ZONE_SIZE);
data.asan_vec.safe_push (prev_offset);
data.asan_vec.safe_push (offset);
+ /* leave a space for alignment */
+ alloc_stack_frame_space (ASAN_RED_ZONE_SIZE, 1);

var_end_seq
= asan_emit_stack_protection (virtual_stack_vars_rtx,
-- 
1.8.3.2

Re: [PATCH 1/6] [GOMP4] OpenACC 1.0+ support in fortran front-end

[Ilmir Usmanov]

Hi Tobias!

On 20.02.2014 03:51, Tobias Burnus wrote:

On 10.02.2014 02:22, Tobias Burnus wrote:


a) Does this part work well when both -fopenmp and -fopenacc is 
used? I mean: "!$acc loop" followed/preceded by "!$omp do"? I could 
imagine that there could be clashes, especially when - e.g. - 
collapse doesn't match.

PGI: Silently ignores OpenMP pragmas.
CAPS: Ignored option '--define' (_OPENMP=).


I like how Cray handles it: It permits both - but neither OpenMP -> 
OpenACC nesting nor vice versa. (It might not always detectable.)


ERROR:
  The !$OMP PARALLEL DO directive cannot be specified within a !$ACC 
PARALLEL region.


And adding OpenACC to an OpenMP loop fails with:

ERROR:
  The !$ACC LOOP directive cannot be specified within a !$OMP PARALLEL 
DO region.


(One gets the same error independent whether one tries to place the 
pragma on the same loop or just nested in the parallel pragma or on 
different loops.)


I think doing likewise would be best.

I agree.




+  if (gfc_implicit_pure (NULL))
+gfc_current_ns->proc_name->attr.implicit_pure = 0;


I believe that will fail with BLOCK - cf. gfc_implicit_pure()

Fortunally, it doesn't.


Are you sure that it works? A block starts a new namespace, hence, 
gfc_implicit_pure() does:


After your notice about namespaces, I tested !$acc declare attribute. 
Viola, it fails. However, other directives work.




Side question: Do we also need to unset implicit_pure for OpenMP?
 As you can see in decode_omp_directive function, the flag is already 
unset.


--
Ilmir.

Re: [PATCH] PR middle-end/60281

[Jakub Jelinek]

On Thu, Feb 20, 2014 at 04:19:12PM +0800, lin zuojian wrote:
> Without aligning the asan stack base,base will only 64-bit aligned in
> ARM machines.
> But asan require 256-bit aligned base because of this:
> 1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
> 2.store multiple/load multiple instructions require the other 2 bits are
> zeros
> 
> that add up lowest 5 bits should be zeros.That means 32 bytes or 256
> bits aligned.
> 
> * asan.c (asan_emit_stack_protection): Forcing the base to align to 256 bits
> * cfgexpand.c (expand_used_vars): Leaving a space in the stack frame for
> alignment

This is wrong.

You certainly don't want to do any of the extra aligning
on non-strict alignment targets, so all the changes must be
if (STRICT_ALIGNMENT) guarded, as they are quite expensive (you need one
extra register in that case).

Second thing is, I think you break --param use-after-return=0 this way
and also functions with very large stack frames, because emit_move_insn
to pbase is then done before you adjust the stack.

Also, I don't think you want to align for ASAN_RED_ZONE_SIZE,
but instead (GET_MODE_ALIGNMENT (SImode) << ASAN_SHADOW_SHIFT) / BITS_PER_UNIT,
and if you do (of course for STRICT_ALIGNMENT targets only), you should
set_mem_align on shadow_mem when it is created.

If you do the realignment, then it would be nice if the middle-end was told
about that, so do
  base_align = crtl->max_used_stack_slot_alignment;
in both the if ((flag_sanitize & SANITIZE_ADDRESS) && ASAN_STACK && pred)
then body and else, and if sanitizing and STRICT_ALIGNMENT, set
base_align to MIN of crtl->max_used_stack_slot_alignment and the alignment
you actually guarantee.

Or, if ARM supports unaligned loads/stores using special instructions,
perhaps you should also benchmark the alternative of not realigning, but
instead making sure those unaligned instructions are used for the shadow
memory loads/stores in the asan prologue/epilogue.

Please next time post the patch from a sane MUA that doesn't eat tabs or
at least as an attachment.  Comments should start with a capital letter, and
with a full stop followed by two spaces, in the ChangeLog also all entries
should end with a full stop.

Jakub

Re: [PATCH] Fix PR60221

[Jakub Jelinek]

On Tue, Feb 18, 2014 at 02:01:03PM +0100, Richard Biener wrote:
> 
> This makes sure to run cleanup-all-empty-eh even at -O0 via ehcleanup2.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk
> (and branches?)
> 
> Thanks,
> Richard.
> 
> 2014-02-18  Richard Biener  
> 
>   PR middle-end/60221
>   * tree-eh.c (execute_cleanup_eh_1): Also cleanup empty EH
>   regions at -O0.

Ok.

Jakub

Re: [PATCH] PR middle-end/60281

[lin zuojian]

> On Thu, Feb 20, 2014 at 04:19:12PM +0800, lin zuojian wrote:
>> Without aligning the asan stack base,base will only 64-bit aligned in
>> ARM machines.
>> But asan require 256-bit aligned base because of this:
>> 1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
>> 2.store multiple/load multiple instructions require the other 2 bits are
>> zeros
>>
>> that add up lowest 5 bits should be zeros.That means 32 bytes or 256
>> bits aligned.
>>
>> * asan.c (asan_emit_stack_protection): Forcing the base to align to 256 bits
>> * cfgexpand.c (expand_used_vars): Leaving a space in the stack frame for
>> alignment
> This is wrong.
>
> You certainly don't want to do any of the extra aligning
> on non-strict alignment targets, so all the changes must be
> if (STRICT_ALIGNMENT) guarded, as they are quite expensive (you need one
> extra register in that case).

I have to do realignment.And llvm's backend also do the realignment.I
just refers to its implementation.

>
> Second thing is, I think you break --param use-after-return=0 this way
> and also functions with very large stack frames, because emit_move_insn
> to pbase is then done before you adjust the stack.
Yes, that's a defect.
>
> Also, I don't think you want to align for ASAN_RED_ZONE_SIZE,
> but instead (GET_MODE_ALIGNMENT (SImode) << ASAN_SHADOW_SHIFT) / 
> BITS_PER_UNIT,
> and if you do (of course for STRICT_ALIGNMENT targets only), you should
> set_mem_align on shadow_mem when it is created.

I agree with you on the alignment value.May invoking set_mem_align on
shadow_mem happen too late at this point?Given RTL has been expanded.
And again I have to do realignment on non STRICT_ALIGNMENT whatever cost
it take or there are always alignment faults.

>
> If you do the realignment, then it would be nice if the middle-end was told
> about that, so do
>   base_align = crtl->max_used_stack_slot_alignment;
> in both the if ((flag_sanitize & SANITIZE_ADDRESS) && ASAN_STACK && pred)
> then body and else, and if sanitizing and STRICT_ALIGNMENT, set
> base_align to MIN of crtl->max_used_stack_slot_alignment and the alignment
> you actually guarantee.

Okay,I will do that.

>
> Or, if ARM supports unaligned loads/stores using special instructions,
> perhaps you should also benchmark the alternative of not realigning, but
> instead making sure those unaligned instructions are used for the shadow
> memory loads/stores in the asan prologue/epilogue.
I have tried to use -fno-peephole2 to shutdown instructions
combinations,but that makes me feel uncomfortable.
>
> Please next time post the patch from a sane MUA that doesn't eat tabs or
> at least as an attachment.  Comments should start with a capital letter, and
> with a full stop followed by two spaces, in the ChangeLog also all entries
> should end with a full stop.
Sorry about that...
BTW,I didn't modify the ChangeLog because this patch should be discussed
carefully.
>
>   Jakub

Re: [PATCH] PR middle-end/60281

[lin zuojian]

If you don't mind my realigning on STRICT_ALIGNMENT machines,I will make
patch v2 soon.
>> On Thu, Feb 20, 2014 at 04:19:12PM +0800, lin zuojian wrote:
>>> Without aligning the asan stack base,base will only 64-bit aligned in
>>> ARM machines.
>>> But asan require 256-bit aligned base because of this:
>>> 1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
>>> 2.store multiple/load multiple instructions require the other 2 bits are
>>> zeros
>>>
>>> that add up lowest 5 bits should be zeros.That means 32 bytes or 256
>>> bits aligned.
>>>
>>> * asan.c (asan_emit_stack_protection): Forcing the base to align to 256 bits
>>> * cfgexpand.c (expand_used_vars): Leaving a space in the stack frame for
>>> alignment
>> This is wrong.
>>
>> You certainly don't want to do any of the extra aligning
>> on non-strict alignment targets, so all the changes must be
>> if (STRICT_ALIGNMENT) guarded, as they are quite expensive (you need one
>> extra register in that case).
> I have to do realignment.And llvm's backend also do the realignment.I
> just refers to its implementation.
>
>> Second thing is, I think you break --param use-after-return=0 this way
>> and also functions with very large stack frames, because emit_move_insn
>> to pbase is then done before you adjust the stack.
> Yes, that's a defect.
>> Also, I don't think you want to align for ASAN_RED_ZONE_SIZE,
>> but instead (GET_MODE_ALIGNMENT (SImode) << ASAN_SHADOW_SHIFT) / 
>> BITS_PER_UNIT,
>> and if you do (of course for STRICT_ALIGNMENT targets only), you should
>> set_mem_align on shadow_mem when it is created.
> I agree with you on the alignment value.May invoking set_mem_align on
> shadow_mem happen too late at this point?Given RTL has been expanded.
> And again I have to do realignment on non STRICT_ALIGNMENT whatever cost
> it take or there are always alignment faults.
>
>> If you do the realignment, then it would be nice if the middle-end was told
>> about that, so do
>>   base_align = crtl->max_used_stack_slot_alignment;
>> in both the if ((flag_sanitize & SANITIZE_ADDRESS) && ASAN_STACK && pred)
>> then body and else, and if sanitizing and STRICT_ALIGNMENT, set
>> base_align to MIN of crtl->max_used_stack_slot_alignment and the alignment
>> you actually guarantee.
> Okay,I will do that.
>
>> Or, if ARM supports unaligned loads/stores using special instructions,
>> perhaps you should also benchmark the alternative of not realigning, but
>> instead making sure those unaligned instructions are used for the shadow
>> memory loads/stores in the asan prologue/epilogue.
> I have tried to use -fno-peephole2 to shutdown instructions
> combinations,but that makes me feel uncomfortable.
>> Please next time post the patch from a sane MUA that doesn't eat tabs or
>> at least as an attachment.  Comments should start with a capital letter, and
>> with a full stop followed by two spaces, in the ChangeLog also all entries
>> should end with a full stop.
> Sorry about that...
> BTW,I didn't modify the ChangeLog because this patch should be discussed
> carefully.
>>  Jakub
>

Re: [PATCH] PR middle-end/60281

[Jakub Jelinek]

On Thu, Feb 20, 2014 at 05:13:36PM +0800, lin zuojian wrote:
> > You certainly don't want to do any of the extra aligning
> > on non-strict alignment targets, so all the changes must be
> > if (STRICT_ALIGNMENT) guarded, as they are quite expensive (you need one
> > extra register in that case).
> 
> I have to do realignment.And llvm's backend also do the realignment.I
> just refers to its implementation.

On !STRICT_ALIGNMENT, you don't need to do the realignment, it just works
as is.  I don't care what llvm does.

> > Also, I don't think you want to align for ASAN_RED_ZONE_SIZE,
> > but instead (GET_MODE_ALIGNMENT (SImode) << ASAN_SHADOW_SHIFT) / 
> > BITS_PER_UNIT,
> > and if you do (of course for STRICT_ALIGNMENT targets only), you should
> > set_mem_align on shadow_mem when it is created.
> 
> I agree with you on the alignment value.May invoking set_mem_align on
> shadow_mem happen too late at this point?Given RTL has been expanded.

I meant to do:
   shadow_mem = gen_rtx_MEM (SImode, shadow_base);
   set_mem_alias_set (shadow_mem, asan_shadow_set);
+  if (STRICT_ALIGNMENT)
+set_mem_align (shadow_mem, ...);
(the default alignment is BITS_PER_UNIT).  No RTL has been expanded with
that yet at that point.

> And again I have to do realignment on non STRICT_ALIGNMENT whatever cost
> it take or there are always alignment faults.

No.

> > Or, if ARM supports unaligned loads/stores using special instructions,
> > perhaps you should also benchmark the alternative of not realigning, but
> > instead making sure those unaligned instructions are used for the shadow
> > memory loads/stores in the asan prologue/epilogue.
> I have tried to use -fno-peephole2 to shutdown instructions
> combinations,but that makes me feel uncomfortable.

You mean that for the prologues right now on ARM we emit unaligned store
insns during expansion and that they are later peepholed into aligned
stores?

Jakub

Re: [PATCH] PR middle-end/60281

[Jakub Jelinek]

On Thu, Feb 20, 2014 at 10:21:12AM +0100, Jakub Jelinek wrote:
> > > Or, if ARM supports unaligned loads/stores using special instructions,
> > > perhaps you should also benchmark the alternative of not realigning, but
> > > instead making sure those unaligned instructions are used for the shadow
> > > memory loads/stores in the asan prologue/epilogue.

Also note that apparently ARM does have unaligned_storesi pattern,
just doesn't provide movmisalignsi expander so that it could be (easily) used 
from
the middle-end.  So you should certainly also try it that way and test.

Jakub

Re: [gomp4] libgomp: plugin for non-shared memory host execution

[Thomas Schwinge]

Hi!

On Wed, 19 Feb 2014 18:59:59 +0100, Jakub Jelinek  wrote:
> On Wed, Feb 19, 2014 at 09:49:20PM +0400, Ilya Verbin wrote:
> > 2014-02-19 20:10 GMT+04:00 Thomas Schwinge :
> > > Here is such a libgomp plugin plus the infrastructure for initial support
> > > of non-shared memory host execution.  Any comments?
> > 
> > This plugin looks good.

Committed to gomp-4_0-branch as r207938.

Reviewing old emails, I now see in

that Jakub suggested to check that »sizeof (void *) == sizeof
(uintptr_t), etc.«, and then in

to use »uintptr_t instead of void *« and different names for the
functions: »device_alloc (taking size and align arguments, returning
uintptr_t target address), device_free (taking uintptr_t target address
and perhaps size), device_copyto (like memcpy, just with target address
uintptr_t instead of void *) and device_copyfrom (similarly), and
device_run hook or similar (taking host and target fn and target
uintptr_t address of the block with pointers)«.  So, the code should
probably be adjusted for that.


> > I think the function call in GOMP_target also should be replaced with
> > a call to plugin:
> > - fn ((void *) tgt->tgt_start);
> > + devicep->device_run_func (fn, (void *) tgt->tgt_start);

Yes.


> > Also I have a question (not related with this plugin): How will
> > libgomp work with multiple devices of the same type?  Probably it
> > should load the plugin once, query it for the number of available
> > devices, add received number of descriptors to the devices[] array, an
> > then pass devicep->id as an argument to all plugin's interfaces.
> 
> Or the devicep pointer.

To which extent to we want/have to expose non-trivial data types to
plugins, such as a devicep pointer as opposed to (void *) tgt->tgt_start?


Grüße,
 Thomas


pgpUaoQXOZTcl.pgp
Description: PGP signature

Re: [PING^2][PATCH] Add a couple of dialect and warning options regarding Objective-C instance variable scope

[Dimitris Papavasiliou]

Hello all,

Pinging this patch review request again.  See previous messages quoted 
below for details.


Regards,
Dimitris

On 02/13/2014 04:22 PM, Dimitris Papavasiliou wrote:

Hello,

Pinging this patch review request. Can someone involved in the
Objective-C language frontend have a quick look at the description of
the proposed features and tell me if it'd be ok to have them in the
trunk so I can go ahead and create proper patches?

Thanks,
Dimitris

On 02/06/2014 11:25 AM, Dimitris Papavasiliou wrote:

Hello,

This is a patch regarding a couple of Objective-C related dialect
options and warning switches. I have already submitted it a while ago
but gave up after pinging a couple of times. I am now informed that
should have kept pinging until I got someone's attention so I'm
resending it.

The patch is now against an old revision and as I stated originally it's
probably not in a state that can be adopted as is. I'm sending it as is
so that the implemented features can be assesed in terms of their
usefulness and if they're welcome I'd be happy to make any necessary
changes to bring it up-to-date, split it into smaller patches, add
test-cases and anything else that is deemed necessary.

Here's the relevant text from my initial message:

Two of these switches are related to a feature request I submitted a
while ago, Bug 56044
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044). I won't reproduce
the entire argument here since it is available in the feature request.
The relevant functionality in the patch comes in the form of two
switches:

-Wshadow-ivars which controls the "local declaration of ‘somevar’ hides
instance variable" warning which curiously is enabled by default instead
of being controlled at least by -Wshadow. The patch changes it so that
this warning can be enabled and disabled specifically through
-Wshadow-ivars as well as with all other shadowing-related warnings
through -Wshadow.

The reason for the extra switch is that, while searching through the
Internet for a solution to this problem I have found out that other
people are inconvenienced by this particular warning as well so it might
be useful to be able to turn it off while keeping all the other
shadowing-related warnings enabled.

-flocal-ivars which when true, as it is by default, treats instance
variables as having local scope. If false (-fno-local-ivars) instance
variables must always be referred to as self->ivarname and references of
ivarname resolve to the local or global scope as usual.

I've also taken the opportunity of adding another switch unrelated to
the above but related to instance variables:

-fivar-visibility which can be set to either private, protected (the
default), public and package. This sets the default instance variable
visibility which normally is implicitly protected. My use-case for it is
basically to be able to set it to public and thus effectively disable
this visibility mechanism altogether which I find no use for and
therefore have to circumvent. I'm not sure if anyone else feels the same
way towards this but I figured it was worth a try.

I'm attaching a preliminary patch against the current revision in case
anyone wants to have a look. The changes are very small and any blatant
mistakes should be immediately obvious. I have to admit to having
virtually no knowledge of the internals of GCC but I have tried to keep
in line with formatting guidelines and general style as well as looking
up the particulars of the way options are handled in the available
documentation to avoid blind copy-pasting. I have also tried to test the
functionality both in my own (relatively large, or at least not too
small) project and with small test programs and everything works as
expected. Finallly, I tried running the tests too but these fail to
complete both in the patched and unpatched version, possibly due to the
way I've configured GCC.

Dimitris

[PATCH GCC]Fix obvious bogus test case

[bin.cheng]

Hi,
The case is an execution case, while the main function doesn't return 0.
Committed as obvious.

Thanks,
bin


gcc/testsuite/ChangeLog
2014-02-20  Bin Cheng  

* gcc.dg/tree-prof/crossmodule-indircall-1.c: Return 0
for execution test case.

RE: [PATCH GCC]Fix obvious bogus test case

[bin.cheng]

And the patch..

Thanks,
bin

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of bin.cheng
> Sent: Thursday, February 20, 2014 6:42 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH GCC]Fix obvious bogus test case
> 
> Hi,
> The case is an execution case, while the main function doesn't return 0.
> Committed as obvious.
> 
> Thanks,
> bin
> 
> 
> gcc/testsuite/ChangeLog
> 2014-02-20  Bin Cheng  
> 
>   * gcc.dg/tree-prof/crossmodule-indircall-1.c: Return 0
>   for execution test case.
> 
> 
> 
Index: gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1.c
===
--- gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1.c(revision 
207809)
+++ gcc/testsuite/gcc.dg/tree-prof/crossmodule-indircall-1.c(working copy)
@@ -16,4 +16,6 @@ main()
 p[i%2](2);
   if (a != 1000)
 abort ();
+
+  return 0;
 }

Re: [PATCH] PR middle-end/60281

[lin zuojian]

Oh, you may think my patch have not violated STRICT_ALIGNMENT.My patch
doesn't realign stack_pointer,but virtual_stack_vars,although they may
share the same position mostly.
As you can see,the code emitted just make the stack 8 bytes aligned.

> You mean that for the prologues right now on ARM we emit unaligned
> store insns during expansion and that they are later peepholed into
> aligned stores? 
Yes.Because SImode is aligned to 4 bytes ,and str is considered aligned
to 4 bytes on all ARM machine,so gcc doesn't consider itself emitting
the unaligned str instructions in the first place.Of course aligned str
can be peepholed into aligned str multiple.

--
lin zuojian

Re: [PATCH] PR middle-end/60281

[Jakub Jelinek]

On Thu, Feb 20, 2014 at 06:46:21PM +0800, lin zuojian wrote:
> Oh, you may think my patch have not violated STRICT_ALIGNMENT.My patch
> doesn't realign stack_pointer,but virtual_stack_vars,although they may
> share the same position mostly.
> As you can see,the code emitted just make the stack 8 bytes aligned.
> 
> > You mean that for the prologues right now on ARM we emit unaligned
> > store insns during expansion and that they are later peepholed into
> > aligned stores? 
> Yes.Because SImode is aligned to 4 bytes ,and str is considered aligned
> to 4 bytes on all ARM machine,so gcc doesn't consider itself emitting
> the unaligned str instructions in the first place.Of course aligned str
> can be peepholed into aligned str multiple.

ARM is a STRICT_ALIGNMENT target, I was suggesting that you do the changes
you want to do only for STRICT_ALIGNMENT targets.  They are not desirable
for !STRICT_ALIGNMENT targets like i?86/x86_64 (or say ppc/ppc64 unless
strict alignment is requested by compielr option).

Jakub

Re: [PATCH] PR middle-end/60281

[Ramana Radhakrishnan]

>> Or, if ARM supports unaligned loads/stores using special instructions,
>> perhaps you should also benchmark the alternative of not realigning, but
>> instead making sure those unaligned instructions are used for the shadow
>> memory loads/stores in the asan prologue/epilogue.
> I have tried to use -fno-peephole2 to shutdown instructions
> combinations,but that makes me feel uncomfortable.

That should not be required. I suspect what you need is a
movmisalignsi expander generating unaligned_store/loadsi patterns.
Notice that these put out ldr / str instructions but with UNSPECs
which means that the peepholers for ldrd / ldm will not catch them.

As Jakub says later in this thread ARM is a STRICT_ALIGNMENT target.
If the compiler is peepholing unaligned ldr's and str's, that would be
a bug and the compiler needs to be fixed to avoid this.

regards
Ramana

>>
>> Please next time post the patch from a sane MUA that doesn't eat tabs or
>> at least as an attachment.  Comments should start with a capital letter, and
>> with a full stop followed by two spaces, in the ChangeLog also all entries
>> should end with a full stop.
> Sorry about that...
> BTW,I didn't modify the ChangeLog because this patch should be discussed
> carefully.
>>
>>   Jakub
>
>

Re: [gomp4] libgomp: plugin for non-shared memory host execution

[Thomas Schwinge]

Hi!

On Wed, 19 Feb 2014 17:10:15 +0100, I wrote:
> $ gcc -m64 -Wall -Wextra -shared -o libgomp-plugin-host.so.1 
> [...]/libgomp/plugin-host.c -fPIC -O -DDEBUG
> 
> ..., and then set LIBGOMP_PLUGIN_PATH=$PWD in the environment.

If putting plugins for several architectures into the same directory (as
required for 32-bit as well as 64-bit x86 GNU/Linux testing,
»RUNTESTFLAGS='--target_board=unix\{,-m32\}'«), libgomp will crash when
loading the incompatible library; a bug that I introduced:

> commit 8495aab54fb244ef2643e43eb3e91a092ff0b14e
> Author: Thomas Schwinge , James Norris 
> 
> Date:   Wed Feb 19 16:53:14 2014 +0100
> 
> libgomp: plugin for non-shared memory host execution.

> --- libgomp/target.c
> +++ libgomp/target.c
> @@ -608,28 +618,43 @@ static bool
>  gomp_load_plugin_for_device (struct gomp_device_descr *device,
>const char *plugin_name)
>  {
> -  if (!device || !plugin_name)
> -return false;
> -
> -  device->plugin_handle = dlopen (plugin_name, RTLD_LAZY);
> -  if (!device->plugin_handle)
> -return false;
> +  char *err = NULL;
>  
>/* Clear any existing error.  */
>dlerror ();
>  
> +  device->plugin_handle = dlopen (plugin_name, RTLD_LAZY);
> +  if (!device->plugin_handle)
> +{
> +  err = dlerror ();
> +  goto out;

> + out:
> +  if (err != NULL)
>  {
> +  gomp_error ("while loading %s: %s", plugin_name, err);
>dlclose (device->plugin_handle);
> -  return false;
>  }
> -
> -  return true;
> +  return err == NULL;

Fixed in r207940 as follows:

commit 4b51d1f28358bf60e96c4d6f3c78f1d7d52c4061
Author: tschwinge 
Date:   Thu Feb 20 11:03:13 2014 +

libgomp: Avoid potential crash in plugin error handling.

* target.c (gomp_load_plugin_for_device): Don't call dlcose if
dlopen failed.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@207940 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git libgomp/ChangeLog.gomp libgomp/ChangeLog.gomp
index c764b17..3dffde4 100644
--- libgomp/ChangeLog.gomp
+++ libgomp/ChangeLog.gomp
@@ -1,4 +1,9 @@
 2014-02-20  Thomas Schwinge  
+
+   * target.c (gomp_load_plugin_for_device): Don't call dlcose if
+   dlopen failed.
+
+2014-02-20  Thomas Schwinge  
James Norris  
 
* plugin-host.c: New file.
diff --git libgomp/target.c libgomp/target.c
index 83fcbd2..a6a5505 100644
--- libgomp/target.c
+++ libgomp/target.c
@@ -647,7 +647,8 @@ gomp_load_plugin_for_device (struct gomp_device_descr 
*device,
   if (err != NULL)
 {
   gomp_error ("while loading %s: %s", plugin_name, err);
-  dlclose (device->plugin_handle);
+  if (device->plugin_handle)
+   dlclose (device->plugin_handle);
 }
   return err == NULL;
 }


Grüße,
 Thomas


pgpkfVhApFq9k.pgp
Description: PGP signature

Re: [PATCH] PR middle-end/60281

[lin zuojian]

于 2014年02月20日 19:05, Ramana Radhakrishnan 写道:
>>> Or, if ARM supports unaligned loads/stores using special instructions,
>>> perhaps you should also benchmark the alternative of not realigning, but
>>> instead making sure those unaligned instructions are used for the shadow
>>> memory loads/stores in the asan prologue/epilogue.
>> I have tried to use -fno-peephole2 to shutdown instructions
>> combinations,but that makes me feel uncomfortable.
> That should not be required. I suspect what you need is a
> movmisalignsi expander generating unaligned_store/loadsi patterns.
> Notice that these put out ldr / str instructions but with UNSPECs
> which means that the peepholers for ldrd / ldm will not catch them.
>
> As Jakub says later in this thread ARM is a STRICT_ALIGNMENT target.
> If the compiler is peepholing unaligned ldr's and str's, that would be
> a bug and the compiler needs to be fixed to avoid this.
>
> regards
> Ramana
That is not a bug of instruction selection.SImode implies that the
address is 4 bytes aligned.
>
>>> Please next time post the patch from a sane MUA that doesn't eat tabs or
>>> at least as an attachment.  Comments should start with a capital letter, and
>>> with a full stop followed by two spaces, in the ChangeLog also all entries
>>> should end with a full stop.
>> Sorry about that...
>> BTW,I didn't modify the ChangeLog because this patch should be discussed
>> carefully.
>>>   Jakub
>>

Re: c-parser.c replace error() by error_at()

[Prathamesh Kulkarni]

On Wed, Feb 19, 2014 at 11:32 PM, Joseph S. Myers
 wrote:
> On Wed, 19 Feb 2014, Prathamesh Kulkarni wrote:
>
>> I have sent it attached this time.
>
> Thanks, this version is OK.  Please start the copyright assignment
> paperwork process if you haven't already done so, if you may be
> contributing more changes in future.
>
> http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
Thanks. I had sent the assignment form by postal mail a week ago. I
have not received
a reply.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: [PATCH] Allow cfgcleanup to remove forwarder loop preheaders and latches

[Richard Biener]

On Wed, 19 Feb 2014, Bin.Cheng wrote:

> On Wed, Feb 19, 2014 at 10:06 PM, Richard Biener  wrote:
> > On Wed, 19 Feb 2014, Bin.Cheng wrote:
> >
> >> Hi Richard,
> >> Does this have to wait for stage 1? Or I will try to work out a full
> >> patch with loop recreating issue fixed.
> >
> > If it is a regression and there is a bugzilla about it it doesn't
> > have to wait.
> >
> > The patch should be complete (but is untested yet)
> >
> >> On Wed, Feb 19, 2014 at 7:57 PM, Richard Biener  wrote:
> >> >
> >> > This allows cfgcleanup to remove some of the extra CFG that exists
> >> > just for loop analysis passes convenience (those can be and are
> >> > easily re-created by passes doing loop_optimizer_init ()).
> >> >
> >> > It may fix a regression uncovered in private communication.
> >> It's the regression about the code size checks in
> >> gcc.target/arm/ivopts.c and gcc.target/arm/ivopts-2.c
> >
> > I see.  So it is a regression then.
> OK, I will file a PR about it.
> 
> >
> >> >
> >> > Untested - my original idea how to fix this (tree_forwarder_block_p
> >> > hunk) ran into the issue in remove_forwarder_block which causes
> >> > loops to be removed / re-discovered (losing meta-data).
> >> >
> >> > Richard.
> >> >
> >> > 2014-02-19  Richard Biener  
> >> >
> >> > * tree-cfgcleanup.c (tree_forwarder_block_p): Protect
> >> > latches and preheaders only if requested.
> >> > (remove_forwarder_block): Update loop structure if we
> >> > removed a forwarder that is a loop latch.
> >> >
> >> > Index: gcc/tree-cfgcleanup.c
> >> > ===
> >> > *** gcc/tree-cfgcleanup.c   (revision 207878)
> >> > --- gcc/tree-cfgcleanup.c   (working copy)
> >> > *** tree_forwarder_block_p (basic_block bb,
> >> > *** 307,321 
> >> >
> >> > if (current_loops)
> >> >   {
> >> > !   basic_block dest;
> >> > !   /* Protect loop latches, headers and preheaders.  */
> >> > if (bb->loop_father->header == bb)
> >> > return false;
> >> > -   dest = EDGE_SUCC (bb, 0)->dest;
> >> >
> >> > !   if (dest->loop_father->header == dest)
> >> > return false;
> >> >   }
> >> > return true;
> >> >   }
> >> >
> >> > --- 307,324 
> >> >
> >> > if (current_loops)
> >> >   {
> >> > !   /* Protect loop headers.  */
> >> > if (bb->loop_father->header == bb)
> >> > return false;
> >> >
> >> > !   /* Protect loop latches and preheaders if requested.  */
> >> > !   basic_block dest = EDGE_SUCC (bb, 0)->dest;
> >> > !   if (dest->loop_father->header == dest
> >> > ! && (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)
> >> > ! || loops_state_satisfies_p (LOOPS_HAVE_SIMPLE_LATCHES)))
> >> > return false;
> >> >   }
> >> Sorry for being nit-picking here. There is a scenario that bb is
> >> pre-header and loop prop is set to (!LOOPS_HAVE_PREHEADERS &&
> >> LOOPS_HAVE_SIMPLE_LATCHES).  Of course, this may not happen anyway.
> >
> > Yeah, but then we'd have to detect whether this is a preheader
> > forwarder or a latch forwarder.  I doubt it happens right now
> > so I thought it doesn't matter to do it like above.
> >
> >> > +
> >> > return true;
> >> >   }
> >> >
> >> > *** remove_forwarder_block (basic_block bb)
> >> > *** 497,503 
> >> > set_immediate_dominator (CDI_DOMINATORS, dest, dom);
> >> >   }
> >> >
> >> > !   /* And kill the forwarder block.  */
> >> > delete_basic_block (bb);
> >> >
> >> > return true;
> >> > --- 500,511 
> >> > set_immediate_dominator (CDI_DOMINATORS, dest, dom);
> >> >   }
> >> >
> >> > !   /* And kill the forwarder block, but first adjust its parent loop
> >> > !  latch info as otherwise the cfg hook has a hard time not to
> >> > !  kill the loop.  */
> >> > !   if (current_loops
> >> > !   && bb->loop_father->latch == bb)
> >> > ! bb->loop_father->latch = dest;
> >> > delete_basic_block (bb);
> >> By this code, do you mean to prevent cfgcleanup from
> >> removing/rebuilding the loop struct?
> >
> > Yes.  It prevents triggering cfghooks.c:
> >
> > void
> > delete_basic_block (basic_block bb)
> > {
> > ...
> >   /* If we remove the header or the latch of a loop, mark the loop for
> >  removal by setting its header and latch to NULL.  */
> >   if (loop->latch == bb
> >   || loop->header == bb)
> > {
> >   loop->header = NULL;
> >   loop->latch = NULL;
> >   loops_state_set (LOOPS_NEED_FIXUP);
> >
> > generally delete_basic_block has too little context to work out
> > anything more specific than the above (so it's a very bad tool ;))
> 
> Well, it can't.  From what I observed, it is pass_ch that modifies the
> loop header with some specific control flow graph.  Doesn't matter if
> the LOOPS_NEED_FIXUP is set before pass_ch, since it calls
> loop_optimizer_init to fix 

[libjava] XFAIL sourcelocation (PR libgcj/55637)

[Rainer Orth]

The libjava sourcelocation output test has been FAILing on mainline for
more than a year, with no sign of anything happening to resolve that.
To reduce testsuite noise, I suggest to XFAIL the test.  In all mainline
test results from february, only a single set of testresults that
included libjava results (for ia64-suse-linux-gnu) didn't show those
failures.

Tested with the appropriate runtest invocations on i386-pc-solaris2.11
and x86_64-unknown-linux-gnu.

Ok for mainline?

Rainer


2014-02-20  Rainer Orth  

PR libgcj/55637
* testsuite/libjava.lang/sourcelocation.xfail: New file.

# HG changeset patch
# Parent 6fd38b9012dee330d1343765cfe3cd0e06f33d33
XFAIL sourcelocation (PR libgcj/55637)

diff --git a/libjava/testsuite/libjava.lang/sourcelocation.xfail b/libjava/testsuite/libjava.lang/sourcelocation.xfail
new file mode 100644
--- /dev/null
+++ b/libjava/testsuite/libjava.lang/sourcelocation.xfail
@@ -0,0 +1,1 @@
+xfail-output

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Fix sanitizer build on sparc (PR sanitizer/59758)

[Jose E. Marchesi]

> On Tue, Feb 18, 2014 at 06:55:51PM +0100, Jose E. Marchesi wrote:
> > This patch fixes builds with --enable-sanitizer, which seems to be the
> > default for sparc now.
> >
> > Build tested in a sparc64-*-linux-gnu system with linux 3.8.13 headers.
> >
> > 2014-02-18  Jose E. Marchesi  
> >
> >   PR sanitizer/59758
> >   * sanitizer_common/sanitizer_platform_limits_posix.h 
(__sanitizer):
> >   Define struct__old_kernel_stat_sz, struct_kernel_stat_sz and
> >   struct_kernel_stat64_sz for sparc targets (both 32 and 64 bits).
> >   (__sanitizer_ipc_perm): Adjust for sparc targets.
> >   (__sanitizer_shmid_ds): Likewise.
> >   (__sanitizer_sigaction): Likewise.
> >   (IOC_SIZE): Likewise.
> >
> >   * sanitizer_common/sanitizer_platform_limits_linux.cc (time_t):
> >   defined as __kernel_time_t, which is needed for sparc.
> >   (struct___old_kernel_stat_sz): Don't check if __sparc__ is 
defined.
>
> Please talk to Konstantin about getting this into the upstream compiler-rt
> repository, we don't need to wait for a merge from there, so once it
> is accepted there, the same patch can be applied to gcc too.

Right. Please read
https://code.google.com/p/address-sanitizer/wiki/HowToContribute

Yesterday I fetched and built the latest llvm/compiler-rt in sparc64.  I
could not manage (in a reasonable time) to get the stuff in
compiler-rt/lib/sanitizer_common and compiler-rt/lib/asan built: these
directories seems to be skipped when compiling on this platform.  No, I
am not familiar at all with the llvm/compiler-rt build system.  Also I
noticed that there are a lot of changes upstream since last gcc merge
that may or may not compile on sparc: basically constants and data
structures duplicating stuff from kernel headers.

Well, I really dont have time to hack the llvm build system and also
keep the upstream sanitizer compiling on sparc until next merge, sorry.

At this point I would suggest to either apply my patch to gcc's
libsanitizer to fix the sparc build until next merge[1] or disable
building libsanitizer on sparc targets.

[1] I offer my help to make sure that whatever comes in the next merge
builds on sparc64 in the gcc source tree.

[C PATCH] fix column number in comma expression warning

[Prathamesh Kulkarni]

Show column number of left operand instead of comma operator
in the warning "left-hand operand of comma expression has no effect"

Example:
ax.c:4:6: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
   x  ,  y;
  ^
Instead of comma operator, show location of left-operand:
ax.c:4:3: warning: left-hand operand of comma expression has no effect
[-Wunused-value]
   x  ,  y;
   ^
Bootstrapped on x86_64-unknown-linux-gnu.

[gcc/c]
* c-parser.c (c_parser_expression): Pass tloc instead of loc to
build_compound_expr.

[gcc/testsuite]
* gcc.dg/Wunused-value-4.c: New test case.

I am not able to figure out, how to write test-case that
raises multiple warnings. example: (void) x, y, z.
I tried this:
/* { dg-warning "8:left-hand operand of comma expression has no effect
  |11:left-hand operand of comma expression has no
effect" } */
x has column number 8 and y has column number 11, but this doesn't
seem to work (the patch works correctly).

Thanks and Regards,
Prathamesh
Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c	(revision 207916)
+++ gcc/c/c-parser.c	(working copy)
@@ -7838,7 +7838,6 @@ c_parser_expression (c_parser *parser)
 {
   struct c_expr next;
   tree lhsval;
-  location_t loc = c_parser_peek_token (parser)->location;
   location_t expr_loc;
   c_parser_consume_token (parser);
   expr_loc = c_parser_peek_token (parser)->location;
@@ -7849,9 +7848,10 @@ c_parser_expression (c_parser *parser)
 	mark_exp_read (lhsval);
   next = c_parser_expr_no_commas (parser, NULL);
   next = convert_lvalue_to_rvalue (expr_loc, next, true, false);
-  expr.value = build_compound_expr (loc, expr.value, next.value);
+  expr.value = build_compound_expr (tloc, expr.value, next.value);
   expr.original_code = COMPOUND_EXPR;
   expr.original_type = next.original_type;
+  tloc = expr_loc;
 }
   return expr;
 }
Index: gcc/testsuite/gcc.dg/Wunused-value-4.c
===
--- gcc/testsuite/gcc.dg/Wunused-value-4.c	(revision 0)
+++ gcc/testsuite/gcc.dg/Wunused-value-4.c	(working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-Wunused-value" } */
+
+void foo(int x);
+
+int a[10];
+
+void f(void)
+{
+  foo ((1, 2));/* { dg-warning "9: left-hand operand of comma expression has no effect" } */ 
+  a[0x03, 004] = 1992; /* { dg-warning "5: left-hand operand of comma expression has no effect" } */
+}

Re: [PATCH] Fix sanitizer build on sparc (PR sanitizer/59758)

[Konstantin Serebryany]

>
> At this point I would suggest to either apply my patch to gcc's
> libsanitizer to fix the sparc build
Please don't.
The "merge" is actually not a merge, it is a simple copy of LLVM
sources over the GCC sources,
no *merging* is ever expected to happen.

> until next merge[1] or disable
> building libsanitizer on sparc targets.

Works for me.
If anyone really wants to support asan on sparc (s)he should work with
us on the upstream (LLVM) repo.
We welcome such work but will request a public build bot.

--kcc


>
> [1] I offer my help to make sure that whatever comes in the next merge
> builds on sparc64 in the gcc source tree.

Re: [PATCH] Fix sanitizer build on sparc (PR sanitizer/59758)

[Jakub Jelinek]

On Thu, Feb 20, 2014 at 01:15:37PM +0100, Jose E. Marchesi wrote:
> Yesterday I fetched and built the latest llvm/compiler-rt in sparc64.  I
> could not manage (in a reasonable time) to get the stuff in
> compiler-rt/lib/sanitizer_common and compiler-rt/lib/asan built: these
> directories seems to be skipped when compiling on this platform.  No, I
> am not familiar at all with the llvm/compiler-rt build system.  Also I
> noticed that there are a lot of changes upstream since last gcc merge
> that may or may not compile on sparc: basically constants and data
> structures duplicating stuff from kernel headers.

Most likely llvm asan isn't supported on sparc, or perhaps even llvm, I
think it is not your responsibility to fix it up.  So, if the patch is
clearly for sparc and doesn't affect anything else, it shouldn't break
anything on the llvm side, so I'd hope it should be ok as is to compiler-rt.

Jakub

Re: [PATCH] Fix sanitizer build on sparc (PR sanitizer/59758)

[Konstantin Serebryany]

On Thu, Feb 20, 2014 at 4:34 PM, Jakub Jelinek  wrote:
> On Thu, Feb 20, 2014 at 01:15:37PM +0100, Jose E. Marchesi wrote:
>> Yesterday I fetched and built the latest llvm/compiler-rt in sparc64.  I
>> could not manage (in a reasonable time) to get the stuff in
>> compiler-rt/lib/sanitizer_common and compiler-rt/lib/asan built: these
>> directories seems to be skipped when compiling on this platform.  No, I
>> am not familiar at all with the llvm/compiler-rt build system.  Also I
>> noticed that there are a lot of changes upstream since last gcc merge
>> that may or may not compile on sparc: basically constants and data
>> structures duplicating stuff from kernel headers.
>
> Most likely llvm asan isn't supported on sparc, or perhaps even llvm, I
> think it is not your responsibility to fix it up.  So, if the patch is
> clearly for sparc and doesn't affect anything else, it shouldn't break
> anything on the llvm side, so I'd hope it should be ok as is to compiler-rt.

We can accept any patch that looks reasonable and does not break our testing.
We can not promise to keep sparc in usable state as we apply other
changes (unless you set a public build bot),
but of course we'll not to break sparc intentionally.

--kcc

>
> Jakub

[Patch, Fortran] PR602864 - fix INQUIRE for write= with stdout/stdin/stderr

[Tobias Burnus]

A rather simple patch.

Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias
2014-02-20  Tobias Burnus  

	PR fortran/602864
	* libgfortran/io/inquire.c (yes, no): New static const char vars.
	(inquire_via_unit): Use them. Return proper value for
	write=, read= and readwrite= for stdin/stdout/stderr.

2014-02-20  Tobias Burnus  

	PR fortran/602864
	* gfortran.dg/inquire_16.f90: New.

diff --git a/gcc/testsuite/gfortran.dg/inquire_16.f90 b/gcc/testsuite/gfortran.dg/inquire_16.f90
new file mode 100644
index 000..03b735e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/inquire_16.f90
@@ -0,0 +1,29 @@
+! { dg-do run }
+!
+! PR fortran/602864
+!
+! Contributed by  Alexander Vogt
+!
+program test_inquire
+  use, intrinsic :: ISO_Fortran_env
+  implicit none
+  character(len=20) :: s_read, s_write, s_readwrite
+
+  inquire(unit=input_unit, read=s_read, write=s_write, &
+  readwrite=s_readwrite)
+  if (s_read /= "YES" .or. s_write /= "NO" .or. s_readwrite /="NO") then
+call abort()
+  endif
+
+  inquire(unit=output_unit, read=s_read, write=s_write, &
+  readwrite=s_readwrite)
+  if (s_read /= "NO" .or. s_write /= "YES" .or. s_readwrite /="NO") then
+call abort()
+  endif
+
+  inquire(unit=error_unit, read=s_read, write=s_write, &
+  readwrite=s_readwrite)
+  if (s_read /= "NO" .or. s_write /= "YES" .or. s_readwrite /="NO") then
+call abort()
+  endif
+end program test_inquire
diff --git a/libgfortran/io/inquire.c b/libgfortran/io/inquire.c
index b12ee51..3f8497a 100644
--- a/libgfortran/io/inquire.c
+++ b/libgfortran/io/inquire.c
@@ -30,7 +30,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #include 
 
 
-static const char undefined[] = "UNDEFINED";
+static const char yes[] = "YES", no[] = "NO", undefined[] = "UNDEFINED";
 
 
 /* inquire_via_unit()-- Inquiry via unit number.  The unit might not exist. */
@@ -130,10 +130,10 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
 	  {
 	  case ACCESS_DIRECT:
 	  case ACCESS_STREAM:
-	p = "NO";
+	p = no;
 	break;
 	  case ACCESS_SEQUENTIAL:
-	p = "YES";
+	p = yes;
 	break;
 	  default:
 	internal_error (&iqp->common, "inquire_via_unit(): Bad access");
@@ -151,10 +151,10 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
 	  {
 	  case ACCESS_SEQUENTIAL:
 	  case ACCESS_STREAM:
-	p = "NO";
+	p = no;
 	break;
 	  case ACCESS_DIRECT:
-	p = "YES";
+	p = yes;
 	break;
 	  default:
 	internal_error (&iqp->common, "inquire_via_unit(): Bad access");
@@ -191,10 +191,10 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
 	switch (u->flags.form)
 	  {
 	  case FORM_FORMATTED:
-	p = "YES";
+	p = yes;
 	break;
 	  case FORM_UNFORMATTED:
-	p = "NO";
+	p = no;
 	break;
 	  default:
 	internal_error (&iqp->common, "inquire_via_unit(): Bad form");
@@ -211,10 +211,10 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
 	switch (u->flags.form)
 	  {
 	  case FORM_FORMATTED:
-	p = "NO";
+	p = no;
 	break;
 	  case FORM_UNFORMATTED:
-	p = "YES";
+	p = yes;
 	break;
 	  default:
 	internal_error (&iqp->common, "inquire_via_unit(): Bad form");
@@ -266,10 +266,10 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
 	switch (u->flags.pad)
 	  {
 	  case PAD_YES:
-	p = "YES";
+	p = yes;
 	break;
 	  case PAD_NO:
-	p = "NO";
+	p = no;
 	break;
 	  default:
 	internal_error (&iqp->common, "inquire_via_unit(): Bad pad");
@@ -336,10 +336,10 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
 	switch (u->flags.async)
 	{
 	  case ASYNC_YES:
-		p = "YES";
+		p = yes;
 		break;
 	  case ASYNC_NO:
-		p = "NO";
+		p = no;
 		break;
 	  default:
 		internal_error (&iqp->common, "inquire_via_unit(): Bad async");
@@ -423,10 +423,10 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
 	  {
 	  case ACCESS_SEQUENTIAL:
 	  case ACCESS_DIRECT:
-		p = "NO";
+		p = no;
 		break;
 	  case ACCESS_STREAM:
-		p = "YES";
+		p = yes;
 		break;
 	  default:
 		internal_error (&iqp->common, "inquire_via_unit(): Bad pad");
@@ -499,7 +499,14 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
 
   if ((cf & IOPARM_INQUIRE_HAS_READ) != 0)
 {
-  p = (u == NULL) ? inquire_read (NULL, 0) :
+  if (!u)
+	inquire_read (NULL, 0);
+  else if (u->unit_number == options.stdin_unit)
+	p = yes;
+  else if (u->unit_number == options.stdout_unit
+	   || u->unit_number == options.stderr_unit)
+	p = no;
+  else
 	inquire_read (u->file, u->file_len);
 
   cf_strcpy (iqp->read, iqp->read_len, p);
@@ -507,7 +514,14 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
 
   if ((cf & IOPARM_INQUIRE_HAS_WRITE) != 0)
 {
-  p = (u == NULL) ? inquire_write (NULL, 0) :
+  if (!u)
+	inquire_write (NULL, 0);
+  else if (u->unit_number == options.stdin_unit)
+	

Re: [C PATCH] fix column number in comma expression warning

[Marek Polacek]

On Thu, Feb 20, 2014 at 05:52:09PM +0530, Prathamesh Kulkarni wrote:
> Show column number of left operand instead of comma operator
> in the warning "left-hand operand of comma expression has no effect"
> 
> Example:
> ax.c:4:6: warning: left-hand operand of comma expression has no effect
> [-Wunused-value]
>x  ,  y;
>   ^

Perhaps a PR should be opened for this.

> Instead of comma operator, show location of left-operand:
> ax.c:4:3: warning: left-hand operand of comma expression has no effect
> [-Wunused-value]
>x  ,  y;
>^

But this patch only handles LHS of comma expression, and not RHS,
right?  IMHO we should do both at the same time (that would be
for 5.0 I'd say).

> Bootstrapped on x86_64-unknown-linux-gnu.
> 
> [gcc/c]
> * c-parser.c (c_parser_expression): Pass tloc instead of loc to
> build_compound_expr.
> 
> [gcc/testsuite]
> * gcc.dg/Wunused-value-4.c: New test case.
> 
> I am not able to figure out, how to write test-case that
> raises multiple warnings. example: (void) x, y, z.
> I tried this:
> /* { dg-warning "8:left-hand operand of comma expression has no effect
>   |11:left-hand operand of comma expression has no
> effect" } */
> x has column number 8 and y has column number 11, but this doesn't
> seem to work (the patch works correctly).

For this you'll need a second dg-warning that specifies the line, so
e.g. something like
/* { dg-warning "11:left-hand operand of comma expression has no effect" "" { 
target *-*-* } 10 } */

(Not reviewing the patch per se now.)

> Thanks and Regards,
> Prathamesh

> Index: gcc/c/c-parser.c
> ===
> --- gcc/c/c-parser.c  (revision 207916)
> +++ gcc/c/c-parser.c  (working copy)
> @@ -7838,7 +7838,6 @@ c_parser_expression (c_parser *parser)
>  {
>struct c_expr next;
>tree lhsval;
> -  location_t loc = c_parser_peek_token (parser)->location;
>location_t expr_loc;
>c_parser_consume_token (parser);
>expr_loc = c_parser_peek_token (parser)->location;
> @@ -7849,9 +7848,10 @@ c_parser_expression (c_parser *parser)
>   mark_exp_read (lhsval);
>next = c_parser_expr_no_commas (parser, NULL);
>next = convert_lvalue_to_rvalue (expr_loc, next, true, false);
> -  expr.value = build_compound_expr (loc, expr.value, next.value);
> +  expr.value = build_compound_expr (tloc, expr.value, next.value);
>expr.original_code = COMPOUND_EXPR;
>expr.original_type = next.original_type;
> +  tloc = expr_loc;
>  }
>return expr;
>  }
> Index: gcc/testsuite/gcc.dg/Wunused-value-4.c
> ===
> --- gcc/testsuite/gcc.dg/Wunused-value-4.c(revision 0)
> +++ gcc/testsuite/gcc.dg/Wunused-value-4.c(working copy)
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-Wunused-value" } */
> +
> +void foo(int x);
> +
> +int a[10];
> +
> +void f(void)
> +{
> +  foo ((1, 2));/* { dg-warning "9: left-hand operand of 
> comma expression has no effect" } */ 
> +  a[0x03, 004] = 1992; /* { dg-warning "5: left-hand operand of 
> comma expression has no effect" } */
> +}

Marek

Re: [PATCH] Fix sanitizer build on sparc (PR sanitizer/59758)

[Jakub Jelinek]

On Thu, Feb 20, 2014 at 04:44:48PM +0400, Konstantin Serebryany wrote:
> On Thu, Feb 20, 2014 at 4:34 PM, Jakub Jelinek  wrote:
> > On Thu, Feb 20, 2014 at 01:15:37PM +0100, Jose E. Marchesi wrote:
> >> Yesterday I fetched and built the latest llvm/compiler-rt in sparc64.  I
> >> could not manage (in a reasonable time) to get the stuff in
> >> compiler-rt/lib/sanitizer_common and compiler-rt/lib/asan built: these
> >> directories seems to be skipped when compiling on this platform.  No, I
> >> am not familiar at all with the llvm/compiler-rt build system.  Also I
> >> noticed that there are a lot of changes upstream since last gcc merge
> >> that may or may not compile on sparc: basically constants and data
> >> structures duplicating stuff from kernel headers.
> >
> > Most likely llvm asan isn't supported on sparc, or perhaps even llvm, I
> > think it is not your responsibility to fix it up.  So, if the patch is
> > clearly for sparc and doesn't affect anything else, it shouldn't break
> > anything on the llvm side, so I'd hope it should be ok as is to compiler-rt.
> 
> We can accept any patch that looks reasonable and does not break our testing.
> We can not promise to keep sparc in usable state as we apply other
> changes (unless you set a public build bot),
> but of course we'll not to break sparc intentionally.

So I think that it is this case.  Of course it is possible next merge
from compiler-rt will break sparc again, so I think we should CC affected
target maintainers at that point and let them test/fix it up when that
happens, but that will be post 4.9.

Jakub

Re: [Patch, Fortran] PR602864 - fix INQUIRE for write= with stdout/stdin/stderr

[Uros Bizjak]

Hello!

> A rather simple patch.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
> 2014-02-20  Tobias Burnus  
>
> PR fortran/602864

... we are not there yet with PR numbers ;)

Uros.

[Ada] Internal access to Reason for Warnings Off

[Arnaud Charlet]

This is an internal change to allow retrieval of the Reason argument
for a given message suppressed by Warnings (Off). No functional effect.

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-02-20  Robert Dewar  

* errout.adb (Set_Warnings_Mode_Off): Add Reason argument.
(Set_Specific_Warning_Off): Add Reason argument.
* errout.ads (Set_Warnings_Mode_Off): Add Reason argument.
(Set_Specific_Warning_Off): Add Reason argument.
* erroutc.adb (Warnings_Entry): Add Reason field
(Specific_Warning_Entry): Add Reason field.
(Warnings_Suppressed): return String_Id for Reason.
(Warning_Specifically_Suppressed): return String_Id for Reason.
* erroutc.ads (Warnings_Entry): Add Reason field.
(Specific_Warning_Entry): Add Reason field.
(Set_Specific_Warning_Off): Add Reason argument.
(Set_Warnings_Mode_Off): Add Reason argument.
(Warnings_Suppressed): return String_Id for Reason.
(Warning_Specifically_Suppressed): return String_Id for Reason.
* errutil.adb (Warnings_Suppressed): returns String_Id for Reason
(Warning_Specifically_Suppressed): returns String_Id for Reason
* gnat_rm.texi: Document that Warning parameter is string literal
or a concatenation of string literals.
* par-prag.adb: New handling for Reason argument.
* sem_prag.adb (Analyze_Pragma, case Warning): New handling
for Reason argument.
* sem_util.ads, sem_util.adb (Get_Reason_String): New procedure.
* sem_warn.ads (Warnings_Off_Entry): Add reason field.
* stringt.adb: Set Null_String_Id.
* stringt.ads (Null_String_Id): New constant.

Index: gnat_rm.texi
===
--- gnat_rm.texi(revision 207905)
+++ gnat_rm.texi(working copy)
@@ -7381,7 +7381,7 @@
 pragma Warnings (static_string_EXPRESSION [,REASON]);
 pragma Warnings (On | Off, static_string_EXPRESSION [,REASON]);
 
-REASON ::= Reason => static_string_EXPRESSION
+REASON ::= Reason => STRING_LITERAL {& STRING_LITERAL}
 @end smallexample
 
 @noindent
Index: stringt.adb
===
--- stringt.adb (revision 207879)
+++ stringt.adb (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- B o d y  --
 --  --
---  Copyright (C) 1992-2012, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2013, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -472,4 +472,12 @@
   end if;
end Write_String_Table_Entry;
 
+--  Setup the null string
+
+pragma Warnings (Off); -- kill strange warning from code below ???
+
+begin
+   Start_String;
+   Null_String_Id := End_String;
+
 end Stringt;
Index: stringt.ads
===
--- stringt.ads (revision 207879)
+++ stringt.ads (working copy)
@@ -6,7 +6,7 @@
 --  --
 -- S p e c  --
 --  --
---  Copyright (C) 1992-2012, Free Software Foundation, Inc. --
+--  Copyright (C) 1992-2013, Free Software Foundation, Inc. --
 --  --
 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
 -- terms of the  GNU General Public License as published  by the Free Soft- --
@@ -48,6 +48,9 @@
 --  value for two identical strings stored separately and also cannot count on
 --  the two Id values being different.
 
+   Null_String_Id : String_Id;
+   --  Gets set to a null string with length zero
+
--
-- String Table Access Subprograms --
--
Index: sem_prag.adb
===
--- sem_prag.adb(revision 207942)
+++ sem_prag.adb(working copy)
@@ -20815,14 +20815,17 @@
 
  --  REASON ::= Reason => Static_String_Expression
 
- when Pragma_Warnings => Warnings : begin
+ when Pragma_Warnings => Warnings : declare
+Reason : String_Id;
+
+ begin
 GNAT_Pragma;
 Check_At_Least_N_Arguments (1);
 
 --  See if last argument is labeled Reason. If so, make sure we
---  have a static string expression, but

Re: [Patch, Fortran] PR602864 - fix INQUIRE for write= with stdout/stdin/stderr

[Paul Richard Thomas]

Dear Uros,

Tobias's patch is designed to be future-proof!

Cheers

Paul

On 20 February 2014 14:26, Uros Bizjak  wrote:
> Hello!
>
>> A rather simple patch.
>>
>> Build and regtested on x86-64-gnu-linux.
>> OK for the trunk?
>>
>> 2014-02-20  Tobias Burnus  
>>
>> PR fortran/602864
>
> ... we are not there yet with PR numbers ;)
>
> Uros.



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
   --Hitchhikers Guide to the Galaxy

[Ada] Issue with SPARK aspects and generics

[Arnaud Charlet]

This patch corrects the propagation of various SPARK aspects from a generic
template to an instance.


-- Source --


--  values.ads

package Values is
   In_1 : Integer := 1234;
end Values;

--  gen.ads

with Values; use Values;

generic
package Gen
  with Abstract_State=>  State,
   Initializes   =>  Out_1,
   Initial_Condition => (Out_1 = 5678)
is
   Out_1 : Integer := 5678;

   procedure Proc (In_2 : Integer; Out_2 : out Integer)
 with Global  => (Input  => In_1,
  In_Out => State,
  Output => Out_1),
  Depends => ((Out_1, Out_2, State) => (In_1, In_2, State));
end Gen;

--  gen.adb

package body Gen
  with Refined_State => (State => (In_3, Out_3))
is
   In_3  : Integer := 1;
   Out_3 : Integer := 2;

   procedure Proc (In_2 : Integer; Out_2 : out Integer)
 with Refined_Global  => (Input  => (In_1,  In_3),
  Output => (Out_1, Out_3)),
  Refined_Depends => ((Out_1, Out_2, Out_3) => (In_1, In_2, In_3))
   is begin null; end Proc;
end Gen;

--  inst.ads

with Gen;

package Inst is new Gen;

-
-- Compilation --
-

$ gcc -c inst.ads

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-02-20  Hristian Kirtchev  

* aspects.adb (Exchange_Aspects): New routine.
* aspects.ads (Exchange_Aspects): New routine.
* atree.adb (Rewrite): Do not check whether the save node has
aspects as it never will, instead check the node about to be clobbered.
* einfo.adb (Write_Field25_Name): Abstract_States can appear in
entities of generic packages.
* sem_ch6.adb (Analyze_Expression_Function): Fix the parent
pointer of an aspect specification list after rewriting takes place.
* sem_ch7.adb (Analyze_Package_Body_Helper): Swap the aspect
specifications of the generic template and the copy used for analysis.
* sem_ch12.adb (Analyze_Generic_Package_Declaration): Swap
the aspect specifications of the generic template and the
copy used for analysis.
(Analyze_Package_Instantiation): Propagate the aspect specifications
from the generic template to the instantiation.
(Build_Instance_Compilation_Unit_Nodes): Propagate the aspect
specifications from the generic template to the instantiation.
* sem_ch13.adb (Analyze_Aspect_Specifications): Handle aspects
Abstract_State, Initializes and Initial_Condition when they
apply to a package instantiation.

Index: sem_ch7.adb
===
--- sem_ch7.adb (revision 207879)
+++ sem_ch7.adb (working copy)
@@ -327,6 +327,11 @@
  New_N := Copy_Generic_Node (N, Empty, Instantiating => False);
  Rewrite (N, New_N);
 
+ --  Once the contents of the generic copy and the template are
+ --  swapped, do the same for their respective aspect specifications.
+
+ Exchange_Aspects (N, New_N);
+
  --  Update Body_Id to point to the copied node for the remainder of
  --  the processing.
 
Index: einfo.adb
===
--- einfo.adb   (revision 207879)
+++ einfo.adb   (working copy)
@@ -9290,7 +9290,8 @@
procedure Write_Field25_Name (Id : Entity_Id) is
begin
   case Ekind (Id) is
- when E_Package=>
+ when E_Generic_Package|
+  E_Package=>
 Write_Str ("Abstract_States");
 
  when E_Variable   =>
Index: sem_ch12.adb
===
--- sem_ch12.adb(revision 207942)
+++ sem_ch12.adb(working copy)
@@ -3019,6 +3019,11 @@
   New_N := Copy_Generic_Node (N, Empty, Instantiating => False);
   Set_Parent_Spec (New_N, Save_Parent);
   Rewrite (N, New_N);
+
+  --  Once the contents of the generic copy and the template are swapped,
+  --  do the same for their respective aspect specifications.
+
+  Exchange_Aspects (N, New_N);
   Id := Defining_Entity (N);
   Generate_Definition (Id);
 
@@ -3088,7 +3093,6 @@
 Check_References (Id);
  end if;
   end if;
-
end Analyze_Generic_Package_Declaration;
 

@@ -3598,7 +3602,7 @@
Make_Package_Renaming_Declaration (Loc,
  Defining_Unit_Name =>
Make_Defining_Identifier (Loc, Chars (Gen_Unit)),
- Name => New_Occurrence_Of (Act_Decl_Id, Loc));
+ Name   => New_Occurrence_Of (Act_Decl_Id, Loc));
 
  Append (Unit_Renaming, Renaming_List);
 
@@ -3616,6 +3620,14 @@
Make_Package_Declaration (Loc,
  Specification => Act_Spec);
 
+ --  Propagate 

Re: [libjava] XFAIL sourcelocation (PR libgcj/55637)

[Bryce McKinlay]

On Thu, Feb 20, 2014 at 12:05 PM, Rainer Orth
 wrote:

> The libjava sourcelocation output test has been FAILing on mainline for
> more than a year, with no sign of anything happening to resolve that.
> To reduce testsuite noise, I suggest to XFAIL the test.  In all mainline
> test results from february, only a single set of testresults that
> included libjava results (for ia64-suse-linux-gnu) didn't show those
> failures.
>
> Tested with the appropriate runtest invocations on i386-pc-solaris2.11
> and x86_64-unknown-linux-gnu.
>
> Ok for mainline?

OK.

The fix for this is to have libjava use libbackttrace to get source
line numbers, rather than rely on external addr2line.

Bryce

Re: [C PATCH] fix column number in comma expression warning

[Prathamesh Kulkarni]

On Thu, Feb 20, 2014 at 6:26 PM, Marek Polacek  wrote:
> On Thu, Feb 20, 2014 at 05:52:09PM +0530, Prathamesh Kulkarni wrote:
>> Show column number of left operand instead of comma operator
>> in the warning "left-hand operand of comma expression has no effect"
>>
>> Example:
>> ax.c:4:6: warning: left-hand operand of comma expression has no effect
>> [-Wunused-value]
>>x  ,  y;
>>   ^
>
> Perhaps a PR should be opened for this.
>
>> Instead of comma operator, show location of left-operand:
>> ax.c:4:3: warning: left-hand operand of comma expression has no effect
>> [-Wunused-value]
>>x  ,  y;
>>^
>
> But this patch only handles LHS of comma expression, and not RHS,
> right?  IMHO we should do both at the same time (that would be
> for 5.0 I'd say).
There's a check for rhs of comma expression in build_compound_expr,
which uses correct location. I am not sure which case fires the
warning for rhs though.
>
>> Bootstrapped on x86_64-unknown-linux-gnu.
>>
>> [gcc/c]
>> * c-parser.c (c_parser_expression): Pass tloc instead of loc to
>> build_compound_expr.
>>
>> [gcc/testsuite]
>> * gcc.dg/Wunused-value-4.c: New test case.
>>
>> I am not able to figure out, how to write test-case that
>> raises multiple warnings. example: (void) x, y, z.
>> I tried this:
>> /* { dg-warning "8:left-hand operand of comma expression has no effect
>>   |11:left-hand operand of comma expression has no
>> effect" } */
>> x has column number 8 and y has column number 11, but this doesn't
>> seem to work (the patch works correctly).
>
> For this you'll need a second dg-warning that specifies the line, so
> e.g. something like
> /* { dg-warning "11:left-hand operand of comma expression has no effect" "" { 
> target *-*-* } 10 } */
Thanks. That worked.
>
> (Not reviewing the patch per se now.)
>
>> Thanks and Regards,
>> Prathamesh
>
>> Index: gcc/c/c-parser.c
>> ===
>> --- gcc/c/c-parser.c  (revision 207916)
>> +++ gcc/c/c-parser.c  (working copy)
>> @@ -7838,7 +7838,6 @@ c_parser_expression (c_parser *parser)
>>  {
>>struct c_expr next;
>>tree lhsval;
>> -  location_t loc = c_parser_peek_token (parser)->location;
>>location_t expr_loc;
>>c_parser_consume_token (parser);
>>expr_loc = c_parser_peek_token (parser)->location;
>> @@ -7849,9 +7848,10 @@ c_parser_expression (c_parser *parser)
>>   mark_exp_read (lhsval);
>>next = c_parser_expr_no_commas (parser, NULL);
>>next = convert_lvalue_to_rvalue (expr_loc, next, true, false);
>> -  expr.value = build_compound_expr (loc, expr.value, next.value);
>> +  expr.value = build_compound_expr (tloc, expr.value, next.value);
>>expr.original_code = COMPOUND_EXPR;
>>expr.original_type = next.original_type;
>> +  tloc = expr_loc;
>>  }
>>return expr;
>>  }
>> Index: gcc/testsuite/gcc.dg/Wunused-value-4.c
>> ===
>> --- gcc/testsuite/gcc.dg/Wunused-value-4.c(revision 0)
>> +++ gcc/testsuite/gcc.dg/Wunused-value-4.c(working copy)
>> @@ -0,0 +1,12 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-Wunused-value" } */
>> +
>> +void foo(int x);
>> +
>> +int a[10];
>> +
>> +void f(void)
>> +{
>> +  foo ((1, 2));/* { dg-warning "9: left-hand operand of 
>> comma expression has no effect" } */
>> +  a[0x03, 004] = 1992; /* { dg-warning "5: left-hand operand of 
>> comma expression has no effect" } */
>> +}
>
> Marek

[Ada] Proper handling of Raise_Expression nodes in Ada 2012

[Arnaud Charlet]

A Raise_Expression is expected to be of any type, and can appear as a component
of any expression. This patch introduces a new type Raise_Type, that is the
initial type of such a node prior to full resolution. A Raise_Expression node
must eventually carry the type imposed by the context. If the type of the
context itself is Raise_Type this indicates that the expression is ambiguous
and must be rejected, as in (raise Constraint_Error) /= (raise Storage_Error).

Compiling raise_ambig.ads must yield:

raise_ambig.ads:2:17: cannot find unique type for raise expression
raise_ambig.ads:2:45: cannot find unique type for raise expression

---
package Raise_Ambig is
B : Boolean := (raise constraint_error) /= (raise storage_error);
end;
--

The following must compile quietly:

---
package CaseExprRaise is
   B : constant BOOLEAN :=
 (case false is
  when False => raise Constraint_Error,
  when True => raise Constraint_Error);

  X : Integer := (raise constraint_error) + (raise storage_error);
  Y : Integer := (raise constraint_error) + 1;
end;

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-02-20  Ed Schonberg  

* stand.ads: Raise_Type: new predefined entity, used as the type
of a Raise_Expression prior to resolution.
* cstand.adb: Build entity for Raise_Type.
* sem_ch11.adb (Analyze_Raise_Expression): use Raise_Type as the
initial type of the node.
* sem_type.adb (Covers): Raise_Type is compatible with all
other types.
* sem_res.adb (Resolve): Remove special handling of Any_Type on
Raise_Expression nodes.
(Resolve_Raise_Expression): Signal ambiguity if the type of the
context is still Raise_Type.

Index: sem_type.adb
===
--- sem_type.adb(revision 207879)
+++ sem_type.adb(working copy)
@@ -1128,6 +1128,11 @@
   elsif BT2 = Any_Type then
  return True;
 
+  --  A Raise_Expressions is legal in any expression context.
+
+  elsif BT2 = Raise_Type then
+ return True;
+
   --  A packed array type covers its corresponding non-packed type. This is
   --  not legitimate Ada, but allows the omission of a number of otherwise
   --  useless unchecked conversions, and since this can only arise in
Index: sem_res.adb
===
--- sem_res.adb (revision 207942)
+++ sem_res.adb (working copy)
@@ -2060,18 +2060,9 @@
  Analyze_Dimension (N);
  return;
 
-  --  A Raise_Expression takes its type from context. The Etype was set
-  --  to Any_Type, reflecting the fact that the expression itself does
-  --  not specify any possible interpretation. So we set the type to the
-  --  resolution type here and now. We need to do this before Resolve sees
-  --  the Any_Type value.
+  --  Any case of Any_Type as the Etype value means that we had a
+  --  previous error.
 
-  elsif Nkind (N) = N_Raise_Expression then
- Set_Etype (N, Typ);
-
-  --  Any other case of Any_Type as the Etype value means that we had
-  --  a previous error.
-
   elsif Etype (N) = Any_Type then
  Debug_A_Exit ("resolving  ", N, "  (done, Etype = Any_Type)");
  return;
@@ -7405,6 +7396,16 @@
   Check_Fully_Declared_Prefix (Typ, P);
   P_Typ := Empty;
 
+  --  A useful optimization:  check whether the dereference denotes an
+  --  element of a container, and if so rewrite it as a call to the
+  --  corresponding Element function.
+  --  Disabled for now, on advice of ARG. A more restricted form of the
+  --  predicate might be acceptable ???
+
+  --  if Is_Container_Element (N) then
+  -- return;
+  --  end if;
+
   if Is_Overloaded (P) then
 
  --  Use the context type to select the prefix that has the correct
@@ -8816,7 +8817,12 @@
 
procedure Resolve_Raise_Expression (N : Node_Id; Typ : Entity_Id) is
begin
-  Set_Etype (N, Typ);
+  if Typ = Raise_Type then
+ Error_Msg_N ("cannot find unique type for raise expression", N);
+ Set_Etype (N, Any_Type);
+  else
+ Set_Etype (N, Typ);
+  end if;
end Resolve_Raise_Expression;
 
---
Index: cstand.adb
===
--- cstand.adb  (revision 207879)
+++ cstand.adb  (working copy)
@@ -1321,6 +1321,13 @@
  Set_First_Index (Any_String, Index);
   end;
 
+  Raise_Type := New_Standard_Entity;
+  Decl := New_Node (N_Full_Type_Declaration, Stloc);
+  Set_Defining_Identifier (Decl, Raise_Type);
+  Set_Scope (Raise_Type, Standard_Standard);
+  Build_Signed_Integer_Type (Raise_Type, Standard_Integer_Size);
+  Make_Name (Raise_Type, "any type");
+
   Standard_Integer_8 := New_Standard_Entity;
   Decl := New_Node (N_Full_Type_Declaration, Stloc);
   Set

[Ada] Allow Object_Size that is a multiple of the alignment

[Arnaud Charlet]

For composite types, any object size should be allowed that is a multiple
of the alignment, but the front end was rejecting some cases. The following
should compile clean, giving the output shown for -gnatR2:

 1. package ObjSizeTest is
 2.type R is record
 3.   A : Integer;
 4.   B : Character;
 5.end record;
 6.for R'Object_Size use 40;
 7.for R'Size use 40;
 8.for R'Alignment use 1;
 9. end ObjSizeTest;

Representation information for unit Objsizetest (spec)

for R'Size use 40;
for R'Alignment use 1;
for R use record
   A at 0 range  0 .. 31;
   B at 4 range  0 ..  7;
end record;

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-02-20  Robert Dewar  

* sem_ch13.adb (Analyze_Attribute_Definition_Clause, case
Object_Size): For non-scalar types allow any value that is a
multiple of 8.
* gnat_rm.texi: Document Object_Size for composites more clearly.

Index: gnat_rm.texi
===
--- gnat_rm.texi(revision 207947)
+++ gnat_rm.texi(working copy)
@@ -8740,6 +8740,10 @@
 integer field, and so the default size of record objects for this type
 will be 64 (8 bytes).
 
+If the alignment of the above record is specified to be 1, then the
+object size will be 40 (5 bytes). This is true by default, and also
+an object size of 40 can be explicitly specified in this case.
+
 A consequence of this capability is that different object sizes can be
 given to subtypes that would otherwise be considered in Ada to be
 statically matching.  But it makes no sense to consider such subtypes
Index: sem_ch13.adb
===
--- sem_ch13.adb(revision 207948)
+++ sem_ch13.adb(working copy)
@@ -4413,17 +4413,17 @@
 else
Check_Size (Expr, U_Ent, Size, Biased);
 
-   if Size /= 8
-and then
-  Size /= 16
-and then
-  Size /= 32
-and then
-  UI_Mod (Size, 64) /= 0
-   then
-  Error_Msg_N
-("Object_Size must be 8, 16, 32, or multiple of 64",
- Expr);
+   if Is_Scalar_Type (U_Ent) then
+  if Size /= 8 and then Size /= 16 and then Size /= 32
+and then UI_Mod (Size, 64) /= 0
+  then
+ Error_Msg_N
+   ("Object_Size must be 8, 16, 32, or multiple of 64",
+Expr);
+  end if;
+
+   elsif Size mod 8 /= 0 then
+  Error_Msg_N ("Object_Size must be a multiple of 8", Expr);
end if;
 
Set_Esize (U_Ent, Size);

Re: [libjava] XFAIL sourcelocation (PR libgcj/55637)

[Rainer Orth]

Bryce McKinlay  writes:

> The fix for this is to have libjava use libbackttrace to get source
> line numbers, rather than rely on external addr2line.

I see.  Doesn't sound exactly like 4.9 material, though.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[Ada] Improve error messages on SPARK annotations

[Arnaud Charlet]

This patch updates the error diagnostics of various SPARK features to emit
clearer and more descriptive messages.


-- Source --


--  messages.ads

package Messages
  with SPARK_Mode => On
is
   A : Integer := 1;
   B : Integer := 2;

   procedure Error_1 (X : in Integer)
 with Depends => (X => +null);

   procedure Error_2 (X : out Integer)
 with Depends => (X => X);

   procedure Error_3 (X : in out Integer)
 with Depends => (X => null);

   procedure Error_4
 with Global  => (In_Out => A),
  Depends => ((A, B) => null);
end Messages;


-- Compilation and output --


$ gcc -c messages.ads
messages.ads:8:23: read-only parameter "X" cannot appear as output in
  dependence relation (SPARK RM 6.1.5(5))
messages.ads:11:28: write-only parameter "X" cannot appear as input in
  dependence relation (SPARK RM 6.1.5(6))
messages.ads:13:23: parameter "X" must appear in at least one input dependence
  list (SPARK RM 6.1.5(8))
messages.ads:17:33: global "A" must appear in at least one input dependence
  list (SPARK RM 6.1.5(8))
messages.ads:18:27: global "B" cannot appear in dependence relation
messages.ads:18:27: "B" is not part of the input or output set of subprogram
  "Error_4"

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-02-20  Hristian Kirtchev  

* sem_prag.adb (Add_Item_To_Name_Buffer): New routine.
(Analyze_Contract_Case): Remove the use of
"may". Replace "aspect Contract_Cases" to avoid categorization
of aspect vs pragma.
(Analyze_External_Property_In_Decl_Part): Remove the use of "formal".
(Analyze_Global_Item): Remove
the use of "formal", specify the subprogram.  Split the
error message about a state with visible refinement into
two. Remove the use of "global" from "volatile global item".
(Analyze_Initialization_Item): Ensure that the SPARK RM reference
is on one line.
(Analyze_Input_Output): Update the call to
Check_Mode. Specify the duplicated item. Reword the error
message concerning an input of a null output list. Use "\"
for error message continuation.
(Analyze_Part_Of): Remove
the use of "may". Use "\" for error message continuation.
(Analyze_Refined_Depends_In_Decl_Part): Update the error
message concerning a useless refinement to match the format
of Refined_Global.
(Analyze_Refined_Global_In_Decl_Part): Reword the error message
concerning a useless refinement.
(Analyze_Refinement_Clause): Use "\" for error message continuation.
(Check_Constituent_Usage): Use "\" for error message continuation.
(Check_Dependency_Clause): Use "\" for error message continuation.
(Check_Matching_Constituent): Use "\" for error message continuation.
(Check_Missing_Part_Of): Use "\" for error message continuation.
(Check_Mode): Renamed to
Check_Role. Update the comment on usage. Redo the error reporting
to use Role_Error.
(Check_Mode_Restriction_In_Enclosing_Context): Use "\" for error
message continuation.
(Find_Mode): Renamed to Find_Role. Update the parameter profile along
with comment on usage. Update all occurrences of Is_Input and Is_Output.
(Inconsistent_Mode_Error): Use "\" for error message continuation.
(Input_Match): Use "\" for error message continuation.
(Role_Error): New routine.
(Set_Convention_From_Pragma): Use "\" for error message continuation.
(Usage_Error): Add local variable Error_Msg. Build specialized error
message showcasing the offending item kind. Redo the diagnostics for
unconstrained types.

Index: sem_prag.adb
===
--- sem_prag.adb(revision 207948)
+++ sem_prag.adb(working copy)
@@ -399,7 +399,8 @@
 
 if Present (Extra_Guard) then
Error_Msg_N
- ("contract case may have only one case guard", Extra_Guard);
+ ("contract case must have exactly one case guard",
+  Extra_Guard);
 end if;
 
 --  Check the placement of "others" (if available)
@@ -407,7 +408,7 @@
 if Nkind (Case_Guard) = N_Others_Choice then
if Others_Seen then
   Error_Msg_N
-("only one others choice allowed in aspect Contract_Cases "
+("only one others choice allowed in contract cases "
  & "(SPARK RM 6.1.3(1))", Case_Guard);
else
   Others_Seen := True;
@@ -415,7 +416,7 @@
 
 elsif Others_Seen then
Error_Msg_N
- ("others must be the last choice in aspect Contract_Cases "
+ ("others must be the last choice in contract cases "
  

[Ada] gnatmake -s: no recompilation when adding some -gnate? switches

[Arnaud Charlet]

When gnatmake is invoked with -s and some additional compilation switches
(-gnateA, -gnateE, -gnateF, -gnateinn, -gnateu, -gnateV or -gnateY),
recompilation does not necessarily occur. This patch fix this.
The test is to invoke gnatmake with -s and one or these switches:
recompilation should occur.

Tested on x86_64-pc-linux-gnu, committed on trunk

2014-02-20  Vincent Celier  

* switch-m.adb (Normalize_Compiler_Switches): Take into account
switches that are recorded in ALI files: -gnateA, -gnateE,
-gnateF, -gnateinn, -gnateu, -gnateV and -gnateY.

Index: switch-m.adb
===
--- switch-m.adb(revision 207879)
+++ switch-m.adb(working copy)
@@ -310,6 +310,10 @@
  else
 case Switch_Chars (Ptr) is
 
+   when 'A' =>
+  Ptr := Ptr + 1;
+  Add_Switch_Component ("-gnateA");
+
when 'D' =>
   Storing (First_Stored + 1 ..
  First_Stored + Max - Ptr + 1) :=
@@ -319,16 +323,17 @@
First_Stored + Max - Ptr + 1));
   Ptr := Max + 1;
 
-   when 'G' =>
+   when 'E' | 'F' | 'G' | 'S' | 'u' | 'V' | 'Y' =>
+  Add_Switch_Component
+("-gnate" & Switch_Chars (Ptr));
   Ptr := Ptr + 1;
-  Add_Switch_Component ("-gnateG");
 
-   when 'I' =>
-  Ptr := Ptr + 1;
-
+   when 'i' | 'I' =>
   declare
- First : constant Positive := Ptr - 1;
+ First : constant Positive := Ptr;
   begin
+ Ptr := Ptr + 1;
+
  if Ptr <= Max and then
Switch_Chars (Ptr) = '='
  then
@@ -376,10 +381,6 @@
 
   return;
 
-   when 'S' =>
-  Ptr := Ptr + 1;
-  Add_Switch_Component ("-gnateS");
-
when others =>
   Last := 0;
   return;

Re: [S390] Fix scheduling performance regression from my shrink-wrap patches

[Andreas Krebbel]

On 19/02/14 16:35, Richard Sandiford wrote:
> gcc/
>   * config/s390/s390.c (s390_mainpool_start): Emit the main_pool
>   instruction at the start of the function if the base register is
>   call-clobbered.  Revert 2014-02-07 change.
>   (s390_early_mach): Don't initialize the base register here.
>   (s390_emit_prologue): Only initialize the base register if it
>   is call-saved.
>   (s300_extra_live_on_entry): New function.
>   (TARGET_EXTRA_LIVE_ON_ENTRY): Define.

Ok to apply. Thanks!

Bye,

-Andreas-

[PATCH] Fix latent bug in replace_uses_by

[Richard Biener]

The following fixes an ICE I got when building libjava with a local
patch.  This causes us to substitute &MEM[&a, 5] into MEM[_3, 0]
to MEM[&MEM[&a, 5], 0] and then asking stmt_ends_bb_p which doesn't
expect such bogus MEM_REFs.  The MEM_REF is canonicalized by
calling fold_stmt on it later, but the fix is of course to move
the marking of altered BBs before doing the actual substitution
(only then we are sure to catch all previous bb-ending stmts).

I also noticed we don't verify MEM_REFs on LHSs.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied
to trunk and branch (it's a regression uncovered by the fix for PR60115).

Richard.

2014-02-20  Richard Biener  

* tree-cfg.c (replace_uses_by): Mark altered BBs before
doing the substitution.
(verify_gimple_assign_single): Also verify bare MEM_REFs
on the lhs.

Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c  (revision 207936)
+++ gcc/tree-cfg.c  (working copy)
@@ -1677,6 +1677,11 @@ replace_uses_by (tree name, tree val)
 
   FOR_EACH_IMM_USE_STMT (stmt, imm_iter, name)
 {
+  /* Mark the block if we change the last stmt in it.  */
+  if (cfgcleanup_altered_bbs
+ && stmt_ends_bb_p (stmt))
+   bitmap_set_bit (cfgcleanup_altered_bbs, gimple_bb (stmt)->index);
+
   FOR_EACH_IMM_USE_ON_STMT (use, imm_iter)
 {
  replace_exp (use, val);
@@ -1701,11 +1706,6 @@ replace_uses_by (tree name, tree val)
  gimple orig_stmt = stmt;
  size_t i;
 
- /* Mark the block if we changed the last stmt in it.  */
- if (cfgcleanup_altered_bbs
- && stmt_ends_bb_p (stmt))
-   bitmap_set_bit (cfgcleanup_altered_bbs, gimple_bb (stmt)->index);
-
  /* FIXME.  It shouldn't be required to keep TREE_CONSTANT
 on ADDR_EXPRs up-to-date on GIMPLE.  Propagation will
 only change sth from non-invariant to invariant, and only
@@ -3986,7 +3986,9 @@ verify_gimple_assign_single (gimple stmt
   return true;
 }
 
-  if (handled_component_p (lhs))
+  if (handled_component_p (lhs)
+  || TREE_CODE (lhs) == MEM_REF
+  || TREE_CODE (lhs) == TARGET_MEM_REF)
 res |= verify_types_in_gimple_reference (lhs, true);
 
   /* Special codes we cannot handle via their class.  */

[PING^3] Re: [PATCH, AArch64] Fix Call Frame Information in ffi_closure_SYSV

[Yufeng Zhang]

Ping^3~~~

Is there a way in getting attention from libffi maintainers?  I really 
would like to see the patch made into gcc before the stage 4 closes.


Thanks,
Yufeng

On 02/12/14 18:08, Yufeng Zhang wrote:

Ping^2~~

Thanks,
Yufeng

On 01/14/14 12:10, Yufeng Zhang wrote:

Ping~

Originally posted it:
http://sourceware.org/ml/libffi-discuss/2013/msg00240.html

Thanks,
Yufeng

On 12/23/13 18:30, Yufeng Zhang wrote:

Hi,

This patch fixes a bug in ./src/aarch64/sysv.S:ffi_closure_SYSV where
stack unwinding information was not generated correctly.

OK for the mainline?

Thanks,
Yufeng

2013-12-23  Yufeng Zhang

* src/aarch64/sysv.S (ffi_closure_SYSV): Use x29 as the
main CFA reg; update cfi_rel_offset.

[patch c++]: Fix PR/58873 [4.7/4.8/4.9 Regression] [c++11] ICE with __underlying_type for broken enum

[Kai Tietz]

Hi,

Issue here is that the argument type gets NULL for function-call of
cp_parser_functional_cast.  This invalid type is the result of
cp_parser_simple_type_specifier call.

2014-02-20  Kai Tietz  

PR c++/58873
* parser.c (cp_parser_functional_cast): Treat NULL_TREE
valued type argument as error_mark_node.

Regression tested for x86_64-unknown-linux-gnu, and i686-w64-mingw32.
Ok for apply?

Regards,
Kai

Index: parser.c
===
--- parser.c(Revision 207953)
+++ parser.c(Arbeitskopie)
@@ -23165,6 +23165,9 @@ cp_parser_functional_cast (cp_parser* parser, tree
   tree cast;
   bool nonconst_p;

+  if (!type)
+type = error_mark_node;
+
   if (cp_lexer_next_token_is (parser->lexer, CPP_OPEN_BRACE))
 {
   maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);

Go patch committed: Avoid crash, fix *&x when x is not addressable

[Ian Lance Taylor]

This patch to the Go frontend avoids a compiler crash on invalid code.
It also fixes the case of *&x when x is not addressable--the expression
was being converted to x without checking, meaning that the compiler
would accept invalid code.  Finally, an error message is fixed to have
correct punctuation.  This is all from PR 60288.  Bootstrapped and ran
Go testsuite on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian

diff -r 638c5b3ab8cb go/expressions.cc
--- a/go/expressions.cc	Mon Feb 17 12:45:42 2014 -0800
+++ b/go/expressions.cc	Thu Feb 20 07:15:48 2014 -0800
@@ -3792,6 +3792,12 @@
 	  if (e == expr)
 		{
 		  // *&x == x.
+		  if (!ue->expr_->is_addressable() && !ue->create_temp_)
+		{
+		  error_at(ue->location(),
+			   "invalid operand for unary %<&%>");
+		  this->set_is_error();
+		}
 		  return ue->expr_;
 		}
 	  ue->set_does_not_escape();
@@ -3828,6 +3834,9 @@
 Unary_expression::do_flatten(Gogo* gogo, Named_object*,
  Statement_inserter* inserter)
 {
+  if (this->is_error_expression() || this->expr_->is_error_expression())
+return Expression::make_error(this->location());
+
   Location location = this->location();
   if (this->op_ == OPERATOR_MULT
   && !this->expr_->is_variable())
@@ -4167,7 +4176,10 @@
   if (!this->expr_->is_addressable())
 	{
 	  if (!this->create_temp_)
-	this->report_error(_("invalid operand for unary %<&%>"));
+	{
+	  error_at(this->location(), "invalid operand for unary %<&%>");
+	  this->set_is_error();
+	}
 	}
   else
 {

[PATCH][i386][AVX512] Match latest spec.

[Ilya Tocar]

Hi,
Latest version of AVX512 spec
http://download-software.intel.com/sites/default/files/managed/50/1a/319433-018.pdf
Has a few changes.
This patch fixes first of them:
Vptestnmd and vptestnmq instructions now have CPUID AVX512F instead of
AVX512CD. This path changes thier CPUID accordingly.
However I have a question about other changes:

1)PREFETCHWT1 instruction now has separate CPUID bit PREFETCHWT1.
We can either support new CPUID or disable PREFETCHWT1 from generating,
without removing code, and enable it in 4.9.1/latest version.
I am not sure that adding new -m flag and related stuff this late
is a good idea. Should still add it?

2)Currently for scatter/gather prefetches intrinsics we accept 1 as
possible hint parameter. This is consistent with ICC. However as
GCC defines _MM_HINT_T0 to 3 and not to 1 as ICC
(see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56603), gather prefethces
are inconsistent with normal prefetches as they won't accept _MM_HINT_T0 as
hint. We can either change gather prefetches to accept 1 instead of 3 and
hope that everyone will use _MM_HINT_T0 and not the raw value, or we can
change _MM_HINT_T0 to be consistent with ICC. What solution do you
prefer?

Patch bellow changes CPUID of vptestnmq/vptestnmd and changes some bogus
%v to v. Bootstraps, passes make check. Ok for trunk?

ChangeLog

2014-02-20  Ilya Tocar  
 
* config/i386/avx512fintrin.h (_mm512_testn_epi32_mask),
(_mm512_mask_testn_epi32_mask), (_mm512_testn_epi64_mask),
(_mm512_mask_testn_epi64_mask): Move to ...
* config/i386/avx512cdintrin.h: Here.
* config/i386/i386.c (bdesc_args): Change MASK_ISA for testnm.
* config/i386/sse.md (avx512f_vmscalef): Remove %.
(avx512f_scalef): Ditto.
(avx512f_testnm3): Change conditon to
TARGET_AVX512F from TARGET_AVX512CD.

And for testsuite

2014-02-20  Ilya Tocar  
 
* gcc.target/i386/avx512cd-vptestnmd-1.c: Change into ...
* gcc.target/i386/avx512f-vptestnmd-1.c: This.
* gcc.target/i386/avx512cd-vptestnmq-1.c: Change into ...
* gcc.target/i386/avx512f-vptestnmq-1.c: This.
* gcc.target/i386/avx512cd-vptestnmd-2.c: Change into ...
* gcc.target/i386/avx512f-vptestnmd-2.c: This.
* gcc.target/i386/avx512cd-vptestnmq-2.c: Change into ...
* gcc.target/i386/avx512f-vptestnmq-2.c: This.


---
 gcc/config/i386/avx512cdintrin.h   | 34 --
 gcc/config/i386/avx512fintrin.h| 34 ++
 gcc/config/i386/i386.c |  4 +-
 gcc/config/i386/sse.md |  8 ++--
 .../gcc.target/i386/avx512cd-vptestnmd-1.c | 16 ---
 .../gcc.target/i386/avx512cd-vptestnmd-2.c | 52 --
 .../gcc.target/i386/avx512cd-vptestnmq-1.c | 16 ---
 .../gcc.target/i386/avx512cd-vptestnmq-2.c | 52 --
 .../gcc.target/i386/avx512f-vptestnmd-1.c  | 16 +++
 .../gcc.target/i386/avx512f-vptestnmd-2.c  | 52 ++
 .../gcc.target/i386/avx512f-vptestnmq-1.c  | 16 +++
 .../gcc.target/i386/avx512f-vptestnmq-2.c  | 52 ++
 12 files changed, 176 insertions(+), 176 deletions(-)
 delete mode 100644 gcc/testsuite/gcc.target/i386/avx512cd-vptestnmd-1.c
 delete mode 100644 gcc/testsuite/gcc.target/i386/avx512cd-vptestnmd-2.c
 delete mode 100644 gcc/testsuite/gcc.target/i386/avx512cd-vptestnmq-1.c
 delete mode 100644 gcc/testsuite/gcc.target/i386/avx512cd-vptestnmq-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/avx512f-vptestnmd-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/avx512f-vptestnmd-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/avx512f-vptestnmq-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/avx512f-vptestnmq-2.c

diff --git a/gcc/config/i386/avx512cdintrin.h b/gcc/config/i386/avx512cdintrin.h
index 3935b77..a4939f7a 100644
--- a/gcc/config/i386/avx512cdintrin.h
+++ b/gcc/config/i386/avx512cdintrin.h
@@ -176,40 +176,6 @@ _mm512_broadcastmw_epi32 (__mmask16 __A)
   return (__m512i) __builtin_ia32_broadcastmw512 (__A);
 }
 
-extern __inline __mmask16
-__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm512_testn_epi32_mask (__m512i __A, __m512i __B)
-{
-  return (__mmask16) __builtin_ia32_ptestnmd512 ((__v16si) __A,
-(__v16si) __B,
-(__mmask16) -1);
-}
-
-extern __inline __mmask16
-__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm512_mask_testn_epi32_mask (__mmask16 __U, __m512i __A, __m512i __B)
-{
-  return (__mmask16) __builtin_ia32_ptestnmd512 ((__v16si) __A,
-(__v16si) __B, __U);
-}
-
-extern __inline __mmask8
-__attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
-_mm512_testn_epi64_mask (__m512i __A, __m512i __B)
-{
-  

Re: [patch c++]: Fix PR/58873 [4.7/4.8/4.9 Regression] [c++11] ICE with __underlying_type for broken enum

[Jason Merrill]

OK.

Jason

Re: [PATCH] Fix PR c++/60065.

[Jason Merrill]

On 02/19/2014 10:00 PM, Adam Butcher wrote:

+  if (current_template_parms)
+{
+  cp_binding_level *maybe_tmpl_scope = current_binding_level->level_chain;
+  while (maybe_tmpl_scope && maybe_tmpl_scope->kind == sk_class)
+   maybe_tmpl_scope = maybe_tmpl_scope->level_chain;
+  if (maybe_tmpl_scope && maybe_tmpl_scope->kind == sk_template_parms)
+   declaring_template_p = true;
+}


Won't this return true for a member function of a class template?  i.e.

template 
struct A {
  void f(auto x);
};

Why doesn't num_template_parameter_lists work as a predicate here?

Jason

Re: [PATCH][i386][AVX512] Match latest spec.

[Uros Bizjak]

On Thu, Feb 20, 2014 at 4:39 PM, Ilya Tocar  wrote:

> Latest version of AVX512 spec
> http://download-software.intel.com/sites/default/files/managed/50/1a/319433-018.pdf
> Has a few changes.
> This patch fixes first of them:
> Vptestnmd and vptestnmq instructions now have CPUID AVX512F instead of
> AVX512CD. This path changes thier CPUID accordingly.
> However I have a question about other changes:
>
> 1)PREFETCHWT1 instruction now has separate CPUID bit PREFETCHWT1.
> We can either support new CPUID or disable PREFETCHWT1 from generating,
> without removing code, and enable it in 4.9.1/latest version.
> I am not sure that adding new -m flag and related stuff this late
> is a good idea. Should still add it?

Please submit the patch anyway. We can relax release constraints on
non-algorithmic patch a bit, weighting in benefits of having gcc
release that fully conforms to some published specification.

> 2)Currently for scatter/gather prefetches intrinsics we accept 1 as
> possible hint parameter. This is consistent with ICC. However as
> GCC defines _MM_HINT_T0 to 3 and not to 1 as ICC
> (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56603), gather prefethces
> are inconsistent with normal prefetches as they won't accept _MM_HINT_T0 as
> hint. We can either change gather prefetches to accept 1 instead of 3 and
> hope that everyone will use _MM_HINT_T0 and not the raw value, or we can
> change _MM_HINT_T0 to be consistent with ICC. What solution do you
> prefer?

Builtins, including __builtin_prefetch, are considered as internal
implementation detail, so we can pass to them wharever we like. The
published interface is in *.h files, and this includes _MM_HINT_T0.
For now, I suggest to change prefetches, so they will accept
_MM_HINT_T0, as this is the least invasive change.

FWIW, we can change _MM_HINT_T0 in the future, as intrinsic headers
correspond to the compiler, but it will raise maintenance burden (you
can't just recompile sources involving builtins with different
versions of the compiler anymore due to difference in constant
arguments).

> Patch bellow changes CPUID of vptestnmq/vptestnmd and changes some bogus
> %v to v. Bootstraps, passes make check. Ok for trunk?
>
> ChangeLog
>
> 2014-02-20  Ilya Tocar  
>
> * config/i386/avx512fintrin.h (_mm512_testn_epi32_mask),
> (_mm512_mask_testn_epi32_mask), (_mm512_testn_epi64_mask),
> (_mm512_mask_testn_epi64_mask): Move to ...
> * config/i386/avx512cdintrin.h: Here.
> * config/i386/i386.c (bdesc_args): Change MASK_ISA for testnm.
> * config/i386/sse.md (avx512f_vmscalef): Remove %.
> (avx512f_scalef): Ditto.
> (avx512f_testnm3): Change conditon to
> TARGET_AVX512F from TARGET_AVX512CD.
>
> And for testsuite
>
> 2014-02-20  Ilya Tocar  
>
> * gcc.target/i386/avx512cd-vptestnmd-1.c: Change into ...
> * gcc.target/i386/avx512f-vptestnmd-1.c: This.
> * gcc.target/i386/avx512cd-vptestnmq-1.c: Change into ...
> * gcc.target/i386/avx512f-vptestnmq-1.c: This.
> * gcc.target/i386/avx512cd-vptestnmd-2.c: Change into ...
> * gcc.target/i386/avx512f-vptestnmd-2.c: This.
> * gcc.target/i386/avx512cd-vptestnmq-2.c: Change into ...
> * gcc.target/i386/avx512f-vptestnmq-2.c: This.

This is OK for mainline.

Thanks,
Uros.

[PATCH, nios2] Large -fPIC support

[Chung-Lin Tang]

This patch adds large GOT support for the Nios II backend. Tested by
running glibc tests with -fPIC forced on.  A few smaller libgcc fixes
are also included as well. Patch committed.

Chung-Lin

2014-02-20  Chung-Lin Tang  
Sandra Loosemore  

gcc/
* config/nios2/nios2.md (unspec): Add UNSPEC_PIC_GOTOFF_SYM enum.
* config/nios2/nios2.c (nios2_function_profiler):
Add -fPIC (flag_pic == 2) support.
(nios2_handle_custom_fpu_cfg): Fix warning parameter.
(nios2_large_offset_p): New function.
(nios2_unspec_reloc_p): Move up position, update to use
nios2_large_offset_p.
(nios2_unspec_address): Remove function.
(nios2_unspec_offset): New function.
(nios2_large_got_address): New function.
(nios2_got_address): Add large offset support.
(nios2_legitimize_tls_address): Update usage of removed and new
functions.
(nios2_symbol_binds_local_p): New function.
(nios2_load_pic_address): Add -fPIC (flag_pic == 2) support.
(nios2_legitimize_address): Update to use nios2_large_offset_p.
(nios2_emit_move_sequence): Avoid legitimizing (const (unspec ...)).
(nios2_print_operand): Merge H/L processing, add hiadj/lo
processing for (const (unspec ...)).
(nios2_unspec_reloc_name): Add UNSPEC_PIC_GOTOFF_SYM case.

gcc/testsuite/
* gcc.target/nios2/biggot-1.c: New.
* gcc.target/nios2/biggot-2.c: New.

libgcc/
* config/nios2/t-nios2 (CRTSTUFF_T_CFLAGS): Add -mno-gpopt.
* config/nios2/crti.S: Remove .file directive.
* config/nios2/crtn.S: Likewise.
Index: gcc/config/nios2/nios2.c
===
--- gcc/config/nios2/nios2.c	(revision 207964)
+++ gcc/config/nios2/nios2.c	(working copy)
@@ -664,7 +664,7 @@ void
 nios2_function_profiler (FILE *file, int labelno ATTRIBUTE_UNUSED)
 {
   fprintf (file, "\tmov\tr8, ra\n");
-  if (flag_pic)
+  if (flag_pic == 1)
 {
   fprintf (file, "\tnextpc\tr2\n");
   fprintf (file, "\t1: movhi\tr3, %%hiadj(_gp_got - 1b)\n");
@@ -673,6 +673,18 @@ nios2_function_profiler (FILE *file, int labelno A
   fprintf (file, "\tldw\tr2, %%call(_mcount)(r2)\n");
   fprintf (file, "\tcallr\tr2\n");
 }
+  else if (flag_pic == 2)
+{
+  fprintf (file, "\tnextpc\tr2\n");
+  fprintf (file, "\t1: movhi\tr3, %%hiadj(_gp_got - 1b)\n");
+  fprintf (file, "\taddi\tr3, r3, %%lo(_gp_got - 1b)\n");
+  fprintf (file, "\tadd\tr2, r2, r3\n");
+  fprintf (file, "\tmovhi\tr3, %%call_hiadj(_mcount)\n");
+  fprintf (file, "\taddi\tr3, %%call_lo(_mcount)\n");
+  fprintf (file, "\tadd\tr3, r2, r3\n");
+  fprintf (file, "\tldw\tr2, 0(r3)\n");
+  fprintf (file, "\tcallr\tr2\n");
+}
   else
 fprintf (file, "\tcall\t_mcount\n");
   fprintf (file, "\tmov\tra, r8\n");
@@ -920,7 +932,7 @@ nios2_handle_custom_fpu_cfg (const char *cfgname,
 }
   else
 warning (0, "ignoring unrecognized switch %<-mcustom-fpu-cfg%> "
-	 "value %<%s%>", cfg);
+	 "value %<%s%>", cfgname);
 
   /* Guard against errors in the standard configurations.  */
   nios2_custom_check_insns ();
@@ -1116,20 +1128,64 @@ nios2_call_tls_get_addr (rtx ti)
   return ret;
 }
 
+/* Return true for large offsets requiring hiadj/lo relocation pairs.  */
+static bool
+nios2_large_offset_p (int unspec)
+{
+  gcc_assert (nios2_unspec_reloc_name (unspec) != NULL);
+
+  if (flag_pic == 2
+  /* FIXME: TLS GOT offset relocations will eventually also get this
+	 treatment, after binutils support for those are also completed.  */
+  && (unspec == UNSPEC_PIC_SYM || unspec == UNSPEC_PIC_CALL_SYM))
+return true;
+
+  /* 'gotoff' offsets are always hiadj/lo.  */
+  if (unspec == UNSPEC_PIC_GOTOFF_SYM)
+return true;
+
+  return false;
+}
+
+/* Return true for conforming unspec relocations.  Also used in
+   constraints.md and predicates.md.  */
+bool
+nios2_unspec_reloc_p (rtx op)
+{
+  return (GET_CODE (op) == CONST
+	  && GET_CODE (XEXP (op, 0)) == UNSPEC
+	  && ! nios2_large_offset_p (XINT (XEXP (op, 0), 1)));
+}
+
+/* Helper to generate unspec constant.  */
 static rtx
-nios2_unspec_address (rtx loc, rtx base_reg, int unspec)
+nios2_unspec_offset (rtx loc, int unspec)
 {
-  rtx unspec_offset =
-gen_rtx_CONST (Pmode, gen_rtx_UNSPEC (Pmode, gen_rtvec (1, loc),
-	  unspec));
-  return gen_rtx_PLUS (Pmode, base_reg, unspec_offset);
+  return gen_rtx_CONST (Pmode, gen_rtx_UNSPEC (Pmode, gen_rtvec (1, loc),
+	   unspec));
 }
 
+/* Generate GOT pointer based address with large offset.  */
 static rtx
+nios2_large_got_address (rtx sym, rtx offset)
+{
+  rtx addr = gen_reg_rtx (Pmode);
+  emit_insn (gen_add3_insn (addr, pic_offset_table_rtx,
+			force_reg (Pmode, offset)));
+  return addr;
+}
+
+/* Generate a GOT pointer based address.  */
+static rtx
 nios2_got_address (rtx loc, int unspec)
 {
+  rtx off

Re: [patch c++]: Fix PR/58873 [4.7/4.8/4.9 Regression] [c++11] ICE with __underlying_type for broken enum

[Jakub Jelinek]

On Thu, Feb 20, 2014 at 10:27:18AM -0500, Jason Merrill wrote:
> OK.

Please include the testcase from the PR into the testsuite though.

Jakub

[PATCH] Fix c++/60272

[Richard Henderson]

As described in the PR, we were performing an unconditional store back to the
EXPECT parameter.  This is fine, so long as EXPECT is not in thread shared
memory, e.g. a local variable.  But the example in the PR uses shared memory
where the extra store introduces a race condition.

I've left a note in the code about fixing this conditional store once we have
amacleod's gimple atomic stuff committed, where we'd be able to tell (at some
point in during optimization) if EXPECT is local, e.g. an SSA_NAME.

Tested on x86_64 and i686, and manually inspecting the generated code.
Any ideas how to regression test this?


r~
gcc/
* builtins.c (expand_builtin_atomic_compare_exchange): Conditionalize
on failure the store back into EXPECT.
libatomic/
* cas_n.c (libat_compare_exchange): Conditionalize on failure
the store back to EPTR.


diff --git a/gcc/builtins.c b/gcc/builtins.c
index f5f55bf..09fefe50 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -5292,7 +5292,7 @@ static rtx
 expand_builtin_atomic_compare_exchange (enum machine_mode mode, tree exp, 
rtx target)
 {
-  rtx expect, desired, mem, oldval;
+  rtx expect, desired, mem, oldval, label;
   enum memmodel success, failure;
   tree weak;
   bool is_weak;
@@ -5330,14 +5330,23 @@ expand_builtin_atomic_compare_exchange (enum 
machine_mode mode, tree exp,
   if (tree_fits_shwi_p (weak) && tree_to_shwi (weak) != 0)
 is_weak = true;
 
+  if (target == const0_rtx)
+target = NULL;
   oldval = expect;
-  if (!expand_atomic_compare_and_swap ((target == const0_rtx ? NULL : &target),
-  &oldval, mem, oldval, desired,
+
+  if (!expand_atomic_compare_and_swap (&target, &oldval, mem, oldval, desired,
   is_weak, success, failure))
 return NULL_RTX;
 
-  if (oldval != expect)
-emit_move_insn (expect, oldval);
+  /* Conditionally store back to EXPECT, lest we create a race condition
+ with an improper store to memory.  */
+  /* ??? With a rearrangement of atomics at the gimple level, we can handle
+ the normal case where EXPECT is totally private, i.e. a register.  At
+ which point the store can be unconditional.  */
+  label = gen_label_rtx ();
+  emit_cmp_and_jump_insns (target, const0_rtx, NE, NULL, VOIDmode, 1, label);
+  emit_move_insn (expect, oldval);
+  emit_label (label);
 
   return target;
 }
diff --git a/libatomic/cas_n.c b/libatomic/cas_n.c
index 39c7833..801262d 100644
--- a/libatomic/cas_n.c
+++ b/libatomic/cas_n.c
@@ -51,10 +51,9 @@ SIZE(libat_compare_exchange) (UTYPE *mptr, UTYPE *eptr, 
UTYPE newval,
 #if !DONE && N <= WORDSIZE && defined(atomic_compare_exchange_w)
 bool
 SIZE(libat_compare_exchange) (UTYPE *mptr, UTYPE *eptr, UTYPE newval,
- int smodel, int fmodel UNUSED)
+ int smodel, int fmodel)
 {
   UWORD mask, shift, weval, woldval, wnewval, t, *wptr;
-  bool ret = false;
 
   pre_barrier (smodel);
 
@@ -82,12 +81,13 @@ SIZE(libat_compare_exchange) (UTYPE *mptr, UTYPE *eptr, 
UTYPE newval,
 }
   while (!atomic_compare_exchange_w (wptr, &woldval, t, true,
 __ATOMIC_RELAXED, __ATOMIC_RELAXED));
-  ret = true;
+  post_barrier (smodel);
+  return true;
+
  failure:
   *eptr = woldval >> shift;
-
-  post_barrier (smodel);
-  return ret;
+  post_barrier (fmodel);
+  return false;
 }
 
 #define DONE 1
@@ -102,18 +102,17 @@ SIZE(libat_compare_exchange) (UTYPE *mptr, UTYPE *eptr, 
UTYPE newval,
 {
   UTYPE oldval;
   UWORD magic;
-  bool ret = false;
+  bool ret;
 
   pre_seq_barrier (smodel);
   magic = protect_start (mptr);
 
   oldval = *mptr;
-  if (oldval == *eptr)
-{
-  *mptr = newval;
-  ret = true;
-}
-  *eptr = oldval;
+  ret = (oldval == *eptr);
+  if (ret)
+*mptr = newval;
+  else
+*eptr = oldval;
 
   protect_end (mptr, magic);
   post_seq_barrier (smodel);

Re: [Patch, Fortran] PR602864 - fix INQUIRE for write= with stdout/stdin/stderr

[Janus Weil]

Hi Tobias,

> A rather simple patch.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?

the patch looks pretty much trivial, int the sense that you just
hard-wire the expected values for the std* units as a special case. I
wonder why the 'inquire_read' and 'inquire_write' functions don't
actually return the correct values?

Cheers,
Janus

Re: [PATCH] Fix c++/60272

[Jakub Jelinek]

On Thu, Feb 20, 2014 at 11:49:30AM -0600, Richard Henderson wrote:
> Tested on x86_64 and i686, and manually inspecting the generated code.
> Any ideas how to regression test this?

No idea about how to test this.

> @@ -5330,14 +5330,23 @@ expand_builtin_atomic_compare_exchange (enum 
> machine_mode mode, tree exp,
>if (tree_fits_shwi_p (weak) && tree_to_shwi (weak) != 0)
>  is_weak = true;
>  
> +  if (target == const0_rtx)
> +target = NULL;
>oldval = expect;
> -  if (!expand_atomic_compare_and_swap ((target == const0_rtx ? NULL : 
> &target),
> -&oldval, mem, oldval, desired,
> +
> +  if (!expand_atomic_compare_and_swap (&target, &oldval, mem, oldval, 
> desired,

I'm wondering if this shouldn't be instead:
  oldval = NULL;
  if (!expand_atomic_compare_and_swap (&target, &oldval, mem, expected, desired,
   is_weak, success, failure))

because otherwise expand_atomic_compare_and_swap could in theory already
store into expect MEM, couldn't it?  I mean, it does:
  /* Load expected into a register for the compare and swap.  */
  if (MEM_P (expected))
expected = copy_to_reg (expected);

  /* Make sure we always have some place to put the return oldval.
 Further, make sure that place is distinct from the input expected,
 just in case we need that path down below.  */
  if (ptarget_oval == NULL
  || (target_oval = *ptarget_oval) == NULL
  || reg_overlap_mentioned_p (expected, target_oval))
target_oval = gen_reg_rtx (mode);
so with NULL *ptarget_oval it will surely allocate a pseudo, but if it is
the expected MEM, as expected has been forced into register earlier,
I don't think it overlaps with that REG and thus it can be already stored
and have oldval == expect after the call.

Jakub

Re: [PATCH] Fix PR c++/60052.

[Jason Merrill]

OK.

Jason

Re: [Patch, Fortran] PR60286 - fix INQUIRE for write= with stdout/stdin/stderr

[Tobias Burnus]

Hi Janus,

On Thu, Feb 20, 2014 at 06:51:30PM +0100, Janus Weil wrote:
> > Build and regtested on x86-64-gnu-linux.
> > OK for the trunk?
> 
> the patch looks pretty much trivial, int the sense that you just
> hard-wire the expected values for the std* units as a special case. I
> wonder why the 'inquire_read' and 'inquire_write' functions don't
> actually return the correct values?

One can inquire by FILE= name and by UNIT=; inquire_read() is using
the file name - either via FILE= directly or for an opened unit
via u->file; it then calls POSIX's access() function on the file name
to determine the permissions. Obviously, that fails if no file
actually exists.

Thus, simply calling the function won't work - and as all three cases
are slightly different, hardcoding the condition is simplest.


However, I now wonder whether one should also take care of other cases,
where no file name exists - but which could be queried. In that case,
one could simply use the mode in which the file was opened - which
one could do in general for files in the UNIT= mode - contrary to
the FILE= mode. I am in particular thinking of scratch files - they
are often opened, then deleted and only file descriptor remains.


Namely, either unconditionally using for UNIT=:

if ((cf & IOPARM_INQUIRE_HAS_READWRITE) != 0)
  p = (u->flags.action == ACTION_READWRITE) ? yes : no;

We probably still need some special case for stdin/stdout/stderr.


Or adding as additional condition:
  if (u->flags->status == STATUS_SCRATCH)
p = (u->flags.action == ACTION_READWRITE) ? yes : no;
to also handle SCRATCH correctly.


* Advantage of access(): Gives the true file mode by the OS.
* Advantage of the open mode: Gives the permissions for which the
unit was opened. Also works in corner cases (scratch, stdout, ...).
Simpler code.

I have no idea what users prefer - but when using the unit directly,
the OPEN's ACCTION= mode feels a bit more natural than access().

Thoughts?

What about the new version of the patch?
It was built and regtested on x86-64-gnu-linux.

Tobias

PS: I also fixed the PR number - thanks Uros!
2014-02-20  Tobias Burnus  

	PR fortran/60286
	* libgfortran/io/inquire.c (yes, no): New static const char vars.
	(inquire_via_unit): Use them. Use OPEN mode instead of using
	POSIX's access to query about write=, read= and readwrite=.

2014-02-20  Tobias Burnus  

	PR fortran/60286
	* gfortran.dg/inquire_16.f90: New.

diff --git a/gcc/testsuite/gfortran.dg/inquire_16.f90 b/gcc/testsuite/gfortran.dg/inquire_16.f90
new file mode 100644
index 000..03b735e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/inquire_16.f90
@@ -0,0 +1,29 @@
+! { dg-do run }
+!
+! PR fortran/60286
+!
+! Contributed by  Alexander Vogt
+!
+program test_inquire
+  use, intrinsic :: ISO_Fortran_env
+  implicit none
+  character(len=20) :: s_read, s_write, s_readwrite
+
+  inquire(unit=input_unit, read=s_read, write=s_write, &
+  readwrite=s_readwrite)
+  if (s_read /= "YES" .or. s_write /= "NO" .or. s_readwrite /="NO") then
+call abort()
+  endif
+
+  inquire(unit=output_unit, read=s_read, write=s_write, &
+  readwrite=s_readwrite)
+  if (s_read /= "NO" .or. s_write /= "YES" .or. s_readwrite /="NO") then
+call abort()
+  endif
+
+  inquire(unit=error_unit, read=s_read, write=s_write, &
+  readwrite=s_readwrite)
+  if (s_read /= "NO" .or. s_write /= "YES" .or. s_readwrite /="NO") then
+call abort()
+  endif
+end program test_inquire
diff --git a/libgfortran/io/inquire.c b/libgfortran/io/inquire.c
index b12ee51..6801d01 100644
--- a/libgfortran/io/inquire.c
+++ b/libgfortran/io/inquire.c
@@ -30,7 +30,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #include 
 
 
-static const char undefined[] = "UNDEFINED";
+static const char yes[] = "YES", no[] = "NO", undefined[] = "UNDEFINED";
 
 
 /* inquire_via_unit()-- Inquiry via unit number.  The unit might not exist. */
@@ -130,10 +130,10 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
 	  {
 	  case ACCESS_DIRECT:
 	  case ACCESS_STREAM:
-	p = "NO";
+	p = no;
 	break;
 	  case ACCESS_SEQUENTIAL:
-	p = "YES";
+	p = yes;
 	break;
 	  default:
 	internal_error (&iqp->common, "inquire_via_unit(): Bad access");
@@ -151,10 +151,10 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
 	  {
 	  case ACCESS_SEQUENTIAL:
 	  case ACCESS_STREAM:
-	p = "NO";
+	p = no;
 	break;
 	  case ACCESS_DIRECT:
-	p = "YES";
+	p = yes;
 	break;
 	  default:
 	internal_error (&iqp->common, "inquire_via_unit(): Bad access");
@@ -191,10 +191,10 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit * u)
 	switch (u->flags.form)
 	  {
 	  case FORM_FORMATTED:
-	p = "YES";
+	p = yes;
 	break;
 	  case FORM_UNFORMATTED:
-	p = "NO";
+	p = no;
 	break;
 	  default:
 	internal_error (&iqp->common, "inquire_via_unit(): Bad form");
@@ -211,10 +211,10 @@ inquire_via_unit (st_parameter_inquire *iq

[PATCH] Fix ix86_vectorize_vec_perm_const_ok (PR target/57896)

[Jakub Jelinek]

Hi!

As discussed in the PR, gen_reg_rtx from when init_emit has not been
initialized is highly undesirable.  The following patch makes sure that
for d->testing_p we never call gen_reg_rtx (i.e. from within
ix86_vectorize_vec_perm_const_ok) and never try to emit insns.

Bootstrapped/regtested on x86_64-linux and i686-linux (together with Uros'
patch to assert that gen_reg_rtx is not called when init_emit is not
active) with RTL checking, further tested with
GCC_TEST_RUN_EXPENSIVE=1 make -j16 -k check 
RUNTESTFLAGS='--target_board=unix\{-msse2,-msse3,-mssse3,-msse4,-mavx,-mavx2,-mavx512f\}
 dg-torture.exp=*vshuf*'
(on AVX HW, so -mavx2 and -mavx512f tests expectedly failed execution,
but at least didn't fail compilation, with the exception of
gcc.dg/torture/vshuf-v8sf.c which ICEs with -mavx2 -DEXPENSIVE, but
both without this patch and with this patch - will look at it eventually).

Ok for trunk (and the attached patch for 4.8 branch where Uros has tested
it)?

2014-02-20  Jakub Jelinek  

PR target/57896
* config/i386/i386.c (expand_vec_perm_interleave2): Don't call
gen_reg_rtx if d->testing_p.
(expand_vec_perm_pshufb2, expand_vec_perm_broadcast_1): Return early
if d->testing_p and we will certainly return true.
(expand_vec_perm_even_odd_1): Likewise.  Don't call gen_reg_rtx
if d->testing_p.

--- gcc/config/i386/i386.c.jj   2014-02-19 19:11:03.600211257 +0100
+++ gcc/config/i386/i386.c  2014-02-20 12:57:30.857266155 +0100
@@ -43411,8 +43411,11 @@ expand_vec_perm_interleave2 (struct expa
   else
dfinal.perm[i] = e;
 }
-  dremap.target = gen_reg_rtx (dremap.vmode);
-  dfinal.op0 = gen_lowpart (dfinal.vmode, dremap.target);
+  if (!d->testing_p)
+{
+  dremap.target = gen_reg_rtx (dremap.vmode);
+  dfinal.op0 = gen_lowpart (dfinal.vmode, dremap.target);
+}
   dfinal.op1 = dfinal.op0;
   dfinal.one_operand_p = true;
 
@@ -43845,6 +43848,9 @@ expand_vec_perm_pshufb2 (struct expand_v
 return false;
   gcc_assert (!d->one_operand_p);
 
+  if (d->testing_p)
+return true;
+
   nelt = d->nelt;
   eltsz = GET_MODE_SIZE (GET_MODE_INNER (d->vmode));
 
@@ -44053,6 +44059,8 @@ expand_vec_perm_even_odd_1 (struct expan
   switch (d->vmode)
 {
 case V4DFmode:
+  if (d->testing_p)
+   break;
   t1 = gen_reg_rtx (V4DFmode);
   t2 = gen_reg_rtx (V4DFmode);
 
@@ -44072,6 +44080,8 @@ expand_vec_perm_even_odd_1 (struct expan
   {
int mask = odd ? 0xdd : 0x88;
 
+   if (d->testing_p)
+ break;
t1 = gen_reg_rtx (V8SFmode);
t2 = gen_reg_rtx (V8SFmode);
t3 = gen_reg_rtx (V8SFmode);
@@ -44113,6 +44123,8 @@ expand_vec_perm_even_odd_1 (struct expan
return expand_vec_perm_pshufb2 (d);
   else
{
+ if (d->testing_p)
+   break;
  /* We need 2*log2(N)-1 operations to achieve odd/even
 with interleave. */
  t1 = gen_reg_rtx (V8HImode);
@@ -44134,6 +44146,8 @@ expand_vec_perm_even_odd_1 (struct expan
return expand_vec_perm_pshufb2 (d);
   else
{
+ if (d->testing_p)
+   break;
  t1 = gen_reg_rtx (V16QImode);
  t2 = gen_reg_rtx (V16QImode);
  t3 = gen_reg_rtx (V16QImode);
@@ -44160,7 +44174,10 @@ expand_vec_perm_even_odd_1 (struct expan
{
  struct expand_vec_perm_d d_copy = *d;
  d_copy.vmode = V4DFmode;
- d_copy.target = gen_reg_rtx (V4DFmode);
+ if (d->testing_p)
+   d_copy.target = gen_lowpart (V4DFmode, d->target);
+ else
+   d_copy.target = gen_reg_rtx (V4DFmode);
  d_copy.op0 = gen_lowpart (V4DFmode, d->op0);
  d_copy.op1 = gen_lowpart (V4DFmode, d->op1);
  if (expand_vec_perm_even_odd_1 (&d_copy, odd))
@@ -44173,6 +44190,9 @@ expand_vec_perm_even_odd_1 (struct expan
  return false;
}
 
+  if (d->testing_p)
+   break;
+
   t1 = gen_reg_rtx (V4DImode);
   t2 = gen_reg_rtx (V4DImode);
 
@@ -44193,7 +44213,10 @@ expand_vec_perm_even_odd_1 (struct expan
{
  struct expand_vec_perm_d d_copy = *d;
  d_copy.vmode = V8SFmode;
- d_copy.target = gen_reg_rtx (V8SFmode);
+ if (d->testing_p)
+   d_copy.target = gen_lowpart (V8SFmode, d->target);
+ else
+   d_copy.target = gen_reg_rtx (V8SFmode);
  d_copy.op0 = gen_lowpart (V8SFmode, d->op0);
  d_copy.op1 = gen_lowpart (V8SFmode, d->op1);
  if (expand_vec_perm_even_odd_1 (&d_copy, odd))
@@ -44206,6 +44229,9 @@ expand_vec_perm_even_odd_1 (struct expan
  return false;
}
 
+  if (d->testing_p)
+   break;
+
   t1 = gen_reg_rtx (V8SImode);
   t2 = gen_reg_rtx (V8SImode);
   t3 = gen_reg_rtx (V4DImode);
@@ -44298,6 +44324,8 @@ expand_vec_perm_broadcast_1 (struct expa
 case V16QImode:
   /* These can be implemented via interleave.  We save one insn by
 stopping once 

Re: c-parser.c replace error() by error_at()

[Joseph S. Myers]

On Thu, 20 Feb 2014, Prathamesh Kulkarni wrote:

> On Wed, Feb 19, 2014 at 11:32 PM, Joseph S. Myers
>  wrote:
> > On Wed, 19 Feb 2014, Prathamesh Kulkarni wrote:
> >
> >> I have sent it attached this time.
> >
> > Thanks, this version is OK.  Please start the copyright assignment
> > paperwork process if you haven't already done so, if you may be
> > contributing more changes in future.
> >
> > http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future
> Thanks. I had sent the assignment form by postal mail a week ago. I
> have not received
> a reply.

If you don't hear anything within another week, I suggest chasing up 
ass...@gnu.org about it.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Fixing SEH exceptions for languages != C++

[Jonathan Schleifer]

There is also definitely a use-after-free if you call _Unwind_DeleteException 
in your personality before returning _URC_INSTALL_CONTEXT (which you should, if 
you don't want to leak and your landing pad doesn't call it). I'm not sure 
though how to fix it. It seems the problem that register 0 is ignored is 
present throughout the whole file and it seems that a proper fix gets a little 
bit more complicated.

--
Jonathan

Re: [PATCH] Fix c++/60272

[Richard Henderson]

On 02/20/2014 12:09 PM, Jakub Jelinek wrote:
> On Thu, Feb 20, 2014 at 11:49:30AM -0600, Richard Henderson wrote:
>> Tested on x86_64 and i686, and manually inspecting the generated code.
>> Any ideas how to regression test this?
> 
> No idea about how to test this.
> 
>> @@ -5330,14 +5330,23 @@ expand_builtin_atomic_compare_exchange (enum 
>> machine_mode mode, tree exp,
>>if (tree_fits_shwi_p (weak) && tree_to_shwi (weak) != 0)
>>  is_weak = true;
>>  
>> +  if (target == const0_rtx)
>> +target = NULL;
>>oldval = expect;
>> -  if (!expand_atomic_compare_and_swap ((target == const0_rtx ? NULL : 
>> &target),
>> -   &oldval, mem, oldval, desired,
>> +
>> +  if (!expand_atomic_compare_and_swap (&target, &oldval, mem, oldval, 
>> desired,
> 
> I'm wondering if this shouldn't be instead:
>   oldval = NULL;
>   if (!expand_atomic_compare_and_swap (&target, &oldval, mem, expected, 
> desired,
>  is_weak, success, failure))
> 
> because otherwise expand_atomic_compare_and_swap could in theory already
> store into expect MEM, couldn't it?  I mean, it does:
>   /* Load expected into a register for the compare and swap.  */
>   if (MEM_P (expected))
> expected = copy_to_reg (expected);
> 
>   /* Make sure we always have some place to put the return oldval.
>  Further, make sure that place is distinct from the input expected,
>  just in case we need that path down below.  */
>   if (ptarget_oval == NULL
>   || (target_oval = *ptarget_oval) == NULL
>   || reg_overlap_mentioned_p (expected, target_oval))
> target_oval = gen_reg_rtx (mode);
> so with NULL *ptarget_oval it will surely allocate a pseudo, but if it is
> the expected MEM, as expected has been forced into register earlier,
> I don't think it overlaps with that REG and thus it can be already stored
> and have oldval == expect after the call.

I don't know any target that actually accepts a MEM for oldval, and since the
current definition of __atomic_compare_and_swap_n takes an address for
expected, we'll always have a MEM.  So at present we'll always allocate a new
pseudo just as if we zero out oldval.

But, fair enough.  It does seem generally safer your way.


r~

[RFA, RFC PATCH, rtl-optimization]: Assert that crtl->emit.regno_pointer_align_length is non-zero when calling gen_reg_rtx

[Uros Bizjak]

Hello!

As discussed in PR 57896, calling gen_reg_rtx without populated crtl
was the cause of severe internal data corruption. The code following

  /* Make sure regno_pointer_align, and regno_reg_rtx are large
 enough to have an element for this pseudo reg number.  */

comment is simply not prepared to handle case where
crtl->emit.regno_pointer_align_length (and reg_rtx_no) is zero. Even
when resizing the array, the allocated array size stays zero (new size
is calculated as crtl->emit.regno_pointer_align_length * 2), and
consequently

  val = gen_raw_REG (mode, reg_rtx_no);
  regno_reg_rtx[reg_rtx_no++] = val;
  return val;

at the end of the function writes well outside the array.

IMO, the consequences of this data corruption warrant assert in
gen_reg_rtx that crtl->emit.regno_pointer_align_length is non-zero. In
case of invalid use, the compiler would ICE in a predictable way, with
a clear message where and what went wrong, instead of ICEing in random
place due to various unpredictable effects of nearby data corruption
(please see debugging troubles in the PR 57896).

I would like to propose the patch for all release branches. The
benefit of gcc_assert instead of gcc_checking_assert is in consistent
ICE (and consequently consistent bugreports) instead of a data
corruption even for the non-checking compiler. I am aware that this
assert *could* trigger some ICEs on other targets, but these will be
triggered _instead_ of internal data corruption.

2014-02-20  Uros Bizjak  

* emit-rtl.c (gen_reg_rtx): Assert that
crtl->emit.regno_pointer_align_length is non-zero.

The patch was bootstrapped and regression tested on
x86_64-pc-linux-gnu {,-m32} on 4.8 and 4.9 branch.

OK for mainline and release branches?

Uros.

Index: emit-rtl.c
===
--- emit-rtl.c  (revision 207965)
+++ emit-rtl.c  (working copy)
@@ -896,6 +896,9 @@ gen_reg_rtx (enum machine_mode mode)
   return gen_rtx_CONCAT (mode, realpart, imagpart);
 }

+  /* Do not call gen_reg_rtx with uninitialized crtl.  */
+  gcc_assert (crtl->emit.regno_pointer_align_length);
+
   /* Make sure regno_pointer_align, and regno_reg_rtx are large
  enough to have an element for this pseudo reg number.  */

Re: [RFA, RFC PATCH, rtl-optimization]: Assert that crtl->emit.regno_pointer_align_length is non-zero when calling gen_reg_rtx

[Jakub Jelinek]

On Thu, Feb 20, 2014 at 08:34:46PM +0100, Uros Bizjak wrote:
> 2014-02-20  Uros Bizjak  
> 
> * emit-rtl.c (gen_reg_rtx): Assert that
> crtl->emit.regno_pointer_align_length is non-zero.
> 
> The patch was bootstrapped and regression tested on
> x86_64-pc-linux-gnu {,-m32} on 4.8 and 4.9 branch.
> 
> OK for mainline and release branches?

Ok for trunk for the time being.  While it has been tested
on x86_64/i686, we have tons of other targets, we need some time
to find out if this doesn't break those other targets,
perhaps they have similar bug like i?86 had.

> --- emit-rtl.c  (revision 207965)
> +++ emit-rtl.c  (working copy)
> @@ -896,6 +896,9 @@ gen_reg_rtx (enum machine_mode mode)
>return gen_rtx_CONCAT (mode, realpart, imagpart);
>  }
> 
> +  /* Do not call gen_reg_rtx with uninitialized crtl.  */
> +  gcc_assert (crtl->emit.regno_pointer_align_length);
> +
>/* Make sure regno_pointer_align, and regno_reg_rtx are large
>   enough to have an element for this pseudo reg number.  */

Jakub

Re: [PATCH] Fix ix86_vectorize_vec_perm_const_ok (PR target/57896)

[Jakub Jelinek]

On Thu, Feb 20, 2014 at 07:39:33PM +0100, Jakub Jelinek wrote:
> active) with RTL checking, further tested with
> GCC_TEST_RUN_EXPENSIVE=1 make -j16 -k check 
> RUNTESTFLAGS='--target_board=unix\{-msse2,-msse3,-mssse3,-msse4,-mavx,-mavx2,-mavx512f\}
>  dg-torture.exp=*vshuf*'
> (on AVX HW, so -mavx2 and -mavx512f tests expectedly failed execution,
> but at least didn't fail compilation, with the exception of
> gcc.dg/torture/vshuf-v8sf.c which ICEs with -mavx2 -DEXPENSIVE, but
> both without this patch and with this patch - will look at it eventually).

The fix for vshuf-v8sf.c -mavx2 -DEXPENSIVE is here, tested with the
above mentioned test (again, only AVX capable HW), the ICE is gone.
Full bootstrap/regtest pending, ok for trunk/4.8 if it succeeds?

2014-02-20  Jakub Jelinek  

* config/i386/i386.c (ix86_expand_vec_perm): Use V8SImode
mode for mask of V8SFmode permutation.

--- gcc/config/i386/i386.c.jj   2014-02-20 13:05:27.0 +0100
+++ gcc/config/i386/i386.c  2014-02-20 19:52:26.142131204 +0100
@@ -21457,7 +21457,7 @@ ix86_expand_vec_perm (rtx operands[])
  return;
 
case V8SFmode:
- mask = gen_lowpart (V8SFmode, mask);
+ mask = gen_lowpart (V8SImode, mask);
  if (one_operand_shuffle)
emit_insn (gen_avx2_permvarv8sf (target, op0, mask));
  else


Jakub

Re: [RFA, RFC PATCH, rtl-optimization]: Assert that crtl->emit.regno_pointer_align_length is non-zero when calling gen_reg_rtx

[Uros Bizjak]

On Thu, Feb 20, 2014 at 9:05 PM, Jakub Jelinek  wrote:
> On Thu, Feb 20, 2014 at 08:34:46PM +0100, Uros Bizjak wrote:
>> 2014-02-20  Uros Bizjak  
>>
>> * emit-rtl.c (gen_reg_rtx): Assert that
>> crtl->emit.regno_pointer_align_length is non-zero.
>>
>> The patch was bootstrapped and regression tested on
>> x86_64-pc-linux-gnu {,-m32} on 4.8 and 4.9 branch.
>>
>> OK for mainline and release branches?
>
> Ok for trunk for the time being.  While it has been tested
> on x86_64/i686, we have tons of other targets, we need some time
> to find out if this doesn't break those other targets,
> perhaps they have similar bug like i?86 had.

OK. I will ping for backport after 4.9 is released.

Thanks,
Uros.

Re: [PATCH] Fix ix86_vectorize_vec_perm_const_ok (PR target/57896)

[Uros Bizjak]

On Thu, Feb 20, 2014 at 9:08 PM, Jakub Jelinek  wrote:

>> active) with RTL checking, further tested with
>> GCC_TEST_RUN_EXPENSIVE=1 make -j16 -k check 
>> RUNTESTFLAGS='--target_board=unix\{-msse2,-msse3,-mssse3,-msse4,-mavx,-mavx2,-mavx512f\}
>>  dg-torture.exp=*vshuf*'
>> (on AVX HW, so -mavx2 and -mavx512f tests expectedly failed execution,
>> but at least didn't fail compilation, with the exception of
>> gcc.dg/torture/vshuf-v8sf.c which ICEs with -mavx2 -DEXPENSIVE, but
>> both without this patch and with this patch - will look at it eventually).
>
> The fix for vshuf-v8sf.c -mavx2 -DEXPENSIVE is here, tested with the
> above mentioned test (again, only AVX capable HW), the ICE is gone.
> Full bootstrap/regtest pending, ok for trunk/4.8 if it succeeds?
>
> 2014-02-20  Jakub Jelinek  
>
> * config/i386/i386.c (ix86_expand_vec_perm): Use V8SImode
> mode for mask of V8SFmode permutation.

OK everywhere.

Thanks,
Uros.

Re: [Patch, testsuite]: Allow MicroBlaze .weakext pattern in regex match

[Mike Stump]

On Feb 16, 2014, at 4:21 PM, David Holsgrove  wrote:
> I've attached an updated patch

Ok, thanks.

Re: [PATCH] Fix ix86_vectorize_vec_perm_const_ok (PR target/57896)

[Richard Henderson]

On 02/20/2014 12:39 PM, Jakub Jelinek wrote:
> +  if (!d->testing_p)
> +{
> +  dremap.target = gen_reg_rtx (dremap.vmode);
> +  dfinal.op0 = gen_lowpart (dfinal.vmode, dremap.target);
> +}
...
> +   if (d->testing_p)
> + d_copy.target = gen_lowpart (V4DFmode, d->target);
> +   else
> + d_copy.target = gen_reg_rtx (V4DFmode);

I'm not keen on these changes, because they could potentially affect how the
insn matching happens.  I'm not 100% sure it actually matters, but I think
there's a simple way around it: use the same gen_raw_REG kind of thing that we
do to begin.

What about this?  Note that I've also slightly adjusted a few of the breaks, to
take into account that both arms of the if will always succeed.


r~
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index cd14e52..d827bb3 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -39499,6 +39499,7 @@ struct expand_vec_perm_d
   rtx target, op0, op1;
   unsigned char perm[MAX_VECT_LEN];
   enum machine_mode vmode;
+  unsigned test_regno;
   unsigned char nelt;
   bool one_operand_p;
   bool testing_p;
@@ -42419,6 +42420,17 @@ init_vselect_insn (void)
   end_sequence ();
 }
 
+/* Create a new psuedo, or for testing, a dummy register.  */
+
+static rtx
+gen_vec_perm_reg (struct expand_vec_perm_p *d, enum machine_mode mode)
+{
+  if (d->testing_p)
+return gen_raw_REG (mode, ++d->test_regno);
+  else
+return gen_reg_rtx (mode);
+}
+
 /* Construct (set target (vec_select op0 (parallel perm))) and
return true if that's a valid instruction in the active ISA.  */
 
@@ -42811,9 +42823,7 @@ expand_vec_perm_pshufb (struct expand_vec_perm_d *d)
{
  for (i = 0; i < 4; i++)
perm[i] = (d->perm[i * nelt / 4] * 4 / nelt) & 3;
- if (d->testing_p)
-   return true;
- target = gen_reg_rtx (V4DImode);
+ target = gen_vec_perm_reg (d, V4DImode);
  if (expand_vselect (target, gen_lowpart (V4DImode, d->op0),
  perm, 4, false))
{
@@ -43411,7 +43421,7 @@ expand_vec_perm_interleave2 (struct expand_vec_perm_d 
*d)
   else
dfinal.perm[i] = e;
 }
-  dremap.target = gen_reg_rtx (dremap.vmode);
+  dremap.target = gen_vec_perm_reg (d, dremap.vmode);
   dfinal.op0 = gen_lowpart (dfinal.vmode, dremap.target);
   dfinal.op1 = dfinal.op0;
   dfinal.one_operand_p = true;
@@ -43845,6 +43855,9 @@ expand_vec_perm_pshufb2 (struct expand_vec_perm_d *d)
 return false;
   gcc_assert (!d->one_operand_p);
 
+  if (d->testing_p)
+return true;
+
   nelt = d->nelt;
   eltsz = GET_MODE_SIZE (GET_MODE_INNER (d->vmode));
 
@@ -44053,6 +44066,8 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm_d 
*d, unsigned odd)
   switch (d->vmode)
 {
 case V4DFmode:
+  if (d->testing_p)
+   break;
   t1 = gen_reg_rtx (V4DFmode);
   t2 = gen_reg_rtx (V4DFmode);
 
@@ -44072,6 +44087,8 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm_d 
*d, unsigned odd)
   {
int mask = odd ? 0xdd : 0x88;
 
+   if (d->testing_p)
+ break;
t1 = gen_reg_rtx (V8SFmode);
t2 = gen_reg_rtx (V8SFmode);
t3 = gen_reg_rtx (V8SFmode);
@@ -44109,6 +44126,8 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm_d 
*d, unsigned odd)
   gcc_unreachable ();
 
 case V8HImode:
+  if (d->testing_p)
+   break;
   if (TARGET_SSSE3)
return expand_vec_perm_pshufb2 (d);
   else
@@ -44130,6 +44149,8 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm_d 
*d, unsigned odd)
   break;
 
 case V16QImode:
+  if (d->testing_p)
+   break;
   if (TARGET_SSSE3)
return expand_vec_perm_pshufb2 (d);
   else
@@ -44160,7 +44181,7 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm_d 
*d, unsigned odd)
{
  struct expand_vec_perm_d d_copy = *d;
  d_copy.vmode = V4DFmode;
- d_copy.target = gen_reg_rtx (V4DFmode);
+ d_copy.target = gen_vec_perm_reg (d, V4DFmode);
  d_copy.op0 = gen_lowpart (V4DFmode, d->op0);
  d_copy.op1 = gen_lowpart (V4DFmode, d->op1);
  if (expand_vec_perm_even_odd_1 (&d_copy, odd))
@@ -44173,6 +44194,9 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm_d 
*d, unsigned odd)
  return false;
}
 
+  if (d->testing_p)
+   break;
+
   t1 = gen_reg_rtx (V4DImode);
   t2 = gen_reg_rtx (V4DImode);
 
@@ -44193,7 +44217,7 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm_d 
*d, unsigned odd)
{
  struct expand_vec_perm_d d_copy = *d;
  d_copy.vmode = V8SFmode;
- d_copy.target = gen_reg_rtx (V8SFmode);
+ d_copy.target = gen_vec_perm_reg (d, V8SFmode);
  d_copy.op0 = gen_lowpart (V8SFmode, d->op0);
  d_copy.op1 = gen_lowpart (V8SFmode, d->op1);
  if (expand_vec_perm_even_odd_1 (&d_

Re: [PATCH] Fix ix86_vectorize_vec_perm_const_ok (PR target/57896)

[Jakub Jelinek]

On Thu, Feb 20, 2014 at 02:41:06PM -0600, Richard Henderson wrote:
> On 02/20/2014 12:39 PM, Jakub Jelinek wrote:
> > +  if (!d->testing_p)
> > +{
> > +  dremap.target = gen_reg_rtx (dremap.vmode);
> > +  dfinal.op0 = gen_lowpart (dfinal.vmode, dremap.target);
> > +}
> ...
> > + if (d->testing_p)
> > +   d_copy.target = gen_lowpart (V4DFmode, d->target);
> > + else
> > +   d_copy.target = gen_reg_rtx (V4DFmode);
> 
> I'm not keen on these changes, because they could potentially affect how the
> insn matching happens.  I'm not 100% sure it actually matters, but I think
> there's a simple way around it: use the same gen_raw_REG kind of thing that we
> do to begin.

Note, the patch has been committed already.

Anyway, I don't see why this would matter, when d->testing_p, d->target
is some pseudo register, d->op0 another one and d->op1 either the same as
d->op0 or yet another register.  For testing we are just matching a single
d_copy (or other permutation) at a time, so all we care about is that
target/op0/op1 have the right modes and that target is a different register
from op0 and op0 either the same as op1 or yet another register.

> What about this?  Note that I've also slightly adjusted a few of the breaks, 
> to
> take into account that both arms of the if will always succeed.

The problem I see with this is that we'll need to maintain test_regno
everywhere.  E.g. there are places which even fir !d->testing_p create
temporary structures and set testing_p in it, that would now require
that we also set test_regno there to something (what?).

Jakub

Re: [Patch, Fortran] PR60286 - fix INQUIRE for write= with stdout/stdin/stderr

[Janus Weil]

Hi,

>> > Build and regtested on x86-64-gnu-linux.
>> > OK for the trunk?
>>
>> the patch looks pretty much trivial, int the sense that you just
>> hard-wire the expected values for the std* units as a special case. I
>> wonder why the 'inquire_read' and 'inquire_write' functions don't
>> actually return the correct values?
>
> One can inquire by FILE= name and by UNIT=; inquire_read() is using
> the file name - either via FILE= directly or for an opened unit
> via u->file; it then calls POSIX's access() function on the file name
> to determine the permissions. Obviously, that fails if no file
> actually exists.
>
> Thus, simply calling the function won't work - and as all three cases
> are slightly different, hardcoding the condition is simplest.
>
>
> However, I now wonder whether one should also take care of other cases,
> where no file name exists - but which could be queried. In that case,
> one could simply use the mode in which the file was opened - which
> one could do in general for files in the UNIT= mode - contrary to
> the FILE= mode. I am in particular thinking of scratch files - they
> are often opened, then deleted and only file descriptor remains.
>
>
> Namely, either unconditionally using for UNIT=:
>
> if ((cf & IOPARM_INQUIRE_HAS_READWRITE) != 0)
>   p = (u->flags.action == ACTION_READWRITE) ? yes : no;
>
> We probably still need some special case for stdin/stdout/stderr.

Do we? If the new version of the patch works correctly, then it seems
that we don't?


> Or adding as additional condition:
>   if (u->flags->status == STATUS_SCRATCH)
> p = (u->flags.action == ACTION_READWRITE) ? yes : no;
> to also handle SCRATCH correctly.
>
>
> * Advantage of access(): Gives the true file mode by the OS.
> * Advantage of the open mode: Gives the permissions for which the
> unit was opened.

Is there actually a difference?

In any case I think INQUIRE with FILE should use the former, while
INQUIRE with UNIT should use the latter, which is apparently what your
new patch does.


> Also works in corner cases (scratch, stdout, ...).
> Simpler code.
>
> I have no idea what users prefer - but when using the unit directly,
> the OPEN's ACCTION= mode feels a bit more natural than access().
>
> Thoughts?
>
> What about the new version of the patch?

I like the new version much better, because it is more general and
even simpler. To my taste it is ok for trunk ...

Thanks,
Janus

Re: [PATCH] Fix ix86_vectorize_vec_perm_const_ok (PR target/57896)

[Richard Henderson]

On 02/20/2014 02:59 PM, Jakub Jelinek wrote:
> ... so all we care about is that
> target/op0/op1 have the right modes and that target is a different register
> from op0 and op0 either the same as op1 or yet another register.

That's my point: yet another register.  Thus the creation of a brand new pseudo
(or brand new dummy) is not irrelevant to the match.

> 
> The problem I see with this is that we'll need to maintain test_regno
> everywhere.  E.g. there are places which even fir !d->testing_p create
> temporary structures and set testing_p in it, that would now require
> that we also set test_regno there to something (what?).

True, I didn't think of the other places we set testing_p.  But that's just one
or two more places to set test_regno.  Not out of the question...


r~

[Patch, Fortran, OOP, Regression] PR 60234: ICE in generate_finalization_wrapper at fortran/class.c:1883

[Janus Weil]

Hi all,

attached is a patch for an ICE-on-valid regression related to finalization.

What the patch does is to defer the building of the vtabs to a later
stage. Previously this was done only for some rare cases, now we do it
basically for all vtabs. This is necessary with finalization, since
building the vtab also implies building the finalization wrapper, for
which it is necessary that the finalizers have been resolved.

Deferring the building of the vtab means that we have to leave blank
the type of the class container's _vtab component at first. This is
then later fixed up in 'gfc_add_component_ref'.

I think in general it's a good strategy for the complete OOP
implementation to defer the building of the front-end structures
(class containers, vtabs, etc) as much as possible. Ultimately it
would be best to generate all the structures only at translation stage
(I think Paul at some point already started preparations for a
trans-class.c). However, this is a major effort and clearly can not be
tackled before the next stage 1.

Anyway, the patch regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk?

Cheers,
Janus



2014-02-20  Janus Weil  

PR fortran/60234
* gfortran.h (gfc_build_class_symbol): Removed argument.
* class.c (gfc_add_component_ref): Fix up missing vtype if necessary.
(gfc_build_class_symbol): Remove argument 'delayed_vtab'. vtab is always
delayed now, except for unlimited polymorphics.
(comp_is_finalizable): Procedure pointer components are not finalizable.
* decl. (build_sym, build_struct, attr_decl1): Removed argument of
'gfc_build_class_symbol'.
* match.c (copy_ts_from_selector_to_associate, select_type_set_tmp):
Ditto.
* symbol.c (gfc_set_default_type): Ditto.


2014-02-20  Janus Weil  

PR fortran/60234
* gfortran.dg/finalize_23.f90: New.
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (revision 207846)
+++ gcc/fortran/class.c (working copy)
@@ -218,6 +218,14 @@ gfc_add_component_ref (gfc_expr *e, const char *na
break;
   tail = &((*tail)->next);
 }
+  if (derived->components->next->ts.type == BT_DERIVED &&
+  derived->components->next->ts.u.derived == NULL)
+{
+  /* Fix up missing vtype.  */
+  gfc_symbol *vtab = gfc_find_derived_vtab 
(derived->components->ts.u.derived);
+  gcc_assert (vtab);
+  derived->components->next->ts.u.derived = vtab->ts.u.derived;
+}
   if (*tail != NULL && strcmp (name, "_data") == 0)
 next = *tail;
   (*tail) = gfc_get_ref();
@@ -543,7 +551,7 @@ gfc_intrinsic_hash_value (gfc_typespec *ts)
 
 bool
 gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
-   gfc_array_spec **as, bool delayed_vtab)
+   gfc_array_spec **as)
 {
   char name[GFC_MAX_SYMBOL_LEN+1], tname[GFC_MAX_SYMBOL_LEN+1];
   gfc_symbol *fclass;
@@ -637,16 +645,17 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a
   if (!gfc_add_component (fclass, "_vptr", &c))
return false;
   c->ts.type = BT_DERIVED;
-  if (delayed_vtab
- || (ts->u.derived->f2k_derived
- && ts->u.derived->f2k_derived->finalizers))
-   c->ts.u.derived = NULL;
-  else
+
+  if (ts->u.derived->attr.unlimited_polymorphic)
{
  vtab = gfc_find_derived_vtab (ts->u.derived);
  gcc_assert (vtab);
  c->ts.u.derived = vtab->ts.u.derived;
}
+  else
+   /* Build vtab later.  */
+   c->ts.u.derived = NULL;
+
   c->attr.access = ACCESS_PRIVATE;
   c->attr.pointer = 1;
 }
@@ -790,7 +799,9 @@ has_finalizer_component (gfc_symbol *derived)
 static bool
 comp_is_finalizable (gfc_component *comp)
 {
-  if (comp->attr.allocatable && comp->ts.type != BT_CLASS)
+  if (comp->attr.proc_pointer)
+return false;
+  else if (comp->attr.allocatable && comp->ts.type != BT_CLASS)
 return true;
   else if (comp->ts.type == BT_DERIVED && !comp->attr.pointer
   && (comp->ts.u.derived->attr.alloc_comp
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 207846)
+++ gcc/fortran/decl.c  (working copy)
@@ -1199,7 +1199,7 @@ build_sym (const char *name, gfc_charlen *cl, bool
   sym->attr.implied_index = 0;
 
   if (sym->ts.type == BT_CLASS)
-return gfc_build_class_symbol (&sym->ts, &sym->attr, &sym->as, false);
+return gfc_build_class_symbol (&sym->ts, &sym->attr, &sym->as);
 
   return true;
 }
@@ -1656,10 +1656,7 @@ build_struct (const char *name, gfc_charlen *cl, g
 scalar:
   if (c->ts.type == BT_CLASS)
 {
-  bool delayed = (gfc_state_stack->sym == c->ts.u.derived)
-|| (!c->ts.u.derived->components
-&& !c->ts.u.derived->attr.zero_comp);
-  bool t2 = gfc_build_class_symbol (&c->ts, &c->attr, &c->as, delayed);
+  bool t2 = gfc_build_class_symbol (&c->ts, &c->attr, &c

[PATCH] [MIPS] Make the gcc driver recognize the -mvirt option

[Moore, Catherine]

Hi Richard,
It would be nice to be able to pass -mvirt to the gcc driver.  Does this patch 
look okay to install?
Also, please let me know if I can install now or if I need to wait for stage 1.
Thanks,
Catherine



virt.cl
Description: virt.cl


virt.patch
Description: virt.patch

Re: [PATCH] [MIPS] Make the gcc driver recognize the -mvirt option

[Richard Sandiford]

"Moore, Catherine"  writes:
> It would be nice to be able to pass -mvirt to the gcc driver.  Does this
> patch look okay to install?
> Also, please let me know if I can install now or if I need to wait for stage 
> 1.

I don't see any problem with it going in now.

> @@ -17447,6 +17448,14 @@ Use (do not use) the MIPS MCU ASE instructions.
>  @opindex mno-eva
>  Use (do not use) the MIPS Enhanced Virtual Addressing instructions.
>  
> +@item -mvirt
> +@itemx -mno-virt
> +@opindex mvirt
> +@opindex mno-virt
> +@item -mvirt
> +@itemx -mno-virt
> +Use (do not use the MIPS Virtualization Application Specific instructions.
> +

This has two copies of:

 @item -mvirt
 @itemx -mno-virt

the second pair should be deleted.  OK with that change, thanks.

Richard

[google/gcc-4_8] Fix demangler to handle conversion operators correctly

[Cary Coutant]

I've backported this patch from trunk at r205292. Committed on
google/gcc-4_8 branch as r207971.

Tested with make check in libiberty.

-cary


2013-11-22  Cary Coutant  

libiberty/
* cp-demangle.c (struct d_info_checkpoint): New struct.
(struct d_print_info): Add current_template field.
(d_operator_name): Set flag when processing a conversion
operator.
(cplus_demangle_type): When processing  for
a conversion operator, backtrack if necessary.
(d_expression_1): Renamed from d_expression.
(d_expression): New wrapper around d_expression_1.
(d_checkpoint): New function.
(d_backtrack): New function.
(d_print_init): Initialize current_template.
(d_print_comp): Set current_template.
(d_print_cast): Put current_template in scope for
printing conversion operator name.
(cplus_demangle_init_info): Initialize is_expression and
is_conversion.
* cp-demangle.h (struct d_info): Add is_expression and
is_conversion fields.
* testsuite/demangle-expected: New test cases.

Re: [RFC] Old school parallelization of WPA streaming

[H.J. Lu]

On Thu, Dec 5, 2013 at 3:54 PM, Jan Hubicka  wrote:
>> On Thu, 21 Nov 2013, Jan Hubicka wrote:
>>
>> > >
>> > > Why do you need an additional -fparallelism?  Wouldn't
>> > > -fwpa=... be a better match, matching -flto=...?  As we already
>> > > pass down a -fwpa option to WPA this would make things easier, no?
>> >
>> > My plan was to possibly use same option later for parallelizing more parts 
>> > of
>> > compiler, not only WPA streaming. Streaming in may have some chance if we 
>> > get
>> > into thread safety of GGC or move sufficient amount of stuff out of GGC.  
>> > Also
>> > we can parallelize inliner heuristic or IPA-PTA if it will ever work. So it
>> > would make sense with -flto-partition=none and perhaps with local 
>> > optimization,
>> > too.
>>
>> I'd like to drop -flto-partition=none eventually.  It's just one more
>> path through the compiler to support ...
>>
>> > But I can definitely update the patch to use -fwpa=N and we can deal with 
>> > this
>> > once this becomes real. (i.e. I have no clue how to parallelize inliner 
>> > without
>> > making its decisions dependent on the parallelizm and declining with 
>> > parallelizm
>> > increased nor I have real plans for stream in procedure)
>>
>> Please.
>>
>
> Hi,
> here is updated patch. Sorry for taking time, I should have more time for 
> hacking again
> now...
>
> Honza
>
> * lto-cgraph.c (asm_nodes_output): Make global.
> * lto-wrapper.c (run_gcc): Pass down paralelizm to WPA.
> * lto.c (lto_parallelism): New static var.
> (do_stream_out, wait_for_child, stream_out): New static functions.
> (lto_wpa_write_files): Add support for parallel streaming.
> (do_whole_program_analysis): Set parallelism.
> * lang.opt (fwpa): Add parameter.
> * lto-lang.c (lto_handle_option): Handle flag_wpa.
> (lto_init): Update use of flag_wpa.
> * lto-streamer.h (asm_nodes_output): Declare.

This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60295


H.J.

[PATCH] std::quoted is too eager to clear the string

[Lars Gullik Bjønnes]

 * include/std/iomanip (_Quoted_string operator>>): Do not clear
   string if input is not quoted.

Currently the string is cleared regardless of
how the string is handled. This patch just
moves the clearing down so that we do not clear
it if we are not going to quote the string
(i.e. let operator>> handle the clearing if needed)
and also not if we encounter any stream error.

This has been reported as (bug 60270).

I have no GCC paperwork in order, but I expect this change
to be simple enough to not require that.

---
 libstdc++-v3/include/std/iomanip | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/std/iomanip b/libstdc++-v3/include/std/iomanip
index b2c7b95..73822db 100644
--- a/libstdc++-v3/include/std/iomanip
+++ b/libstdc++-v3/include/std/iomanip
@@ -415,8 +415,6 @@ _GLIBCXX_END_NAMESPACE_VERSION
 const _Quoted_string&,
  _CharT>& __str)
   {
-   __str._M_string.clear();
-
_CharT __c;
__is >> __c;
if (!__is.good())
@@ -427,6 +425,7 @@ _GLIBCXX_END_NAMESPACE_VERSION
__is >> __str._M_string;
return __is;
  }
+   __str._M_string.clear();
std::ios_base::fmtflags __flags
  = __is.flags(__is.flags() & ~std::ios_base::skipws);
do
-- 
1.9.0


-- 
Lgb

Re: [PATCH] std::quoted is too eager to clear the string

[Jonathan Wakely]

On 21 February 2014 00:00, Lars Gullik Bjønnes wrote:
>
>  * include/std/iomanip (_Quoted_string operator>>): Do not clear
>string if input is not quoted.
>
> Currently the string is cleared regardless of
> how the string is handled. This patch just
> moves the clearing down so that we do not clear
> it if we are not going to quote the string
> (i.e. let operator>> handle the clearing if needed)
> and also not if we encounter any stream error.
>
> This has been reported as (bug 60270).
>
> I have no GCC paperwork in order, but I expect this change
> to be simple enough to not require that.

I agree, and we already have a testcase in the PR I opened.

I'll commit this for 4.9.1, thanks for reporting and fixing it.

Re: [PATCH] Fix c++/60272

[Richard Henderson]

On 02/20/2014 01:22 PM, Richard Henderson wrote:
> On 02/20/2014 12:09 PM, Jakub Jelinek wrote:
>> On Thu, Feb 20, 2014 at 11:49:30AM -0600, Richard Henderson wrote:
>>> Tested on x86_64 and i686, and manually inspecting the generated code.
>>> Any ideas how to regression test this?
>>
>> No idea about how to test this.
>>
>>> @@ -5330,14 +5330,23 @@ expand_builtin_atomic_compare_exchange (enum 
>>> machine_mode mode, tree exp,
>>>if (tree_fits_shwi_p (weak) && tree_to_shwi (weak) != 0)
>>>  is_weak = true;
>>>  
>>> +  if (target == const0_rtx)
>>> +target = NULL;
>>>oldval = expect;
>>> -  if (!expand_atomic_compare_and_swap ((target == const0_rtx ? NULL : 
>>> &target),
>>> -  &oldval, mem, oldval, desired,
>>> +
>>> +  if (!expand_atomic_compare_and_swap (&target, &oldval, mem, oldval, 
>>> desired,
>>
>> I'm wondering if this shouldn't be instead:
>>   oldval = NULL;
>>   if (!expand_atomic_compare_and_swap (&target, &oldval, mem, expected, 
>> desired,
>> is_weak, success, failure))
>>
>> because otherwise expand_atomic_compare_and_swap could in theory already
>> store into expect MEM, couldn't it?  I mean, it does:
>>   /* Load expected into a register for the compare and swap.  */
>>   if (MEM_P (expected))
>> expected = copy_to_reg (expected);
>>
>>   /* Make sure we always have some place to put the return oldval.
>>  Further, make sure that place is distinct from the input expected,
>>  just in case we need that path down below.  */
>>   if (ptarget_oval == NULL
>>   || (target_oval = *ptarget_oval) == NULL
>>   || reg_overlap_mentioned_p (expected, target_oval))
>> target_oval = gen_reg_rtx (mode);
>> so with NULL *ptarget_oval it will surely allocate a pseudo, but if it is
>> the expected MEM, as expected has been forced into register earlier,
>> I don't think it overlaps with that REG and thus it can be already stored
>> and have oldval == expect after the call.
> 
> I don't know any target that actually accepts a MEM for oldval, and since the
> current definition of __atomic_compare_and_swap_n takes an address for
> expected, we'll always have a MEM.  So at present we'll always allocate a new
> pseudo just as if we zero out oldval.
> 
> But, fair enough.  It does seem generally safer your way.

Like so.


r~

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 09fefe50..35969ad 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -5332,9 +5332,12 @@ expand_builtin_atomic_compare_exchange (enum 
machine_mode mode, tree exp,
 
   if (target == const0_rtx)
 target = NULL;
-  oldval = expect;
 
-  if (!expand_atomic_compare_and_swap (&target, &oldval, mem, oldval, desired,
+  /* Lest the rtl backend create a race condition with an imporoper store
+ to memory, always create a new pseudo for OLDVAL.  */
+  oldval = NULL;
+
+  if (!expand_atomic_compare_and_swap (&target, &oldval, mem, expect, desired,
   is_weak, success, failure))
 return NULL_RTX;
 

Re: [RFC] Old school parallelization of WPA streaming

[Andi Kleen]

> I plan to commit it shortly (i am just slowly progressing through the
> bugreports and TODOs cumulated)
> - indeed for bigger apps and edit/relink cycle it is an life saver ;)

I haven't tested exactly around this, but I see a ~10s (~5%) improved kernel
LTO build time going from 4.9-20140209 to 20140220

Also major faults went down somewhat.

gcc49
gcc version 4.9.0 20140209 (experimental) (GCC) 
real=178.91 user=1829.87 system=125.76 share=1093%% maxrss=1231580 ins=37848 
outs=7852280 mfaults=49741854 waits=151528
gcc49
gcc version 4.9.0 20140220 (experimental) (GCC) 
real=168.90 user=1824.20 system=127.04 share=1155%% maxrss=1231996 ins=448 
outs=7808584 mfaults=49257032 waits=136755

-Andi

Re: [RFC] Old school parallelization of WPA streaming

[Jan Hubicka]

> > I plan to commit it shortly (i am just slowly progressing through the
> > bugreports and TODOs cumulated)
> > - indeed for bigger apps and edit/relink cycle it is an life saver ;)
> 
> I haven't tested exactly around this, but I see a ~10s (~5%) improved kernel
> LTO build time going from 4.9-20140209 to 20140220

Good to know! It also improves firefox build noticeably.
I added some comments to the PR itself. I do not see how it can make too many
WPA processes, given that it does not fork without explicit -flto=N argument
that is not passed by the bootstrap-lto.mk config. So perhaps something is
wrong with parsing command liine arguments and setting lto_parallelizm?

Also for all builds I tested so far the memory is not dominated by WPA
streaming but by the subsequent ltrans-es now.  Things are different with
-fprofile-generate that adds a lot of extra datastructures to stream. Generally
I am trying to convince people to profile without LTO as it is much faster.
I will try to reproduce the problem - but I am running ltobootstraps and
profiled-ltobootstrap regularly and never saw too many WPA processes at
once.

Honza

[PATCH v2] PR middle-end/60281

[lin zuojian]

Hi,
I have misunderstood the meaning of STRICT_ALIGNMENT.Sorry for that Jakub.
I think patch v2 have modified as Jakub suggested.


---
Without aligning the asan stack base,this base will only 64-bit aligned
in ARM machines.
But asan require 256-bit aligned base because of this:
1.right shift take ASAN_SHADOW_SHIFT(which is 3) bits are zeros
2.store multiple/load multiple instructions require the other 2 bits are
zeros

that add up lowest 5 bits should be zeros.That means 32 bytes or 256
bits aligned.

* asan.c (asan_emit_stack_protection): Forcing the base to align to 256
bits if STRICT_ALIGNMENT.
And set shadow_mem align to 256 bits if STRICT_ALIGNMENT
* cfgexpand.c (expand_stack_vars): set base_align appropriately when
asan is on
(expand_used_vars): Leaving a space in the stack frame for alignment if
STRICT_ALIGNMENT
---
gcc/asan.c | 10 ++
gcc/cfgexpand.c | 13 -
2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/gcc/asan.c b/gcc/asan.c
index 53992a8..8d8ad50 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -1017,8 +1017,16 @@ asan_emit_stack_protection (rtx base, rtx pbase,
unsigned int alignb,
base_align_bias = ((asan_frame_size + alignb - 1)
& ~(alignb - HOST_WIDE_INT_1)) - asan_frame_size;
}
+ /* Align base if target is STRICT_ALIGNMENT. */
+ if (STRICT_ALIGNMENT)
+ base = expand_binop (Pmode, and_optab, base,
+ gen_int_mode (-((GET_MODE_ALIGNMENT (SImode) << ASAN_SHADOW_SHIFT) /
BITS_PER_UNIT), Pmode),
+ NULL_RTX, 1, OPTAB_DIRECT);
+
if (use_after_return_class == -1 && pbase)
emit_move_insn (pbase, base);
+
+
base = expand_binop (Pmode, add_optab, base,
gen_int_mode (base_offset - base_align_bias, Pmode),
NULL_RTX, 1, OPTAB_DIRECT);
@@ -1097,6 +1105,8 @@ asan_emit_stack_protection (rtx base, rtx pbase,
unsigned int alignb,
&& (ASAN_RED_ZONE_SIZE >> ASAN_SHADOW_SHIFT) == 4);
shadow_mem = gen_rtx_MEM (SImode, shadow_base);
set_mem_alias_set (shadow_mem, asan_shadow_set);
+ if (STRICT_ALIGNMENT)
+ set_mem_align(shadow_mem, (GET_MODE_ALIGNMENT (SImode) <<
ASAN_SHADOW_SHIFT));
prev_offset = base_offset;
for (l = length; l; l -= 2)
{
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 06d494c..63d8020 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -1013,10 +1013,18 @@ expand_stack_vars (bool (*pred) (size_t), struct
stack_vars_data *data)
if (data->asan_base == NULL)
data->asan_base = gen_reg_rtx (Pmode);
base = data->asan_base;
+
+ if (!STRICT_ALIGNMENT)
+ base_align = crtl->max_used_stack_slot_alignment;
+ else
+ base_align = MAX(crtl->max_used_stack_slot_alignment,
+ (GET_MODE_ALIGNMENT (SImode) << ASAN_SHADOW_SHIFT));
}
else
+ {
offset = alloc_stack_frame_space (stack_vars[i].size, alignb);
- base_align = crtl->max_used_stack_slot_alignment;
+ base_align = crtl->max_used_stack_slot_alignment;
+ }
}
else
{
@@ -1843,6 +1851,9 @@ expand_used_vars (void)
= alloc_stack_frame_space (redzonesz, ASAN_RED_ZONE_SIZE);
data.asan_vec.safe_push (prev_offset);
data.asan_vec.safe_push (offset);
+ /* Leave a space for alignment if STRICT_ALIGNMENT. */
+ if (STRICT_ALIGNMENT)
+ alloc_stack_frame_space ((GET_MODE_ALIGNMENT (SImode) <<
ASAN_SHADOW_SHIFT) / BITS_PER_UNIT , 1);

var_end_seq
= asan_emit_stack_protection (virtual_stack_vars_rtx,
-- 
1.8.3.2

libgo patch committed: Fix heap address for Aarch64

[Ian Lance Taylor]

This libgo patch from Michael Hudson-Doyle fixes the heap address for
Aarch64, as described in the patch.  Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian

diff -r dd599141ce32 libgo/runtime/malloc.goc
--- a/libgo/runtime/malloc.goc	Thu Feb 20 07:18:12 2014 -0800
+++ b/libgo/runtime/malloc.goc	Thu Feb 20 19:17:49 2014 -0800
@@ -27,6 +27,31 @@
 #define KindPtr GO_PTR
 #define KindNoPointers GO_NO_POINTERS
 
+// GCCGO SPECIFIC CHANGE
+//
+// There is a long comment in runtime_mallocinit about where to put the heap
+// on a 64-bit system.  It makes assumptions that are not valid on linux/arm64
+// -- it assumes user space can choose the lower 47 bits of a pointer, but on
+// linux/arm64 we can only choose the lower 39 bits.  This means the heap is
+// roughly a quarter of the available address space and we cannot choose a bit
+// pattern that all pointers will have -- luckily the GC is mostly precise
+// these days so this doesn't matter all that much.  The kernel (as of 3.13)
+// will allocate address space starting either down from 0x7f or up
+// from 0x20, so we put the heap roughly in the middle of these two
+// addresses to minimize the chance that a non-heap allocation will get in the
+// way of the heap.
+//
+// This all means that there isn't much point in trying 256 different
+// locations for the heap on such systems.
+#ifdef __aarch64__
+#define HeapBase(i) ((void*)(uintptr)(0x40ULL<<32))
+#define HeapBaseOptions 1
+#else
+#define HeapBase(i) ((void*)(uintptr)(i<<40|0x00c0ULL<<32))
+#define HeapBaseOptions 0x80
+#endif
+// END GCCGO SPECIFIC CHANGE
+
 // Mark mheap as 'no pointers', it does not contain interesting pointers but occupies ~45K.
 MHeap runtime_mheap;
 
@@ -423,9 +448,8 @@
 		bitmap_size = arena_size / (sizeof(void*)*8/4);
 		spans_size = arena_size / PageSize * sizeof(runtime_mheap.spans[0]);
 		spans_size = ROUND(spans_size, PageSize);
-		for(i = 0; i <= 0x7f; i++) {
-			p = (void*)(uintptr)(i<<40 | 0x00c0ULL<<32);
-			p = runtime_SysReserve(p, bitmap_size + spans_size + arena_size);
+		for(i = 0; i < HeapBaseOptions; i++) {
+			p = runtime_SysReserve(HeapBase(i), bitmap_size + spans_size + arena_size);
 			if(p != nil)
 break;
 		}

[PATCH][AARCH64]PR60034

[Kugan]

Hi all,

Compiling inline asm results in ICE (PR60034). Alignment calculation in
aarch64_classify_address for (symbol_ref:DI ("*.LANCHOR4") [flags
0x182])) seems wrong here.

Fixing this also  caused a regression for pr38151.c, which is due to
complex type being allocated with wrong alignment. Attached patch fixes
these issues.

Regression tested on qemu-aarch64 for aarch64-none-linux-gnu with no new
regressions.

Is this patch OK?

Thanks,
Kugan

gcc/
+2014-02-21  Kugan Vivekanandarajah  
+
+   PR target/60034
+   * aarch64/aarch64.c (aarch64_classify_address): Fix alignment for
+   SYMBOL_REF_FLAGS.
+   * aarch64/aarch64.h (DATA_ALIGNMENT):  Fix alignment for COMPLEX_TYPE.
+

gcc/testsuite/
+2014-02-21  Kugan Vivekanandarajah  
+
+   PR target/60034
+   * gcc.target/aarch64/pr60034.c: New file.
+
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index ea90311..89187c0 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -3203,6 +3203,8 @@ aarch64_classify_address (struct aarch64_address_info 
*info,
}
  else if (SYMBOL_REF_DECL (sym))
align = DECL_ALIGN (SYMBOL_REF_DECL (sym));
+ else if (SYMBOL_REF_FLAGS (sym))
+   align = GET_MODE_ALIGNMENT (GET_MODE (sym));
  else
align = BITS_PER_UNIT;
 
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 13c424c..b93e9da 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -132,6 +132,7 @@
   ALIGN) < BITS_PER_WORD)  \
 && (TREE_CODE (EXP) == ARRAY_TYPE  \
|| TREE_CODE (EXP) == UNION_TYPE\
+   || TREE_CODE (EXP) == COMPLEX_TYPE  \
|| TREE_CODE (EXP) == RECORD_TYPE)) \
? BITS_PER_WORD : (ALIGN))
 
diff --git a/gcc/testsuite/gcc.target/aarch64/pr60034.c 
b/gcc/testsuite/gcc.target/aarch64/pr60034.c
index e69de29..99c821d 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr60034.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr60034.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-std=gnu99 -fgnu89-inline -O -Wall -Winline -Wwrite-strings 
-fmerge-all-constants -frounding-math -g -Wstrict-prototypes" } */
+
+static unsigned long global_max_fast;
+
+int __libc_mallopt (int param_number, int value)
+{
+ __asm__ __volatile__ ("# %[_SDT_A21]" :: [_SDT_A21] "nr" ((global_max_fast)));
+ global_max_fast = 1;
+}

[PATCH] Fix PR 60268

[Andrey Belevantsev]

Hello,

While fixing PR 58960 I forgot about single-block regions placing the 
initialization of the new nr_regions_initial variable in the wrong place. 
Thus for single block regions we ended up with nr_regions = 1 and 
nr_regions_initial = 0 and effectively turned off sched-pressure 
immediately.  No worries for the usual scheduling path but with the 
-flive-range-shrinkage we have broke an assert that sched-pressure is in 
the specific mode.


Fixed by placing the initialization properly at the end of sched_rgn_init 
and also moving the check for sched_pressure != NONE outside of the if 
statement in schedule_region as discussed in the PR trail with Jakub.


Bootstrapped and tested on x86-64, ok?

Andrey

gcc/

2014-02-21  Andrey Belevantsev  

PR rtl-optimization/60268
* sched-rgn.c (haifa_find_rgns): Move the nr_regions_initial init to ...
(sched_rgn_init) ... here.
(schedule_region): Check for SCHED_PRESSURE_NONE earlier.

testsuite/

2014-02-21  Andrey Belevantsev  

PR rtl-optimization/60268
* gcc.c-torture/compile/pr60268.c: New test.
diff --git a/gcc/sched-rgn.c b/gcc/sched-rgn.c
index 0573b6a..dc6fa16 100644
--- a/gcc/sched-rgn.c
+++ b/gcc/sched-rgn.c
@@ -1067,7 +1067,6 @@ haifa_find_rgns (void)
 	BLOCK_TO_BB (bb->index) = 0;
   }
 
-  nr_regions_initial = nr_regions;
   free (max_hdr);
   free (degree);
   free (stack);
@@ -2997,10 +2996,10 @@ schedule_region (int rgn)
 
   /* Do not support register pressure sensitive scheduling for the new regions
  as we don't update the liveness info for them.  */
-  if (rgn >= nr_regions_initial)
+  if (sched_pressure != SCHED_PRESSURE_NONE
+  && rgn >= nr_regions_initial)
 {
-  if (sched_pressure != SCHED_PRESSURE_NONE)
-	free_global_sched_pressure_data ();
+  free_global_sched_pressure_data ();
   sched_pressure = SCHED_PRESSURE_NONE;
 }
 
@@ -3166,6 +3165,7 @@ sched_rgn_init (bool single_blocks_p)
 
   RGN_BLOCKS (nr_regions) = (RGN_BLOCKS (nr_regions - 1) +
 			 RGN_NR_BLOCKS (nr_regions - 1));
+  nr_regions_initial = nr_regions;
 }
 
 /* Free data structures for region scheduling.  */
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr60268.c b/gcc/testsuite/gcc.c-torture/compile/pr60268.c
new file mode 100644
index 000..c3a6f94
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr60268.c
@@ -0,0 +1,6 @@
+/* { dg-options "-flive-range-shrinkage" } */
+void f()
+{
+  int i = 0;
+  void *p = 0;
+}

Re: [Patch, Fortran, OOP, Regression] PR 60234: ICE in generate_finalization_wrapper at fortran/class.c:1883

[Tobias Burnus]

Hi Janus,

Janus Weil wrote:

What the patch does is to defer the building of the vtabs to a later
stage. Previously this was done only for some rare cases, now we do it
basically for all vtabs. This is necessary with finalization, since
building the vtab also implies building the finalization wrapper, for
which it is necessary that the finalizers have been resolved.

Anyway, the patch regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk?


Looks good to me.

Does

 comp_is_finalizable (gfc_component *comp)
 {
-  if (comp->attr.allocatable && comp->ts.type != BT_CLASS)
+  if (comp->attr.proc_pointer)
+return false;
+  else if (comp->attr.allocatable && comp->ts.type != BT_CLASS)

fix an other PR - or did you just spot it when looking at the code? It 
it certainly simple, correct and should go in.


Tobias


2014-02-20  Janus Weil  

 PR fortran/60234
 * gfortran.h (gfc_build_class_symbol): Removed argument.
 * class.c (gfc_add_component_ref): Fix up missing vtype if necessary.
 (gfc_build_class_symbol): Remove argument 'delayed_vtab'. vtab is always
 delayed now, except for unlimited polymorphics.
 (comp_is_finalizable): Procedure pointer components are not finalizable.
 * decl. (build_sym, build_struct, attr_decl1): Removed argument of
 'gfc_build_class_symbol'.
 * match.c (copy_ts_from_selector_to_associate, select_type_set_tmp):
 Ditto.
 * symbol.c (gfc_set_default_type): Ditto.


2014-02-20  Janus Weil  

 PR fortran/60234
 * gfortran.dg/finalize_23.f90: New.

[4.7 PATCH] Fix ix86_vectorize_vec_perm_const_ok (PR target/57896)

[Uros Bizjak]

On Thu, Feb 20, 2014 at 7:39 PM, Jakub Jelinek  wrote:

> As discussed in the PR, gen_reg_rtx from when init_emit has not been
> initialized is highly undesirable.  The following patch makes sure that
> for d->testing_p we never call gen_reg_rtx (i.e. from within
> ix86_vectorize_vec_perm_const_ok) and never try to emit insns.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux (together with Uros'
> patch to assert that gen_reg_rtx is not called when init_emit is not
> active) with RTL checking, further tested with
> GCC_TEST_RUN_EXPENSIVE=1 make -j16 -k check 
> RUNTESTFLAGS='--target_board=unix\{-msse2,-msse3,-mssse3,-msse4,-mavx,-mavx2,-mavx512f\}
>  dg-torture.exp=*vshuf*'
> (on AVX HW, so -mavx2 and -mavx512f tests expectedly failed execution,
> but at least didn't fail compilation, with the exception of
> gcc.dg/torture/vshuf-v8sf.c which ICEs with -mavx2 -DEXPENSIVE, but
> both without this patch and with this patch - will look at it eventually).

Attached is the complete backport of the patch to 4.7 branch. Jakub,
there is a slight churn in expand_vec_parm_interleave2 (there is no
dfinal.one_operand_p), can you please check if everything is OK there?

2014-02-21  Uros Bizjak  

Backport from mainline
2014-02-20  Jakub Jelinek  

* config/i386/i386.c (ix86_expand_vec_perm): Use V8SImode
mode for mask of V8SFmode permutation.

Backport from 4.8 branch
2014-02-20  Jakub Jelinek  

PR target/57896
* config/i386/i386.c (expand_vec_perm_interleave2): Don't call
gen_reg_rtx if d->testing_p.
(expand_vec_perm_pshufb2, expand_vec_perm_even_odd_1,
expand_vec_perm_broadcast_1): Return early if d->testing_p and
we will certainly return true.

Tested on x86_64-pc-linux-gnu {,-m32} with additional gen_reg_rtx
assert added, also with GCC_TEST_RUN_EXPENSIVE=1 -k check
RUNTESTFLAGS='--target_board=unix\{-msse2,-msse3,-mssse3,-msse4,-mavx,-mavx2\}
dg-torture.exp=*vshuf*' on AVX target, which uncovered the above
mentioned unrelated ICE, which is also fixed with this patch.

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 207970)
+++ config/i386/i386.c  (working copy)
@@ -20073,7 +20073,7 @@ ix86_expand_vec_perm (rtx operands[])
  return;
 
case V8SFmode:
- mask = gen_lowpart (V8SFmode, mask);
+ mask = gen_lowpart (V8SImode, mask);
  if (one_operand_shuffle)
emit_insn (gen_avx2_permvarv8sf (target, op0, mask));
  else
@@ -36655,7 +36655,9 @@ expand_vec_perm_interleave2 (struct expand_vec_per
   else
dfinal.perm[i] = e;
 }
-  dfinal.op0 = gen_reg_rtx (dfinal.vmode);
+
+  if (!d->testing_p)
+dfinal.op0 = gen_reg_rtx (dfinal.vmode);
   dfinal.op1 = dfinal.op0;
   dremap.target = dfinal.op0;
 
@@ -37052,6 +37054,8 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm
   switch (d->vmode)
 {
 case V4DFmode:
+  if (d->testing_p)
+   break;
   t1 = gen_reg_rtx (V4DFmode);
   t2 = gen_reg_rtx (V4DFmode);
 
@@ -37071,6 +37075,8 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm
   {
int mask = odd ? 0xdd : 0x88;
 
+   if (d->testing_p)
+ break;
t1 = gen_reg_rtx (V8SFmode);
t2 = gen_reg_rtx (V8SFmode);
t3 = gen_reg_rtx (V8SFmode);
@@ -37112,6 +37118,8 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm
return expand_vec_perm_pshufb2 (d);
   else
{
+ if (d->testing_p)
+   break;
  /* We need 2*log2(N)-1 operations to achieve odd/even
 with interleave. */
  t1 = gen_reg_rtx (V8HImode);
@@ -37133,6 +37141,8 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm
return expand_vec_perm_pshufb2 (d);
   else
{
+ if (d->testing_p)
+   break;
  t1 = gen_reg_rtx (V16QImode);
  t2 = gen_reg_rtx (V16QImode);
  t3 = gen_reg_rtx (V16QImode);
@@ -37165,6 +37175,9 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm
  return expand_vec_perm_even_odd_1 (&d_copy, odd);
}
 
+  if (d->testing_p)
+   break;
+
   t1 = gen_reg_rtx (V4DImode);
   t2 = gen_reg_rtx (V4DImode);
 
@@ -37191,6 +37204,9 @@ expand_vec_perm_even_odd_1 (struct expand_vec_perm
  return expand_vec_perm_even_odd_1 (&d_copy, odd);
}
 
+  if (d->testing_p)
+   break;
+
   t1 = gen_reg_rtx (V8SImode);
   t2 = gen_reg_rtx (V8SImode);
 
@@ -37283,6 +37299,8 @@ expand_vec_perm_broadcast_1 (struct expand_vec_per
 case V16QImode:
   /* These can be implemented via interleave.  We save one insn by
 stopping once we have promoted to V4SImode and then use pshufd.  */
+  if (d->testing_p)
+   return true;
   do
{
  rtx dest;

Re: [Patch, Fortran] PR60286 - fix INQUIRE for write= with stdout/stdin/stderr

[Tobias Burnus]

Hi,

Janus Weil wrote:

Namely, either unconditionally using for UNIT=:

if ((cf & IOPARM_INQUIRE_HAS_READWRITE) != 0)
   p = (u->flags.action == ACTION_READWRITE) ? yes : no;

We probably still need some special case for stdin/stdout/stderr.

Do we? If the new version of the patch works correctly, then it seems
that we don't?


I wrote that before carefully checking the code and actually doing the 
modification. unit.c's init_units sets them correctly.




* Advantage of access(): Gives the true file mode by the OS.
* Advantage of the open mode: Gives the permissions for which the
unit was opened.

Is there actually a difference?


Well, you can do:

open(99, file="test.dat", action="write")
write(99, *) 6
rewind(99)
read(99, *) i
end

If you look at the file permissions of the generated file, they are - 
here- '-rw-r--r--', i.e. for the user readable and writable.


However, the code will fail due to the action='write' at run time with:
 Fortran runtime error: Cannot read from file opened for WRITE

That's another reason for using the action mode with by-unit inquire.


In any case I think INQUIRE with FILE should use the former, while
INQUIRE with UNIT should use the latter, which is apparently what your
new patch does.


I concur - hence, I implemented it that way.

I like the new version much better, because it is more general and 
even simpler. To my taste it is ok for trunk ... 


Committed as Rev. 207979.

Thanks for the review!

Tobias

Re: [4.7 PATCH] Fix ix86_vectorize_vec_perm_const_ok (PR target/57896)

[Jakub Jelinek]

On Fri, Feb 21, 2014 at 08:30:39AM +0100, Uros Bizjak wrote:
> Attached is the complete backport of the patch to 4.7 branch. Jakub,
> there is a slight churn in expand_vec_parm_interleave2 (there is no
> dfinal.one_operand_p), can you please check if everything is OK there?

Yeah, one_operand_p has been introduced only in 4.8.  LGTM.

Jakub