Re: [PATCH] Fix fold making valid VEC_PERMs invalid

[Richard Biener]

On November 3, 2014 8:34:11 AM CET, Jakub Jelinek  wrote:
>On Mon, Nov 03, 2014 at 08:15:32AM +0100, Marc Glisse wrote:
>> Should I commit the following version, which passed testing as well?
>
>Yes, thanks.

Thanks for fixing this!

Richard.

>   Jakub

Re: [PATCH] x86: allow to suppress default clobbers added to asm()s

[Jan Beulich]

>>> On 31.10.14 at 20:02,  wrote:
> On 10/31/14 02:07, Jan Beulich wrote:
>> While it always seemed wrong to me that there's no way to avoid the
>> default "flags" and "fpsr" clobbers, the regression the fix for
>> PR/60663 introduced (see PR/63637) makes it even more desirable to have
>> such a mechanism: This way, at least asm()s with a single output and no
>> explicit clobbers can again be made subject to CSE.
>>
>> gcc:
>> 2014-10-31  Jan Beulich  
>>
>>  * config/i386/i386.c (ix86_target_string): Add
>>  -mno-default-asm-clobbers.
>>  (ix86_valid_target_attribute_inner_p): Handle
>>  -m{,no-}default-asm-clobbers.
>>  (ix86_md_asm_clobbers): Handle "inverse" clobbers.
>>  * config/i386/i386.h (NOCC_REGNUM, NOFPSR_REGNUM): Define.
>>  (ADDITIONAL_REGISTER_NAMES): Add "cc", "!cc", "!flags", and
>>  "!fpsr".
>>  * config/i386/i386.opt: Add mdefault-asm-clobbers and
>>  mno-default-asm-clobbers.
>>  * varasm.c (decode_reg_name_and_count): Permit negative
>>  register numbers in ADDITIONAL_REGISTER_NAMES.
>>
>> gcc/testsuite:
>> 2014-10-31  Jan Beulich  
>>
>>  * gcc.target/i386/20060218-1.c: Adjust expected error.
>>  * gcc.target/i386/invclbr[123].c: New.
> I really don't like having an option that's globally applied for this 
> feature.  THough I am OK with having a mechanism to avoid implicit 
> clobbers on specific ASMs.

Why not? That way, for projects/components knowing all their
asm()s have all clobbers explicitly specified they could avoid
having to touch all of them and instead just pass the new option.
That said - if the option isn't being liked, I'm fine dropping it.

> Why use negative numbers for the hard register numbers?  I wouldn't be 
> at all surprised if lots of random code assumes register numbers are 
> always positive.

I think I want through all relevant places, and fixed the one where
the assumption was wrongly made. The nice thing about using
negative numbers here is that there is already at least one place
where negative numbers aren't valid, and we want them to not be
valid there.

> I don't like adding new registers with special names like !foo.  Instead 
> I think that listing "!cc" or something similar in the asm itself if it 
> doesn't clobber the cc register would be better.

You mean interpreting the ! in generic code? Doable, but not very
nice imo considering that the default addition of clobbers is limited
to very few architectures, plus dealing with this in a generic way
would - afaict - make the change quite a bit more intrusive.

Jan

[PATCH, testsuite, ARM] Check lr other than r3

[Zhenqiang Chen]

Hi,

pr45701-1.c FAIL for all tests. The patch updates it to check lr other than
r3, based on the comments in arm_compute_save_reg_mask,

  /* ...
 Otherwise if we do not use the link register we do not need to save
 it.  If we are pushing other registers onto the stack however, we
 can save an instruction in the epilogue by pushing the link register
 now and then popping it back into the PC.  This incurs extra memory
 accesses though, so we only do it when optimizing for size, and only
 if we know that we will not need a fancy return sequence.  */

The updated case PASS for Cortex-M0/M4 and Cortext-A15 (THUMB and ARM
modes).

OK for trunk?

Thanks!
-Zhenqiang

testsuite/ChangeLog:
2014-11-03  Zhenqiang Chen  

* gcc.target/arm/pr45701-1.c: Check LR used.

diff --git a/gcc/testsuite/gcc.target/arm/pr45701-1.c
b/gcc/testsuite/gcc.target/arm/pr45701-1.c
index 2c690d5..c087cfc 100644
--- a/gcc/testsuite/gcc.target/arm/pr45701-1.c
+++ b/gcc/testsuite/gcc.target/arm/pr45701-1.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-skip-if "" { ! { arm_thumb1_ok || arm_thumb2_ok } } } */
 /* { dg-options "-mthumb -Os" }  */
-/* { dg-final { scan-assembler "push\t\{r3" } } */
+/* { dg-final { scan-assembler "lr\}" } } */
 /* { dg-final { scan-assembler-not "r8" } } */
 
 extern int hist_verify;

Re: [PATCH, PR61605, 2/2] Use fuse-caller-save info in pass_cprop_hardreg

[Joey Ye]

Tom,

This patch broke arm thumb1 bootstrap. Please check details at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63718

Best Regards
Joey


On Fri, Oct 17, 2014 at 5:57 AM, Jeff Law  wrote:
> On 10/16/14 03:14, Tom de Vries wrote:
>>
>> Eric,
>>
>> this patch is the second half of the fix for PR61605.
>>
>> It make sure in pass_cprop_hardreg that, if available we use the
>> call-specific information provided by fuse-caller-save, rather than the
>> generic regs_invalidated_by_call info.
>>
>> The 2 patches together allow an insn to removed from the
>> gcc.target/i386/fuse-caller-save.c testcase, which is updated
>> accordingly in this patch.
>>
>> Bootstrapped and reg-tested on x86_64.
>>
>> OK for trunk?
>>
>> Thanks,
>> - Tom
>>
>> 0002-Use-fuse-caller-save-info-in-cprop-hardreg.patch
>>
>>
>> 2014-10-13  Tom de Vries
>>
>> PR rtl-optimization/61605
>> * regcprop.c (copyprop_hardreg_forward_1): Use
>> regs_invalidated_by_this_call instead of regs_invalidated_by_call.
>>
>> * gcc.target/i386/fuse-caller-save.c: Update addition check.  Add
>> movl
>> absence check.
>
> OK.
> Jeff
>

[PATCH, testsuite, ARM] Skip combine-cmp-shift.c and unsined-extend-1.c for Thumb1

[Zhenqiang Chen]

Hi,

For combine-cmp-shift.c, Thumb1 does not have cmp and shift instruction.
For unsigned-extend-1.c, it bases on conditional execution to optimize uxtb.
But this is not for Thumb1.

The patch skips the final check when arm_thumb1_ok.

OK for trunk?

Thanks!
-Zhenqiang

testsuite/ChangeLog:
2014-11-03  Zhenqiang Chen  

* gcc.target/arm/combine-cmp-shift.c: Skip arm_thumb1_ok.
* gcc.target/arm/unsined-extend-1.c: Likewise.

diff --git a/gcc/testsuite/gcc.target/arm/combine-cmp-shift.c
b/gcc/testsuite/gcc.target/arm/combine-cmp-shift.c
index a64f20e..6291b06 100644
--- a/gcc/testsuite/gcc.target/arm/combine-cmp-shift.c
+++ b/gcc/testsuite/gcc.target/arm/combine-cmp-shift.c
@@ -1,6 +1,6 @@
 /* { dg-skip-if "incompatible options" { arm*-*-* } { "-march=*" } {
"-march=armv7-a" } } */
 /* { dg-options "-O2 -mcpu=cortex-a8" }  */
-/* { dg-final { scan-assembler "cmp\tr\[0-9\]*, r\[0-9\]*, asr #31" } } */
+/* { dg-final { scan-assembler "cmp\tr\[0-9\]*, r\[0-9\]*, asr #31" {
target { ! arm_thumb1_ok } } } } */
 
 typedef int SItype __attribute__ ((mode (SI)));
 typedef int DItype __attribute__ ((mode (DI)));
diff --git a/gcc/testsuite/gcc.target/arm/unsigned-extend-1.c
b/gcc/testsuite/gcc.target/arm/unsigned-extend-1.c
index 3b4ab04..ea90548 100644
--- a/gcc/testsuite/gcc.target/arm/unsigned-extend-1.c
+++ b/gcc/testsuite/gcc.target/arm/unsigned-extend-1.c
@@ -6,4 +6,4 @@ unsigned char foo (unsigned char c)
   return (c >= '0') && (c <= '9');
 }
 
-/* { dg-final { scan-assembler-not "uxtb" } } */
+/* { dg-final { scan-assembler-not "uxtb" { target { ! arm_thumb1_ok } } }
} */

Re: [PATCH, i386]: Add target x86_64-*-* to many tests

[Uros Bizjak]

On Sun, Nov 2, 2014 at 10:35 PM, Uros Bizjak  wrote:

>> Attached (mechanical) patch adds i?86-*-* target to many tests, where
>> only x86_64-*-* is listed. Please note that x86_64-*-* already
>> included && lp64 for 64bit specific tests due to -m32 multilib
>> testing.
>
> Following patch adds missing x86_64-*-* target in the same way.

And following patch fixes x32 fallout.

2014-11-03  Uros Bizjak  

* gcc.c-torture/execute/20010129-1.c: Compile with -mtune=i686
for ia32 targets only.
* g++.dg/ext/attrib42.C: Compile for ia32 targets only.
* g++.dg/tree-ssa/pr29902.C: Ditto.
* g++.dg/cpp0x/gen-attrs-42.C: Ditto.

Tested on x86_64-linux-gnu {,-m32} and committed to mainline SVN.

Uros.
Index: gcc.c-torture/execute/20010129-1.c
===
--- gcc.c-torture/execute/20010129-1.c  (revision 217029)
+++ gcc.c-torture/execute/20010129-1.c  (working copy)
@@ -1,4 +1,4 @@
-/* { dg-options "-mtune=i686" { target { { i?86-*-* x86_64-*-* } && ilp32 } } 
} */
+/* { dg-options "-mtune=i686" { target { { i?86-*-* x86_64-*-* } && ia32 } } } 
*/
 
 extern void abort (void);
 extern void exit (int);
Index: g++.dg/ext/attrib42.C
===
--- g++.dg/ext/attrib42.C   (revision 217029)
+++ g++.dg/ext/attrib42.C   (working copy)
@@ -1,4 +1,4 @@
-// { dg-do compile { target { { i?86-*-* x86_64-*-* } && ilp32 } } }
+// { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } }
 
 struct A {
   __attribute__((fastcall))
Index: g++.dg/tree-ssa/pr29902.C
===
--- g++.dg/tree-ssa/pr29902.C   (revision 217029)
+++ g++.dg/tree-ssa/pr29902.C   (working copy)
@@ -1,6 +1,5 @@
-/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } } */
 /* { dg-options "-O1 -fprefetch-loop-arrays -march=athlon" } */
-/* { dg-require-effective-target ilp32 } */
 
 int length1();
 int g(int);
Index: g++.dg/cpp0x/gen-attrs-42.C
===
--- g++.dg/cpp0x/gen-attrs-42.C (revision 217029)
+++ g++.dg/cpp0x/gen-attrs-42.C (working copy)
@@ -1,5 +1,5 @@
 // { dg-options "-pedantic" }
-// { dg-do compile { target { { i?86-*-* x86_64-*-* } && ilp32 } } }
+// { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } }
 // { dg-require-effective-target c++11 }
 
 struct A {

Re: [PATCH] FreeBSD arm support, EABI.

[Bin.Cheng]

On Mon, Nov 3, 2014 at 6:11 AM, Andreas Tobler  wrote:
> Hello all,
>
> this is a patch which brings support for arm*-*-freebsd* to trunk.
> The architectures supported are arm-*-*freebsd*, armv6-*-freebsd* and
> armv6hf-*-freebsd*.
> armv6 stands for ARM_ARCH == 6, arm stands for ARM_ARCH < 6.
Just out of curiosity, what about armv7?

Thanks,
bin
>
> There is kernel development for armv8 aka. aarch64 ongoing but this is not
> covered here. This patch only covers 32-bit arm in a basic manner.
>
> The patch is built and tested against armv6, armv6hf and arm. The former two
> tests (lots of) were done on a WANDBOARD-QUAD, the latter on a MARVELL board
> with 256MB Ram and 200MHz cpu (around 72h+ for a build and test.)
>
> Results for armv6hf are on the list. Only one entry but locally I ran
> several dozens runs...
>
> Once if this patch is accepted a few test suite additions will follow.
> (arm*-*-*eabi* -> arm_eabi)
>
> The patch itself is also prepared for arm*eb*-*-freebsd*, but I could not
> test since I lack the HW.
>
> I appreciate comments, questions and also an ack if this patch is ok for
> trunk.
>
> TIA,
>
> Andreas
>
> toplevel:
>
> 2014-11-02  Andreas Tobler  
>
> * configure.ac: Don't add ${libgcj} for arm*-*-freebsd*.
> * configure: Regenerate.
>
> gcc:
>
> 2014-11-02  Andreas Tobler  
>
> * config.gcc (arm*-*-freebsd*): New configuration.
> * config/arm/freebsd.h: New file.
> * config.host: A extras components for arm*-*-freebsd*.
> * config/arm/arm.c (arm_init_libfuncs): FreeBSD does not support 8
> byte
> atomics for __ARM_ARCH__ < 6 yet.
> (arm_option_override): FreeBSD has not yet implemented unaligned
> access.
>
> libgcc:
>
> 2014-11-02  Andreas Tobler  
>
> * config.host (arm*-*-freebsd*): Add new configuration for
> arm*-*-freebsd*.
> * config/arm/freebsd-atomic.c: New file.
> * config/arm/t-freebsd: Likewise.
> * config/arm/unwind-arm.h: Add __FreeBSD__ to the list of
> 'PC-relative
> indirect' OS's.
>
> libstdc++:
>
> 2014-11-02  Andreas Tobler  
>
> * configure.host: Add arm*-*-freebsd* port_specific_symbol_files.
>

Re: update address taken: don't drop clobbers

[Richard Biener]

On Sun, Nov 2, 2014 at 11:34 AM, Marc Glisse  wrote:
> On Fri, 31 Oct 2014, Richard Biener wrote:
>
>> On Sat, Oct 25, 2014 at 6:29 PM, Marc Glisse  wrote:
>>>
>>> On Fri, 24 Oct 2014, Jeff Law wrote:
>>>
 I'm starting to agree -- a later message indicated you wanted to drop
 the
 unlink_stmt_vdef call and you wanted to avoid gsi_replace, that seems
 fine.
 I'll approve once those things are taken care of.
>>>
>>>
>>>
>>> The following passed bootstrap+testsuite. I wasn't sure what exactly a
>>> clobber is guaranteed not to have (no histograms for instance? At least I
>>> assumed it doesn't throw) so I may have kept some unnecessary calls when
>>> I
>>> inlined gsi_replace. I'd be happy to remove any you feel is useless.
>>>
>>> 2014-10-26  Marc Glisse  
>>>
>>> PR tree-optimization/60770
>>> gcc/
>>> * tree-into-ssa.c: Include value-prof.h.
>>> (maybe_register_def): Replace clobbers with default definitions.
>>> * tree-ssa-live.c: Include tree-ssa.h.
>>> (set_var_live_on_entry): Do not mark undefined variables as live.
>>> (verify_live_on_entry): Do not check undefined variables.
>>> * tree-ssa.h (ssa_undefined_value_p): New parameter for the case
>>> of partially undefined variables.
>>> * tree-ssa.c (ssa_undefined_value_p): Likewise.
>>> (execute_update_addresses_taken): Do not drop clobbers.
>>>
>>> gcc/testsuite/
>>> * gcc.dg/tree-ssa/pr60770-1.c: New file.
>>>
>>> --
>>> Marc Glisse
>>>
>>> Index: gcc/testsuite/gcc.dg/tree-ssa/pr60770-1.c
>>> ===
>>> --- gcc/testsuite/gcc.dg/tree-ssa/pr60770-1.c   (revision 0)
>>> +++ gcc/testsuite/gcc.dg/tree-ssa/pr60770-1.c   (working copy)
>>> @@ -0,0 +1,11 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-O -Wall" } */
>>> +
>>> +int f(int n){
>>> +  int*p;
>>> +  {
>>> +int yyy=n;
>>> +p=&yyy;
>>> +  }
>>> +  return *p; /* { dg-warning "yyy" } */
>>> +}
>>> Index: gcc/tree-into-ssa.c
>>> ===
>>> --- gcc/tree-into-ssa.c (revision 216689)
>>> +++ gcc/tree-into-ssa.c (working copy)
>>> @@ -52,20 +52,21 @@ along with GCC; see the file COPYING3.
>>>  #include "expr.h"
>>>  #include "tree-dfa.h"
>>>  #include "tree-ssa.h"
>>>  #include "tree-inline.h"
>>>  #include "tree-pass.h"
>>>  #include "cfgloop.h"
>>>  #include "domwalk.h"
>>>  #include "params.h"
>>>  #include "diagnostic-core.h"
>>>  #include "tree-into-ssa.h"
>>> +#include "value-prof.h"
>>>
>>>  #define PERCENT(x,y) ((float)(x) * 100.0 / (float)(y))
>>>
>>>  /* This file builds the SSA form for a function as described in:
>>> R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. Zadeck.
>>> Efficiently
>>> Computing Static Single Assignment Form and the Control Dependence
>>> Graph. ACM Transactions on Programming Languages and Systems,
>>> 13(4):451-490, October 1991.  */
>>>
>>>  /* Structure to map a variable VAR to the set of blocks that contain
>>> @@ -1837,26 +1838,42 @@ maybe_register_def (def_operand_p def_p,
>>>  {
>>>tree def = DEF_FROM_PTR (def_p);
>>>tree sym = DECL_P (def) ? def : SSA_NAME_VAR (def);
>>>
>>>/* If DEF is a naked symbol that needs renaming, create a new
>>>   name for it.  */
>>>if (marked_for_renaming (sym))
>>>  {
>>>if (DECL_P (def))
>>> {
>>> - tree tracked_var;
>>> + if (gimple_clobber_p (stmt) && is_gimple_reg (sym))
>>
>>
>> I think you know that sym is a gimple-reg as the code previously
>> unconditionally generated an SSA name for it.
>
>
> I checked that in July and it failed:
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01828.html
>
>>> +   {
>>> + /* Replace clobber stmts with a default def. This new use
>>> of a
>>> +default definition may make it look like SSA_NAMEs have
>>> +conflicting lifetimes, so we need special code to let
>>> them
>>> +coalesce properly.  */
>>> + /* Hand-inlined version of the following, for safety
>>> +gsi_replace (&gsi, gimple_build_nop (), true);  */
>>> + gimple nop = gimple_build_nop ();
>>> + gimple_set_bb (nop, gsi_bb (gsi));
>>> + gimple_set_bb (stmt, NULL);
>>> + gimple_remove_stmt_histograms (cfun, stmt);
>>> + delink_stmt_imm_use (stmt);
>>> + gsi_set_stmt (&gsi, nop);
>>
>>
>> Is there any reason for this dance?  I'd rather have maybe_register_def
>> return a bool whether to remove the stmt... passing it down to the
>> single caller of rewrite_update_stmt which can then gsi_remove the
>> stmt.
>
>
> For more context, my starting point was the code in rewrite_stmt, which
> I was trying to port to rewrite_update_stmt (and thus
> maybe_register_def):
>
> if (gimple_clobber_p (stmt)
> && is_gimple_reg (var))
>   {
>  

Re: [PATCH] FreeBSD arm support, EABI.

[Andreas Tobler]

- Original Message 
From: Bin.Cheng 
To: Andreas Tobler 
Cc: GCC Patches 
Subject: Re: [PATCH] FreeBSD arm support, EABI.
Date: 03/11/14 10:04

> On Mon, Nov 3, 2014 at 6:11 AM, Andreas Tobler
 wrote:
> > Hello all,
> >
> > this is a patch which brings support for arm*-*-freebsd* to trunk.
> > The architectures supported are arm-*-*freebsd*, armv6-*-freebsd* and
> > armv6hf-*-freebsd*.
> > armv6 stands for ARM_ARCH == 6, arm stands for ARM_ARCH < 6.
> Just out of curiosity, what about armv7?

Sorry, I should have written 'armv6 stands for ARM_ARCH >= 6'. But I have no
evidence how an armv8 (ARM_ARCH == 8) will/would work.

Thanks for the curiosity :)

Andreas

Re: [PATCH 2/n] OpenMP 4.0 offloading infrastructure: LTO streaming

[Jakub Jelinek]

On Tue, Oct 28, 2014 at 10:30:47PM +0300, Ilya Verbin wrote:
> --- a/gcc/cgraph.c
> +++ b/gcc/cgraph.c
> @@ -70,6 +70,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "tree-dfa.h"
>  #include "profile.h"
>  #include "params.h"
> +#include "context.h"
>  
>  /* FIXME: Only for PROP_loops, but cgraph shouldn't have to know about this. 
>  */
>  #include "tree-pass.h"
> @@ -474,6 +475,13 @@ cgraph_node::create (tree decl)
>gcc_assert (TREE_CODE (decl) == FUNCTION_DECL);
>  
>node->decl = decl;
> +
> +  if (lookup_attribute ("omp declare target", DECL_ATTRIBUTES (decl)))
> +{
> +  node->offloadable = 1;
> +  g->have_offload = true;
> +}

I wonder if we shouldn't optimize here and call lookup_attribute only
if there is a chance that the attribute might be present, so guard with
flag_openmp (and flag_openacc later on?).  During LTO the cgraph nodes
are streamed in and supposedly the flag offloadable too.

> @@ -2129,8 +2141,12 @@ symbol_table::compile (void)
>  fprintf (stderr, "Performing interprocedural optimizations\n");
>state = IPA;
>  
> +  /* OpenMP offloading requires LTO infrastructure.  */
> +  if (!in_lto_p && flag_openmp && g->have_offload)
> +flag_generate_lto = 1;

On the other side, do you need flag_openmp here?  Supposedly g->have_offload
would already been set if needed.

Jakub

[PATCH] [BUILDROBOT] RX: Mark unused argument

[Jan-Benedict Glaw]

Hi!

I noticed that rx_handle_func_attribute() doesn't use it's `args'
argument any longer since DJ removed it's a gcc_assert() using it.
See eg. this build:
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372376

[...]
g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. 
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber 
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../../gcc/gcc/../libbacktrace-o rx.o -MT rx.o -MMD -MP -MF 
./.deps/rx.TPo ../../../gcc/gcc/config/rx/rx.c
../../../gcc/gcc/config/rx/rx.c:2675:13: error: unused parameter ‘args’ 
[-Werror=unused-parameter]
  tree   args,
 ^
cc1plus: all warnings being treated as errors
make[2]: *** [rx.o] Error 1





Silence the warning. Ok for mainline?


2014-11-03  Jan-Benedict Glaw  

* config/rx/rx.c (rx_handle_func_attribute): Mark unused argument.

 
diff --git a/gcc/config/rx/rx.c b/gcc/config/rx/rx.c
index f3e1129..e757566 100644
--- a/gcc/config/rx/rx.c
+++ b/gcc/config/rx/rx.c
@@ -2672,7 +2672,7 @@ rx_elf_asm_destructor (rtx symbol, int priority)
 static tree
 rx_handle_func_attribute (tree * node,
  tree   name,
- tree   args,
+ tree   args ATTRIBUTE_UNUSED,
  intflags ATTRIBUTE_UNUSED,
  bool * no_add_attrs)
 {
-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  Alles sollte so einfach wie möglich gemacht sein.
the second  :  Aber nicht einfacher.  (Einstein)


signature.asc
Description: Digital signature

[BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, ifcvt] Allow CC mode if HAVE_cbranchcc4)

[Jan-Benedict Glaw]

On Wed, 2014-10-29 18:27:57 +0800, Zhenqiang Chen  
wrote:
> Hi,
> 
> The patch enhances ifcvt to allow_cc_mode if HAVE_cbranchcc4.
> 
> Bootstrap and no make check regression on X86-64.
> Will add new test cases after ccmp is enabled.
> 
> Ok for trunk?

This seems to uncover something for s390x-linux, see
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372394

[...]
g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual 
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. 
-I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. 
-I/home/jbglaw/repos/gcc/gcc/../include 
-I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o ifcvt.o -MT ifcvt.o -MMD -MP 
-MF ./.deps/ifcvt.TPo /home/jbglaw/repos/gcc/gcc/ifcvt.c
/home/jbglaw/repos/gcc/gcc/ifcvt.c:1456:5: error: token "." is not valid in 
preprocessor expressions
/home/jbglaw/repos/gcc/gcc/ifcvt.c:1788:5: error: token "." is not valid in 
preprocessor expressions
/home/jbglaw/repos/gcc/gcc/ifcvt.c:2370:5: error: token "." is not valid in 
preprocessor expressions
make[1]: *** [ifcvt.o] Error 1

It's choking on the HAVE_cbranchcc4 macro itself there.

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
 Signature of:If it doesn't work, force it.
 the second  :   If it breaks, it needed replacing anyway.


signature.asc
Description: Digital signature

Re: [BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, ifcvt] Allow CC mode if HAVE_cbranchcc4)

[Jakub Jelinek]

On Mon, Nov 03, 2014 at 11:06:06AM +0100, Jan-Benedict Glaw wrote:
> On Wed, 2014-10-29 18:27:57 +0800, Zhenqiang Chen  
> wrote:
> > Hi,
> > 
> > The patch enhances ifcvt to allow_cc_mode if HAVE_cbranchcc4.
> > 
> > Bootstrap and no make check regression on X86-64.
> > Will add new test cases after ccmp is enabled.
> > 
> > Ok for trunk?
> 
> This seems to uncover something for s390x-linux, see
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372394
> 
> [...]
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual 
> -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
> -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. 
> -I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. 
> -I/home/jbglaw/repos/gcc/gcc/../include 
> -I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
> -I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
> -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o ifcvt.o -MT ifcvt.o -MMD 
> -MP -MF ./.deps/ifcvt.TPo /home/jbglaw/repos/gcc/gcc/ifcvt.c
> /home/jbglaw/repos/gcc/gcc/ifcvt.c:1456:5: error: token "." is not valid in 
> preprocessor expressions
> /home/jbglaw/repos/gcc/gcc/ifcvt.c:1788:5: error: token "." is not valid in 
> preprocessor expressions
> /home/jbglaw/repos/gcc/gcc/ifcvt.c:2370:5: error: token "." is not valid in 
> preprocessor expressions
> make[1]: *** [ifcvt.o] Error 1
> 
> It's choking on the HAVE_cbranchcc4 macro itself there.

Note the HAVE_* macros can be not defined, or defined to complex expressions
(for the conditions), not necessarily compile time constants.
At the start of ifcvt.c there is:
#ifndef HAVE_conditional_move
#define HAVE_conditional_move 0
#endif
#ifndef HAVE_incscc
#define HAVE_incscc 0
#endif
#ifndef HAVE_decscc
#define HAVE_decscc 0
#endif
#ifndef HAVE_trap
#define HAVE_trap 0
#endif

so supposedly HAVE_cbranchcc4 should be treated similarly, and all the
#if HAVE_cbranchcc4 code actually replaced with if (HAVE_cbranchcc4)
#instead.

Jakub

Re: [PATCH, ifcvt] Allow CC mode if HAVE_cbranchcc4

[Andreas Schwab]

"Zhenqiang Chen"  writes:

> diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
> index a28f5c1..5cd0ac0 100644
> --- a/gcc/ifcvt.c
> +++ b/gcc/ifcvt.c
> @@ -1441,10 +1441,17 @@ noce_emit_cmove (struct noce_if_info *if_info, rtx
> x, enum rtx_code code,
>end_sequence ();
>  }
>  
> -  /* Don't even try if the comparison operands are weird.  */
> +  /* Don't even try if the comparison operands are weird
> + except that the target supports cbranchcc4.  */
>if (! general_operand (cmp_a, GET_MODE (cmp_a))
>|| ! general_operand (cmp_b, GET_MODE (cmp_b)))
> -return NULL_RTX;
> +{
> +#if HAVE_cbranchcc4

You need to make that a runtime check.

  #ifdef HAVE_cbranchcc4
 if (HAVE_cbranchcc4)

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, ifcvt] Allow CC mode if HAVE_cbranchcc4)

[Jan-Benedict Glaw]

On Mon, 2014-11-03 11:06:06 +0100, Jan-Benedict Glaw  wrote:
> On Wed, 2014-10-29 18:27:57 +0800, Zhenqiang Chen  
> wrote:
> > Hi,
> > 
> > The patch enhances ifcvt to allow_cc_mode if HAVE_cbranchcc4.
> > 
> > Bootstrap and no make check regression on X86-64.
> > Will add new test cases after ccmp is enabled.
> > 
> > Ok for trunk?
> 
> This seems to uncover something for s390x-linux, see
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372394
> 
> [...]
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual 
> -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
> -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. 
> -I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. 
> -I/home/jbglaw/repos/gcc/gcc/../include 
> -I/home/jbglaw/repos/gcc/gcc/../libcpp/include  
> -I/home/jbglaw/repos/gcc/gcc/../libdecnumber 
> -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o ifcvt.o -MT ifcvt.o -MMD 
> -MP -MF ./.deps/ifcvt.TPo /home/jbglaw/repos/gcc/gcc/ifcvt.c
> /home/jbglaw/repos/gcc/gcc/ifcvt.c:1456:5: error: token "." is not valid in 
> preprocessor expressions
> /home/jbglaw/repos/gcc/gcc/ifcvt.c:1788:5: error: token "." is not valid in 
> preprocessor expressions
> /home/jbglaw/repos/gcc/gcc/ifcvt.c:2370:5: error: token "." is not valid in 
> preprocessor expressions
> make[1]: *** [ifcvt.o] Error 1
> 
> It's choking on the HAVE_cbranchcc4 macro itself there.

Oh, and with the most recent ifcvt.c changes, this boils down to:

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -I../../../gcc/gcc/. 
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include 
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber 
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../../gcc/gcc/../libbacktrace-o ifcvt.o -MT ifcvt.o -MMD -MP -MF 
./.deps/ifcvt.TPo ../../../gcc/gcc/ifcvt.c
In file included from ./tm.h:19:0,
 from ../../../gcc/gcc/ifcvt.c:23:
./options.h:263:36: error: token "." is not valid in preprocessor expressions
 #define target_flags global_options.x_target_flags
^
./options.h:4276:29: note: in expansion of macro ‘target_flags’
 #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
 ^
./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
 #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
  ^
../../../gcc/gcc/ifcvt.c:1467:5: note: in expansion of macro ‘HAVE_cbranchcc4’
 #if HAVE_cbranchcc4
 ^
./options.h:263:36: error: token "." is not valid in preprocessor expressions
 #define target_flags global_options.x_target_flags
^
./options.h:4276:29: note: in expansion of macro ‘target_flags’
 #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
 ^
./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
 #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
  ^
../../../gcc/gcc/ifcvt.c:1799:5: note: in expansion of macro ‘HAVE_cbranchcc4’
 #if HAVE_cbranchcc4
 ^
./options.h:263:36: error: token "." is not valid in preprocessor expressions
 #define target_flags global_options.x_target_flags
^
./options.h:4276:29: note: in expansion of macro ‘target_flags’
 #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
 ^
./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
 #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
  ^
../../../gcc/gcc/ifcvt.c:2381:5: note: in expansion of macro ‘HAVE_cbranchcc4’
 #if HAVE_cbranchcc4
 ^
make[2]: *** [ifcvt.o] Error 1



(See build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372420
for reference.)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:   ...und wenn Du denkst, es geht nicht mehr,
the second  :  kommt irgendwo ein Lichtlein her.


signature.asc
Description: Digital signature

Re: [PATCH AVX512] Fix dg.torture tests with avx512

[Jakub Jelinek]

On Fri, Oct 31, 2014 at 11:17:07AM +0100, Uros Bizjak wrote:
> I'd like to ask Jakub for a review of the above two parts, other parts
> are OK with a rename (as mentioned above).

Looks ok to me.  Where the ICEs discovered just by normal make check or only
with GCC_TEST_RUN_EXPENSIVE ?  If the latter, can you promote one of the
permutations that caused the ICEs to normal tests?  If not and
GCC_TEST_RUN_EXPENSIVE has not been tested, can you try that?

Jakub

[PATCH v3] Fix PR56480 aka DR374. Allow explicit specialization in enclosing namespace.

[Markus Trippelsdorf]

On 2014.11.02 at 21:12 -0500, Jason Merrill wrote:
> On 11/02/2014 09:15 AM, Markus Trippelsdorf wrote:
> > +  if (cxx_dialect < cxx11)
> > +   {
> > + permerror (input_location, "specialization of %qD in different "
> > +"namespace", tmpl);
> > + permerror (input_location, "  from definition of %q+#D", tmpl);
> > +   }
> > +  else
> > +   check_explicit_instantiation_namespace (tmpl);
> 
> In most cases I think DRs should apply to C++98 as well.  In this case I 
> think a pedwarn only with -pedantic in C++98 is appropriate.  Let's put 
> all the logic in check_  And add a flag to distinguish between 
> instantiation and specialization.

Thanks for the suggestions. I've implemented them below.

(If someone comes up with a better name than:
check_instant_or_special_namespace I would change it)

BTW both EDG and clang reject g++.dg/template/spec17.C:

namespace io { 
  template  int foo();
}
using namespace io;
template<> int foo();

But I think it is a reasonable extension to accept it.

Patch tested on powerpc64-unknown-linux-gnu.

2014-11-03  Markus Trippelsdorf  

DR 374
PR c++/56480
* pt.c (check_explicit_instantiation_namespace)
(check_specialization_namespace): Consolidate into 
check_instant_or_special_namespace.
(check_instant_or_special_namespace): pedwarn only with
-pedantic in C++98.
(maybe_process_partial_specialization): Call consolidated
function.
(register_specialization): Likewise.
(do_decl_instantiation): Likewise.
(do_type_instantiation): Likewise.

DR 374
PR c++/56480
* g++.dg/template/spec17.C: Add -pedantic and -pedantic-errors
to dg-options. Don't dg-error for C++11 and up.
* g++.dg/template/spec25.C: Likewise. Adjust regex.
* g++.dg/template/spec36.C: Likewise.
* g++.old-deja/g++.ns/template13.C: Likewise.
* g++.old-deja/g++.pt/explicit73.C: Likewise.
* g++.old-deja/g++.pt/lookup10.C: Likewise.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 2cf10f442f68..0eaa6a22f39d 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -755,57 +755,58 @@ end_explicit_instantiation (void)
   processing_explicit_instantiation = false;
 }
 
-/* An explicit specialization or partial specialization of TMPL is being
-   declared.  Check that the namespace in which the specialization is
-   occurring is permissible.  Returns false iff it is invalid to
-   specialize TMPL in the current namespace.  */
+/* If specialization is true, an explicit specialization or partial
+   specialization of TMPL is being declared.  Check that the namespace
+   in which the specialization is occurring is permissible.  Returns
+   false iff it is invalid to specialize TMPL in the current namespace.
+   If specialization is false, TMPL is an explicit instantiation.
+   Check that it is valid to perform this explicit instantiation in
+   the current namespace.  */
 
 static bool
-check_specialization_namespace (tree tmpl)
+check_instant_or_special_namespace (tree tmpl, bool specialization)
 {
   tree tpl_ns = decl_namespace_context (tmpl);
 
-  /* [tmpl.expl.spec]
-
- An explicit specialization shall be declared in the namespace of
- which the template is a member, or, for member templates, in the
- namespace of which the enclosing class or enclosing class
- template is a member.  An explicit specialization of a member
- function, member class or static data member of a class template
- shall be declared in the namespace of which the class template is
- a member.  */
-  if (current_scope() != DECL_CONTEXT (tmpl)
-  && !at_namespace_scope_p ())
+  if (specialization)
 {
-  error ("specialization of %qD must appear at namespace scope", tmpl);
-  return false;
-}
-  if (is_associated_namespace (current_namespace, tpl_ns))
-/* Same or super-using namespace.  */
-return true;
-  else
-{
-  permerror (input_location, "specialization of %qD in different 
namespace", tmpl);
-  permerror (input_location, "  from definition of %q+#D", tmpl);
-  return false;
-}
-}
-
-/* SPEC is an explicit instantiation.  Check that it is valid to
-   perform this explicit instantiation in the current namespace.  */
+  /* [tmpl.expl.spec]
 
-static void
-check_explicit_instantiation_namespace (tree spec)
-{
-  tree ns;
+ An explicit specialization shall be declared in the namespace of
+ which the template is a member, or, for member templates, in the
+ namespace of which the enclosing class or enclosing class
+ template is a member.  An explicit specialization of a member
+ function, member class or static data member of a class template
+ shall be declared in the namespace of which the class template is
+ a member.  */
+  if (current_scope () != DECL_CONTEXT (tmpl) && !at_namespace_scope_p ())
+{
+  error ("sp

Re: [PATCH] FreeBSD arm support, EABI.

[Kyrill Tkachov]

Hi Andreas,

CC'ing arm maintainers and a couple of comments inline.

On 02/11/14 22:11, Andreas Tobler wrote:

Hello all,

this is a patch which brings support for arm*-*-freebsd* to trunk.
The architectures supported are arm-*-*freebsd*, armv6-*-freebsd* and
armv6hf-*-freebsd*.
armv6 stands for ARM_ARCH == 6, arm stands for ARM_ARCH < 6.


Why split at ARM_ARCH == 6 ? I see in the patch you define 
TARGET_FREEBSD_ARMv6 but
only ever use it to define the SUBTARGET_CPU_DEFAULT. In the other arm 
triplets I don't think

we have architecture-specific identifiers in the arm* parts...


+
+#if defined (TARGET_FREEBSD_ARMv6)
+#undef  SUBTARGET_CPU_DEFAULT
+#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm1176jzs
+#else
+#undef  SUBTARGET_CPU_DEFAULT
+#define SUBTARGET_CPU_DEFAULT   TARGET_CPU_arm9
+#endif
+


What about ARMv7? The default CPU there is TARGET_CPU_cortexa8


Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 217020)
+++ gcc/config.gcc  (working copy)
@@ -259,7 +259,6 @@
 arm*-wince-pe* \
   | arm*-*-ecos-elf\
   | arm*-*-elf \
- | arm*-*-freebsd* \
   | arm*-*-linux*  \
   | arm*-*-uclinux*\
   | i[34567]86-go32-*  \
@@ -1000,6 +999,27 @@
extra_options="${extra_options} arm/vxworks.opt"
tmake_file="${tmake_file} arm/t-arm arm/t-vxworks"
;;
+arm*-*-freebsd*)# ARM FreeBSD EABI
+   tm_file="dbxelf.h elfos.h ${fbsd_tm_file} arm/elf.h"
+   case $target in
+   arm*b-*-freebsd*)
+   tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
+   ;;
+   esac
+   tmake_file="${tmake_file} arm/t-arm arm/t-bpabi"
+   tm_file="${tm_file} arm/bpabi.h arm/freebsd.h arm/aout.h arm/arm.h"
+   case $target in
+   armv[67]*-*-freebsd*)
+   tm_defines="${tm_defines} TARGET_FREEBSD_ARMv6=1"
+   ;;
+   esac


So you also match armv7*-*-freebsd*. As mentioned above I'm not sure why 
we would want these per-architecture triplets. If we do want to have 
these per-architecture triplets, there is also the ARMv8 AArch32 state 
which is supported in the arm backend and can be identified by ARM_ARCH 
== 8. Do we want to add an armv8*-*-freebsd triplet as well?


Cheers,
Kyrill

Re: [AArch64, Docs, Patch] Add reference to ACLE in docs.

[Tejas Belagod]

On 29/10/14 00:22, Joseph S. Myers wrote:

On Tue, 28 Oct 2014, Tejas Belagod wrote:


Hi,

Here is patch that consolidates AArch64 and ARM Intrinsics sections in
extend.texi into one ACLE section to avoid information repetition and adds
reference to the ARM C Language Extension spec on infocenter.arm.com.


This seems to lose the information about which extensions are supported by
GCC (given that not all of ACLE is supported; e.g. arm_acle.h has only the
CRC intrinsics, while __fp16 isn't supported for AArch64 and the support
for ARM corresponds to an older version of the specification).



If I mention in a couple of sentences the level of ACLE support there is 
in GCC currently, this section will need to be updated every time there 
is an improvement in ACLE support - I guess we'll just have to remember 
to remove parts of this section as we do that.


Thanks for the review, I'll respin the patch.

Thanks,
Tejas.

Re: [PATCH] Use CONVERT_EXPR_P and friends in the middle-end

[Richard Biener]

On Fri, Oct 31, 2014 at 6:59 PM, Joseph S. Myers
 wrote:
> On Fri, 31 Oct 2014, Richard Biener wrote:
>
>> This fixes the few places where explicit checks for NOP_EXPR
>> or CONVERT_EXPRs crept in.
>
> The goal really should be to eliminate anything that distinguishes the
> two, and then combine them (eliminate NOP_EXPR) (as I said in
> ).

Yes,

>> A noticable change may be the tree-eh.c one where we previously
>> considered FP NOP_EXPRs trapping if flag_trapping_math
>> ("Any fp arithmetic may trap") but now like FP CONVERT_EXPRs
>> only when honor_nans (but for some reason the honor_nans
>> cases don't check flag_trapping_math).  I'm not 100% sure which
>> variant is more correct (this is FP <-> FP conversions thus
>> widenings, truncations, converts from/to DFP).
>
> Well, use of honor_nans there is confused.  (honor_nans is set in
> operation_could_trap_p in a way that checks flag_trapping_math &&
> !flag_finite_math_only - but doesn't check HONOR_NANS on the relevant
> floating-point mode.)
>
> Setting aside for the moment that -ftrapping-math covers both cases where
> actual trap handlers are called, and cases where exception flags are set
> without calling trap handlers (the latter being the only one covered by
> ISO C at present), the following applies:
>
> * Conversions of quiet NaNs from one floating-point type to another do not
> raise exceptions.  Conversions of signaling NaNs do, however, and
> conversions of finite values can raise "inexact" (except for widening from
> a narrower to a wider type with the same radix) and "underflow" (except
> for widening, again, and with an exception to the exception in the case of
> __float80 to __float128 conversion with underflow traps enabled).
>
> * Conversions from floating point to integer (FIX_TRUNC_EXPR) do however
> raise "invalid" for NaN (or infinite) arguments - and for finite arguments
> outside the range of the destination type (this includes -1 and below
> converted to unsigned types).  Whether they raise "inexact" for
> non-integer arguments is unspecified.  To a first approximation, even with
> -ffinite-math-only, assume with -ftrapping-math that "invalid" may be
> raised for such conversions because of out-of-range values (although the
> range of binary16 - currently only supported as ARM __fp16 - is narrow
> enough that if you ignore non-finite values, conversions to some signed
> integer types are guaranteed in-range).
>
> It looks like the honor_nans argument was intended for the case of ordered
> conversions, for which it's correct that quiet NaNs raise exceptions, and
> is being misused for conversions, where fp_operation && flag_trapping_math
> is the right thing to check (although there are certain subcases,
> depending on the types involved, where in fact you can't have traps).
> That in turn is the default, suggesting just removing the CASE_CONVERT and
> FIX_TRUNC_EXPR cases (the effect of which is to treat certain conversions
> as trapping for -ffinite-math-only where previously they weren't treated
> as trapping).

Ok, I'll test a patch doing that.

Thanks,
Richard.

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

Re: [PATCH] [BUILDROBOT] RX: Mark unused argument

[Nicholas Clifton]

Hi Jan-Benedict,


2014-11-03  Jan-Benedict Glaw  

* config/rx/rx.c (rx_handle_func_attribute): Mark unused argument.


Approved - please apply.

Cheers
  Nick

[match-and-simplify] support operator list

[Prathamesh Kulkarni]

(had sent it earlier by private mail).

The attached patch supports operator-list and it's use in for.
For now, operator-list is rejected in expression.

This patch also allows user-defined operator to be used as operator-list
(user-defined ops are really temporary or "scoped" operator-lists).
(for op (plus minus)
  op2 (op...)
  (simplify
 ...))

Should that be supported or rejected ?

* genmatch.c
  (user_id): Add new member is_oper_list.
  (user_id::user_id): Add new default argument.
  (parser::parse_operator_list): New function.
  (parser::parse_for): Allow operator-list.
  (parser::parse_pattern): Call parser::parse_operator_list.
  (parser::parse_operation): Reject operator-list.

* match-comparison.pd
  Define operator-lists eq_ops and cc and use them in patterns.

Thanks,
Prathamesh
Index: gcc/genmatch.c
===
--- gcc/genmatch.c	(revision 216916)
+++ gcc/genmatch.c	(working copy)
@@ -234,10 +234,11 @@
 
 struct user_id : public id_base
 {
-  user_id (const char *id_)
-: id_base (id_base::USER, id_), substitutes (vNULL), used (false) {}
+  user_id (const char *id_, bool is_oper_list_ = false)
+: id_base (id_base::USER, id_), substitutes (vNULL), used (false), is_oper_list (is_oper_list_) {}
   vec substitutes;
   bool used;
+  bool is_oper_list;
 };
 
 template<>
@@ -2443,6 +2444,7 @@
   void parse_for (source_location);
   void parse_if (source_location);
   void parse_predicates (source_location);
+  void parse_operator_list ();
 
   cpp_reader *r;
   vec active_ifs;
@@ -2611,6 +2613,11 @@
   id_base *op = get_operator (id);
   if (!op)
 fatal_at (id_tok, "unknown operator %s", id);
+
+  user_id *p = dyn_cast (op);
+  if (p && p->is_oper_list)
+fatal_at (id_tok, "operator-list not allowed in expression");
+
   return op;
 }
 
@@ -2989,7 +2996,12 @@
 	fatal_at (token, "operator '%s' with arity %d does not match "
 		  "others with arity %d", oper, idb->nargs, arity);
 
-	  op->substitutes.safe_push (idb);
+	  if (user_id *p = dyn_cast (idb))
+	for (unsigned si = 0; si < p->substitutes.length (); ++si)
+	  op->substitutes.safe_push (p->substitutes[si]);
+	  else 
+	op->substitutes.safe_push (idb);
+
 	}
   op->nargs = arity;
   token = expect (CPP_CLOSE_PAREN);
@@ -3045,6 +3057,52 @@
 }
 }
 
+void
+parser::parse_operator_list ()
+{
+  const cpp_token *token = peek (); 
+  const char *id = get_ident ();
+
+  if (get_operator (id) != 0)
+fatal_at (token, "operator %s already defined", id);
+
+  user_id *op = new user_id (id, true);
+  int arity = -1;
+  
+  while ((token = peek_ident ()) != 0)
+{
+  token = peek (); 
+  const char *oper = get_ident ();
+  id_base *idb = get_operator (oper);
+  
+  if (idb == 0)
+	fatal_at (token, "no such operator '%s'", oper);
+
+  if (arity == -1)
+	arity = idb->nargs;
+  else if (idb->nargs == -1)
+	;
+  else if (arity != idb->nargs)
+	fatal_at (token, "operator '%s' with arity %d does not match "
+			 "others with arity %d", oper, idb->nargs, arity);
+
+  if (user_id *p = dyn_cast (idb)) // we don't need to check for ->is_oper_list here.
+	for (unsigned i = 0; i < p->substitutes.length (); ++i)
+	  op->substitutes.safe_push (p->substitutes[i]);
+  else
+	op->substitutes.safe_push (idb);
+}
+
+  if (op->substitutes.length () == 0)
+fatal_at (token, "operator-list cannot be empty");
+
+  op->nargs = arity;
+  id_base **slot = operators->find_slot_with_hash (op, op->hashval, INSERT);
+  *slot = op;
+}
+
+
+
 /* Parse an outer if expression.
  if = '(' 'if' '('  ')'  ')'  */
 
@@ -3145,6 +3203,13 @@
 	fatal_at (token, "define_predicates inside if or for is not supported");
   parse_predicates (token->src_loc);
 }
+  else if (strcmp (id, "define_operator_list") == 0)
+{
+  if (active_ifs.length () > 0
+	  || active_fors.length () > 0)
+	fatal_at (token, "operator-list cannot be defined inside 'for' or 'if'");
+  parse_operator_list ();
+}
   else
 fatal_at (token, "expected %s'simplify', 'match', 'for' or 'if'",
 	  active_ifs.length () == 0 && active_fors.length () == 0
Index: gcc/match-comparison.pd
===
--- gcc/match-comparison.pd	(revision 216916)
+++ gcc/match-comparison.pd	(working copy)
@@ -1,5 +1,8 @@
 /* From fold_binary.  */
 
+(define_operator_list eq_ops eq ne)
+(define_operator_list cc eq_ops lt le gt ge)
+
 /* On GIMPLE bool != 0 is simply the canonical way to express a
condition in COND_EXPRs and GIMPLE_CONDs.
???  Of course for assignments we still may want to strip those...  */
@@ -15,7 +18,7 @@
 @0)))
 
 /* Distribute operations in equality compares.  */
-(for op (eq ne)
+(for op (eq_ops)
  /* -exp op CST is exp op -CST.  */
  (simplify
   /* ??? fix fold-const to use negate_expr_p  */
@@ -29,7 +32,7 @@
 /* From fold_comparison, in the order of transforms in there.  */
 

Re: [PATCH] Merge from match-and-simplify, remove fold_unary dispatch from fold_stmt

[Richard Biener]

On Fri, Oct 31, 2014 at 2:07 PM, Richard Biener
 wrote:
> This implements the last pattern from fold_unary that covers
> inputs that can come from a GIMPLE_UNARY_RHS assignment
> and thus allows removal of the fold_unary dispatch from fold_stmt
> and gimple_fold_stmt_to_constant_1.  Remember that to not cause
> regressions it is enough to cover cases that do not need SSA
> name use-def following.  Also remember that gimple_simplify
> still dispatches to fold_unary for all tcc_constant operands.
>
> The next goal is obviously to remove the GIMPLE_BINARY_RHS and
> GIMPLE_TERNARY_RHS dispatches to fold_binary/ternary.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

The following is what I applied.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

Richard.

2014-11-03  Richard Biener  

* match.pd: Add two abs patterns.  Announce tree_expr_nonnegative_p.
Also drop bogus FLOAT_EXPR and FIX_TRUNC_EXPR.
* fold-const.c (fold_unary_loc): Remove them here.
(tree_unary_nonnegative_warnv_p): Use CASE_CONVERT.
* gimple-fold.c (fold_gimple_assign): Remove now obsolete
GIMPLE_UNARY_RHS case.
(gimple_fold_stmt_to_constant_1): Likewise.
(replace_stmt_with_simplification): Fix inverted comparison.


mas-merge-10
Description: Binary data

SRA: don't drop clobbers

[Marc Glisse]

Hello,

now that the update_address_taken patch is in, let me re-post the SRA 
follow-up. With this patch, testcase pr60517.C (attached) has a use of an 
undefined variable at the time of the uninit pass. Sadly, while this 
warned with earlier versions of the other patch (when I was inserting 
default definitions of new variables), it does not anymore because we have 
TREE_NO_WARNING all over the place. Still, I believe this is a step in the 
right direction, and it passed bootstrap+testsuite (minus the new 
testcase). Would it be ok to commit the tree-sra.c change? Then I could 
close PR60770 (the warning itself is PR60517).


2014-11-03  Marc Glisse  

PR tree-optimization/60770
* tree-sra.c (clobber_subtree): New function.
(sra_modify_constructor_assign): Call it.

--
Marc GlisseIndex: gcc/testsuite/g++.dg/tree-ssa/pr60517.C
===
--- gcc/testsuite/g++.dg/tree-ssa/pr60517.C (revision 0)
+++ gcc/testsuite/g++.dg/tree-ssa/pr60517.C (working copy)
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O -Wall" } */
+
+struct B {
+double x[2];
+};
+struct A {
+B b;
+B getB() { return b; }
+};
+
+double foo(A a) {
+double * x = &(a.getB().x[0]);
+return x[0]; /* { dg-warning "" } */
+}
Index: gcc/tree-sra.c
===
--- gcc/tree-sra.c  (revision 217035)
+++ gcc/tree-sra.c  (working copy)
@@ -2716,20 +2716,51 @@ init_subtree_with_zero (struct access *a
   if (insert_after)
gsi_insert_after (gsi, ds, GSI_NEW_STMT);
   else
gsi_insert_before (gsi, ds, GSI_SAME_STMT);
 }
 
   for (child = access->first_child; child; child = child->next_sibling)
 init_subtree_with_zero (child, gsi, insert_after, loc);
 }
 
+/* Clobber all scalar replacements in an access subtree.  ACCESS is the the
+   root of the subtree to be processed.  GSI is the statement iterator used
+   for inserting statements which are added after the current statement if
+   INSERT_AFTER is true or before it otherwise.  */
+
+static void
+clobber_subtree (struct access *access, gimple_stmt_iterator *gsi,
+   bool insert_after, location_t loc)
+
+{
+  struct access *child;
+
+  if (access->grp_to_be_replaced)
+{
+  tree rep = get_access_replacement (access);
+  tree clobber = build_constructor (access->type, NULL);
+  TREE_THIS_VOLATILE (clobber) = 1;
+  gimple stmt = gimple_build_assign (rep, clobber);
+
+  if (insert_after)
+   gsi_insert_after (gsi, stmt, GSI_NEW_STMT);
+  else
+   gsi_insert_before (gsi, stmt, GSI_SAME_STMT);
+  update_stmt (stmt);
+  gimple_set_location (stmt, loc);
+}
+
+  for (child = access->first_child; child; child = child->next_sibling)
+clobber_subtree (child, gsi, insert_after, loc);
+}
+
 /* Search for an access representative for the given expression EXPR and
return it or NULL if it cannot be found.  */
 
 static struct access *
 get_access_for_expr (tree expr)
 {
   HOST_WIDE_INT offset, size, max_size;
   tree base;
 
   /* FIXME: This should not be necessary but Ada produces V_C_Es with a type of
@@ -3028,43 +3059,41 @@ enum assignment_mod_result { SRA_AM_NONE
 SRA_AM_REMOVED };  /* stmt eliminated */
 
 /* Modify assignments with a CONSTRUCTOR on their RHS.  STMT contains a pointer
to the assignment and GSI is the statement iterator pointing at it.  Returns
the same values as sra_modify_assign.  */
 
 static enum assignment_mod_result
 sra_modify_constructor_assign (gimple stmt, gimple_stmt_iterator *gsi)
 {
   tree lhs = gimple_assign_lhs (stmt);
-  struct access *acc;
-  location_t loc;
-
-  acc = get_access_for_expr (lhs);
+  struct access *acc = get_access_for_expr (lhs);
   if (!acc)
 return SRA_AM_NONE;
+  location_t loc = gimple_location (stmt);
 
   if (gimple_clobber_p (stmt))
 {
-  /* Remove clobbers of fully scalarized variables, otherwise
-do nothing.  */
+  /* Clobber the replacement variable.  */
+  clobber_subtree (acc, gsi, !acc->grp_covered, loc);
+  /* Remove clobbers of fully scalarized variables, they are dead.  */
   if (acc->grp_covered)
{
  unlink_stmt_vdef (stmt);
  gsi_remove (gsi, true);
  release_defs (stmt);
  return SRA_AM_REMOVED;
}
   else
-   return SRA_AM_NONE;
+   return SRA_AM_MODIFIED;
 }
 
-  loc = gimple_location (stmt);
   if (vec_safe_length (CONSTRUCTOR_ELTS (gimple_assign_rhs1 (stmt))) > 0)
 {
   /* I have never seen this code path trigger but if it can happen the
 following should handle it gracefully.  */
   if (access_has_children_p (acc))
generate_subtree_copies (acc->first_child, lhs, acc->offset, 0, 0, gsi,
 true, true, loc);
   return SRA_AM_MODIFIED;
 }
 

Re: [match-and-simplify] support operator list

[Jakub Jelinek]

On Mon, Nov 03, 2014 at 06:26:12PM +0530, Prathamesh Kulkarni wrote:
> --- gcc/match-comparison.pd   (revision 216916)
> +++ gcc/match-comparison.pd   (working copy)
> @@ -1,5 +1,8 @@
>  /* From fold_binary.  */
>  
> +(define_operator_list eq_ops eq ne)
> +(define_operator_list cc eq_ops lt le gt ge)

I think cc is a bad name for the macro, that usually stands for condition
code register.

Jakub

[PATCH] Optimize UBSAN_NULL checks, add sanopt.c

[Marek Polacek]

Another shot at optimizing redundant UBSAN_NULL statements.

This time we walk the dominator tree - that should result in
more effective optimization - and keep a list of UBSAN_NULL
statements that dominate the current block, see the comment
before sanopt_optimize_walker.  Statements coming from blocks
that are left during the CFG walk are lazily removed, but I
think that isn't really necessary: see the ??? comment.

E.g. on http://ur1.ca/iohtf this allowed us to drop 8 stmts.

I moved all of this into new sanopt.c file.
(I guess that file includes some headers that we in fact don't
need, but the header flattening doesn't make it easy to check,
there are too many of them.)

Bootstrapped(-ubsan)/regtested on x86_64-linux, ok for trunk?

2014-11-03  Marek Polacek  

* Makefile.in (OBJS): Add sanopt.o.
(GTFILES): Add sanopt.c.
* asan.h (asan_expand_check_ifn): Declare.
* asan.c (asan_expand_check_ifn): No longer static.
(class pass_sanopt, pass_sanopt::execute, make_pass_sanopt): Move...
* sanopt.c: ...here.  New file.
testsuite/
* c-c++-common/ubsan/align-2.c: Remove dg-output.
* c-c++-common/ubsan/align-4.c: Likewise.
* g++.dg/ubsan/null-1.C: Likewise.
* g++.dg/ubsan/null-2.C: Likewise.

diff --git gcc/Makefile.in gcc/Makefile.in
index 9c67fe2..f383032 100644
--- gcc/Makefile.in
+++ gcc/Makefile.in
@@ -1376,6 +1376,7 @@ OBJS = \
asan.o \
tsan.o \
ubsan.o \
+   sanopt.o \
tree-call-cdce.o \
tree-cfg.o \
tree-cfgcleanup.o \
@@ -2305,6 +2306,7 @@ GTFILES = $(CPP_ID_DATA_H) $(srcdir)/input.h 
$(srcdir)/coretypes.h \
   $(srcdir)/asan.c \
   $(srcdir)/ubsan.c \
   $(srcdir)/tsan.c \
+  $(srcdir)/sanopt.c \
   $(srcdir)/ipa-devirt.c \
   $(srcdir)/internal-fn.h \
   @all_gtfiles@
diff --git gcc/asan.c gcc/asan.c
index 8f146d2..79dede7 100644
--- gcc/asan.c
+++ gcc/asan.c
@@ -2497,7 +2497,7 @@ asan_finish_file (void)
 
 /* Expand the ASAN_{LOAD,STORE} builtins.  */
 
-static bool
+bool
 asan_expand_check_ifn (gimple_stmt_iterator *iter, bool use_calls)
 {
   gimple g = gsi_stmt (*iter);
@@ -2800,114 +2800,4 @@ make_pass_asan_O0 (gcc::context *ctxt)
   return new pass_asan_O0 (ctxt);
 }
 
-/* Perform optimization of sanitize functions.  */
-
-namespace {
-
-const pass_data pass_data_sanopt =
-{
-  GIMPLE_PASS, /* type */
-  "sanopt", /* name */
-  OPTGROUP_NONE, /* optinfo_flags */
-  TV_NONE, /* tv_id */
-  ( PROP_ssa | PROP_cfg | PROP_gimple_leh ), /* properties_required */
-  0, /* properties_provided */
-  0, /* properties_destroyed */
-  0, /* todo_flags_start */
-  TODO_update_ssa, /* todo_flags_finish */
-};
-
-class pass_sanopt : public gimple_opt_pass
-{
-public:
-  pass_sanopt (gcc::context *ctxt)
-: gimple_opt_pass (pass_data_sanopt, ctxt)
-  {}
-
-  /* opt_pass methods: */
-  virtual bool gate (function *) { return flag_sanitize; }
-  virtual unsigned int execute (function *);
-
-}; // class pass_sanopt
-
-unsigned int
-pass_sanopt::execute (function *fun)
-{
-  basic_block bb;
-
-  int asan_num_accesses = 0;
-  if (flag_sanitize & SANITIZE_ADDRESS)
-{
-  gimple_stmt_iterator gsi;
-  FOR_EACH_BB_FN (bb, fun)
-   for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
- {
-   gimple stmt = gsi_stmt (gsi);
-   if (is_gimple_call (stmt) && gimple_call_internal_p (stmt)
-   && gimple_call_internal_fn (stmt) == IFN_ASAN_CHECK)
- ++asan_num_accesses;
- }
-}
-
-  bool use_calls = ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD < INT_MAX
-&& asan_num_accesses >= ASAN_INSTRUMENTATION_WITH_CALL_THRESHOLD;
-
-  FOR_EACH_BB_FN (bb, fun)
-{
-  gimple_stmt_iterator gsi;
-  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); )
-   {
- gimple stmt = gsi_stmt (gsi);
- bool no_next = false;
-
- if (!is_gimple_call (stmt))
-   {
- gsi_next (&gsi);
- continue;
-   }
-
- if (gimple_call_internal_p (stmt))
-   {
- enum internal_fn ifn = gimple_call_internal_fn (stmt);
- switch (ifn)
-   {
-   case IFN_UBSAN_NULL:
- no_next = ubsan_expand_null_ifn (&gsi);
- break;
-   case IFN_UBSAN_BOUNDS:
- no_next = ubsan_expand_bounds_ifn (&gsi);
- break;
-   case IFN_UBSAN_OBJECT_SIZE:
- no_next = ubsan_expand_objsize_ifn (&gsi);
- break;
-   case IFN_ASAN_CHECK:
- no_next = asan_expand_check_ifn (&gsi, use_calls);
- break;
-   default:
- break;
-   }
-   }
-
- if (dump_file && (dump_flags & TDF_DETAILS))
-   {
- fprintf (dump_file, "Optimized\n  ");
- print_gimple_stmt (dump_file, stmt, 0, dump_flags);
- fprintf (dump_file, "\

[patch,avr] correct incorrect spec string for device specs

[Sivanupandi, Pitchumani]

Hi,

Unrecognized option error is issued by avr-gcc for devices with AVR_ISA_RMW.
This is because of an incorrect spec string device spec generation.

Below patch corrects the incorrect spec string in gen-avr-mmcu-specs.c.
If OK, could someone commit please?

diff --git a/gcc/config/avr/gen-avr-mmcu-specs.c 
b/gcc/config/avr/gen-avr-mmcu-specs.c
index 73bacf4..772e862 100644
--- a/gcc/config/avr/gen-avr-mmcu-specs.c
+++ b/gcc/config/avr/gen-avr-mmcu-specs.c
@@ -53,7 +53,7 @@ print_mcu (const avr_mcu_t *mcu)
 ? " -msp8" : " %dev_attribute & AVR_ERRATA_SKIP) ? " -mskip-bug" : "";
-  rmw = (mcu->dev_attribute & AVR_ISA_RMW) ? "%%{!mno-rmw: -mrmw}" : "";
+  rmw = (mcu->dev_attribute & AVR_ISA_RMW) ? "%{!mno-rmw: -mrmw}" : "";
 
   const char *arch_name = avr_arch_types[mcu->arch].arch_name;

Regards,
Pitchumani

Gcc/ChangeLog

2014-11-03  Pitchumani Sivanupandi  

 

* config/avr/gen-avr-mmcu-specs.c: Remove unnecessary format specifier.

Re: [PATCH v3] Fix PR56480 aka DR374. Allow explicit specialization in enclosing namespace.

[Jason Merrill]

On 11/03/2014 05:27 AM, Markus Trippelsdorf wrote:

BTW both EDG and clang reject g++.dg/template/spec17.C:

namespace io {
   template  int foo();
}
using namespace io;
template<> int foo();

But I think it is a reasonable extension to accept it.


We should reject it, too.  We can only leave out the namespace 
qualification with inline namespaces.



+// { dg-options "-pedantic -pedantic-errors" }


You shouldn't need these dg-options lines; if a testcase has no 
dg-options line, -pedantic-errors is the default.


Jason

Re: [C++ PING^2] Re: [PATCH 5/5] Add illegal cilk checks to C++ front.

[Andi Kleen]

Andi Kleen  writes:

Ping!^2

> Andi Kleen  writes:
>
> Ping!
>
> Can someone from the C++ side please approve this patch?
> That's the only patch not approved in this patch kit, but blocking
> the commit.
>
> -Andi
>
>> From: Andi Kleen 
>>
>> Add calls for several illegal Cilk cases to the C++ frontend.
>> C++ usually doesn't ICE unlike C on illegal cilk, but it's
>> better to match C in what is allowed and what is not.
>>
>> if (_Cilk_spawn ...) is still not errored, but at least it doesn't ICE.
>>
>> gcc/cp/:
>>
>> 2014-09-30  Andi Kleen  
>>
>>  * semantics.c (finish_goto_stmt): Call check_no_cilk.
>>  (finish_while_stmt_cond): Dito.
>>  (finish_do_stmt): Dito.
>>  (finish_for_cond): Dito.
>>  (finish_switch_cond): Dito.
>> ---
>>  gcc/cp/semantics.c | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
>> index 7569826..9ca03be 100644
>> --- a/gcc/cp/semantics.c
>> +++ b/gcc/cp/semantics.c
>> @@ -621,6 +621,8 @@ finish_goto_stmt (tree destination)
>>  TREE_USED (destination) = 1;
>>else
>>  {
>> +  if (check_no_cilk (destination, "as a computed goto expression"))
>> +destination = error_mark_node;
>>destination = mark_rvalue_use (destination);
>>if (!processing_template_decl)
>>  {
>> @@ -792,6 +794,8 @@ begin_while_stmt (void)
>>  void
>>  finish_while_stmt_cond (tree cond, tree while_stmt, bool ivdep)
>>  {
>> +  if (check_no_cilk (cond, "as a condition for while statement"))
>> +cond = error_mark_node;
>>cond = maybe_convert_cond (cond);
>>finish_cond (&WHILE_COND (while_stmt), cond);
>>begin_maybe_infinite_loop (cond);
>> @@ -847,6 +851,8 @@ finish_do_body (tree do_stmt)
>>  void
>>  finish_do_stmt (tree cond, tree do_stmt, bool ivdep)
>>  {
>> +  if (check_no_cilk (cond, "as a condition for a do-while statement"))
>> +cond = error_mark_node;
>>cond = maybe_convert_cond (cond);
>>end_maybe_infinite_loop (cond);
>>if (ivdep && cond != error_mark_node)
>> @@ -956,6 +962,8 @@ finish_for_init_stmt (tree for_stmt)
>>  void
>>  finish_for_cond (tree cond, tree for_stmt, bool ivdep)
>>  {
>> +  if (check_no_cilk (cond, "in a condition for a for-loop"))
>> +cond = error_mark_node;
>>cond = maybe_convert_cond (cond);
>>finish_cond (&FOR_COND (for_stmt), cond);
>>begin_maybe_infinite_loop (cond);
>> @@ -1118,6 +1126,10 @@ void
>>  finish_switch_cond (tree cond, tree switch_stmt)
>>  {
>>tree orig_type = NULL;
>> +
>> +  if (check_no_cilk (cond, "as a condition for switch statement"))
>> +cond = error_mark_node;
>> +
>>if (!processing_template_decl)
>>  {
>>/* Convert the condition to an integer or enumeration type.  */

-- 
a...@linux.intel.com -- Speaking for myself only

Re: [COMMITTED][PATCH PR63173] [AARCH64, NEON] Improve vld[234](q?)_dup intrinsics

[Alan Lawrence]

So we've been seeing

FAIL: gcc.target/aarch64/vldN_dup_1.c

on aarch64_be-none-elf, since this patch went in. Felix, did you test for 
bigendian?

However, this failure is fixed if I apply David Sherwood's patch set:

https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00942.html
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01099.html

So maybe I can "ping" that on David's behalf (+Alan Hayward's 
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00952.html on which those two 
patches depend).


Cheers, Alan



Yangfei (Felix) wrote:

On 24 October 2014 03:21, Yangfei (Felix)  wrote:


Thanks for the comments. I updated the patch with the intrinsic moved to its

place.

Attached please find the new version of the patch.
OK for the trunk?


Index: gcc/ChangeLog


=
==

--- gcc/ChangeLog   (revision 216558)
+++ gcc/ChangeLog   (working copy)
@@ -1,3 +1,39 @@
+2014-10-23  Felix Yang  
+   Jiji Jiang 

Double space before "<".  Otherwise OK.
Thanks /Marcus


Committed to trunk as r216630 with the space issue fixed. Thanks.

Re: [PATCH]Partially fix PR61529, bound basic block frequency

[Renlin Li]

On 29/10/14 12:42, Teresa Johnson wrote:

Hi Renlin,

Are the incoming edge counts or probabilities insane in this case? I
guess the patch is ok if we need to do this to handle those incoming
insanitiles. But I can't approve patches myself.


Not really, it's just a little bigger than the limit.

For this particular test case, ABC is a threaded path.
B is the fallthrough basic block of A, D is a basic block split from B 
(used to be a self loop). A, B and D have roughly the same frequency ( 
8281, 9100, 8281).
When calculating the path_in_freq, frequencies from AB and DB edges are 
accumulated, and the final result is large than BB_FREQ_MAX.



  A
100% |
  |  9%
-->B-->C
| |
|100%| 91%
| |
D



There are 2 suspicious points:
1, The BD edge is not correctly guessed at the profile stage. However, 
anyway it's heuristic, so I don't think, it's here the problem starts.
2, The BD edge is not eliminated before jump threading. But the jump 
threading pass will analysis the condition jump statement in B block (In 
this particular case, the BD probability should be zero), and makes the 
decision to thread it.


Later in the dom pass, the BD edge is indeed removed.


However, this is a fix to code (r215739) committed after the ICE in
the original bug report and in comment 2 were reported, so I wonder if
it is just hiding the original problem. Originally this was reported
to be due to r210538 - ccing Dehao who was the author of that patch.
Dehao, did you get a chance to look at this bug and see why your
change triggered it? It is possible that Dehao's patch simply
amplified an even further upstream profile insanity, but it would be
good to confirm.

Thanks!
Teresa

On Wed, Oct 29, 2014 at 2:26 AM, Renlin Li  wrote:

Hi all,

This is a simple patch to fix ICE in comment 2 of PR61529:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529

Bound checking code is added to make sure the frequency is within legal
range.

As far as I have observed, r215830 patch fixes the glibc building ICE. And
this patch should fix the ICE while building the sample code in comment 2
using aarch64-none-elf toolchain. Until now, all the ICEs reported in this
bug ticket should be fixed.

x86_64-unknown-linux-gnu bootstrap and regression test have been done, no
new issue.
aarch64-none-elf toolchain has been test on the model. No new regression.

Is this Okay for trunk?

gcc/ChangeLog:

2014-10-29  Renlin Li
  PR middle-end/61529
 * tree-ssa-threadupdate.c (compute_path_counts): Bound path_in_freq.

Re: [PATCH] Optimize UBSAN_NULL checks, add sanopt.c

[Jakub Jelinek]

On Mon, Nov 03, 2014 at 03:27:57PM +0100, Marek Polacek wrote:
> I moved all of this into new sanopt.c file.
> (I guess that file includes some headers that we in fact don't
> need, but the header flattening doesn't make it easy to check,
> there are too many of them.)

Well, in theory you could just script removing them one by one and just
make sanopt.o after each step to see if the header is or is not needed,
perhaps with some manual tweeks.

> +/* This is used to carry information about basic blocks.  It is
> +   attached to the AUX field of the standard CFG block.  */
> +
> +struct sanopt_info
> +{
> +  /* True if this BB has been visited.  */
> +  bool visited_p;
> +};
> +
> +
> +/* Try to optimize away redundant UBSAN_NULL checks.
> +   
> +   We walk blocks in the CFG via a depth first search of the dominator
> +   tree; we push unique UBSAN_NULL statements into a vector in the
> +   NULL_CHECK_MAP as we enter the blocks.  When leaving a block, we
> +   mark the block as visited; then when checking the statements in the
> +   vector, we ignore statements that are coming from already visited
> +   blocks, because these cannot dominate anything anymore.  */
> +
> +static void
> +sanopt_optimize_walker (basic_block bb,
> + hash_map > *map)

Perhaps in preparation for future optimizations (other UBSAN_*
calls, and ASAN_CHECK and tsan builtins), you should consider
putting the hash_map into some structure and pass address of that
structure instead, so that you have all the pass context at the same spot.
You could put asan_num_accesses in there too, see below.

> +   /* We already have recorded a UBSAN_NULL check
> +  for this pointer.  Perhaps we can drop this one.
> +  But only if this check doesn't specify stricter
> +  alignment.  */
> +   int i;
> +   gimple g;
> +
> +   FOR_EACH_VEC_ELT (v, i, g)
> + {
> +   /* Remove statements for BBs that have been
> +  already processed.  */
> +   sanopt_info *si = (sanopt_info *) gimple_bb (g)->aux;
> +   if (si->visited_p)
> + {
> +   /* ??? This might be unneccesary; we could just
> +  skip the stale statements.  */
> +   v.unordered_remove (i);
> +   continue;
> + }

I think it would be better to walk the vector backwards instead of forward.
1) if you have the same SSA_NAME there multiple times, ignoring the already
   unnecessary stmts, the only case where you'd have multiple stmts is
   if the earlier stmts dominate the following stmts and for some reason
   weren't optimized away; that for some reason currently should be
   just higher required alignment in the dominated stmt (e.g. say have
   UBSAN_NULL (foo_23, 0); UBSAN_NULL (foo_23, 2); UBSAN_NULL (foo_23, 4);
   where the first stmt dominates the second two and second stmt dominates
   the last one.
2) All the si->visited_p stmts should be always at the end of the vector
   IMHO, preceeded only by !si->visited_p stmts.
Thus, when walking backwards, first remove the stmts with bb->visited_p,
once you hit one that doesn't have it set, I believe there shouldn't be any
further.  And then in theory it should be fine to just compare the last
stmt in the vector that was left (if any).

> +unsigned int
> +pass_sanopt::execute (function *fun)
> +{
> +  basic_block bb;
> +
> +  /* Try to remove redundant checks.  */
> +  if (optimize
> +  && (flag_sanitize & (SANITIZE_NULL | SANITIZE_ALIGNMENT)))
> +sanopt_optimize (fun);

Perhaps you could return the asan_num_accesses value computed during
sanopt_optimize (just count IFN_ASAN_CHECK calls that you don't optimize
away), and do this only in else if (i.e. when sanopt_optimize has not been
run).  That way, you'd save one extra IL walk.

> +  if (flag_sanitize & SANITIZE_ADDRESS)
> +{
> +  gimple_stmt_iterator gsi;
> +  FOR_EACH_BB_FN (bb, fun)
> + for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> +   {
> + gimple stmt = gsi_stmt (gsi);
> + if (is_gimple_call (stmt) && gimple_call_internal_p (stmt)
> + && gimple_call_internal_fn (stmt) == IFN_ASAN_CHECK)
> +   ++asan_num_accesses;
> +   }
> +}

Otherwise LGTM, thanks for working on this.

Jakub

Re: SRA: don't drop clobbers

[Martin Jambor]

Hi,

On Mon, Nov 03, 2014 at 01:59:24PM +0100, Marc Glisse wrote:
> Hello,
> 
> now that the update_address_taken patch is in, let me re-post the
> SRA follow-up. With this patch, testcase pr60517.C (attached) has a
> use of an undefined variable at the time of the uninit pass. Sadly,
> while this warned with earlier versions of the other patch (when I
> was inserting default definitions of new variables), it does not
> anymore because we have TREE_NO_WARNING all over the place. Still, I
> believe this is a step in the right direction, and it passed
> bootstrap+testsuite (minus the new testcase).

I am not sure what you mean by "minus the new testcase" but, with the
gimple checking compiler at least, the testcase produces an ICE:

  pr60517.C: In function ‘double foo(A)’:
  pr60517.C:15:1: error: non-decl/MEM_REF LHS in clobber statement
   }
   ^
  SR.1_8
  SR.1_8 ={v} {CLOBBER};
  pr60517.C:15:1: internal compiler error: verify_gimple failed
  0xc7810d verify_gimple_in_cfg(function*, bool)
  /home/mjambor/gcc/mine/src/gcc/tree-cfg.c:5039
  0xb8256f execute_function_todo
  /home/mjambor/gcc/mine/src/gcc/passes.c:1758
  0xb83183 execute_todo
  /home/mjambor/gcc/mine/src/gcc/passes.c:1815

The problem is exactly what the verifier complains about, a clobber of
an SSA_NAME which I agree with the verifier is a really bad idea.

If you want SRA to produce information that at a given point a scalar
replacement (which will become an SSA_NAME) does not have any valid
data, the way to represent that is to load it with a value from a
default-definition SSA name.  Something along the lines of
get_repl_default_def_ssa_name which unfortunately you cannot directly
use without confusing the SSA renamer.

The easiest way, at least to test a proof of concept, is probably to
create another declaration of the same type (reusing bits from
create_access_replacement, especially setting the same
DECL_DEBUG_EXPR), get its default-definition using
get_or_create_ssa_default_def and then assign that to the replacement
instead of trying to clobber it.

(A more correct approach would be to design a way of telling the
renamer that at this point the scalar becomes undefined and that it
should start using default-defs until the next definition appears but
that is likely to be difficult, although that is just my guess, it
might be easy.)

> Would it be ok to commit the tree-sra.c change?

I don't think so, sorry about the bad news.

Martin

Re: [match-and-simplify] support operator list

[Richard Biener]

On Mon, Nov 3, 2014 at 2:01 PM, Jakub Jelinek  wrote:
> On Mon, Nov 03, 2014 at 06:26:12PM +0530, Prathamesh Kulkarni wrote:
>> --- gcc/match-comparison.pd   (revision 216916)
>> +++ gcc/match-comparison.pd   (working copy)
>> @@ -1,5 +1,8 @@
>>  /* From fold_binary.  */
>>
>> +(define_operator_list eq_ops eq ne)
>> +(define_operator_list cc eq_ops lt le gt ge)
>
> I think cc is a bad name for the macro, that usually stands for condition
> code register.

OTOH it is a perfect match for 'condition code'.

Richard.

> Jakub

[PATCH] Adjust conversion handling in operation_could_trap_helper_p, gimplify CONVERT_EXPR as NOP_EXPR

[Richard Biener]

$subject, as suggested by Joseph and Jakub

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.

Richard.

2014-11-03  Richard Biener  

* tree-eh.c (operation_could_trap_helper_p): Handle conversions
like ordinary operations.
* gimplify.c (gimplify_conversion): Gimplify CONVERT_EXPR
as NOP_EXPR.

Index: gcc/tree-eh.c
===
--- gcc/tree-eh.c   (revision 217046)
+++ gcc/tree-eh.c   (working copy)
@@ -2436,11 +2436,6 @@ operation_could_trap_helper_p (enum tree
 case UNEQ_EXPR:
   return honor_snans;
 
-case CONVERT_EXPR:
-case FIX_TRUNC_EXPR:
-  /* Conversion of floating point might trap.  */
-  return honor_nans;
-
 case NEGATE_EXPR:
 case ABS_EXPR:
 case CONJ_EXPR:
Index: gcc/gimplify.c
===
--- gcc/gimplify.c  (revision 217046)
+++ gcc/gimplify.c  (working copy)
@@ -1739,6 +1739,10 @@ gimplify_conversion (tree *expr_p)
 *expr_p = fold_build1_loc (loc, VIEW_CONVERT_EXPR, TREE_TYPE (*expr_p),
   TREE_OPERAND (*expr_p, 0));
 
+  /* Canonicalize CONVERT_EXPR to NOP_EXPR.  */
+  if (TREE_CODE (*expr_p) == CONVERT_EXPR)
+TREE_SET_CODE (*expr_p, NOP_EXPR);
+
   return GS_OK;
 }
 

Re: [match-and-simplify] support operator list

[Jakub Jelinek]

On Mon, Nov 03, 2014 at 04:46:43PM +0100, Richard Biener wrote:
> On Mon, Nov 3, 2014 at 2:01 PM, Jakub Jelinek  wrote:
> > On Mon, Nov 03, 2014 at 06:26:12PM +0530, Prathamesh Kulkarni wrote:
> >> --- gcc/match-comparison.pd   (revision 216916)
> >> +++ gcc/match-comparison.pd   (working copy)
> >> @@ -1,5 +1,8 @@
> >>  /* From fold_binary.  */
> >>
> >> +(define_operator_list eq_ops eq ne)
> >> +(define_operator_list cc eq_ops lt le gt ge)
> >
> > I think cc is a bad name for the macro, that usually stands for condition
> > code register.
> 
> OTOH it is a perfect match for 'condition code'.

So eqcodes and ccodes, or comp_code, ... ?
Saving a few keystrokes there can be a problem for readability.
Not to mention that there are various other tcc_comparison codes (lggt,
unordered, ordered, un{lt,le,gt,ge,eq}).

Jakub

Re: SRA: don't drop clobbers

[Marc Glisse]

On Mon, 3 Nov 2014, Martin Jambor wrote:


On Mon, Nov 03, 2014 at 01:59:24PM +0100, Marc Glisse wrote:

Hello,

now that the update_address_taken patch is in, let me re-post the
SRA follow-up. With this patch, testcase pr60517.C (attached) has a
use of an undefined variable at the time of the uninit pass. Sadly,
while this warned with earlier versions of the other patch (when I
was inserting default definitions of new variables), it does not
anymore because we have TREE_NO_WARNING all over the place. Still, I
believe this is a step in the right direction, and it passed
bootstrap+testsuite (minus the new testcase).


I am not sure what you mean by "minus the new testcase" but, with the
gimple checking compiler at least, the testcase produces an ICE:

 pr60517.C: In function ‘double foo(A)’:
 pr60517.C:15:1: error: non-decl/MEM_REF LHS in clobber statement
  }
  ^
 SR.1_8
 SR.1_8 ={v} {CLOBBER};
 pr60517.C:15:1: internal compiler error: verify_gimple failed
 0xc7810d verify_gimple_in_cfg(function*, bool)
 /home/mjambor/gcc/mine/src/gcc/tree-cfg.c:5039
 0xb8256f execute_function_todo
 /home/mjambor/gcc/mine/src/gcc/passes.c:1758
 0xb83183 execute_todo
 /home/mjambor/gcc/mine/src/gcc/passes.c:1815

The problem is exactly what the verifier complains about, a clobber of
an SSA_NAME which I agree with the verifier is a really bad idea.

If you want SRA to produce information that at a given point a scalar
replacement (which will become an SSA_NAME) does not have any valid
data, the way to represent that is to load it with a value from a
default-definition SSA name.  Something along the lines of
get_repl_default_def_ssa_name which unfortunately you cannot directly
use without confusing the SSA renamer.

The easiest way, at least to test a proof of concept, is probably to
create another declaration of the same type (reusing bits from
create_access_replacement, especially setting the same
DECL_DEBUG_EXPR), get its default-definition using
get_or_create_ssa_default_def and then assign that to the replacement
instead of trying to clobber it.

(A more correct approach would be to design a way of telling the
renamer that at this point the scalar becomes undefined and that it
should start using default-defs until the next definition appears but
that is likely to be difficult, although that is just my guess, it
might be easy.)


Would it be ok to commit the tree-sra.c change?


I don't think so, sorry about the bad news.


Thanks for your help. I am quite confused. I am not seeing the failure you 
mention, but since I am building from trunk with no specific option I 
should be getting gimple checking.


The way I expect things to work:
1) we have a clobber for a variable V
2) SRA creates a variable SR and replaces uses of V
3) (new) next to V's clobber, we insert a clobber for SR
4) update_address_taken notices that SR does not have its address taken, 
and thus replaces it by SSA_NAMEs, and after the clobber by an undefined 
variable (yesterday it would just have removed the clobber).


What you describe in a parenthesis about the renamer is pretty much what I 
think rewrite_update_stmt does, with the clobber as the hint.


Do you have further comments, based on these explanations, that could help 
me pinpoint what is going wrong?


--
Marc Glisse

Re: [PATCH 23/27] Documentation: the "intro" subdirectory

[Jeff Law]

On 10/31/14 15:44, David Malcolm wrote:


I don't see #26 or #27 in the series?  Were they particularly large?


Yes: I deliberately didn't send 19, 26, 27 as they were large (170k and
up), and are essentially already approved:

OK.  No worries then.

Jeff

Re: [PATCH] FreeBSD arm support, EABI.

[Andreas Tobler]

Hi Kyrill,

On 03.11.14 12:44, Kyrill Tkachov wrote:


CC'ing arm maintainers and a couple of comments inline.


Thank you!


On 02/11/14 22:11, Andreas Tobler wrote:

Hello all,

this is a patch which brings support for arm*-*-freebsd* to trunk.
The architectures supported are arm-*-*freebsd*, armv6-*-freebsd* and
armv6hf-*-freebsd*.
armv6 stands for ARM_ARCH == 6, arm stands for ARM_ARCH < 6.


Why split at ARM_ARCH == 6 ? I see in the patch you define
TARGET_FREEBSD_ARMv6 but
only ever use it to define the SUBTARGET_CPU_DEFAULT. In the other arm
triplets I don't think
we have architecture-specific identifiers in the arm* parts...


Well, I mentioned it in another response, it was unfortunate from me to 
write the equal sign. What we currently do is the following:


ARM_ARCH >= 6 becomes armv6*-*-freebsd*
ARM_ARCH <= 5 becomes arm-*-freebsd*

So, would you suggest to leave the SUBTARGET_CPU_DEFAULT away?


+
+#if defined (TARGET_FREEBSD_ARMv6)
+#undef  SUBTARGET_CPU_DEFAULT
+#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm1176jzs
+#else
+#undef  SUBTARGET_CPU_DEFAULT
+#define SUBTARGET_CPU_DEFAULT   TARGET_CPU_arm9
+#endif
+


What about ARMv7? The default CPU there is TARGET_CPU_cortexa8


Would fall under armv6 with the above rule.


Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 217020)
+++ gcc/config.gcc  (working copy)
@@ -259,7 +259,6 @@
  arm*-wince-pe*\
| arm*-*-ecos-elf   \
| arm*-*-elf\
- | arm*-*-freebsd* \
| arm*-*-linux* \
| arm*-*-uclinux*   \
| i[34567]86-go32-* \
@@ -1000,6 +999,27 @@
extra_options="${extra_options} arm/vxworks.opt"
tmake_file="${tmake_file} arm/t-arm arm/t-vxworks"
;;
+arm*-*-freebsd*)# ARM FreeBSD EABI
+   tm_file="dbxelf.h elfos.h ${fbsd_tm_file} arm/elf.h"
+   case $target in
+   arm*b-*-freebsd*)
+   tm_defines="${tm_defines} TARGET_BIG_ENDIAN_DEFAULT=1"
+   ;;
+   esac
+   tmake_file="${tmake_file} arm/t-arm arm/t-bpabi"
+   tm_file="${tm_file} arm/bpabi.h arm/freebsd.h arm/aout.h arm/arm.h"
+   case $target in
+   armv[67]*-*-freebsd*)
+   tm_defines="${tm_defines} TARGET_FREEBSD_ARMv6=1"
+   ;;
+   esac


So you also match armv7*-*-freebsd*. As mentioned above I'm not sure why
we would want these per-architecture triplets. If we do want to have
these per-architecture triplets, there is also the ARMv8 AArch32 state
which is supported in the arm backend and can be identified by ARM_ARCH
== 8. Do we want to add an armv8*-*-freebsd triplet as well?


Aehm, this is left over from a trial where I tried an 
armv7hf-*-freebsd*. This does not exist yet and I'm not sure if we 
really want that.


Regarding armv8, for the 64-bit there will be another triplet. armv8 
with AArch32 would also fall under armv6 now, but I can not say how it 
would behave, I lack the hardware ;)


Thanks for the feedback.

Andreas

Re: [libgomp, libiberty, libobjc] Fix gnu11 fallout on Solaris 10+

[Rainer Orth]

Richard Henderson  writes:

> On 10/24/2014 01:56 AM, Rainer Orth wrote:
>> And even with the _XOPEN_SOURCE business out of the way, there's still
>> the question what to do about _POSIX_SOURCE in libiberty/sigsetmask.c.
>> Given that it was introduced almost 20 years ago, it may well be
>> unnecessary for the systems we still care about.
>
> Probably.

I've included the following patch in my Solaris 10, 11, and Linux/x86_64
bootstraps for some time now.  I guess the risk of just defining
_XOPEN_SOURCE to 600 is manageable and eventual fallout restricted to
GCC; not sure about the libiberty change, given that it probably
supports far more and older systems than GCC does.

Anyway: ok for mainline?

Thanks.
Rainer


2014-10-22  Rainer Orth  

libobjc:
* thr.c (_XOPEN_SOURCE): Define as 600.

libiberty:
* sigsetmask.c (_POSIX_SOURCE): Remove.

libgomp:
* config/posix/lock.c (_XOPEN_SOURCE) Define as 600.

# HG changeset patch
# Parent 0ae9b18fcb6f31523dd31f1825a3bb540ad84289
Fix gnu11 fallout on Solaris 10+

diff --git a/libgomp/config/posix/lock.c b/libgomp/config/posix/lock.c
--- a/libgomp/config/posix/lock.c
+++ b/libgomp/config/posix/lock.c
@@ -30,8 +30,9 @@
to do better and streamline the locking as well as reduce the size
of the types exported.  */
 
-/* We need Unix98 extensions to get recursive locks.  */
-#define _XOPEN_SOURCE 500
+/* We need UNIX98/XPG5 extensions to get recursive locks.  Request XPG6 since
+   Solaris requires this for C99 and later.  */
+#define _XOPEN_SOURCE 600
 
 #include "libgomp.h"
 
diff --git a/libiberty/sigsetmask.c b/libiberty/sigsetmask.c
--- a/libiberty/sigsetmask.c
+++ b/libiberty/sigsetmask.c
@@ -15,7 +15,6 @@ be the value @code{1}).
 
 */
 
-#define _POSIX_SOURCE
 #include 
 /* Including  seems to be needed by ISC. */
 #include 
diff --git a/libobjc/thr.c b/libobjc/thr.c
--- a/libobjc/thr.c
+++ b/libobjc/thr.c
@@ -27,8 +27,9 @@ see the files COPYING3 and COPYING.RUNTI
 #define _LIBOBJC
 /* The line below is needed for declarations of functions such as
pthread_mutexattr_settype, without which gthr-posix.h may fail to
-   compile within libobjc.  */
-#define _XOPEN_SOURCE 500
+   compile within libobjc.  While we only need XPG5 for this, Solaris
+   requires XPG6 for C99 and later.  */
+#define _XOPEN_SOURCE 600
 #include "config.h"
 #include "tconfig.h"
 #include "coretypes.h"

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

libgo patch committed: Use -dumpversion rather than looking at BASE-VER

[Ian Taylor]

This patch from Peter Collingbourne changes the libgo install to get
the version number from gccgo -dumpversion rather than looking at the
BASE-VER file in the gcc source directory.  Bootstrapped on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian
diff -r 21b8b46b67f2 libgo/Makefile.am
--- a/libgo/Makefile.am Tue Oct 28 15:56:23 2014 -0700
+++ b/libgo/Makefile.am Mon Nov 03 08:29:13 2014 -0800
@@ -15,7 +15,7 @@
 
 SUBDIRS = ${subdirs}
 
-gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER)
+gcc_version := $(shell $(GOC) -dumpversion)
 
 MAINT_CHARSET = latin1
 

Re: [patch,avr] correct incorrect spec string for device specs

[Joern Rennecke]

On 3 November 2014 14:33, Sivanupandi, Pitchumani
 wrote:
> Hi,
>
> Unrecognized option error is issued by avr-gcc for devices with AVR_ISA_RMW.
> This is because of an incorrect spec string device spec generation.
>
> Below patch corrects the incorrect spec string in gen-avr-mmcu-specs.c.
> If OK, could someone commit please?
>
> diff --git a/gcc/config/avr/gen-avr-mmcu-specs.c 
> b/gcc/config/avr/gen-avr-mmcu-specs.c
> index 73bacf4..772e862 100644
> --- a/gcc/config/avr/gen-avr-mmcu-specs.c
> +++ b/gcc/config/avr/gen-avr-mmcu-specs.c
> @@ -53,7 +53,7 @@ print_mcu (const avr_mcu_t *mcu)
>  ? " -msp8" : " %
>errata_skip = (mcu->dev_attribute & AVR_ERRATA_SKIP) ? " -mskip-bug" : "";
> -  rmw = (mcu->dev_attribute & AVR_ISA_RMW) ? "%%{!mno-rmw: -mrmw}" : "";
> +  rmw = (mcu->dev_attribute & AVR_ISA_RMW) ? "%{!mno-rmw: -mrmw}" : "";
>
>const char *arch_name = avr_arch_types[mcu->arch].arch_name;
>
> Regards,
> Pitchumani
>
> Gcc/ChangeLog
>
> 2014-11-03  Pitchumani Sivanupandi 
>
> * config/avr/gen-avr-mmcu-specs.c: Remove unnecessary format specifier.

Oops, indeed.  Although the way I'd put it is that what you're removing is an
extraneous %-printf quoting - extraneous because the variable rmw is not
actually a format string, but a string that is emitted under control
of format strings.

Re: [AArch64, Patch] Restructure arm_neon.h vector types's implementation(Take 2).

[Marcus Shawcroft]

On 1 October 2014 09:26, Tejas Belagod  wrote:
> Hi,
>
> Returning to this old thread,
>
> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02285.html
>
> here is a patch after a few rounds of review comments, specifically:
>
> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02248.html
> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02285.html
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00566.html
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00324.html
>
> Sorry for the delay in respinning this patch.
>
> Tested on aarch64-none-elf. OK for trunk?
>
> Thanks,
> Tejas.
>
> Changelog:
>
> 2014-10-01  Tejas Belagod  
>
> * config/aarch64/aarch64-builtins.c
> (aarch64_build_scalar_type): Remove.
> (aarch64_scalar_builtin_types, aarch64_simd_type,
> aarch64_simd_type, aarch64_mangle_builtin_scalar_type,
> aarch64_mangle_builtin_vector_type,
> aarch64_mangle_builtin_type, aarch64_simd_builtin_std_type,
> aarch64_lookup_simd_builtin_type, aarch64_simd_builtin_type,
> aarch64_init_simd_builtin_types,
> aarch64_init_simd_builtin_scalar_types): New.
> (aarch64_init_simd_builtins): Refactor.
> (aarch64_init_crc32_builtins): Fixup with qualifier.
> * config/aarch64/aarch64-protos.h
> (aarch64_mangle_builtin_type): Export.
> * config/aarch64/aarch64-simd-builtin-types.def: New.
> * config/aarch64/aarch64.c (aarch64_simd_mangle_map): Remove.
> (aarch64_mangle_type): Refactor.
> * config/aarch64/arm_neon.h: Declare vector types based on
> internal types.
> * config/aarch64/t-aarch64: Update dependency.

OK /Marcus

[libcc1, build] Enable libcc1 on Solaris

[Rainer Orth]

I noticed that the new libcc1 wasn't built on Solaris.  This happens
because socketpair doesn't live in libc, but in libsocket instead.  To
deal with this, I've copied the libgo (and libjava) code to detect the
need for libsocket and libnsl.  Once the build was attempted, two
failures had to be dealt with:

* FD_ZERO and friends need  for a memset declaration.

* On Solaris 10, AF_LOCAL isn't defined in system headers, while AF_UNIX
  is.  In both libgo and libjava, there are unconditional uses of
  AF_UNIX, so I've followed their lead.

Those changes allowed libcc1.so to build.

Bootstrapped without regressions on i386-pc-solaris2.1[01] and
x86_64-unknown-linux-gnu, ok for mainline?

Btw., MAINTAINERS doesn't currently list a libcc1 maintainer.  I believe
it should.

Rainer


2014-10-31  Rainer Orth  

* configure.ac (libcc1_cv_lib_sockets): Check for -lsocket -lnsl.
* configure: Regenerate.
* connection.cc: Include .
* libcc1.cc (libcc1_compile): Use AF_UNIX instead of AF_LOCAL.

# HG changeset patch
# Parent f122bfdb06f01264f8c4766b51f932d37a0eca3d
Enable libcc1 on Solaris

diff --git a/libcc1/configure.ac b/libcc1/configure.ac
--- a/libcc1/configure.ac
+++ b/libcc1/configure.ac
@@ -63,6 +63,36 @@ if test "$GXX" = yes; then
 fi
 AC_SUBST(libsuffix)
 
+dnl Test for -lsocket and -lnsl.  Copied from libgo/configure.ac.
+AC_CACHE_CHECK([for socket libraries], libcc1_cv_lib_sockets,
+  [libcc1_cv_lib_sockets=
+   libcc1_check_both=no
+   AC_CHECK_FUNC(connect, libcc1_check_socket=no, libcc1_check_socket=yes)
+   if test "$libcc1_check_socket" = "yes"; then
+ unset ac_cv_func_connect
+ AC_CHECK_LIB(socket, main, libcc1_cv_lib_sockets="-lsocket",
+ 		  libcc1_check_both=yes)
+   fi
+   if test "$libcc1_check_both" = "yes"; then
+ libcc1_old_libs=$LIBS
+ LIBS="$LIBS -lsocket -lnsl"
+ unset ac_cv_func_accept
+ AC_CHECK_FUNC(accept,
+		   [libcc1_check_nsl=no
+		libcc1_cv_lib_sockets="-lsocket -lnsl"])
+ unset ac_cv_func_accept
+ LIBS=$libcc1_old_libs
+   fi
+   unset ac_cv_func_gethostbyname
+   libcc1_old_libs="$LIBS"
+   AC_CHECK_FUNC(gethostbyname, ,
+		 [AC_CHECK_LIB(nsl, main,
+		 	[libcc1_cv_lib_sockets="$libcc1_cv_lib_sockets -lnsl"])])
+   unset ac_cv_func_gethostbyname
+   LIBS=$libcc1_old_libs
+])
+LIBS="$LIBS $libcc1_cv_lib_sockets"
+
 # If any of these functions are missing, simply don't bother building
 # this plugin.
 GCC_ENABLE_PLUGINS
diff --git a/libcc1/connection.cc b/libcc1/connection.cc
--- a/libcc1/connection.cc
+++ b/libcc1/connection.cc
@@ -21,6 +21,7 @@ along with GCC; see the file COPYING3.  
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "marshall.hh"
 #include "connection.hh"
diff --git a/libcc1/libcc1.cc b/libcc1/libcc1.cc
--- a/libcc1/libcc1.cc
+++ b/libcc1/libcc1.cc
@@ -440,7 +440,7 @@ libcc1_compile (struct gcc_base_context 
   libcc1 *self = (libcc1 *) s;
 
   int fds[2];
-  if (socketpair (AF_LOCAL, SOCK_STREAM, 0, fds) != 0)
+  if (socketpair (AF_UNIX, SOCK_STREAM, 0, fds) != 0)
 {
   self->print ("could not create socketpair\n");
   return 0;

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

[libgo] Remove Solaris 11.1+ zone_net_addr_t treatment

[Rainer Orth]

The recent godump changes broke Solaris 11.1+ bootstrap in libgo:
before, gen-sysinfo.so had

type _zone_net_addr_t struct { zna_family uint16; zna_plen uint16; zna_addru 
struct { znau_addr6 _in6_addr; }; }

which was filtered out by mksysinfo.sh due to the use of _in6_addr.

After the change, there's now

type _zone_net_addr_t struct { zna_family uint16; zna_plen uint16; zna_addru 
struct { znau_addr6 [16]byte; Godump_0_align [0]uint32; }; }

instead, not filtered, but added a second time by the _zone_net_addr_t
code in mksysinfo.sh, which leads to redefinition warnings/errors.

Simply removing the old _zone_net_addr_t fragment fixes this and
restores bootstrap.

Bootstrapped without regressions on i386-pc-solaris2.1[01], ok for
mainline?

Rainer


2014-10-31  Rainer Orth  

* mksysinfo.sh (_zone_net_addr_t): Remove handling.

# HG changeset patch
# Parent 99be3781928c62bd9d00f98b4cd5304bcc7d8043
Remove Solaris 11.1+ zone_net_addr_t treatment

diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -1203,11 +1203,6 @@ grep '^type _inotify_event ' gen-sysinfo
 grep '^const _CLONE_' gen-sysinfo.go | \
   sed -e 's/^\(const \)_\(CLONE_[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
 
-# The Solaris 11 Update 1 _zone_net_addr_t struct.
-grep '^type _zone_net_addr_t ' gen-sysinfo.go | \
-sed -e 's/_in6_addr/[16]byte/' \
->> ${OUT}
-
 # Struct sizes.
 set cmsghdr Cmsghdr ip_mreq IPMreq ip_mreqn IPMreqn ipv6_mreq IPv6Mreq \
 ifaddrmsg IfAddrmsg ifinfomsg IfInfomsg in_pktinfo Inet4Pktinfo \

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

Re: SRA: don't drop clobbers

[Martin Jambor]

Hi,

On Mon, Nov 03, 2014 at 05:17:22PM +0100, Marc Glisse wrote:
> On Mon, 3 Nov 2014, Martin Jambor wrote:
> >On Mon, Nov 03, 2014 at 01:59:24PM +0100, Marc Glisse wrote:
> >>
> >>now that the update_address_taken patch is in, let me re-post the
> >>SRA follow-up. With this patch, testcase pr60517.C (attached) has a
> >>use of an undefined variable at the time of the uninit pass. Sadly,
> >>while this warned with earlier versions of the other patch (when I
> >>was inserting default definitions of new variables), it does not
> >>anymore because we have TREE_NO_WARNING all over the place. Still, I
> >>believe this is a step in the right direction, and it passed
> >>bootstrap+testsuite (minus the new testcase).
> >
> >I am not sure what you mean by "minus the new testcase" but, with the
> >gimple checking compiler at least, the testcase produces an ICE:
> >
> > pr60517.C: In function ‘double foo(A)’:
> > pr60517.C:15:1: error: non-decl/MEM_REF LHS in clobber statement
> >  }
> >  ^
> > SR.1_8
> > SR.1_8 ={v} {CLOBBER};
> > pr60517.C:15:1: internal compiler error: verify_gimple failed
> > 0xc7810d verify_gimple_in_cfg(function*, bool)
> > /home/mjambor/gcc/mine/src/gcc/tree-cfg.c:5039
> > 0xb8256f execute_function_todo
> > /home/mjambor/gcc/mine/src/gcc/passes.c:1758
> > 0xb83183 execute_todo
> > /home/mjambor/gcc/mine/src/gcc/passes.c:1815
> >
> >The problem is exactly what the verifier complains about, a clobber of
> >an SSA_NAME which I agree with the verifier is a really bad idea.
> >
> >If you want SRA to produce information that at a given point a scalar
> >replacement (which will become an SSA_NAME) does not have any valid
> >data, the way to represent that is to load it with a value from a
> >default-definition SSA name.  Something along the lines of
> >get_repl_default_def_ssa_name which unfortunately you cannot directly
> >use without confusing the SSA renamer.
> >
> >The easiest way, at least to test a proof of concept, is probably to
> >create another declaration of the same type (reusing bits from
> >create_access_replacement, especially setting the same
> >DECL_DEBUG_EXPR), get its default-definition using
> >get_or_create_ssa_default_def and then assign that to the replacement
> >instead of trying to clobber it.
> >
> >(A more correct approach would be to design a way of telling the
> >renamer that at this point the scalar becomes undefined and that it
> >should start using default-defs until the next definition appears but
> >that is likely to be difficult, although that is just my guess, it
> >might be easy.)
> >
> >>Would it be ok to commit the tree-sra.c change?
> >
> >I don't think so, sorry about the bad news.
> 
> Thanks for your help. I am quite confused. I am not seeing the
> failure you mention, but since I am building from trunk with no
> specific option I should be getting gimple checking.
> 
> The way I expect things to work:
> 1) we have a clobber for a variable V
> 2) SRA creates a variable SR and replaces uses of V
> 3) (new) next to V's clobber, we insert a clobber for SR
> 4) update_address_taken notices that SR does not have its address
> taken, and thus replaces it by SSA_NAMEs, and after the clobber by
> an undefined variable (yesterday it would just have removed the
> clobber).

update_address_taken?  The conversion to SSA form is done by means of
returning TODO_update_ssa from the (early) SRA pass (which is what I
mean by the renamer).

> 
> What you describe in a parenthesis about the renamer is pretty much
> what I think rewrite_update_stmt does, with the clobber as the hint.
> 
> Do you have further comments, based on these explanations, that
> could help me pinpoint what is going wrong?

I just applied your patch on top of trunk revision 217032 on my
x86_64-linux (openSUSE 13.1) desktop, configured with

/home/mjambor/gcc/mine/src/configure --prefix=/home/mjambor/gcc/mine/inst 
--enable-languages=c,c++ --enable-checking=yes --disable-bootstrap 
--with-plugin-ld=/home/mjambor/binutils/obj/gold/ld-new --disable-libsanitizer 
--disable-multilib

built with simple make -j8, 

and ran the testcase with make -k check RUNTESTFLAGS="dg.exp=pr60517.C"

And the error popped out in gcc/testsuite/g++/g++.log.  I really can't
think of reason why you don't see it.

But I do and little wonder, really, given the second condition in
verify_gimple_assign_single, which is there for more than a year.
Looking at the dumped statement it seems that the LHS is already an
SSA_NAME.  Moreover, when I dumped the erroneous body in gdb, I have
not seen any default definitions anywhere.  So if your intention was
to teach the renamer to turn this into default definitions, it does
not work and update_ssa did not get the hint.

Martin

[RTL, Patch] Int div by constant compilation enhancement

[Alex Velenko]

Hi,
This patch adds a mid-end check to catch division by
constant case and optimize it to generate one shift,
instead of two.

A testacase to check the correct codegeneration for aarch64
is added. This check is not made generic, because the optimisation
implemented is not used by all targets.

Is it ok?

Thanks,
Alex

gcc/

2014-11-03  Alex Velenko  

* simplify-rtx.c (simplify_binary_operation_1): Div check added.
* rtl.h (SUBREG_P): New macro added.

gcc/testsuite/

2014-11-03  Alex Velenko  

* gcc.dg/asr-div1.c : New testcase.
>From 471fbb2057b4d338d01bb403f0973adbed33a31d Mon Sep 17 00:00:00 2001
From: Alex Velenko 
Date: Mon, 6 Oct 2014 15:33:36 +0100
Subject: [PATCH] [RTL, Patch] Int div by constant compilation enhancement

This patch adds a mid-end check to catch division by
constant case and optimize it to generate one shift,
instead of two.

A testacase to check the correct codegeneration for aarch64
is added. This check is not made generic, because the optimisation
implemented is not used by all targets.
Thanks,
Alex

gcc/

2014-11-03  Alex Velenko  

	* simplify-rtx.c (simplify_binary_operation_1): Div check added.
	* rtl.h (SUBREG_P): New macro added.

gcc/testsuite/

2014-11-03  Alex Velenko  

	* gcc.dg/asr-div1.c : New testcase.
---
 gcc/rtl.h   |  3 +++
 gcc/simplify-rtx.c  | 38 
 gcc/testsuite/gcc.dg/asr_div1.c | 56 +
 3 files changed, 97 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/asr_div1.c

diff --git a/gcc/rtl.h b/gcc/rtl.h
index ddd39c9..6222817 100644
--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -789,6 +789,9 @@ struct GTY(()) rtvec_def {
 /* Predicate yielding nonzero iff X is a data for a jump table.  */
 #define JUMP_TABLE_DATA_P(INSN) (GET_CODE (INSN) == JUMP_TABLE_DATA)
 
+/* Predicate yielding nonzero iff RTX is a subreg.  */
+#define SUBREG_P(RTX) (GET_CODE (RTX) == SUBREG)
+
 template <>
 template <>
 inline bool
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index d783c22..e01fba7 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -3102,6 +3102,44 @@ simplify_binary_operation_1 (enum rtx_code code, enum machine_mode mode,
 	  && UINTVAL (trueop0) == GET_MODE_MASK (mode)
 	  && ! side_effects_p (op1))
 	return op0;
+  /* Given:
+ scalar modes M1, M2
+ scalar constants c1, c2
+ size (M2) > size (M1)
+ c1 == size (M2) - size (M1)
+ optimize:
+ (ashiftrt:M1 (subreg:M1 (lshiftrt:M2 (reg:M2)
+  (const_int ))
+  )
+  (const_int ))
+ to:
+ (subreg:M1 (ashiftrt:M2 (reg:M2)
+ (const_int ))
+  ).  */
+  if (!VECTOR_MODE_P (mode)
+  && SUBREG_P (op0)
+  && CONST_INT_P (op1)
+  && (GET_CODE (SUBREG_REG (op0)) == LSHIFTRT)
+  && !VECTOR_MODE_P (GET_MODE (SUBREG_REG (op0)))
+  && CONST_INT_P (XEXP (SUBREG_REG (op0), 1))
+  && (GET_MODE_BITSIZE (GET_MODE (SUBREG_REG (op0)))
+  > GET_MODE_BITSIZE (mode))
+  && (INTVAL (XEXP (SUBREG_REG (op0), 1))
+  == (GET_MODE_BITSIZE (GET_MODE (SUBREG_REG (op0)))
+  - GET_MODE_BITSIZE (mode)))
+  && subreg_lowpart_p (op0))
+{
+  rtx tmp = GEN_INT (INTVAL (XEXP (SUBREG_REG (op0), 1))
+ + INTVAL (op1));
+  machine_mode inner_mode = GET_MODE (SUBREG_REG (op0));
+  tmp = simplify_gen_binary (ASHIFTRT,
+ GET_MODE (SUBREG_REG (op0)),
+ XEXP (SUBREG_REG (op0), 0),
+ tmp);
+  return simplify_gen_subreg (mode, tmp, inner_mode,
+  subreg_lowpart_offset (mode,
+ inner_mode));
+}
 canonicalize_shift:
   if (SHIFT_COUNT_TRUNCATED && CONST_INT_P (op1))
 	{
diff --git a/gcc/testsuite/gcc.dg/asr_div1.c b/gcc/testsuite/gcc.dg/asr_div1.c
new file mode 100644
index 000..61430ca
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/asr_div1.c
@@ -0,0 +1,56 @@
+/* Test division by const int generates only one shift.  */
+/* { dg-do run } */
+/* { dg-options "-O2 -fdump-rtl-combine-all" } */
+
+extern void abort (void);
+
+#define NOINLINE __attribute__((noinline))
+
+static NOINLINE int
+f1 (int n)
+{
+  return n / 33;
+}
+
+static NOINLINE int
+f2 (int n)
+{
+  return n / 77;
+}
+
+int
+main ()
+{
+  int a = 0x;
+  int b = 0x;
+  int c;
+  c = f1 (a);
+  if (c != 0xfd6a052c)
+abort ();
+  c = f1 (b);
+  if (c != 0x295FAD4)
+abort ();
+  c = f2 (a);
+  if (c != 0xfee44b5c)
+abort ();
+  c = f2 (b);
+  if (c != 0x11bb4a4)
+abort ();
+  return 0;
+}
+
+/* Following replacement pattern of intger division by constant, GCC is expected
+   to 

Re: Recent go changes broke alpha bootstrap

[Dominik Vogt]

On Thu, Oct 30, 2014 at 08:05:14AM -0700, Ian Taylor wrote:
> On Thu, Oct 30, 2014 at 5:46 AM, Dominik Vogt  wrote:
> > I'm not quite sure about the best approach.  The attempt to
> > represent C unions in the "right" way is ultimately futile as Go
> > does not have the types necessary for it.  For example, the
> > handling of anonymous bit fields will never be right as it's
> > undefinied.  On the other hand I could fix the issue at hand by
> > changing the way anonymous unions are represented in Go.
> >
> > Example:
> >
> >   struct { int8_t x; union { int16_t y; int 32_t z; }; };
> >
> > Was represented (before the patch) as
> >
> >   struct { X byte; int16 Y; }
> >
> > which had size 4, alignment 2 and y at offset 2 but should had
> > have size 8, alignment 4 and y at offset 4.  With the current
> > patch the Go layout is
> >
> >   struct { X byte; artificial_name struct { y [2]byte; align [0]int32; } }
> >
> > with the proper size, alignment and offset, but y is addressed as
> > ".artificial_name.y" insted of just ".y", and y is a byte array
> > and not an int16.
> >
> > I could remove the "artificial_name struct" and add padding before
> > and after y instead:
> >
> >   struct { X byte; pad_0 [3]byte; Y int16; pad_1 [2]byte; align [0]int32; }
> >
> > What do you think?
> 
> Sounds good to me.  Basically the fields of the anonymous union should
> be promoted to become fields of the struct.  We can't do it in
> general, but we can do it for the first field.  That addresses the
> actual uses of anonymous unions.

The attached patch fixes this, at least if the first element of the
union is not a bitfield.

Bitfields can really not be represented properly in Go (think about
constructs like "struct { int : 1; int bf : 1; }"), I'd rather not
try to represent them in a predictable way.  The patched code may
or may not give them a name, and reserves the proper amount of
padding where required in structs.  If a union begins with an
anonymous bitfield (which makes no sense), that is ignored.  If a
union begins with a named bitfield (possibly after unnamed ones),
this may or may not be used as the (sole) element of the Go
struct.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt
IBM Germany
>From 52d6792fb89a2f2beb2b897c7794b30245400e61 Mon Sep 17 00:00:00 2001
From: Dominik Vogt 
Date: Mon, 3 Nov 2014 17:49:33 +0100
Subject: [PATCH 1/2] godump: "Fix" handling of anonymous structs and unions.

Remove the "struct { ... }" around them as was the case before.

Note that bitfields are note handled in any predictable way.  They may be
replaced by padding or not, and a union beginning with a bitfield may use the
bitfield in the Go struct or may use the first non-bitfield element of the
union.  This is not really fixable.
---
 gcc/godump.c| 183 +++
 gcc/testsuite/gcc.misc-tests/godump-1.c | 849 +++-
 2 files changed, 697 insertions(+), 335 deletions(-)

diff --git a/gcc/godump.c b/gcc/godump.c
index fccd3eb..7c386c4 100644
--- a/gcc/godump.c
+++ b/gcc/godump.c
@@ -678,11 +678,13 @@ go_force_record_alignment (struct obstack *ob, const char *type_string,
 
 static bool
 go_format_type (struct godump_container *container, tree type,
-		bool use_type_name, bool is_func_ok, unsigned int *p_art_i)
+		bool use_type_name, bool is_func_ok, unsigned int *p_art_i,
+		bool is_anon_record_or_union)
 {
   bool ret;
   struct obstack *ob;
   unsigned int art_i_dummy;
+  bool is_union = false;
 
   if (p_art_i == NULL)
 {
@@ -856,7 +858,7 @@ go_format_type (struct godump_container *container, tree type,
   else
 	{
 	  if (!go_format_type (container, TREE_TYPE (type), use_type_name,
-			   true, NULL))
+			   true, NULL, false))
 	ret = false;
 	}
   break;
@@ -882,15 +884,19 @@ go_format_type (struct godump_container *container, tree type,
 	obstack_1grow (ob, '0');
   obstack_1grow (ob, ']');
   if (!go_format_type (container, TREE_TYPE (type), use_type_name, false,
-			   NULL))
+			   NULL, false))
 	ret = false;
   break;
 
+case UNION_TYPE:
+  is_union = true;
+  /* Fall through to RECORD_TYPE case.  */
 case RECORD_TYPE:
   {
 	unsigned int prev_field_end;
-	unsigned int most_strict_known_alignment;
+	unsigned int known_alignment;
 	tree field;
+	bool emitted_a_field;
 
 	/* FIXME: Why is this necessary?  Without it we can get a core
 	   dump on the s390x headers, or from a file containing simply
@@ -898,51 +904,77 @@ go_format_type (struct godump_container *container, tree type,
 	layout_type (type);
 
 	prev_field_end = 0;
-	most_strict_known_alignment = 1;
-	obstack_grow (ob, "struct { ", 9);
-	for (field = TYPE_FIELDS (type);
+	known_alignment = 1;
+	/* Anonymous records and unions are flattened, i.e. they are not put
+	   into "struct { ... }".  */
+	if (!is_anon_record_or_union)
+	  obstack_grow (ob, "struct { ", 9);
+	for (field = TYPE_FIELDS (type), emitted_a_field = false;
 	 field != NULL_TREE;
 	 fiel

Re: [PATCH 7/11][ARM] Migrate to new reduc_plus_scal_optab

[Ramana Radhakrishnan]

On Fri, Oct 24, 2014 at 12:57 PM, Alan Lawrence  wrote:
> This migrates ARM from reduc_splus_optab and reduc_uplus optab to a single
> reduc_plus_optab.
>
> Tested, in combination with next patch:
> bootstrap on arm-none-linux-gnueabihf
> cross-tested check-gcc on arm-none-eabi.
>

Ok.

Ramana
> gcc/ChangeLog:
>
> config/arm/neon.md (reduc_plus_*): Rename to...
> (reduc_plus_scal_*): ...this; reduce to temp and extract scalar
> result.

[gomp4] Mark fopenacc as LTO option

[Tom de Vries]

Thomas,

This patch marks fopenacc as LTO option.

This allows fopenacc to be passed to lto, which means the openacc builtins are 
recognized when reading in the LTO stream. This fixes a number of testcases in 
the libgomp testsuite.


ok for gomp-4_0-branch?

Thanks,
- Tom
2014-11-03  Tom de Vries  

	* c.opt (fopenacc): Mark as LTO option.

	* lang.opt (fopenacc): Mark as LTO option.

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 09951c9..fd5a615 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1193,7 +1193,7 @@ ObjC ObjC++ Var(flag_objc1_only)
 Conform to the Objective-C 1.0 language as implemented in GCC 4.0
 
 fopenacc
-C ObjC C++ ObjC++ Var(flag_openacc)
+C ObjC C++ ObjC++ LTO Var(flag_openacc)
 Enable OpenACC
 
 fopenmp
diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index bbea334..48b47af 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -530,7 +530,7 @@ Fortran
 Set default accessibility of module entities to PRIVATE.
 
 fopenacc
-Fortran
+Fortran LTO
 ; Documented in C
 
 fopenmp
-- 
1.9.1

Re: [PATCH 10/11][RS6000] Migrate reduction optabs to reduc_..._scal

[Bill Schmidt]

On Fri, 2014-10-24 at 19:49 -0400, David Edelsohn wrote:
> On Fri, Oct 24, 2014 at 8:06 AM, Alan Lawrence  wrote:
> > This migrates the reduction patterns in altivec.md and vector.md to the new
> > names. I've not touched paired.md as I wasn't really sure how to fix that
> > (how do I vec_extractv2sf ?), moreover the testing I did didn't seem to
> > exercise any of those patterns (iow: I'm not sure what would be an
> > appropriate target machine?).
> >
> > I note the reduc_uplus_v16qi (which I've removed, as unsigned and signed
> > addition should be equivalent) differed from reduc_splus_v16qi in using
> > gen_altivec_vsum4ubs rather than gen_altivec_vsum4sbs.  Testcases
> > gcc.dg/vect/{slp-24-big-array.c,slp-24.c,vect-reduc-1char-big-array.c,vert-reduc-1char.c}
> > thus produce assembly which differs from previously (only) in that
> > "vsum4ubs" becomes "vsum4sbs". These tests are still passing so I assume
> > this is OK.

Given that the only 32-bit quantity being added here is zero, the
difference in saturation points for vsum4ubs and vsum4sbs won't come
into play, so I agree this should be fine.

I would like to ask Mike Meissner to look over the changes to the
reduction patterns in vector.md.  He wrote those and is more familiar
with that piece than I am.  On the surface I don't see any problems, but
I could miss something subtle.

Otherwise I'm ok with the patch.

Thanks,
Bill

(p.s. Sorry for the delay on reviewing this.  As David noted, I was
traveling, and I ended up having no access to my mail for most of the
week due to an IT snafu.)

> >
> > The combining of signed and unsigned addition also improves
> > gcc.dg/vect/{vect-outer-4i.c,vect-reduc-1short.c,vect-reduc-dot-u8b.c,vect-reduc-pattern-1c-big-array.c,vect-reduc-pattern-1c.c}
> > : these are now reduced using direct vector reduction, rather than with
> > shifts as previously (because there was only a reduc_splus rather than the
> > reduc_uplus these tests looked for).
> >
> > ((Side note: the RTL changes to vector.md are to match the combine patterns
> > in vsx.md; now that we now longer depend upon combine to generate those
> > patterns (as the optab outputs them directly), one might wish to remove the
> > smaller pattern from vsx.md, and/or simplify the RTL. I theorize that a
> > reduction of a two-element vector is just adding the first element to the
> > second, so maybe to something like
> >
> >   [(parallel [(set (match_operand:DF 0 "vfloat_operand" "")
> >(VEC_reduc:V2DF
> > (vec_select:DF
> >  (match_operand:V2DF 1 "vfloat_operand" "")
> >  (parallel [(const_int 1)]))
> > (vec_select:DF
> >  (match_dup 1)
> >  (parallel [(const_int 0)]
> >   (clobber (match_scratch:V2DF 2 ""))])]
> >
> > but I think it's best for me to leave that to the port maintainers.))
> >
> > Bootstrapped and check-gcc on powerpc64-none-linux-gnu
> > (gcc110.fsffrance.org, with thanks to the GCC Compile Farm).
> >
> > gcc/ChangeLog:
> >
> > * config/rs6000/altivec.md (reduc_splus_): Rename to...
> > (reduc_plus_scal_): ...this, and rs6000_expand_vector_extract.
> > (reduc_uplus_v16qi): Remove.
> >
> > * config/rs6000/vector.md (VEC_reduc_name): change "splus" to "plus"
> > (reduc__v2df): Rename to...
> > (reduc__scal_v2df): ...this, wrap VEC_reduc in a
> > vec_select of element 1.
> > (reduc__v4sf): Rename to...
> > (reduc__scal_v4sf): ...this, wrap VEC_reduc in a
> > vec_select of element 3, add scratch register.
> >
> 
> This needs some input from Bill, but he will be busy with a conference
> this week.
> 
> - David
> 

Re: [PATCH] FreeBSD arm support, EABI.

[Joseph Myers]

On Sun, 2 Nov 2014, Andreas Tobler wrote:

>   * config/arm/arm.c (arm_init_libfuncs): FreeBSD does not support 8
> byte
>   atomics for __ARM_ARCH__ < 6 yet.
>   (arm_option_override): FreeBSD has not yet implemented unaligned
> access.

The __FreeBSD__ conditionals in arm.c are incorrect.  Those would test for 
FreeBSD *host*, but you need a conditional for FreeBSD *target* here.

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

Re: [AArch64, Docs, Patch] Add reference to ACLE in docs.

[Joseph Myers]

On Mon, 3 Nov 2014, Tejas Belagod wrote:

> If I mention in a couple of sentences the level of ACLE support there is in
> GCC currently, this section will need to be updated every time there is an
> improvement in ACLE support - I guess we'll just have to remember to remove
> parts of this section as we do that.

Yes, it's generally the case when adding new user-visible features that 
documentation needs updating.  The release notes (gcc-N/changes.html in 
htdocs) should be updated for any significant new features as well.

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

Re: [PATCH v3] Fix PR56480 aka DR374. Allow explicit specialization in enclosing namespace.

[Markus Trippelsdorf]

On 2014.11.03 at 08:47 -0600, Jason Merrill wrote:
> On 11/03/2014 05:27 AM, Markus Trippelsdorf wrote:
> > BTW both EDG and clang reject g++.dg/template/spec17.C:
> >
> > namespace io {
> >template  int foo();
> > }
> > using namespace io;
> > template<> int foo();
> >
> > But I think it is a reasonable extension to accept it.
> 
> We should reject it, too.  We can only leave out the namespace 
> qualification with inline namespaces.

Where would be the best place to check for this issue?

> > +// { dg-options "-pedantic -pedantic-errors" }
> 
> You shouldn't need these dg-options lines; if a testcase has no 
> dg-options line, -pedantic-errors is the default.

OK. Fixed.

-- 
Markus

Re: [PATCH][PPC] Skip gcc.target tests with conflicting -mcpu

[Mike Stump]

On Oct 30, 2014, at 10:25 AM, Andrew Stubbs  wrote:
> Many of the tests in gcc.target/powerpc specify an explicit -mcpu option with 
> dg-options. This is a problem for multilib configurations that use -mcpu in 
> their definition

> OK to commit?

Given the discussion, I think the patch as is is fine.  Thanks.

Ok.

Re: SRA: don't drop clobbers

[Marc Glisse]

On Mon, 3 Nov 2014, Martin Jambor wrote:


I just applied your patch on top of trunk revision 217032 on my


Ah, that explains it, thanks. This patch is a follow-up to r217034. Still, 
I didn't expect the ICE you are seeing by applying this patch to older 
trunk, I'll try to reproduce that.


--
Marc Glisse

Re: [patch,avr] correct incorrect spec string for device specs

[Denis Chertykov]

Committed.

Re: [PATCH] FreeBSD arm support, EABI.

[Andreas Tobler]

On 03.11.14 18:53, Joseph Myers wrote:

On Sun, 2 Nov 2014, Andreas Tobler wrote:


* config/arm/arm.c (arm_init_libfuncs): FreeBSD does not support 8
byte
atomics for __ARM_ARCH__ < 6 yet.
(arm_option_override): FreeBSD has not yet implemented unaligned
access.


The __FreeBSD__ conditionals in arm.c are incorrect.  Those would test for
FreeBSD *host*, but you need a conditional for FreeBSD *target* here.



Ouch, yes.

This I'd have to define via config/arm/freebsd.h, right?

#define ARM_FREEBSD

Index: arm.c
===
--- arm.c   (revision 216539)
+++ arm.c   (working copy)
@@ -2188,7 +2188,11 @@
 {
   /* For Linux, we have access to kernel support for atomic 
operations.  */

   if (arm_abi == ARM_ABI_AAPCS_LINUX)
+#ifndef ARM_FREEBSD
 init_sync_libfuncs (2 * UNITS_PER_WORD);
+#else
+init_sync_libfuncs (UNITS_PER_WORD);
+#endif



Thank you!
Andreas

Re: [PATCH] FreeBSD arm support, EABI.

[Joseph Myers]

On Mon, 3 Nov 2014, Andreas Tobler wrote:

> > The __FreeBSD__ conditionals in arm.c are incorrect.  Those would test for
> > FreeBSD *host*, but you need a conditional for FreeBSD *target* here.
> > 
> 
> Ouch, yes.
> 
> This I'd have to define via config/arm/freebsd.h, right?
> 
> #define ARM_FREEBSD

Yes, that seems the right place.

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

Re: [PATCH 07/27] New file: gcc/jit/dummy-frontend.c

[Jeff Law]

On 10/31/14 11:02, David Malcolm wrote:

gcc/jit/
* dummy-frontend.c: New.

OK.

jeff

Re: [PATCH 11/27] New file: gcc/jit/jit-common.h

[Jeff Law]

On 10/31/14 11:02, David Malcolm wrote:

This header has forward declarations of both the jit::recording
and jit::playback internal APIs.

gcc/jit/
* jit-common.h: New.

OK
jeff

Re: [Patch, Fortran] Add CO_REDUCE

[Tobias Burnus]

Andreas Schwab wrote:

Tobias Burnus  writes:


diff --git a/gcc/testsuite/gfortran.dg/coarray_collectives_14.f90 
b/gcc/testsuite/gfortran.dg/coarray_collectives_14.f90
new file mode 100644
index 000..f0ab932
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_collectives_14.f90

FAIL: gfortran.dg/coarray_collectives_14.f90   -O   (test for errors, line 55)


Sorry for the test failure. One shouldn't do last-minute commits before 
leaving for vacation. Fixed by the attached patch and in Rev. 217053.


I will fill a PR for the FIXME item.

Tobias
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog	(Revision 217051)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,7 @@
+2014-11-03  Tobias Burnus  
+
+	* gfortran.dg/coarray_collectives_14.f90: Fix testcase.
+
 2014-11-03  Marek Polacek  
 
 	PR c/52769
Index: gcc/testsuite/gfortran.dg/coarray_collectives_14.f90
===
--- gcc/testsuite/gfortran.dg/coarray_collectives_14.f90	(Revision 217052)
+++ gcc/testsuite/gfortran.dg/coarray_collectives_14.f90	(Arbeitskopie)
@@ -15,24 +15,24 @@ program test
   external ext
 
   type t
-procedure(), nopass :: ext
-procedure(valid), nopass :: valid
-procedure(sub), nopass :: sub
-procedure(nonpure), nopass :: nonpure
-procedure(arg1), nopass :: arg1
-procedure(arg2), nopass :: arg2
-procedure(elem), nopass :: elem
-procedure(realo), nopass :: realo
-procedure(int8), nopass :: int8
-procedure(arr), nopass :: arr
-procedure(ptr), nopass :: ptr
-procedure(alloc), nopass :: alloc
-procedure(opt), nopass :: opt
-procedure(val), nopass :: val
-procedure(async), nopass :: async
-procedure(tgt), nopass :: tgt
-procedure(char44), nopass :: char44
-procedure(char34), nopass :: char34
+procedure(), pointer, nopass :: ext
+procedure(valid), pointer, nopass :: valid
+procedure(sub), pointer, nopass :: sub
+procedure(nonpure), pointer, nopass :: nonpure
+procedure(arg1), pointer, nopass :: arg1
+procedure(arg3), pointer, nopass :: arg3
+procedure(elem), pointer, nopass :: elem
+procedure(realo), pointer, nopass :: realo
+procedure(int8), pointer, nopass :: int8
+procedure(arr), pointer, nopass :: arr
+procedure(ptr), pointer, nopass :: ptr
+procedure(alloc), pointer, nopass :: alloc
+procedure(opt), pointer, nopass :: opt
+procedure(val), pointer, nopass :: val
+procedure(async), pointer, nopass :: async
+procedure(tgt), pointer, nopass :: tgt
+procedure(char44), pointer, nopass :: char44
+procedure(char34), pointer, nopass :: char34
   end type t
 
   type(t) :: dt
@@ -62,7 +62,7 @@ program test
   call co_reduce(caf, arg3) ! { dg-error "shall have two arguments" }
   call co_reduce(caf, dt%arg3) ! { dg-error "shall have two arguments" }
   call co_reduce(caf, elem) ! { dg-error "ELEMENTAL non-INTRINSIC procedure 'elem' is not allowed as an actual argument" }
-  call co_reduce(caf, dt%elem) ! { dg-error "ELEMENTAL non-INTRINSIC procedure 'elem' is not allowed as an actual argument" }
+  call co_reduce(caf, dt%elem) ! { FIXME: "ELEMENTAL non-INTRINSIC procedure 'elem' is not allowed as an actual argument" }
   call co_reduce(caf, realo) ! { dg-error "A argument at .1. has type INTEGER.4. but the function passed as OPERATOR at .2. returns REAL.4." }
   call co_reduce(caf, dt%realo) ! { dg-error "A argument at .1. has type INTEGER.4. but the function passed as OPERATOR at .2. returns REAL.4." }
   call co_reduce(caf, int8) ! { dg-error "A argument at .1. has type INTEGER.4. but the function passed as OPERATOR at .2. returns INTEGER.8." }

Re: C++ Patch for c++/60894

[Fabien Chêne]

2014-10-09 15:34 GMT+02:00 Jason Merrill :
[...]
>> If the USING_DECL is returned, the code below will be rejected as
>> expected, but the error message will not mention the line where the
>> USING_DECL appears as the previous definition, but at the target
>> declaration of the USING_DECL instead.
>
>
> I think that's what happens if you strip the USING_DECL and return what it
> points to; if you return the USING_DECL itself that shouldn't happen (though
> then the caller needs to be able to deal with getting a USING_DECL).

[Sorry for the delay] Humm, l_a_c_t returns a TYPE upon success, shall
I change it and return a DECL instead ?

-- 
Fabien

Re: [PATCH 08/27] New file: gcc/jit/libgccjit.h

[Jeff Law]

On 10/31/14 11:02, David Malcolm wrote:

This header is the public API for the library.

gcc/jit/
* libgccjit.h: New.

Given this is inside the JIT subdirectory, I'm not doing a depth review.

 +

+/* A gcc_jit_block encapsulates a "basic block" of statements within a
+   function (i.e. with one entry point and one exit point).
+
+   Every block within a function must be terminated with a conditional,
+   a branch, or a return.
? That doesn't seem right.   We don't really place restrictions on what 
ends a block, but we do place restrictions on what kinds of IL 
statements can appear in the middle of a block.



+
+   All of the blocks in a function must be reachable via some path from
+   the first block.
?  Is this something your code requires?  While we have some code which 
assumes unreachable blocks do not exist, we generally deal with that by 
running the cfgcleanup passes which will identify and remove the 
unreachables.


And this raises one of those questions that's been in the back of my 
mind.  What's the right level of documentation and exposure of 
internals.  When I read the docs, one of questions I kept to myself was 
whether or not we've giving the users too much or too little 
information.  As well as a vague concern that actually using the JIT is 
going to be so painful due to exposure of implementation details that we 
might want to just go in with the expectation that this is really a V0 
implementation and that it's all going to have to change and be 
rewritten as GCC's internals get sorted out.





+
+/*
+   Acquire a JIT-compilation context.
+
+   FIXME: error-handling?
There's a whole class of problems with error handling. GCC has always 
had this notation that it can terminate compilation when something "bad" 
happens.  In a JIT world that may not be appropriate.  But that's 
probably outside the scope of what we want to try and tackle at this stage.




+enum gcc_jit_int_option
+{
+  /* How much to optimize the code.
+ Valid values are 0-3, corresponding to GCC's command-line options
+ -O0 through -O3.
+
+ The default value is 0 (unoptimized).  */
+  GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL,
+
+  GCC_JIT_NUM_INT_OPTIONS
+};
I don't think we explicitly disallow optimization values > 3, they just 
don't do anything.




+
+/* Options taking boolean values.
+   These all default to "false".  */
+enum gcc_jit_bool_option
+{
+  /* If true, gcc_jit_context_compile will attempt to do the right
+ thing so that if you attach a debugger to the process, it will
+ be able to inspect variables and step through your code.
+
+ Note that you can't step through code unless you set up source
+ location information for the code (by creating and passing in
+ gcc_jit_location instances).  */
+  GCC_JIT_BOOL_OPTION_DEBUGINFO,
The comment makes me ask, why not always have this on and have 
gcc_jit_context_compile try to do the right thing? :-)



+
+  /* If true, gcc_jit_context_compile will dump its initial "tree"
+ representation of your code to stderr (before any
+ optimizations).  */
+  GCC_JIT_BOOL_OPTION_DUMP_INITIAL_TREE,

Is stderr really the best place for the debugging dumps?



+
+/* Populating the fields of a formerly-opaque struct type.
+   This can only be called once on a given struct type.  */
+extern void
+gcc_jit_struct_set_fields (gcc_jit_struct *struct_type,
+  gcc_jit_location *loc,
+  int num_fields,
+  gcc_jit_field **fields);
What happens if you call it more than once?  Is the once only property 
something we ought to be enforcing, or is that really an internal issue?



+
+enum gcc_jit_function_kind

[ ... ]
So do we have any use for alias, thunks, etc here?

And WRT types (and perhaps other stuff), there's a pretty direct mapping 
between the rest of GCC and the JIT stuff.  I worry a bit that someone 
changing the core of GCC may not know they need to make analogous 
changes to the JIT bits.  It's a general concern, no need to do anything 
about it right now.  If it breaks you get to fix it ;-)

[ ... ]

In your code to build up the contents of blocks, would it make sense to 
"finalize" the block or somesuch concept after adding a  statement which 
terminates the block to ensure someone doesn't append statements after 
the block terminitating statement?



Patch is OK -- the issues noted above are more things I think are worth 
discussing and possibly making changes in the future.  Nothing above is 
significant enough today to warrant making changes in the codebase IMHO.

Jeff

Re: [PATCH 10/27] New file: gcc/jit/libgccjit.c

[Jeff Law]

On 10/31/14 11:02, David Malcolm wrote:

This file implements the entrypoints of the library's public API.

It performs error-checking at this boundary, before calling into the
jit-recording.h internal API.

gcc/jit/
* libgccjit.c: New.
---
  gcc/jit/libgccjit.c | 1506 +++
  1 file changed, 1506 insertions(+)
  create mode 100644 gcc/jit/libgccjit.c

+
+#define IS_ASCII_ALPHA(CHAR) \
+  (\
+((CHAR) >= 'a' && (CHAR) <='z')  \
+|| \
+((CHAR) >= 'A' && (CHAR) <= 'Z') \
+  )
+
+#define IS_ASCII_DIGIT(CHAR) \
+  ((CHAR) >= '0' && (CHAR) <='9')
+
+#define IS_ASCII_ALNUM(CHAR) \
+  (IS_ASCII_ALPHA (CHAR) || IS_ASCII_DIGIT (CHAR))

Can't we rely on the C library to give us equivalents?


+
+/* TODO: mark failure branches as unlikely? */
+
Not likely worth the effort.  And it'd be better to somehow mark 
jit_error such that anytime a path unconditionally calls jit_error, the 
whole path is considered unlikely.


I think it was Ball & Larus that had a predictor of this nature, I don't 
recall its effectiveness offhand.  But I'd rather be marking the 
function than sprinlkling unlikely all over the actual codepaths.





+static bool
+compatible_types (gcc::jit::recording::type *ltype,
+ gcc::jit::recording::type *rtype)
All function definitions should have a block comment describing the 
function and its arguments.   This comment applies throughout the code 
and needs to be addressed prior to commit.  In fact I really can't even 
continue review of this code due to the lack of comments -- I rely 
heavily on them.


jeff

[PATCH] Optimize BIT_AND_EXPRs for UBSAN_OBJECT_SIZE

[Marek Polacek]

We don't emit UBSAN_BOUNDS checks in case we can at compile-time
prove that the array access is fine.  Also if we have [i & CST],
where CST is <= bound_of_the_array, we know we're fine as well.

But we don't have similar BIT_AND_EXPR check for UBSAN_OBJECT_SIZE
which is what this patch attempts to add.
(This is unrelated to the UBSAN_NULL optimization I posted earlier
today.)

Bootstrap-ubsan/regtest passed on x86_64-linux, ok for trunk?

2014-11-03  Marek Polacek  

* ubsan.c (instrument_object_size): Optimize [x & CST] array accesses.
testsuite/
* c-c++-common/ubsan/object-size-10.c: New test.

diff --git gcc/testsuite/c-c++-common/ubsan/object-size-10.c 
gcc/testsuite/c-c++-common/ubsan/object-size-10.c
index e69de29..ebc8582 100644
--- gcc/testsuite/c-c++-common/ubsan/object-size-10.c
+++ gcc/testsuite/c-c++-common/ubsan/object-size-10.c
@@ -0,0 +1,79 @@
+/* { dg-do run } */
+/* { dg-skip-if "" { *-*-* } { "*" } { "-O2" } } */
+/* { dg-options "-fsanitize=undefined" } */
+
+static char a[128];
+static int b[128];
+
+__attribute__ ((noinline, noclone)) int
+fn1 (int i)
+{
+  asm ("");
+  return a[i & 127];
+}
+
+__attribute__ ((noinline, noclone)) int
+fn2 (int i)
+{
+  asm ("");
+  return a[i & 128];
+}
+
+/* { dg-output "index 128 out of bounds for type 'char 
\\\[128\\\]'\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*load of address \[^\n\r]* with insufficient space for 
an object of type 'char'\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*note: pointer points here\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*\\^\[^\n\r]*(\n|\r\n|\r)" } */
+
+__attribute__ ((noinline, noclone)) int
+fn3 (int i)
+{
+  asm ("");
+  return b[i & 127];
+}
+
+__attribute__ ((noinline, noclone)) int
+fn4 (int i)
+{
+  asm ("");
+  return b[i & 128];
+}
+
+/* { dg-output "\[^\n\r]*index 128 out of bounds for type 'int 
\\\[128\\\]'\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*load of address \[^\n\r]* with insufficient space for 
an object of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*note: pointer points here\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*\\^\[^\n\r]*(\n|\r\n|\r)" } */
+
+__attribute__ ((noinline, noclone)) int
+fn5 (int i, int j)
+{
+  asm ("");
+  return b[i & j];
+}
+
+/* { dg-output "\[^\n\r]*index 128 out of bounds for type 'int 
\\\[128\\\]'\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*load of address \[^\n\r]* with insufficient space for 
an object of type 'int'\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*note: pointer points here\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*\[^\n\r]*(\n|\r\n|\r)" } */
+/* { dg-output "\[^\n\r]*\\^\[^\n\r]*(\n|\r\n|\r)" } */
+
+__attribute__ ((noinline, noclone)) int
+fn6 (int i)
+{
+  asm ("");
+  return b[i & 0];
+}
+
+int
+main (void)
+{
+  fn1 (128);
+  fn2 (128);
+  fn3 (128);
+  fn4 (128);
+  fn5 (128, 127);
+  fn5 (128, 128);
+  fn6 (128);
+  return 0;
+}
diff --git gcc/ubsan.c gcc/ubsan.c
index ed2fc54..41cf546 100644
--- gcc/ubsan.c
+++ gcc/ubsan.c
@@ -1438,6 +1438,7 @@ instrument_object_size (gimple_stmt_iterator *gsi, bool 
is_lhs)
   location_t loc = gimple_location (stmt);
   tree t = is_lhs ? gimple_get_lhs (stmt) : gimple_assign_rhs1 (stmt);
   tree type;
+  tree index = NULL_TREE;
   HOST_WIDE_INT size_in_bytes;
 
   type = TREE_TYPE (t);
@@ -1456,6 +1457,8 @@ instrument_object_size (gimple_stmt_iterator *gsi, bool 
is_lhs)
}
   break;
 case ARRAY_REF:
+  index = TREE_OPERAND (t, 1);
+  break;
 case INDIRECT_REF:
 case MEM_REF:
 case VAR_DECL:
@@ -1537,6 +1540,24 @@ instrument_object_size (gimple_stmt_iterator *gsi, bool 
is_lhs)
   && tree_int_cst_le (t, sizet))
 return;
 
+  if (index != NULL_TREE
+  && TREE_CODE (index) == SSA_NAME
+  && TREE_CODE (sizet) == INTEGER_CST)
+{
+  gimple def = SSA_NAME_DEF_STMT (index);
+  if (is_gimple_assign (def)
+ && gimple_assign_rhs_code (def) == BIT_AND_EXPR
+ && TREE_CODE (gimple_assign_rhs2 (def)) == INTEGER_CST)
+   {
+ tree cst = gimple_assign_rhs2 (def);
+ tree sz = fold_build2 (EXACT_DIV_EXPR, sizetype, sizet,
+TYPE_SIZE_UNIT (type));
+ if (tree_int_cst_sgn (cst) >= 0
+ && tree_int_cst_lt (cst, sz))
+   return;
+   }
+}
+
   /* Nope.  Emit the check.  */
   t = force_gimple_operand_gsi (gsi, t, true, NULL_TREE, true,
GSI_SAME_STMT);

Marek

[RFC PATCH, i386]: Fix PR 63538, With -mcmodel=medium .lrodata accesses do not use 64-bit addresses

[Uros Bizjak]

Hello!

Following patch fixes PR 63538, where the data in the large data
section was accessed through 32bit address. The patch unifies places
where large data sections are determined and passes all declarations
to ix86_in_large_data_p only.

The patch fixes the testcase form the PR. Also, the code from several
tests involving various -mlarge-data-threshold= settings looks
consistent now.

2014-11-03  Uros Bizjak  

PR target/63538
* config/i386/i386.c (ix86_encode_section_info): Do not check
TREE_STATIC and DECL_EXTERNAL when setting SYMBOL_FLAG_FAR_ADDR flag.
(x86_64_elf_select_section): Do not check ix86_cmodel here.
(x86_64_elf_unique_section): Ditto.

The patch was bootstrapped and regression tested on x86_64-linux-gnu
{,-m32}. However, the -mcmodel testcases are virtually non-existent,
this is the reason for the RFC status of the patch.

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 217050)
+++ config/i386/i386.c  (working copy)
@@ -5099,8 +5099,7 @@ ATTRIBUTE_UNUSED static section *
 x86_64_elf_select_section (tree decl, int reloc,
   unsigned HOST_WIDE_INT align)
 {
-  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
-  && ix86_in_large_data_p (decl))
+  if (ix86_in_large_data_p (decl))
 {
   const char *sname = NULL;
   unsigned int flags = SECTION_WRITE;
@@ -5186,8 +5185,7 @@ x86_64_elf_section_type_flags (tree decl, const ch
 static void ATTRIBUTE_UNUSED
 x86_64_elf_unique_section (tree decl, int reloc)
 {
-  if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
-  && ix86_in_large_data_p (decl))
+  if (ix86_in_large_data_p (decl))
 {
   const char *prefix = NULL;
   /* We only need to use .gnu.linkonce if we don't have COMDAT groups.  */
@@ -44230,9 +44228,7 @@ ix86_encode_section_info (tree decl, rtx rtl, int
 {
   default_encode_section_info (decl, rtl, first);
 
-  if (TREE_CODE (decl) == VAR_DECL
-  && (TREE_STATIC (decl) || DECL_EXTERNAL (decl))
-  && ix86_in_large_data_p (decl))
+  if (ix86_in_large_data_p (decl))
 SYMBOL_REF_FLAGS (XEXP (rtl, 0)) |= SYMBOL_FLAG_FAR_ADDR;
 }
 

Re: [PATCH 14/27] New files: gcc/jit/jit-builtins.{c|h}

[Jeff Law]

On 10/31/14 11:02, David Malcolm wrote:

These files implement support for builtins, for the
   gcc_jit_context_get_builtin_function
API entrypoint.

Only a subset of builtins are currently supported, based on those
that I needed when porting GNU Octave's JIT.

Attempts to use other builtins may lead to an error:
   "unimplemented primitive type for builtin"
being emitted on the gcc_jit_context.

gcc/jit/
* jit-builtins.c: New.
* jit-builtins.h: New.
So how do you envision maintenance on this in the future?  Reality is 
folks are regularly adding new builtins, are they going to have to 
update the JIT too?


OK for the trunk.

jeff

Re: [PATCH 15/27] New file: gcc/jit/jit-playback.h

[Jeff Law]

On 10/31/14 11:02, David Malcolm wrote:

This files declares the gcc::jit::playback internal API, called by
the dummy "frontend" to replay the public API calls made to the
library.  A thin wrapper around trees.

gcc/jit/
* jit-playback.h: New.

OK.
jeff

Re: [PATCH 17/27] New file: gcc/jit/libgccjit++.h

[Jeff Law]

On 10/31/14 11:02, David Malcolm wrote:

This adds a C++ wrapper API, with syntactic sugar for reducing the
verbosity compared to the C API.

gcc/jit/
* libgccjit++.h: New.

OK.
Jeff

Re: [PATCH 20/27] Documentation: Makefile and conf.py

[Jeff Law]

On 10/31/14 11:02, David Malcolm wrote:

When I previously submitted the jit for review, I posted all of the
documentation as one big patch, as:
   "[PATCH 08/10] Documentation for the JIT library (Re: Patches 5-10 of jit 
merger)"
 https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01392.html

Since then, I've:

   * eliminated all mentions of pkg-config (since we no longer support
 this)

   * eliminated the installation section and the discussion of packages

   * converted the final page (docs/internals/index.rst) into a short
 guide for contributors to the project (e.g. myself and other
 maintainers)

Prebuilt HTML from this can be seen at:
   https://dmalcolm.fedorapeople.org/gcc/libgccjit-api-docs/index.html

To make review easier, I've split the documentation up to smaller
patches, starting with this one.

This patch adds the Makefile and configuration file for Sphinx
for building docs from the .rst files that follow.

gcc/jit/
* docs/Makefile: New.
* docs/conf.py: New.

OK.
Jeff

Re: [PATCH 12/27] New file: gcc/jit/jit-recording.h

[Jeff Law]

On 10/31/14 11:02, David Malcolm wrote:

This file declares the gcc::jit::recording internal API, so that
libgccjit.c can record the calls that are made to the public API, for
later playback by the dummy frontend.

gcc/jit/
* jit-recording.h: New.
---
  gcc/jit/jit-recording.h | 1593 +++
  1 file changed, 1593 insertions(+)
  create mode 100644 gcc/jit/jit-recording.h

diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
new file mode 100644
index 000..bb1a2ee
--- /dev/null
+++ b/gcc/jit/jit-recording.h

[ ... ]


+
+private:
+  void validate ();
So give the complexities in interfacing with the guts of GCC, would it 
make sense to expose the validate method?



+/* or just use std::string? */
+class string : public memento
Is there some reason not to use std::string?  I really like using 
standard components rather than rolling our own.




OK for the trunk.

jeff

Re: [PATCH 06/27] New file: gcc/jit/Make-lang.in

[Jeff Law]

On 10/31/14 11:02, David Malcolm wrote:

gcc/jit/
* Make-lang.in: New.

OK.
jeff

Re: [PATCH 01/27] gcc: configure and Makefile changes needed by jit

[Jeff Law]

On 10/31/14 11:02, David Malcolm wrote:

An earlier version of this was posted as:
   "[PATCH 2/5] gcc: configure and Makefile changes needed by jit"
 https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01169.html

Since then, I've eliminated the gcc_version, bindir, and pkgconfigdir
additions, and added the FULL_DRIVER_NAME variable and symlink, to
avoid the need to install when running the jit testsuite.

gcc/ChangeLog:
* Makefile.in (doc_build_sys): New variable, set to "sphinx" if
sphinx is installed, falling back to "texinfo" otherwise.
(FULL_DRIVER_NAME): New variable, adapted from the
install-driver target.  New target, a symlink within the builddir,
linked to "xgcc", for use when running the JIT library from the
builddir.
(MOSTLYCLEANFILES): Add FULL_DRIVER_NAME.
(install-driver): Use $(FULL_DRIVER_NAME) rather than spelling it
out.

* configure.ac (doc_build_sys): New variable, set to "sphinx" if
sphinx is installed, falling back to "texinfo" otherwise.
(GCC_DRIVER_NAME): Generate a gcc-driver-name.h file containing
GCC_DRIVER_NAME for the benefit of jit/internal-api.c.

* configure: Regenerate.

OK.
jeff

Re: SRA: don't drop clobbers

[Marc Glisse]

On Mon, 3 Nov 2014, Marc Glisse wrote:


On Mon, 3 Nov 2014, Martin Jambor wrote:


I just applied your patch on top of trunk revision 217032 on my


Ah, that explains it, thanks. This patch is a follow-up to r217034. Still, I 
didn't expect the ICE you are seeing by applying this patch to older trunk, 
I'll try to reproduce that.


It is TODO_update_address_taken that used to remove clobbers, and as you 
said ESRA goes straight to TODO_update_ssa, which explains why the 
clobbers caused trouble. In any case, after r217034, update_ssa should 
handle clobbers much better. Could you take an other look based on a more 
recent trunk, please?


--
Marc Glisse

Re: The nvptx port [11/11] More tools.

[Jeff Law]

On 10/31/14 17:50, Bernd Schmidt wrote:

On 10/31/2014 09:56 PM, Jeff Law wrote:

Pondering this a bit more, I think this is fine in concept.  As you
note, removing the GNU extensions or at least making them conditional
would be good since these are going to be built with the host tools.

I'm not going to dig into the implementations...  I'm going to assume
the nvptx maintainer (that's highly likely to be you :-) will own their
care and feeding.


I was beginning to think I'd just make a separate package. That could
then also include a nvptx-run which would have to link against CUDA
libraries.

Your call.

jeff

Re: [PATCH 13/27] New file: gcc/jit/jit-recording.c

[Jeff Law]

On 10/31/14 11:02, David Malcolm wrote:

Implementation of the gcc::jit::recording internal API, so that
libgccjit.c can record the calls that are made to the public API, for
later playback by the dummy frontend.

gcc/jit/
* jit-recording.c: New.
Cursory review since it's the JIT implementation directory which you'll 
likely end up owning...




+
+/* Assuming that this block has been terminated, get the number of
+   successor blocks, which will be 0, 1 or 2, for return, unconditional
+   jump, and conditional jump respectively.
+   NEXT1 and NEXT2 must be non-NULL.  The first successor block (if any)
+   is written to NEXT1, and the second (if any) to NEXT2.
+
+   Used when validating functions, and when dumping dot representations
+   of them.  */
So presumably no multi-way branches yet?  Might be better to build the 
API in such a way that it handles multi-way branches from the get-go 
rather than retrofitting later.  Your call.


Otherwise I don't see anything objectionable.  OK for the trunk.
jeff

Re: [PATCH] Optimize BIT_AND_EXPRs for UBSAN_OBJECT_SIZE

[Jeff Law]

On 11/03/14 13:47, Marek Polacek wrote:

We don't emit UBSAN_BOUNDS checks in case we can at compile-time
prove that the array access is fine.  Also if we have [i & CST],
where CST is <= bound_of_the_array, we know we're fine as well.

But we don't have similar BIT_AND_EXPR check for UBSAN_OBJECT_SIZE
which is what this patch attempts to add.
(This is unrelated to the UBSAN_NULL optimization I posted earlier
today.)

Bootstrap-ubsan/regtest passed on x86_64-linux, ok for trunk?

2014-11-03  Marek Polacek  

* ubsan.c (instrument_object_size): Optimize [x & CST] array accesses.
testsuite/
* c-c++-common/ubsan/object-size-10.c: New test.

OK.
jeff

Re: nvptx offloading patches [1/n]

[Jeff Law]

On 11/01/14 05:47, Bernd Schmidt wrote:

This is one of the patches required to make offloading via the LTO path
work when the machines involved differ.

x86 requires bigger alignments for some types than nvptx does, which
becomes an issue when reading LTO produced by the host compiler. The
problem with having a variable with DECL_ALIGN larger than the stack
alignment is that gcc will try to align the variable dynamically with an
alloca/rounding operation, and there isn't a working alloca on nvptx.
Besides, the overhead would be pointless.

The patch below restricts the alignments to the maximum possible when
reading in LTO data in an offload compiler. Unfortunately
BIGGEST_ALIGNMENT isn't suitable for this, as it can vary at runtime
with attribute((target)), and because vector modes can exceed it, so a
limit based on BIGGEST_ALIGNMENT would be unsuitable for some ports.
Instead I've added a hook called limit_offload_alignment which is called
when reading LTO on an offload compiler. It does nothing anywhere except
on ptx where it limits alignments to 64 bit.

Bootstrapped and tested on x86_64-linux. Ok?

Not ideal.

Doesn't this affect our ability to pass data back and forth between the 
host and GPU?  Or is this strictly a problem with stack objects and thus 
lives entirely on the GPU?


jeff

Re: nvptx offloading patches [2/n]

[Jeff Law]

On 11/01/14 05:51, Bernd Schmidt wrote:

LTO has a mechanism not to stream out common nodes that are expected to
be identical on each run. When using LTO to communicate between
compilers for different targets, the va_list_type_node and related ones
must be excluded from this.

Richard B mentioned in a recent mail that the i386 backend uses direct
comparisons to va_list_type_node. After investigating a bit it seems to
me that this is not actually a problem: what's being compared is the
return value of ix86_canonical_va_list_type, which always chooses one of
va_list_type_node or its ABI variants, so the comparison should hold
even with this patch.

Bootstrapped and tested on x86_64-linux, ok?
Would like the SuSE guys to chime in here since they know more about the 
streamer than I.


jeff

Re: nvptx offloading patches [3/n], RFD

[Jeff Law]

On 11/01/14 05:57, Bernd Schmidt wrote:

This is not against current trunk; it applies to gomp-4_0-branch where
it is one of the necessary parts to make offloading x86->nvptx work. The
issue is that the LTO file format depends on the machine_modes enum, it
needs to match between host and offload target. The easiest way to do
this is to just use the host-modes.def when compiling an offload compiler.

Ports that want to be hosts for offloading may need to modify their
modes.def. The patch below contains changes to i386-modes.def which
modifies XFmode depending on a target switch. I'm not actually entirely
sure what to do about this. Do we want to make this flag an error when
offloading is enabled? Or maybe add float format support to the
-foffload-abi option?

Thoughts? Ok for the first part of the patch once the other offloading
patches have gone in (bootstrapped and tested on x86_64-linux)?
It feels like we've got another real distinction to make.  We've had 
host, build & target and they're all independent.  It feels like we need 
offload target and better separate between target and offload target. 
Then we need to figure out the places where we've got bleed-out.


Not sure how to deal with this any further out than the immediate term 
than using a hack like this. Though I'd prefer to avoid the #ifdef as it 
seems to me this shouldn't be baked in at build/configure time.


jeff

Re: [PATCH] Optimize BIT_AND_EXPRs for UBSAN_OBJECT_SIZE

[Jakub Jelinek]

On Mon, Nov 03, 2014 at 09:47:05PM +0100, Marek Polacek wrote:
> @@ -1456,6 +1457,8 @@ instrument_object_size (gimple_stmt_iterator *gsi, bool 
> is_lhs)
>   }
>break;
>  case ARRAY_REF:
> +  index = TREE_OPERAND (t, 1);
> +  break;
>  case INDIRECT_REF:
>  case MEM_REF:
>  case VAR_DECL:

In theory, perhaps you could check the offset from get_inner_reference
instead, and look for SSA_NAME set to BIT_AND_EXPR there instead, to handle
cases like
struct S { int a, b; } a[1024];
...
int j = a[i & 1023].b;
etc. - you have size of the base already computed, if the constant part
of offset and bitoffset together is less than that size and the variable
part of it is SSA_NAME set to BIT_AND_EXPR with non-negative const smaller
than size - (constant part of offset + (bitoffset + BITS_PER_UNIT - 1) /
BITS_PER_UNIT + access size), optimize the check away.  But perhaps it can
wait for later.

> @@ -1537,6 +1540,24 @@ instrument_object_size (gimple_stmt_iterator *gsi, 
> bool is_lhs)
>&& tree_int_cst_le (t, sizet))
>  return;
>  
> +  if (index != NULL_TREE
> +  && TREE_CODE (index) == SSA_NAME
> +  && TREE_CODE (sizet) == INTEGER_CST)
> +{
> +  gimple def = SSA_NAME_DEF_STMT (index);
> +  if (is_gimple_assign (def)
> +   && gimple_assign_rhs_code (def) == BIT_AND_EXPR
> +   && TREE_CODE (gimple_assign_rhs2 (def)) == INTEGER_CST)
> + {
> +   tree cst = gimple_assign_rhs2 (def);
> +   tree sz = fold_build2 (EXACT_DIV_EXPR, sizetype, sizet,
> +  TYPE_SIZE_UNIT (type));
> +   if (tree_int_cst_sgn (cst) >= 0
> +   && tree_int_cst_lt (cst, sz))
> + return;
> + }
> +}
> +
>/* Nope.  Emit the check.  */
>t = force_gimple_operand_gsi (gsi, t, true, NULL_TREE, true,
>   GSI_SAME_STMT);
> 

Ok, thanks.

Jakub

Re: [PARCH 1/2, x86, PR63534] Fix darwin bootstrap

[Jeff Law]

On 11/01/14 06:39, Evgeny Stupachenko wrote:

When PIC register is pseudo there is nothing special about it's value
that setjmp can hurt. So if the pseudo register lives across
setjmp_receiver RA should care about correct allocation (in case it is
not saved/restored, it should go on stack). gcc.dg tests and specs
I've tested behave like this.
If the allocator picked a call-clobbered register for the PIC register, 
then we're obviously OK since the setjmp has to be expected to clobber 
the PIC register.


But if the PIC register is in a call-saved register, then it's going to 
be assumed to not be clobbered across calls and I don't believe that is 
guaranteed for builtin setjmp/longjmp.  Those restore SP, FP and an 
ARGP, but not anything else by default.


So the callee might have clobbered the call saved hard register, 
expecting to restore its value in its epilogue.  But due to the longjmp, 
that epilogue never gets called and thus the call-saved register won't 
have the right value in the receiver.


Now if your argument is that IRA/LRA handle this, that's fine, a pointer 
to that code would be appreciated so that it can be quickly audited. 
Certainly the old local-alloc/global-alloc had magic for setjmp/longjmp 
and maybe IRA/LRA does too, but it's better to be sure than just assume.




The initial problem comes from non-local goto as it tries to emit
pseudo PIC register after reload.
?  You mean it emits a reference to the pseudo into RTL?  That would 
indicate that the allocators never put the pseudo into a hard 
register?!?  RTL dumps with a few pointers to key insns would help here.


jeff

fix obvious typos in input.c

[Manuel López-Ibáñez]

Committed as r217057.

Index: gcc/input.c
===
--- gcc/input.c (revision 217056)
+++ gcc/input.c (revision 217057)
@@ -749,19 +749,20 @@
 expanded_location
 expand_location_to_spelling_point (source_location loc)
 {
-  return expand_location_1 (loc, /*expansion_piont_p=*/false);
+  return expand_location_1 (loc, /*expansion_point_p=*/false);
 }

-/* If LOCATION is in a system header and if it's a virtual location for
-   a token coming from the expansion of a macro M, unwind it to the
-   location of the expansion point of M.  Otherwise, just return
+/* If LOCATION is in a system header and if it is a virtual location for
+   a token coming from the expansion of a macro, unwind it to the
+   location of the expansion point of the macro.  Otherwise, just return
LOCATION.

This is used for instance when we want to emit diagnostics about a
-   token that is located in a macro that is itself defined in a system
-   header -- e.g for the NULL macro.  In that case, if LOCATION is
-   passed to diagnostics emitting functions like warning_at as is, no
-   diagnostic won't be emitted.  */
+   token that may be located in a macro that is itself defined in a
+   system header, for example, for the NULL macro.  In such a case, if
+   LOCATION were passed directly to diagnostic functions such as
+   warning_at, the diagnostic would be suppressed (unless
+   -Wsystem-headers).  */

 source_location
 expansion_point_location_if_in_system_header (source_location location)
Index: gcc/ChangeLog
===
--- gcc/ChangeLog   (revision 217056)
+++ gcc/ChangeLog   (revision 217057)
@@ -1,3 +1,8 @@
+2014-11-04  Manuel López-Ibáñez  
+
+   * input.c (expand_location_to_spelling_point): Fix typo.
+   (expansion_point_location_if_in_system_header): Fix comment.
+
 2014-11-03  Pitchumani Sivanupandi 

* config/avr/gen-avr-mmcu-specs.c: Remove unnecessary format specifier.

Re: nvptx offloading patches [1/n]

[Bernd Schmidt]

On 11/03/2014 11:22 PM, Jeff Law wrote:

On 11/01/14 05:47, Bernd Schmidt wrote:

This is one of the patches required to make offloading via the LTO path
work when the machines involved differ.

x86 requires bigger alignments for some types than nvptx does, which
becomes an issue when reading LTO produced by the host compiler. The
problem with having a variable with DECL_ALIGN larger than the stack
alignment is that gcc will try to align the variable dynamically with an
alloca/rounding operation, and there isn't a working alloca on nvptx.
Besides, the overhead would be pointless.

The patch below restricts the alignments to the maximum possible when
reading in LTO data in an offload compiler. Unfortunately
BIGGEST_ALIGNMENT isn't suitable for this, as it can vary at runtime
with attribute((target)), and because vector modes can exceed it, so a
limit based on BIGGEST_ALIGNMENT would be unsuitable for some ports.
Instead I've added a hook called limit_offload_alignment which is called
when reading LTO on an offload compiler. It does nothing anywhere except
on ptx where it limits alignments to 64 bit.

Bootstrapped and tested on x86_64-linux. Ok?

Not ideal.

Doesn't this affect our ability to pass data back and forth between the
host and GPU?  Or is this strictly a problem with stack objects and thus
lives entirely on the GPU?


Communication between host and GPU is all done via some form of memcpy, 
so I wouldn't expect this to be a problem. Structure layouts and such 
are decided by the host compiler and since that uses higher alignments, 
they should work fine on the GPU. I believe the only thing this really 
does is relax the requirements when allocating storage on the GPU side.



Bernd

Re: Recent go changes broke alpha bootstrap

[Ian Taylor]

On Mon, Nov 3, 2014 at 9:02 AM, Dominik Vogt  wrote:
> On Thu, Oct 30, 2014 at 08:05:14AM -0700, Ian Taylor wrote:
>> On Thu, Oct 30, 2014 at 5:46 AM, Dominik Vogt  
>> wrote:
>> > I'm not quite sure about the best approach.  The attempt to
>> > represent C unions in the "right" way is ultimately futile as Go
>> > does not have the types necessary for it.  For example, the
>> > handling of anonymous bit fields will never be right as it's
>> > undefinied.  On the other hand I could fix the issue at hand by
>> > changing the way anonymous unions are represented in Go.
>> >
>> > Example:
>> >
>> >   struct { int8_t x; union { int16_t y; int 32_t z; }; };
>> >
>> > Was represented (before the patch) as
>> >
>> >   struct { X byte; int16 Y; }
>> >
>> > which had size 4, alignment 2 and y at offset 2 but should had
>> > have size 8, alignment 4 and y at offset 4.  With the current
>> > patch the Go layout is
>> >
>> >   struct { X byte; artificial_name struct { y [2]byte; align [0]int32; } }
>> >
>> > with the proper size, alignment and offset, but y is addressed as
>> > ".artificial_name.y" insted of just ".y", and y is a byte array
>> > and not an int16.
>> >
>> > I could remove the "artificial_name struct" and add padding before
>> > and after y instead:
>> >
>> >   struct { X byte; pad_0 [3]byte; Y int16; pad_1 [2]byte; align [0]int32; }
>> >
>> > What do you think?
>>
>> Sounds good to me.  Basically the fields of the anonymous union should
>> be promoted to become fields of the struct.  We can't do it in
>> general, but we can do it for the first field.  That addresses the
>> actual uses of anonymous unions.
>
> The attached patch fixes this, at least if the first element of the
> union is not a bitfield.
>
> Bitfields can really not be represented properly in Go (think about
> constructs like "struct { int : 1; int bf : 1; }"), I'd rather not
> try to represent them in a predictable way.  The patched code may
> or may not give them a name, and reserves the proper amount of
> padding where required in structs.  If a union begins with an
> anonymous bitfield (which makes no sense), that is ignored.  If a
> union begins with a named bitfield (possibly after unnamed ones),
> this may or may not be used as the (sole) element of the Go
> struct.


Thanks.  I committed your patch.

Ian

Re: [COMMITTED][PATCH PR63173] [AARCH64, NEON] Improve vld[234](q?)_dup intrinsics

[Yangfei (Felix)]

> So we've been seeing
> 
> FAIL: gcc.target/aarch64/vldN_dup_1.c
> 
> on aarch64_be-none-elf, since this patch went in. Felix, did you test for
> bigendian?
> 
> However, this failure is fixed if I apply David Sherwood's patch set:
> 
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00942.html
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01099.html
> 
> So maybe I can "ping" that on David's behalf (+Alan Hayward's
> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00952.html on which those two
> patches depend).
> 
> Cheers, Alan
> 
> 

Hi Alan,

As we don't have a big-endian platform, we carried the testing for 
little-endian.
Hope this is helpful to you. 

Re: [PATCH 08/27] New file: gcc/jit/libgccjit.h

[David Malcolm]

On Mon, 2014-11-03 at 13:22 -0700, Jeff Law wrote:
> On 10/31/14 11:02, David Malcolm wrote:
> > This header is the public API for the library.
> >
> > gcc/jit/
> > * libgccjit.h: New.
> Given this is inside the JIT subdirectory, I'm not doing a depth review.
> 
>   +
> > +/* A gcc_jit_block encapsulates a "basic block" of statements within a
> > +   function (i.e. with one entry point and one exit point).
> > +
> > +   Every block within a function must be terminated with a conditional,
> > +   a branch, or a return.
> ? That doesn't seem right.   We don't really place restrictions on what 
> ends a block, but we do place restrictions on what kinds of IL 
> statements can appear in the middle of a block.

Adding a conditional, branch or return to a gcc_jit_block terminates
that block, so you can't add further statements to it.  Hence the API
*does* restrict those statements from being in the middle of a block.

> > +
> > +   All of the blocks in a function must be reachable via some path from
> > +   the first block.
> ?  Is this something your code requires?  While we have some code which 
> assumes unreachable blocks do not exist, we generally deal with that by 
> running the cfgcleanup passes which will identify and remove the 
> unreachables.

An earlier version of the API was much more freeform, without blocks,
instead having labels, requiring the client code to add statements in
order.  It initially seemed like a good idea, but my experience porting
the GNU Octave JIT from llvm was that as a user I needed warnings from
the API about messed-up control flow: it's just too easy to add a
statement to the wrong block, or to use the wrong block for a jump
target.  Once I added these restrictions (and validation checks), it
became dramatically easier to do the port.

The requirement above that blocks are explicitly terminated also came
from this experience: I felt that having the ability for control flow to
implicitly "fall off the end of a block" was more of a liability for
library users than a benefit; better to require them to explicitly state
where control flow should go.

Bear in mind that the intended user of this library is a language
implementer, and they typically not writing code to build a specific
function; they're writing code that walks some other IR (e.g. bytecode)
and uses it to build another function. 
This gives them three levels of implementation: 
  A) the high-level function (e.g. Octave),
  B) the IR for that function (e.g. Octave AST), and 
  C) libgccjit API's version of it
Figuring out where something is going wrong is "fun" to debug.  Hence
the more validation checks we can build in, the easier it will be for
them.   That's my thinking, anyway :)


> And this raises one of those questions that's been in the back of my 
> mind.  What's the right level of documentation and exposure of 
> internals.  When I read the docs, one of questions I kept to myself was 
> whether or not we've giving the users too much or too little 
> information.  As well as a vague concern that actually using the JIT is 
> going to be so painful due to exposure of implementation details that we 
> might want to just go in with the expectation that this is really a V0 
> implementation and that it's all going to have to change and be 
> rewritten as GCC's internals get sorted out.

Hmmm...  I guess we'll have to see.

> > +
> > +/*
> > +   Acquire a JIT-compilation context.
> > +
> > +   FIXME: error-handling?
> There's a whole class of problems with error handling. GCC has always 
> had this notation that it can terminate compilation when something "bad" 
> happens.  In a JIT world that may not be appropriate.  But that's 
> probably outside the scope of what we want to try and tackle at this stage.
Right.  FWIW I consider it a bug if a shared library ever aborts the
process it's in, which is at odds with how much of libiberty and gcc are
written, so changing that is a long-term thing.

The FIXME above relates specifically to the gcc_jit_context_acquire
entrypoint: the rest of the API handles errors by reporting them on a
context, but clearly we can't do that until we have a context.  Though
it can only fail due to memory failure, and given the amount of other
code that aborts on memory failure, it may be futile trapping that.

> > +enum gcc_jit_int_option
> > +{
> > +  /* How much to optimize the code.
> > + Valid values are 0-3, corresponding to GCC's command-line options
> > + -O0 through -O3.
> > +
> > + The default value is 0 (unoptimized).  */
> > +  GCC_JIT_INT_OPTION_OPTIMIZATION_LEVEL,
> > +
> > +  GCC_JIT_NUM_INT_OPTIONS
> > +};
> I don't think we explicitly disallow optimization values > 3, they just 
> don't do anything.
> 
> 
> > +
> > +/* Options taking boolean values.
> > +   These all default to "false".  */
> > +enum gcc_jit_bool_option
> > +{
> > +  /* If true, gcc_jit_context_compile will attempt to do the right
> > + thing so that if you attach a debugger to the proces

RE: [BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, ifcvt] Allow CC mode if HAVE_cbranchcc4)

[Zhenqiang Chen]

> -Original Message-
> From: Jan-Benedict Glaw [mailto:jbg...@lug-owl.de]
> Sent: Monday, November 03, 2014 6:16 PM
> To: Zhenqiang Chen; Hartmut Penner; Ulrich Weigand; Andreas Krebbel
> Cc: 'Richard Henderson'; gcc-patches@gcc.gnu.org
> Subject: Re: [BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, 
> ifcvt]
> Allow CC mode if HAVE_cbranchcc4)
> 
> On Mon, 2014-11-03 11:06:06 +0100, Jan-Benedict Glaw 
> wrote:
> > On Wed, 2014-10-29 18:27:57 +0800, Zhenqiang Chen
>  wrote:
> > > Hi,
> > >
> > > The patch enhances ifcvt to allow_cc_mode if HAVE_cbranchcc4.
> > >
> > > Bootstrap and no make check regression on X86-64.
> > > Will add new test cases after ccmp is enabled.
> > >
> > > Ok for trunk?
> >
> > This seems to uncover something for s390x-linux, see
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372394
> >
> > [...]
> > g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-
> exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -
> Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common
> -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -
> I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -
> I/home/jbglaw/repos/gcc/gcc/../libcpp/include  -
> I/home/jbglaw/repos/gcc/gcc/../libdecnumber -
> I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -
> I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o ifcvt.o -MT ifcvt.o -MMD -
> MP -MF ./.deps/ifcvt.TPo /home/jbglaw/repos/gcc/gcc/ifcvt.c
> > /home/jbglaw/repos/gcc/gcc/ifcvt.c:1456:5: error: token "." is not
> > valid in preprocessor expressions
> > /home/jbglaw/repos/gcc/gcc/ifcvt.c:1788:5: error: token "." is not
> > valid in preprocessor expressions
> > /home/jbglaw/repos/gcc/gcc/ifcvt.c:2370:5: error: token "." is not
> > valid in preprocessor expressions
> > make[1]: *** [ifcvt.o] Error 1
> >
> > It's choking on the HAVE_cbranchcc4 macro itself there.
> 
> Oh, and with the most recent ifcvt.c changes, this boils down to:
> 
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-
> strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -
> pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -
> Werror -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -
> I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
> -I../../../gcc/gcc/../libcpp/include
> -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber -
> I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -
> I../../../gcc/gcc/../libbacktrace-o ifcvt.o -MT ifcvt.o -MMD -MP -
> MF ./.deps/ifcvt.TPo ../../../gcc/gcc/ifcvt.c
> In file included from ./tm.h:19:0,
>  from ../../../gcc/gcc/ifcvt.c:23:
> ./options.h:263:36: error: token "." is not valid in preprocessor expressions
> #define target_flags global_options.x_target_flags
> ^
> ./options.h:4276:29: note: in expansion of macro ‘target_flags’
>  #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>  ^
> ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
>  #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
>   ^
> ../../../gcc/gcc/ifcvt.c:1467:5: note: in expansion of macro ‘HAVE_cbranchcc4’
>  #if HAVE_cbranchcc4
>  ^
> ./options.h:263:36: error: token "." is not valid in preprocessor expressions
> #define target_flags global_options.x_target_flags
> ^
> ./options.h:4276:29: note: in expansion of macro ‘target_flags’
>  #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>  ^
> ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
>  #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
>   ^
> ../../../gcc/gcc/ifcvt.c:1799:5: note: in expansion of macro ‘HAVE_cbranchcc4’
>  #if HAVE_cbranchcc4
>  ^
> ./options.h:263:36: error: token "." is not valid in preprocessor expressions
> #define target_flags global_options.x_target_flags
> ^
> ./options.h:4276:29: note: in expansion of macro ‘target_flags’
>  #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>  ^
> ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
>  #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
>   ^
> ../../../gcc/gcc/ifcvt.c:2381:5: note: in expansion of macro ‘HAVE_cbranchcc4’
>  #if HAVE_cbranchcc4
>  ^
> make[2]: *** [ifcvt.o] Error 1
> 
> 
> 
> (See build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372420
> for reference.)
> 
> MfG, JBG
> 
> --
>   Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
> Signature of:   ...und wenn Du de

RE: [BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, ifcvt] Allow CC mode if HAVE_cbranchcc4)

[Zhenqiang Chen]

Sorry for breaking the build. The patch was reverted.

I will rework on it.

Thanks!
-Zhenqiang

> -Original Message-
> From: Jan-Benedict Glaw [mailto:jbg...@lug-owl.de]
> Sent: Monday, November 03, 2014 6:16 PM
> To: Zhenqiang Chen; Hartmut Penner; Ulrich Weigand; Andreas Krebbel
> Cc: 'Richard Henderson'; gcc-patches@gcc.gnu.org
> Subject: Re: [BUILDROBOT] s390x-linux: Breaking in ifcvt.c (was: [PATCH, 
> ifcvt]
> Allow CC mode if HAVE_cbranchcc4)
> 
> On Mon, 2014-11-03 11:06:06 +0100, Jan-Benedict Glaw 
> wrote:
> > On Wed, 2014-10-29 18:27:57 +0800, Zhenqiang Chen
>  wrote:
> > > Hi,
> > >
> > > The patch enhances ifcvt to allow_cc_mode if HAVE_cbranchcc4.
> > >
> > > Bootstrap and no make check regression on X86-64.
> > > Will add new test cases after ccmp is enabled.
> > >
> > > Ok for trunk?
> >
> > This seems to uncover something for s390x-linux, see
> > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372394
> >
> > [...]
> > g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-
> exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -
> Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common
> -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -
> I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -
> I/home/jbglaw/repos/gcc/gcc/../libcpp/include  -
> I/home/jbglaw/repos/gcc/gcc/../libdecnumber -
> I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -
> I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o ifcvt.o -MT ifcvt.o -MMD -
> MP -MF ./.deps/ifcvt.TPo /home/jbglaw/repos/gcc/gcc/ifcvt.c
> > /home/jbglaw/repos/gcc/gcc/ifcvt.c:1456:5: error: token "." is not
> > valid in preprocessor expressions
> > /home/jbglaw/repos/gcc/gcc/ifcvt.c:1788:5: error: token "." is not
> > valid in preprocessor expressions
> > /home/jbglaw/repos/gcc/gcc/ifcvt.c:2370:5: error: token "." is not
> > valid in preprocessor expressions
> > make[1]: *** [ifcvt.o] Error 1
> >
> > It's choking on the HAVE_cbranchcc4 macro itself there.
> 
> Oh, and with the most recent ifcvt.c changes, this boils down to:
> 
> g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-
> strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -
> pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -
> Werror -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../../gcc/gcc -
> I../../../gcc/gcc/. -I../../../gcc/gcc/../include 
> -I../../../gcc/gcc/../libcpp/include
> -I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber -
> I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -
> I../../../gcc/gcc/../libbacktrace-o ifcvt.o -MT ifcvt.o -MMD -MP -
> MF ./.deps/ifcvt.TPo ../../../gcc/gcc/ifcvt.c
> In file included from ./tm.h:19:0,
>  from ../../../gcc/gcc/ifcvt.c:23:
> ./options.h:263:36: error: token "." is not valid in preprocessor expressions
> #define target_flags global_options.x_target_flags
> ^
> ./options.h:4276:29: note: in expansion of macro ‘target_flags’
>  #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>  ^
> ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
>  #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
>   ^
> ../../../gcc/gcc/ifcvt.c:1467:5: note: in expansion of macro ‘HAVE_cbranchcc4’
>  #if HAVE_cbranchcc4
>  ^
> ./options.h:263:36: error: token "." is not valid in preprocessor expressions
> #define target_flags global_options.x_target_flags
> ^
> ./options.h:4276:29: note: in expansion of macro ‘target_flags’
>  #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>  ^
> ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
>  #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
>   ^
> ../../../gcc/gcc/ifcvt.c:1799:5: note: in expansion of macro ‘HAVE_cbranchcc4’
>  #if HAVE_cbranchcc4
>  ^
> ./options.h:263:36: error: token "." is not valid in preprocessor expressions
> #define target_flags global_options.x_target_flags
> ^
> ./options.h:4276:29: note: in expansion of macro ‘target_flags’
>  #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>  ^
> ./insn-flags.h:439:26: note: in expansion of macro ‘TARGET_HARD_FLOAT’
>  #define HAVE_cbranchcc4 (TARGET_HARD_FLOAT)
>   ^
> ../../../gcc/gcc/ifcvt.c:2381:5: note: in expansion of macro ‘HAVE_cbranchcc4’
>  #if HAVE_cbranchcc4
>  ^
> make[2]: *** [ifcvt.o] Error 1
> 
> 
> 
> (See build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=372420
> for reference.)
> 
> MfG, JBG
> 
> --
>   Jan-Benedict Glaw  jbg

[patch] Use aliases for type traits in C++14 mode.

[Jonathan Wakely]

For C++14-only components we can use the aliases for type traits.

Tested x86_64-linux, committed to trunk.
commit cdb81d65750569f86a526856c99c2ef3c5266d11
Author: Jonathan Wakely 
Date:   Tue Nov 5 23:21:01 2013 +

Use aliases for type traits in C++14 mode.

* include/bits/unique_ptr.h (make_unique): Use alias for trait.
* include/experimental/optional (__constexpr_addressof): Likewise.
(_Optional_base, optional, make_optional): Likewise.

diff --git a/libstdc++-v3/include/bits/unique_ptr.h 
b/libstdc++-v3/include/bits/unique_ptr.h
index ce38c5a..5c2c534 100644
--- a/libstdc++-v3/include/bits/unique_ptr.h
+++ b/libstdc++-v3/include/bits/unique_ptr.h
@@ -768,7 +768,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 inline typename _MakeUniq<_Tp>::__array
 make_unique(size_t __num)
-{ return unique_ptr<_Tp>(new typename remove_extent<_Tp>::type[__num]()); }
+{ return unique_ptr<_Tp>(new remove_extent_t<_Tp>[__num]()); }
 
   /// Disable std::make_unique for arrays of known bound
   template
diff --git a/libstdc++-v3/include/experimental/optional 
b/libstdc++-v3/include/experimental/optional
index 973775b..7e01abe 100644
--- a/libstdc++-v3/include/experimental/optional
+++ b/libstdc++-v3/include/experimental/optional
@@ -151,16 +151,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 * overloaded addressof operator (unary operator&), in which case the call
 * will not be a constant expression.
 */
-  template::value,
-int>::type...>
+  template::value, int>...>
 constexpr _Tp* __constexpr_addressof(_Tp& __t)
 { return &__t; }
 
   /**
 * @brief Fallback overload that defers to __addressof.
 */
-  template::value,
-int>::type...>
+  template::value, int>...>
 inline _Tp* __constexpr_addressof(_Tp& __t)
 { return std::__addressof(__t); }
 
@@ -184,7 +182,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // Remove const to avoid prohibition of reusing object storage for
   // const-qualified types in [3.8/9]. This is strictly internal
   // and even optional itself is oblivious to it.
-  using _Stored_type = typename remove_const<_Tp>::type;
+  using _Stored_type = remove_const_t<_Tp>;
 
 public:
   // [X.Y.4.1] Constructors.
@@ -208,10 +206,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 : _M_payload(std::forward<_Args>(__args)...), _M_engaged(true) { }
 
   template&,
-   _Args&&...>::value,
-  int>::type...>
+   enable_if_t&,
+_Args&&...>::value,
+   int>...>
 constexpr explicit _Optional_base(in_place_t,
   initializer_list<_Up> __il,
   _Args&&... __args)
@@ -330,7 +328,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 class _Optional_base<_Tp, false>
 {
 private:
-  using _Stored_type = typename remove_const<_Tp>::type;
+  using _Stored_type = remove_const_t<_Tp>;
 
 public:
   constexpr _Optional_base() noexcept
@@ -350,10 +348,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 : _M_payload(std::forward<_Args>(__args)...), _M_engaged(true) { }
 
   template&,
-   _Args&&...>::value,
-  int>::type...>
+   enable_if_t&,
+_Args&&...>::value,
+  int>...>
 constexpr explicit _Optional_base(in_place_t,
   initializer_list<_Up> __il,
   _Args&&... __args)
@@ -472,10 +470,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 // Unique tag type.
 optional<_Tp>>
 {
-  static_assert(__and_<__not_::type,
- nullopt_t>>,
-  __not_::type,
- in_place_t>>,
+  static_assert(__and_<__not_, nullopt_t>>,
+  __not_, in_place_t>>,
   __not_>>(),
 "Invalid instantiation of optional");
 
@@ -497,10 +493,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
   template
-typename enable_if<
- is_same<_Tp, typename decay<_Up>::type>::value,
- optional&
-   >::type
+enable_if_t>::value, optional&>
 operator=(_Up&& __u)
 {
   static_assert(__and_,
@@ -527,11 +520,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
   template
-typename enable_if<
- is_constructible<_Tp,
-  initializer_list<_Up>&,
-  _Args&&...>::value
-   >::type
+enable_if_t&,
+  

[patch] Simplify construction of _Bind_simple in

[Jonathan Wakely]

With the arity-checking I added recently we don't need the SFINAE
constraints on the number of arguments to _Bind_simple's constructors.

Tested x86_64-linux, committed to trunk.

commit d78bba658af1677b873d391649ee237150b3c916
Author: Jonathan Wakely 
Date:   Mon Nov 3 14:52:15 2014 +

* include/std/functional (_Bind_simple): Simplify construction.

diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index f615ae4..f8e9b54 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -1582,18 +1582,10 @@ _GLIBCXX_HAS_NESTED_TYPE(result_type)
 {
   typedef typename result_of<_Callable(_Args...)>::type result_type;
 
-  template::type>
+  template
 explicit
-_Bind_simple(const _Callable& __callable, _Args2&&... __args)
-: _M_bound(__callable, std::forward<_Args2>(__args)...)
-{ }
-
-  template::type>
-explicit
-_Bind_simple(_Callable&& __callable, _Args2&&... __args)
-: _M_bound(std::move(__callable), std::forward<_Args2>(__args)...)
+_Bind_simple(_Tp&& __f, _Up&&... __args)
+: _M_bound(std::forward<_Tp>(__f), std::forward<_Up>(__args)...)
 { }
 
   _Bind_simple(const _Bind_simple&) = default;
@@ -1607,7 +1599,6 @@ _GLIBCXX_HAS_NESTED_TYPE(result_type)
   }
 
 private:
-
   template
 typename result_of<_Callable(_Args...)>::type
 _M_invoke(_Index_tuple<_Indices...>)

Re: [patch] LWG 2019 - std::isblank

[Jonathan Wakely]

On 21/10/14 13:26 +0100, Jonathan Wakely wrote:

On 20/10/14 23:08 +0100, Jonathan Wakely wrote:

On 20 October 2014 18:40, Tim Shen  wrote:

On Mon, Oct 20, 2014 at 5:34 AM, Jonathan Wakely  wrote:

Committed to trunk.


Yay, I think it's the time to remove regex_traits::_RegexMask?


Yes, I wanted to get isblank in first, and see how many targets I
broke, then revisit regex.


I don't think we can remove _RegexMask entirely, as we still need
special handling for the "w" class, so maybe something like the
attached.

Alternatively we could replace _M_extended with bool _M_under and not
need to do any bitwise operations like _M_extended & _S_valid_mask.


I've committed the attached.

Tested x86_64-linux.

commit 5afff08e352c971f2658d056a1b1b78a4db99fce
Author: Jonathan Wakely 
Date:   Mon Nov 3 15:02:24 2014 +

Use ctype_base::blank in regex_traits.

* include/bits/regex.h (regex_traits::_RegexMask): Remove _S_blank and
adjust _S_valid_mask.
* include/bits/regex.tcc (regex_traits::lookup_classname): Use
ctype_base::blank.

diff --git a/libstdc++-v3/include/bits/regex.h 
b/libstdc++-v3/include/bits/regex.h
index 4244f2e..30189e3 100644
--- a/libstdc++-v3/include/bits/regex.h
+++ b/libstdc++-v3/include/bits/regex.h
@@ -97,14 +97,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 private:
   struct _RegexMask
{
- typedef typename std::ctype::mask _BaseType;
+ typedef std::ctype_base::mask _BaseType;
  _BaseType _M_base;
  unsigned char _M_extended;
  static constexpr unsigned char _S_under = 1 << 0;
- // FIXME: _S_blank should be removed in the future,
- // when locale's complete.
- static constexpr unsigned char _S_blank = 1 << 1;
- static constexpr unsigned char _S_valid_mask = 0x3;
+ static constexpr unsigned char _S_valid_mask = 0x1;
 
  constexpr _RegexMask(_BaseType __base = 0,
   unsigned char __extended = 0)
diff --git a/libstdc++-v3/include/bits/regex.tcc 
b/libstdc++-v3/include/bits/regex.tcc
index 3322379..94cbbfa 100644
--- a/libstdc++-v3/include/bits/regex.tcc
+++ b/libstdc++-v3/include/bits/regex.tcc
@@ -335,7 +335,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{"s", ctype_base::space},
{"alnum", ctype_base::alnum},
{"alpha", ctype_base::alpha},
-   {"blank", {0, _RegexMask::_S_blank}},
+   {"blank", ctype_base::blank},
{"cntrl", ctype_base::cntrl},
{"digit", ctype_base::digit},
{"graph", ctype_base::graph},
@@ -377,11 +377,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return __fctyp.is(__f._M_base, __c)
// [[:w:]]
|| ((__f._M_extended & _RegexMask::_S_under)
-   && __c == __fctyp.widen('_'))
-   // [[:blank:]]
-   || ((__f._M_extended & _RegexMask::_S_blank)
-   && (__c == __fctyp.widen(' ')
-   || __c == __fctyp.widen('\t')));
+   && __c == __fctyp.widen('_'));
 }
 
   template

[patch] Make std::reference_wrapper trivially copyable.

[Jonathan Wakely]

This might be required for C++17, and is beneficial anyway, so let's
change it now.

Tested x86_64-linux, committed to trunk.

commit 3b1cfc115060eb85f2a43c4bef80d25c4aefaa95
Author: Jonathan Wakely 
Date:   Tue Nov 4 01:51:48 2014 +

Make reference_wrapper trivially copyable.

* include/std/functional (reference_wrapper): Define copy constructor
and copy assignment as defaulted.
* testsuite/20_util/bind/ref_neg.cc: Adjust dg-error.
* testsuite/20_util/reference_wrapper/requirements.cc: New.

diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index f8e9b54..25ec1b3 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -410,16 +410,10 @@ _GLIBCXX_HAS_NESTED_TYPE(result_type)
 
   reference_wrapper(_Tp&&) = delete;
 
-  reference_wrapper(const reference_wrapper<_Tp>& __inref) noexcept
-  : _M_data(__inref._M_data)
-  { }
+  reference_wrapper(const reference_wrapper&) = default;
 
   reference_wrapper&
-  operator=(const reference_wrapper<_Tp>& __inref) noexcept
-  {
-   _M_data = __inref._M_data;
-   return *this;
-  }
+  operator=(const reference_wrapper&) = default;
 
   operator _Tp&() const noexcept
   { return this->get(); }
diff --git a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc 
b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
index 1063dd3..4e627cf 100644
--- a/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
@@ -30,10 +30,10 @@ void test01()
 {
   const int dummy = 0;
   std::bind(&inc, _1)(0);   // { dg-error  "no match" }
-  // { dg-error "rvalue|const" "" { target *-*-* } 1213 }
-  // { dg-error "rvalue|const" "" { target *-*-* } 1227 }
-  // { dg-error "rvalue|const" "" { target *-*-* } 1241 }
-  // { dg-error "rvalue|const" "" { target *-*-* } 1255 }
+  // { dg-error "rvalue|const" "" { target *-*-* } 1207 }
+  // { dg-error "rvalue|const" "" { target *-*-* } 1221 }
+  // { dg-error "rvalue|const" "" { target *-*-* } 1235 }
+  // { dg-error "rvalue|const" "" { target *-*-* } 1249 }
   std::bind(&inc, std::ref(dummy))();  // { dg-error  "no match" }
 }
 
diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/requirements.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/requirements.cc
new file mode 100644
index 000..c4d784c
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/requirements.cc
@@ -0,0 +1,32 @@
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++11" }
+// { dg-do compile }
+
+#include 
+
+struct NonTrivial
+{
+  ~NonTrivial() { }
+};
+
+using R = std::reference_wrapper;
+
+static_assert(std::is_copy_constructible::value, "copy constructible");
+static_assert(std::is_copy_assignable::value, "copy assignable");
+static_assert(std::is_trivially_copyable::value, "trivially copyable");

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

[Jonathan Wakely]

On 03/11/14 17:19 +0100, Paolo Carlini wrote:

Hi,

On 11/03/2014 03:55 PM, Rainer Emrich wrote:

Since the recent changes to the testsuites the folowing make targets in the
libstdc++ testsuite directory don't work anymore:

check-parallel
check-performance
check-performance-parallel

Any comments?
All I can see so far is a non-conforming use of default arguments (ie, 
repeated in the function template definitions) in 
include/parallel/algo.h, which the front-end didn't catch until quite 
recently (not in 4.9.x). See below what I mean to apply to fix that. 
Not sure if you meant something else (too) in your terse message, 
tough.


 has the same problem, fixed with this patch.
commit 356183f393d2fce9beb5b2d4772b9f8ab83280cd
Author: Jonathan Wakely 
Date:   Tue Nov 4 03:33:07 2014 +

	* include/parallel/numeric.h: Do not use default arguments in function
	template redeclarations (definitions).

diff --git a/libstdc++-v3/include/parallel/numeric b/libstdc++-v3/include/parallel/numeric
index 8254635..e89f27e 100644
--- a/libstdc++-v3/include/parallel/numeric
+++ b/libstdc++-v3/include/parallel/numeric
@@ -85,8 +85,7 @@ namespace __parallel
 __accumulate_switch(__RAIter __begin, __RAIter __end, 
   _Tp __init, _BinaryOperation __binary_op, 
   random_access_iterator_tag, 
-  __gnu_parallel::_Parallelism __parallelism_tag  
-  = __gnu_parallel::parallel_unbalanced)
+  __gnu_parallel::_Parallelism __parallelism_tag)
 {
   if (_GLIBCXX_PARALLEL_CONDITION(
 static_cast<__gnu_parallel::_SequenceIndex>(__end - __begin)
@@ -193,8 +192,7 @@ namespace __parallel
 			   _BinaryFunction2 __binary_op2,
 			   random_access_iterator_tag,
 			   random_access_iterator_tag,
-			   __gnu_parallel::_Parallelism __parallelism_tag
-			   = __gnu_parallel::parallel_unbalanced)
+			   __gnu_parallel::_Parallelism __parallelism_tag)
 {
   if (_GLIBCXX_PARALLEL_CONDITION((__last1 - __first1)
   >= __gnu_parallel::_Settings::get().
@@ -419,8 +417,7 @@ namespace __parallel
  random_access_iterator_tag,
  random_access_iterator_tag,
  __gnu_parallel::_Parallelism
- __parallelism_tag
- = __gnu_parallel::parallel_balanced)
+ __parallelism_tag)
 {
   if (_GLIBCXX_PARALLEL_CONDITION(
 static_cast<__gnu_parallel::_SequenceIndex>(__end - __begin)

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

[Jonathan Wakely]

On 03/11/14 22:07 +, Jonathan Wakely wrote:

On 3 November 2014 17:51, Paolo Carlini  wrote:

.. other than the above issue, I see a segmentation fault for:

performance/ext/pb_ds/multimap_text_insert_mem_large.cc

and a compile error for:

performance/ext/pb_ds/priority_queue_text_pop_mem.cc

which boils down to a an error at include/bits/stl_deque.h:519 (likely pd_ds
is misusing std::deque). Jon, can you double check the latter?


I think it's a bug I introduced to std::deque -- I'm assuming that
MoveConstructible allocators are also MoveAssignable, which is not a
valid assumption. I'll fix it.


Fixed by this patch, committed to trunk.
commit f84f372dceab9cd9401caf326f942557e8ccfcac
Author: Jonathan Wakely 
Date:   Tue Nov 4 03:16:55 2014 +

Do not assume allocator is assignable.

	* include/bits/stl_deque.h (_Deque_base(_Deque_base&&)): Copy
	allocator instead of moving.
	* testsuite/23_containers/deque/allocator/move-2.cc: New.

diff --git a/libstdc++-v3/include/bits/stl_deque.h b/libstdc++-v3/include/bits/stl_deque.h
index acb7715..d50d3c90 100644
--- a/libstdc++-v3/include/bits/stl_deque.h
+++ b/libstdc++-v3/include/bits/stl_deque.h
@@ -503,23 +503,11 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 
 #if __cplusplus >= 201103L
   _Deque_base(_Deque_base&& __x)
-  : _M_impl(std::move(__x._M_get_Tp_allocator()))
+  : _M_impl(__x._M_get_Tp_allocator())
   {
+	_M_initialize_map(0);
 	if (__x._M_impl._M_map)
-	  {
-	this->_M_impl._M_swap_data(__x._M_impl);
-	__try
-	  {
-		// Re-initialize __x using its moved-from allocator.
-		__x._M_initialize_map(0);
-	  }
-	__catch (...)
-	  {
-		this->_M_impl._M_swap_data(__x._M_impl);
-		__x._M_get_Tp_allocator() = std::move(_M_get_Tp_allocator());
-		__throw_exception_again;
-	  }
-	  }
+	  this->_M_impl._M_swap_data(__x._M_impl);
   }
 
   _Deque_base(_Deque_base&& __x, const allocator_type& __a, size_type __n)
diff --git a/libstdc++-v3/testsuite/23_containers/deque/allocator/move-2.cc b/libstdc++-v3/testsuite/23_containers/deque/allocator/move-2.cc
new file mode 100644
index 000..3932676
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/deque/allocator/move-2.cc
@@ -0,0 +1,53 @@
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++11" }
+// { dg-do compile }
+
+#include 
+
+template
+struct Alloc
+{
+  using value_type = T;
+
+  Alloc() = default;
+
+  template
+Alloc(const Alloc&) { }
+
+  Alloc& operator=(const Alloc&) = delete;
+
+  T* allocate(std::size_t n)
+  { return std::allocator{}.allocate(n); }
+
+  void deallocate(T* p, std::size_t n)
+  { std::allocator{}.deallocate(p, n); }
+};
+
+template
+bool operator==(const Alloc&, const Alloc&) { return true; }
+
+template
+bool operator!=(const Alloc&, const Alloc&) { return false; }
+
+void
+test01()
+{
+  std::deque> d;
+  auto d2 = std::move(d);
+}

Re: [patch] Use aliases for type traits in C++14 mode.

[Jonathan Wakely]

Hmm, not sure how I managed to swap the content-type of the two parts
of that message. The body was meant to read:

On 04/11/14 02:51 +, Jonathan Wakely wrote:

For C++14-only components we can use the aliases for type traits.

Tested x86_64-linux, committed to trunk.

Re: [patch] Make std::reference_wrapper trivially copyable.

[Jonathan Wakely]

Messed up the content-types here too, the body was meant to be:

On 04/11/14 02:53 +, Jonathan Wakely wrote:

This might be required for C++17, and is beneficial anyway, so let's
change it now.

Tested x86_64-linux, committed to trunk.

Re: libstdc++ testsuite make targets check-parallel and check-performance don't work anymore

[Jonathan Wakely]

On 04/11/14 03:41 +, Jonathan Wakely wrote:

On 03/11/14 22:07 +, Jonathan Wakely wrote:

On 3 November 2014 17:51, Paolo Carlini  wrote:

.. other than the above issue, I see a segmentation fault for:

   performance/ext/pb_ds/multimap_text_insert_mem_large.cc


Fixed like so.


commit 75a3f132da320a76baf7e82f4f850cdfce239a2e
Author: Jonathan Wakely 
Date:   Tue Nov 4 04:33:32 2014 +

	* testsuite/util/testsuite_allocator.h (operator==): Fix recursion.

diff --git a/libstdc++-v3/testsuite/util/testsuite_allocator.h b/libstdc++-v3/testsuite/util/testsuite_allocator.h
index 8edc0a5..dec8d1a 100644
--- a/libstdc++-v3/testsuite/util/testsuite_allocator.h
+++ b/libstdc++-v3/testsuite/util/testsuite_allocator.h
@@ -209,7 +209,7 @@ namespace __gnu_test
 {
   const Alloc1& alloc1 = lhs;
   const Alloc2& alloc2 = rhs;
-  return lhs == rhs;
+  return alloc1 == alloc2;
 }
 
   template