Re: [PATCH] Enable -fsanitize-recover for KASan

[Dmitry Vyukov]

On Fri, Sep 5, 2014 at 10:54 AM, Yury Gribov  wrote:
> Hi all,
>
> This patch enables -fsanitize-recover for KASan by default. This causes
> KASan to continue execution after error in case of inline instrumentation.
> This feature is needed because
> - reports during early bootstrap won't even be printed
> - needed to run all tests w/o rebooting machine for every test
> - needed for interactive work on desktop
>
> Bootstrapped and regtested on x64.
>
> Ok to commit?


Can we do it w/o doubling number of runtime entry points?
Looks like a wrong way to pass global options to runtime. If we need
to pass several other options, number of entry points will sky rocket.
I vaguely remember there are some globals that compiler uses to
communicate configuration (version, shadow base) to runtime. Can we
use them to enable recover mode in runtime?

Re: [Patch ARM] Fix PR target/56846

[Andrew Haley]

On 25/08/14 11:32, Tony Wang wrote:
> Hi all,
> 
> The bug is reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846, 
> and it’s about the problem that
> when exception handler is involved in the function, then _Unwind_Backtrace 
> function will run into deadloop on
> arm target. 
> 
> Cmd line: arm-none-eabi-g++ -mthumb -mcpu=cortex-m3 -O0 -g -std=c++11 
> -specs=rdimon.specs main.c -o main.exe
> #include 
> #include 
> _Unwind_Reason_Code trace_func(struct _Unwind_Context * context, void* arg)
> {
>   void *ip = (void *)_Unwind_GetIP(context);
>   printf("Address: %p\n", ip);
>   return _URC_NO_REASON;
> }
> void bar()
> {
>   puts("This is in bar");
>   _Unwind_Backtrace((_Unwind_Trace_Fn)&trace_func, 0);
> }
> void foo()
> {
>   try
>   {
> bar();
>   }
>   catch (...)
>   {
> puts("Exception");
>   }
> }
> 
> The potential of such a bug is discussed long time ago in mail:
> https://gcc.gnu.org/ml/gcc/2007-08/msg00235.html. Basically, as the ARM EHABI 
> does not define how to implement
> the Unwind_Backtrace, Andrew give control to the personality routine to 
> unwind the stack, and use the unwind
> state combination of “_US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND” to 
> represent that the caller is asking the
> personality routine to only unwind the stack for it. 
> 
> However, the pr in the libstdc++-v3 doesn’t handle such a unwind state 
> pattern correctly. When the backtrace
> function passes such a pattern to it, it will still return _URC_HANDLER_FOUND 
> to the caller in some cases.
> It’s because the pr will think that the _Unwind_Backtrace is raising a none 
> type exception to it, so if the
> exception handler in current stack frame can catch anything(like catch(…)), 
> the pr will return
> _URC_HANDLER_FOUND to the caller and ask for next step. But definitely, the 
> unwind backtrace function don’t
> know what to do when pr return an exception handler to it.
> 
> So this patch just evaluate such a unwind state pattern at the beginning of 
> the personality routine in
> libstdc++-v3, if we meet with “_US_VIRTUAL_UNWIND_FRAME | _US_FORCE_UNWIND”, 
> then we directly call macro
> CONTINUE_UNWINDING to unwind the stack and return.
> 
> Is this a reasonable fix?
> 
> gcc/libstdc++-v3/ChangeLog:
> 2014-8-25   Tony Wang 
> 
>  PR target/56846
>  * libsupc++/eh_personality.cc: Return with CONTINUE_UNWINDING
>  when meet with the unwind state pattern: 
> _US_VIRTUAL_UNWIND_FRAME |
>  _US_FORCE_UNWIND

That looks very sensible, but it's not my call to approve it.

Andrew.

Re: [Patch AArch64] Add support for crtfastmath.c

[Ramana Radhakrishnan]

On 04/09/14 18:12, Richard Henderson wrote:

On 09/04/2014 07:04 AM, Ramana Radhakrishnan wrote:

gcc/Changelog

2014-09-04  Marcus Shawcroft  
 Ramana Radhakrishnan  

* config/aarch64/aarch64-elf-raw.h (ENDFILE_SPEC): Add 
crtfastmath.o.
* config/aarch64/aarch64-linux.h
(GNU_USER_TARGET_MATH_ENDFILE_SPEC): Define.
  (ENDFILE_SPEC): Define and use GNU_USER_TARGET_MATH_ENDFILE_SPEC.

libgcc/Changelog

2014-09-04  Marcus Shawcroft  
 Ramana Radhakrishnan  

* config.host (aarch64*): Include crtfastmath and t-crtfm.
* config/aarch64/crtfastmath.c: New file.


ENOPATCH.


r~




Bah - ofcourse.

Here it is attached.

Ramana
diff --git a/gcc/config/aarch64/aarch64-elf-raw.h 
b/gcc/config/aarch64/aarch64-elf-raw.h
index adec7e7..b9d4e8d 100644
--- a/gcc/config/aarch64/aarch64-elf-raw.h
+++ b/gcc/config/aarch64/aarch64-elf-raw.h
@@ -23,7 +23,9 @@
 #define GCC_AARCH64_ELF_RAW_H
 
 #define STARTFILE_SPEC " crti%O%s crtbegin%O%s crt0%O%s"
-#define ENDFILE_SPEC " crtend%O%s crtn%O%s"
+#define ENDFILE_SPEC \
+  " crtend%O%s crtn%O%s " \
+  "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}"
 
 #ifndef LINK_SPEC
 #define LINK_SPEC "%{mbig-endian:-EB} %{mlittle-endian:-EL} -X \
diff --git a/gcc/config/aarch64/aarch64-linux.h 
b/gcc/config/aarch64/aarch64-linux.h
index 8d20310..1731432 100644
--- a/gcc/config/aarch64/aarch64-linux.h
+++ b/gcc/config/aarch64/aarch64-linux.h
@@ -37,6 +37,14 @@
 
 #define LINK_SPEC LINUX_TARGET_LINK_SPEC
 
+#define GNU_USER_TARGET_MATHFILE_SPEC \
+  "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s}"
+
+#undef ENDFILE_SPEC
+#define ENDFILE_SPEC   \
+  GNU_USER_TARGET_MATHFILE_SPEC " " \
+  GNU_USER_TARGET_ENDFILE_SPEC
+
 #define TARGET_OS_CPP_BUILTINS()   \
   do   \
 {  \
diff --git a/libgcc/config.host b/libgcc/config.host
index 0550c34..2ea8f20 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -322,13 +322,15 @@ esac
 case ${host} in
 aarch64*-*-elf)
extra_parts="$extra_parts crtbegin.o crtend.o crti.o crtn.o"
+   extra_parts="$extra_parts crtfastmath.o"
tmake_file="${tmake_file} ${cpu_type}/t-aarch64"
-   tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp"
+   tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp t-crtfm"
;;
 aarch64*-*-linux*)
+   extra_parts="$extra_parts crtfastmath.o"
md_unwind_header=aarch64/linux-unwind.h
tmake_file="${tmake_file} ${cpu_type}/t-aarch64"
-   tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp"
+   tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp t-crtfm"
;;
 alpha*-*-linux*)
tmake_file="${tmake_file} alpha/t-alpha alpha/t-ieee t-crtfm 
alpha/t-linux"
diff --git a/libgcc/config/aarch64/crtfastmath.c 
b/libgcc/config/aarch64/crtfastmath.c
new file mode 100644
index 000..3a8ddfc
--- /dev/null
+++ b/libgcc/config/aarch64/crtfastmath.c
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) 2014 Free Software Foundation, Inc.
+ *
+ * This file 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 file 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.
+ *
+ * Under Section 7 of GPL version 3, you are granted additional
+ * permissions described in the GCC Runtime Library Exception, version
+ * 3.1, as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License and
+ * a copy of the GCC Runtime Library Exception along with this program;
+ * see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+ * .
+ */
+
+#define _FPU_FPCR_FZ 0x100
+
+#define _FPU_SETCW(fpcr)  \
+  {   \
+__asm__ __volatile__ ("msr fpcr, %0" : : "r" (fpcr)); \
+  }
+
+static void __attribute__((constructor))
+set_fast_math (void)
+{
+  /* Flush to zero, round to nearest, IEEE exceptions disabled.  */
+  _FPU_SETCW (_FPU_FPCR_FZ);
+}

Re: [PATCH] Enable -fsanitize-recover for KASan

[Yury Gribov]

On 09/05/2014 11:32 AM, Dmitry Vyukov wrote:

Can we do it w/o doubling number of runtime entry points?


I didn't find a good way to achieve this. See, normal asan reporting 
functions

have a noreturn attribute (defined in sanitizer.def) which can't be changed
depending on cmdline flag.


Looks like a wrong way to pass global options to runtime.
If we need
to pass several other options, number of entry points will sky rocket.


We only need new definitions if functions look significantly different 
for compiler

(noreturn, etc.).


I vaguely remember there are some globals that compiler uses to
communicate configuration (version, shadow base) to runtime.


This would make the recovery setting global then.
It may be desirable to have per-object (or even per-function) options 
(or maybe not).


-Y

Re: [PATCH] Fix PR63148 - two choices

[Richard Biener]

On Thu, 4 Sep 2014, Jeff Law wrote:

> On 09/04/14 06:11, Richard Biener wrote:
> > 
> > The following two patches each fix PR63148, a wrong-code issue
> > caused by bogus array indices a-la
> > &global_data.b[(sizetype) i + 536870911] which have a correct
> > address when lowered but bogus index.
> > 
> > The case in question can be mitigated by disabling folding of
> > (sizetype) i * 8 + 4294967288 to ((sizetype) i + 536870911) * 8
> > but that makes the real error - the existence of
> > try_move_mult_to_index - just harder to trigger (I have already
> > removed all similar code over the years).
> > 
> > So the second variant is removing try_move_mult_to_index.
> > 
> > The wrong-code is a regression from 4.7 which means a fix
> > for the branches would be nice as well.
> > 
> > Removing try_move_mult_to_index makes us correctly detect
> > the dependence and not vectorize the testcase while only
> > doing the mitigation makes dependence analysis fail and
> > we create a runtime alias check (which would be a regression
> > as well here - 4.7 also didn't vectorize this by detecting
> > the dependence).
> > 
> > I'm not sure which patch has the least side-effects on the
> > branches.
> > 
> > Sofar I have only fully tested removing try_move_mult_to_index
> > on trunk which has some fallout that I have fixed and some
> > fallout that should be addressed as followup.  The patch
> > contains three new testcases from PR19807 we didn't add
> > and for which we regressed two with 4.8 already (-2 and -3)
> > and they still fail after the patch.
> > 
> > Patch 2 is bootstrapped and tested on x86_64-unknown-linux-gnu,
> > patch 1 is in testing.

I have now tested patch 1 dumbing down fold_plusminus_mult_expr
and it passes bootstrap and testing without further fallout.
So even as it isn't a real fix for the issue I suspect it may
have less side-effects than the other patch ripping out
try_move_mult_to_index completely.

So I am considering patch 1 for the branches (but I'm yet
unsure about it).  Having to maintain two different states
of the fix also doesn't sound too great.

> > I have a strong preference to have patch 2 on trunk.
> > 
> > Any preferences for the branches?
> > 
> > Thanks,
> > Richard.
> > 
> > 
> > 2014-09-04  Richard Biener  
> > 
> > PR middle-end/63148
> > * fold-const.c (fold_plusminus_mult_expr): Avoid case
> > producing invalid array indexes when the multiplication
> > is stripped.
> > 
> > * gcc.dg/vect/pr63148.c: New testcase.
> Given the pain we've had through the years with these kinds of out-of-bounds
> indices which are compensated for elsewhere in the address computation, I'm
> all for making them go away.
> 
> As two examples of where this matters, the PA port does its segment selection
> on just the base register, not the entire effective address. Thus when we muck
> around with indices like this, the base register has the compensation code and
> thus may result in selecting a different segment than would be the case if we
> looked at the entire effective address.
> 
> One of the mn103 parts has a similar problem, but it was actually a processor
> bug -- it was supposed to work correctly and select from the entire effective
> address, but it was broken in the hardware and we've had the "joys" of working
> around that errata in the compiler.
> 
> The argument for keeping this kind of braindamage has that it's allowed for
> more efficient code for things like virtual origin array addressing in Ada.
> But it's been nothing but pain.

Ok, so for now I am going to apply the removal of try_move_mult_to_index
to trunk and see whether anything bad falls out of that.

Richard.

[AArch64 Obvious] Add a mode to operand 1 of sibcall_value_insn

[James Greenhalgh]

Hi,

AArch64 builds have recently been spitting out:

  .../gcc/config/aarch64/aarch64.md:629: warning: operand 1 missing mode?

I've committed the attached patch as obvious, giving operand 1 DImode.

The patch was tested on AArch64 cross with no problems.

Thanks,
James

---
2014-09-05  James Greenhalgh  

* config/aarch64/aarch64.md (sibcall_value_insn): Give operand 1
DImode.
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 3c51fd367e954d513aac1180ec4025f15d46c87e..cb548460430f36a8e7701296f7bbd976952b9a86 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -628,7 +628,8 @@ (define_insn "*sibcall_insn"
 
 (define_insn "*sibcall_value_insn"
   [(set (match_operand 0 "" "")
-	(call (mem:DI (match_operand 1 "aarch64_call_insn_operand" "Ucs, Usf"))
+	(call (mem:DI
+		(match_operand:DI 1 "aarch64_call_insn_operand" "Ucs, Usf"))
 	  (match_operand 2 "" "")))
(return)
(use (match_operand 3 "" ""))]

Re: [PATCH] Enable -fsanitize-recover for KASan

[Dmitry Vyukov]

On Fri, Sep 5, 2014 at 12:12 PM, Yury Gribov  wrote:
> On 09/05/2014 11:32 AM, Dmitry Vyukov wrote:
>>
>> Can we do it w/o doubling number of runtime entry points?
>
>
> I didn't find a good way to achieve this. See, normal asan reporting
> functions
> have a noreturn attribute (defined in sanitizer.def) which can't be changed
> depending on cmdline flag.


I have not looked at the code in detail. But it looks weird to me that
in a general-purpose programming language we can't alter an attribute
of an in-memory object. I would expect that the attribute is just a
field in a struct describing the functionm and the field can be freely
set/reset. Is not it the case?



>> Looks like a wrong way to pass global options to runtime.
>> If we need
>> to pass several other options, number of entry points will sky rocket.
>
>
> We only need new definitions if functions look significantly different for
> compiler
> (noreturn, etc.).
>
>> I vaguely remember there are some globals that compiler uses to
>> communicate configuration (version, shadow base) to runtime.
>
>
> This would make the recovery setting global then.
> It may be desirable to have per-object (or even per-function) options (or
> maybe not).


This makes sense.
Leaving for others to chime in.

Re: [AArch64 Obvious] Add a mode to operand 1 of sibcall_value_insn

[Kyrill Tkachov]

On 05/09/14 09:20, James Greenhalgh wrote:

Hi,

AArch64 builds have recently been spitting out:

   .../gcc/config/aarch64/aarch64.md:629: warning: operand 1 missing mode?

I've committed the attached patch as obvious, giving operand 1 DImode.


I remember noticing that some time ago, thanks for fixing this up.
I wonder if there could be a new starter task in adding -Werror - style 
functionality to the gen*
programs so that during bootstrap they could produce a hard error, 
getting us to fix the warnings

in the MD files.

Kyrill



The patch was tested on AArch64 cross with no problems.

Thanks,
James

---
2014-09-05  James Greenhalgh  

* config/aarch64/aarch64.md (sibcall_value_insn): Give operand 1
DImode.

Re: [PATCH] Enable -fsanitize-recover for KASan

[Yury Gribov]

On 09/05/2014 12:23 PM, Dmitry Vyukov wrote:

I didn't find a good way to achieve this. See, normal asan reporting
functions
have a noreturn attribute (defined in sanitizer.def) which can't be changed
depending on cmdline flag.

I have not looked at the code in detail. But it looks weird to me that
in a general-purpose programming language we can't alter an attribute
of an in-memory object.


Well, builtins are described by metadata in .def files
(those are not written in general purpose language).
Post-hacking generated trees sounds ugly...

-Y

Re: [debug-early] reuse variable DIEs and fix their context

[Richard Biener]

On Fri, Sep 5, 2014 at 4:38 AM, Aldy Hernandez  wrote:
> On 09/04/14 03:42, Richard Biener wrote:
>>
>> On Wed, Sep 3, 2014 at 7:54 PM, Aldy Hernandez  wrote:
>
>
>> Flow-wise I still want to move hand-off to the cgraph code to toplev.c,
>> out from the FEs final_write_gloabals hook:
>>
>>/* This must also call finalize_compilation_unit.  */
>>lang_hooks.decls.final_write_globals ();
>>
>> that would make clearer how control flows.
>
>
> Neat.  I like it.
>
>> I'd also rather split the hook into two ... (and call the 2nd non-early
>> phase hook from where we output the code).  What does that phase
>> output for global decls anyway?
>
>
> This is also a very good idea, and it makes the intent clearer.
>
>> Otherwise looks like a good incremental improvement to me.
>
>
> Since we're pretty much on the same page, I've committed this revision you
> just looked at, so we can talk about the changes you mention above
> separately, namely:
>
> a) Divorcing final_write_globals and finalize_compilation.
> b) Splitting the global_decl hook into two.
>
> So this is what I have in mind (patch attached).  I'd like to split
> LANG_HOOKS_WRITE_GLOBALS in favor of LANG_HOOKS_{EARLY,LATE}_WRITE_GLOBALS,
> as well as splitting the global_decl debug hook into
> {early,late}_global_decl.  I've commented things throughout to make it very
> clear what we're getting at.

I meant that LATE_WRITE_GLOBALS shouldn't be a langhook
at all but instead the middle-end should be in control of that and
implement it in a language independent way.  After all this will be
called from LTO LTRANS phase.

> I chose to dispense with the old names to make it very clear what the hook
> should do, and to make sure I didn't miss any places.
>
> Toplev will now look much cleaner:
>
> +  /* Emit early debugging information as well as globals.  */
> +  timevar_start (TV_PHASE_DEFERRED);
> +  lang_hooks.decls.early_write_globals ();
> +  timevar_stop (TV_PHASE_DEFERRED);
> +
> +  /* We're done parsing; proceed to optimize and emit assembly.  */
> +  timevar_start (TV_PHASE_OPT_GEN);
> +  symtab->finalize_compilation_unit ();
> +  timevar_stop (TV_PHASE_OPT_GEN);
> +
> +  /* Amend any debugging information generated previously.  */
> +  timevar_start (TV_PHASE_DBGINFO);
> +  lang_hooks.decls.late_write_globals ();
> +  timevar_stop (TV_PHASE_DBGINFO);
>
> Prety... if I do say so myself.

Yeah - apart from that langhook issue for late_write_globals ;)

> The attached patch is untested, and will fail miserably on anything but C
> (lto, c++, etc).  But it shows how I'd like to approach this.
>
> Would you bless this approach, so I can continue with the other languages
> and LTO?

Be prepared to meet some fun with Java and moving finalize_compilation_unit
out (I remember trying that at some point).

Otherwise it would be nice if you can implement late_write_globals by
simply walking the symbol table with sth like

  FOR_EACH_DEFINED_SYMBOL (node)
 debug_hooks->late_global_decl (node->decl);

well - of course it will likely not be _that_ simple.  And eventually it's
better to do this from where we have done the output (in varasm.c
for variables and somewhere in final.c for functions), but let's try
that FOR_EACH as it looks so simple ;)

Richard.

> As usual, thanks for your feedback.
> Aldy

[PATCH][ARM/AArch64] Schedule alu_ext for Cortex-A53

[Kyrill Tkachov]

Hi all,

We didn't schedule alu_ext and alus_ext anywhere for Cortex-A53 so this 
patch handles it.

Tested arm-none-eabi and aarch64-none-elf.
Ok for trunk?

Thanks,
Kyrill

2014-09-05  Kyrylo Tkachov  

* config/arm/cortex-a53.md (cortex_a53_alu_shift): Add alu_ext,
alus_ext.commit bcf2870adc2602ff6961c25e31a8855af25fc767
Author: Kyrylo Tkachov 
Date:   Wed Sep 3 16:52:40 2014 +0100

[AArch64] Add Cortex-A53 scheduling for alu_ext,alus_ext ops

diff --git a/gcc/config/arm/cortex-a53.md b/gcc/config/arm/cortex-a53.md
index e798dde..c12738c 100644
--- a/gcc/config/arm/cortex-a53.md
+++ b/gcc/config/arm/cortex-a53.md
@@ -85,7 +85,7 @@ (define_insn_reservation "cortex_a53_alu_shift" 2
   (and (eq_attr "tune" "cortexa53")
(eq_attr "type" "alu_shift_imm,alus_shift_imm,\
 crc,logic_shift_imm,logics_shift_imm,\
-alu_shift_reg,alus_shift_reg,\
+alu_ext,alus_ext,alu_shift_reg,alus_shift_reg,\
 logic_shift_reg,logics_shift_reg,\
 extend,mov_shift,mov_shift_reg,\
 mvn_shift,mvn_shift_reg"))

Re: [PATCH] Enable -fsanitize-recover for KASan

[Andrey Ryabinin]

On 09/05/2014 10:54 AM, Yury Gribov wrote:
> Hi all,
> 
> This patch enables -fsanitize-recover for KASan by default. This causes KASan 
> to continue execution after error in case of inline instrumentation. This 
> feature is needed because
> - reports during early bootstrap won't even be printed
> - needed to run all tests w/o rebooting machine for every test
> - needed for interactive work on desktop
> 


I just add that this option is required for inline instrumentation in kernel.
There is some places in kernel where we validly touch poisoned memory
and we need to disable error reporting in runtime. For that we use per task 
variable and check it
__asan_report function and don't print anything if flag is raised.
So there is must be the way to return from report functions.

And how does it work if someone wants to try -fsanitize=address 
-fsanitize-recover.
Seems you didn't touch libsanitzer in this patch, so I guess this will cause 
link time error, right ?

> Bootstrapped and regtested on x64.
> 
> Ok to commit?
> 
> -Y

[PATCH][AArch64] PR 61749: Do not ICE in lane intrinsics when passed non-constant lane number

[Kyrill Tkachov]

Hi all,

As the PR says we currently ICE in aarch64_simd_lane_bounds when processing

#include "arm_neon.h"

int32x4_t foo (int32x4_t a, int16x4_t b, int16x4_t c, int d)
{
  return vqdmlal_lane_s16 (a, b, c, d);
}

This code is invalid since the lane argument (d) should be a 
compile-time constant. This can be fixed by setting the qualifier for 
the 4th argument for these intrinsics to qualifier_immediate so that the 
expansion code in aarch64-builtins.c can detect that and emit the 
appropriate message.


This, however, is not enough by itself. We will emit the error but then 
proceed anyway and ICE. From looking around other backends (and rs6000 
in particular), the correct thing to do in these cases is to return 
const0_rtx to signify that a user input error occured. This patch does 
that and also makes sure we hit gcc_unreachable () instead of returning 
NULL_RTX when the requested builtin to expand cannot be found. This is 
the correct thing to do because returning NULL_RTX is apparently just 
the way to show that the builtin does not return a result (e.g. for void 
builtins).


Before this patch on the above code we would get:

$BUILD/install/lib/gcc/aarch64-none-elf/4.10.0/include/arm_neon.h: In 
function 'foo':
$BUILD/install/lib/gcc/aarch64-none-elf/4.10.0/include/arm_neon.h:19294:10: 
internal compiler error: in aarch64_simd_lane_bounds, at 
config/aarch64/aarch64.c:7715

   return __builtin_aarch64_sqdmlal_lanev4hi (__a, __b, __c, __d);
  ^
0xc608d0 aarch64_simd_lane_bounds(rtx_def*, long, long)
$SRC/gcc/config/aarch64/aarch64.c:7715
0xcb0221 gen_aarch64_sqdmlal_lanev4hi(rtx_def*, rtx_def*, rtx_def*, 
rtx_def*, rtx_def*)

$SRC/gcc/config/aarch64/aarch64-simd.md:3015
0xc65b7f insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*, 
rtx_def*) const

$SRC/src/gcc/gcc/recog.h:311
0xc65b7f aarch64_simd_expand_args
$SRC/gcc/config/aarch64/aarch64-builtins.c:888
0xc66318 aarch64_simd_expand_builtin(int, tree_node*, rtx_def*)
$SRC/gcc/config/aarch64/aarch64-builtins.c:990
0xc66968 aarch64_expand_builtin(tree_node*, rtx_def*, rtx_def*, 
machine_mode, int)

etc...


Now we get the more helpful:
build-aarch64/install/lib/gcc/aarch64-none-elf/4.10.0/include/arm_neon.h:19371:10: 
error: incompatible type for argument 4, expected 'const int'

   return __builtin_aarch64_sqdmlal_lanev4hi (__a, __b, __c, __d);

As for the testcase, we want to check that we give an error but do not 
ICE. The dg-excess-errors directive is the closest I've found to that.
The test appears as an expected fail. If, however, we were to ICE it 
would appear as an unexpected failure, which is what we would want.


Tested on aarch64-none-elf and bootstrapped on aarch64-linux.

Ok for trunk?

2014-09-05  Kyrylo Tkachov  

PR target/61749
* config/aarch64/aarch64-builtins.c (aarch64_types_quadop_qualifiers):
Use qualifier_immediate for last operand.  Rename to...
(aarch64_types_ternop_lane_qualifiers): ... This.
(TYPES_QUADOP): Rename to...
(TYPES_TERNOP_LANE): ... This.
(aarch64_simd_expand_args): Return const0_rtx when encountering user
error.  Change return of 0 to return of NULL_RTX.
(aarch64_crc32_expand_builtin): Likewise.
(aarch64_expand_builtin): Return NULL_RTX instead of 0.
ICE when expanding unknown builtin.
* config/aarch64/aarch64-simd-builtins.def (sqdmlal_lane): Use
TERNOP_LANE qualifiers.
(sqdmlsl_lane): Likewise.
(sqdmlal_laneq): Likewise.
(sqdmlsl_laneq): Likewise.
(sqdmlal2_lane): Likewise.
(sqdmlsl2_lane): Likewise.
(sqdmlal2_laneq): Likewise.
(sqdmlsl2_laneq): Likewise.

2014-09-05  Kyrylo Tkachov  

PR target/61749
* gcc.target/aarch64/vqdml_lane_intrinsics-bad_1.c: New test.commit 796f7ec499411034d5eb7441b51d0493d6299327
Author: Kyrylo Tkachov 
Date:   Wed Aug 6 16:47:29 2014 +0100

[AArch64] PR target/61749 Fix ICE when passing non-literal lane to some intrinsics

diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index ba58a99..16c9329 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -178,10 +178,10 @@ aarch64_types_ternopu_qualifiers[SIMD_MAX_BUILTIN_ARGS]
 #define TYPES_TERNOPU (aarch64_types_ternopu_qualifiers)
 
 static enum aarch64_type_qualifiers
-aarch64_types_quadop_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+aarch64_types_ternop_lane_qualifiers[SIMD_MAX_BUILTIN_ARGS]
   = { qualifier_none, qualifier_none, qualifier_none,
-  qualifier_none, qualifier_none };
-#define TYPES_QUADOP (aarch64_types_quadop_qualifiers)
+  qualifier_none, qualifier_immediate };
+#define TYPES_TERNOP_LANE (aarch64_types_ternop_lane_qualifiers)
 
 static enum aarch64_type_qualifiers
 aarch64_types_getlane_qualifiers[SIMD_MAX_BUILTIN_ARGS]
@@ -907,8 +907,11 @@ aarch64_simd_expand_args (rtx target, int icode, int have_retval,
 	case SIMD_ARG_CONSTANT:
 	  if (!(*insn_data[icode].operand[argc + have_retval].predicate)
 		  (op[arg

Re: [PATCH] Enable -fsanitize-recover for KASan

[Yury Gribov]

On 09/05/2014 12:59 PM, Andrey Ryabinin wrote:
And how does it work if someone wants to try -fsanitize=address 

-fsanitize-recover.

Seems you didn't touch libsanitzer in this patch,
so I guess this will cause link time error, right ?


Exactly, Asan team does not want recovery mode for userspace Asan.
BTW it may make sense to emit a friendly error message instead
of those link errors.

-Y

[PATCH][1/2] Abstract away marking loops for removal

[Richard Biener]

This patch does just $subject, leaving the sanity checking
under ENABLE_CHECKING for 2/2.

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

Richard.

2014-09-05  Richard Biener  

* cfgloop.c (mark_loop_for_removal): New function.
* cfgloop.h (mark_loop_for_removal): Declare.
* cfghooks.c (delete_basic_block): Use mark_loop_for_removal.
(merge_blocks): Likewise.
(duplicate_block): Likewise.
* except.c (sjlj_emit_dispatch_table): Likewise.
* tree-eh.c (cleanup_empty_eh_merge_phis): Likewise.
* tree-ssa-threadupdate.c (ssa_redirect_edges): Likewise.
(thread_through_loop_header): Likewise.

Index: trunk/gcc/cfghooks.c
===
*** trunk.orig/gcc/cfghooks.c   2014-09-05 10:13:28.713737197 +0200
--- trunk/gcc/cfghooks.c2014-09-05 10:14:27.537733147 +0200
*** delete_basic_block (basic_block bb)
*** 569,582 
struct loop *loop = bb->loop_father;
  
/* If we remove the header or the latch of a loop, mark the loop for
!removal by setting its header and latch to NULL.  */
if (loop->latch == bb
  || loop->header == bb)
!   {
! loop->header = NULL;
! loop->latch = NULL;
! loops_state_set (LOOPS_NEED_FIXUP);
!   }
  
remove_bb_from_loops (bb);
  }
--- 569,578 
struct loop *loop = bb->loop_father;
  
/* If we remove the header or the latch of a loop, mark the loop for
!removal.  */
if (loop->latch == bb
  || loop->header == bb)
!   mark_loop_for_removal (loop);
  
remove_bb_from_loops (bb);
  }
*** merge_blocks (basic_block a, basic_block
*** 760,770 
  /* ... we merge two loop headers, in which case we kill
 the inner loop.  */
  if (b->loop_father->header == b)
!   {
! b->loop_father->header = NULL;
! b->loop_father->latch = NULL;
! loops_state_set (LOOPS_NEED_FIXUP);
!   }
}
/* If we merge a loop header into its predecessor, update the loop
 structure.  */
--- 756,762 
  /* ... we merge two loop headers, in which case we kill
 the inner loop.  */
  if (b->loop_father->header == b)
!   mark_loop_for_removal (b->loop_father);
}
/* If we merge a loop header into its predecessor, update the loop
 structure.  */
*** duplicate_block (basic_block bb, edge e,
*** 1099,1107 
  && cloop->header == bb)
{
  add_bb_to_loop (new_bb, loop_outer (cloop));
! cloop->header = NULL;
! cloop->latch = NULL;
! loops_state_set (LOOPS_NEED_FIXUP);
}
else
{
--- 1091,1097 
  && cloop->header == bb)
{
  add_bb_to_loop (new_bb, loop_outer (cloop));
! mark_loop_for_removal (cloop);
}
else
{
Index: trunk/gcc/cfgloop.c
===
*** trunk.orig/gcc/cfgloop.c2014-09-05 10:13:28.713737197 +0200
--- trunk/gcc/cfgloop.c 2014-09-05 10:14:35.787732579 +0200
*** bb_loop_depth (const_basic_block bb)
*** 1931,1933 
--- 1931,1943 
  {
return bb->loop_father ? loop_depth (bb->loop_father) : 0;
  }
+ 
+ /* Marks LOOP for removal and sets LOOPS_NEED_FIXUP.  */
+ 
+ void
+ mark_loop_for_removal (loop_p loop)
+ {
+   loop->header = NULL;
+   loop->latch = NULL;
+   loops_state_set (LOOPS_NEED_FIXUP);
+ }
Index: trunk/gcc/cfgloop.h
===
*** trunk.orig/gcc/cfgloop.h2014-09-05 10:13:28.713737197 +0200
--- trunk/gcc/cfgloop.h 2014-09-05 10:14:27.537733147 +0200
*** struct loop * loop_version (struct loop
*** 336,341 
--- 336,343 
  extern bool remove_path (edge);
  extern void unloop (struct loop *, bool *, bitmap);
  extern void scale_loop_frequencies (struct loop *, int, int);
+ void mark_loop_for_removal (loop_p);
+ 
  
  /* Induction variable analysis.  */
  
Index: trunk/gcc/except.c
===
*** trunk.orig/gcc/except.c 2014-09-05 10:13:28.713737197 +0200
--- trunk/gcc/except.c  2014-09-05 10:14:27.538733147 +0200
*** sjlj_emit_dispatch_table (rtx_code_label
*** 1375,1384 
  {
for (loop = bb->loop_father;
 loop_outer (loop); loop = loop_outer (loop))
! {
!   loop->header = NULL;
!   loop->latch = NULL;
! }
  }
  }
  
--- 1375,1381 
  {
for (loop = bb->loop_father;
 loop_outer (loop); loop = loop_outer (loop))
! mark_loop_for_removal (loop);
  }
  }
  
Index: trunk/gcc

Re: [PATCH] Enable -fsanitize-recover for KASan

[Jakub Jelinek]

On Fri, Sep 05, 2014 at 12:33:54PM +0400, Yury Gribov wrote:
> On 09/05/2014 12:23 PM, Dmitry Vyukov wrote:
> >>I didn't find a good way to achieve this. See, normal asan reporting
> >>functions
> >>have a noreturn attribute (defined in sanitizer.def) which can't be changed
> >>depending on cmdline flag.
> >I have not looked at the code in detail. But it looks weird to me that
> >in a general-purpose programming language we can't alter an attribute
> >of an in-memory object.
> 
> Well, builtins are described by metadata in .def files
> (those are not written in general purpose language).
> Post-hacking generated trees sounds ugly...

Note, in ubsan you also have __ubsan_something and __ubsan_something_abort
entrypoints, the latter is noreturn and terminates program, the former
is not and is used for -fsanitize-recover.

Though, for that option the default is yes for ubsan purposes, while asan
wants a default to no, so it is unclear how to solve that.  Either different
option for asan recovery, or tristate option etc.

Jakub

Re: [PATCH] Enable -fsanitize-recover for KASan

[Yury Gribov]

On 09/05/2014 01:28 PM, Jakub Jelinek wrote:

Though, for that option the default is yes for ubsan purposes, while asan
wants a default to no, so it is unclear how to solve that.  Either different
option for asan recovery, or tristate option etc.


Currently I force set it on encountering -fsanitize=... (true for UBSan 
and KASan, false otherwise).

Can do tristate as well.

-Y

Re: [PATCH, Cilk+] CIlk_for enabling in the compiler

[Thomas Schwinge]

Hi!

On Fri, 29 Aug 2014 14:36:17 +, "Zamyatin, Igor"  
wrote:
> The patch is another attempt to enable Cilk_for (see eg 
> https://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm)
>  in the GCC compiler.
> 
> Bootstrapped and regtested on x86_64.
> Is it ok for the trunk?

(Committed as r214818.)

One question:

> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -7056,6 +7058,7 @@ gimplify_omp_for (tree *expr_p, gimple_seq *pre_p)
>  case OMP_FOR: kind = GF_OMP_FOR_KIND_FOR; break;
>  case OMP_SIMD: kind = GF_OMP_FOR_KIND_SIMD; break;
>  case CILK_SIMD: kind = GF_OMP_FOR_KIND_CILKSIMD; break;
> +case CILK_FOR: kind = GF_OMP_FOR_KIND_CILKFOR; break;
>  case OMP_DISTRIBUTE: kind = GF_OMP_FOR_KIND_DISTRIBUTE; break;
>  default:
>gcc_unreachable ();
> @@ -8128,6 +8131,7 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p, 
> gimple_seq *post_p,
>   case OMP_FOR:
>   case OMP_SIMD:
>   case CILK_SIMD:
> + case CILK_FOR:
>   case OMP_DISTRIBUTE:
> ret = gimplify_omp_for (expr_p, pre_p);
> break;

> --- a/gcc/tree.def
> +++ b/gcc/tree.def
> @@ -1064,6 +1064,10 @@ DEFTREECODE (OMP_SIMD, "omp_simd", tcc_statement, 6)
> Operands like for OMP_FOR.  */
> DEFTREECODE (CILK_SIMD, "cilk_simd", tcc_statement, 6)
> 
> +/* Cilk Plus - _Cilk_for (..)
> +   Operands like for OMP_FOR.  */
> +DEFTREECODE (CILK_FOR, "cilk_for", tcc_statement, 6)
> +
> /* OpenMP - #pragma omp distribute [clause1 ... clauseN]
> Operands like for OMP_FOR.  */
> DEFTREECODE (OMP_DISTRIBUTE, "omp_distribute", tcc_statement, 6)

Shouldn't CILK_FOR also be added to gcc/gimplify.c:is_gimple_stmt, next
to all the other OMP_FOR variants?

diff --git gcc/gimplify.c gcc/gimplify.c
index 2319fc3..a621824 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -4426,6 +4426,7 @@ is_gimple_stmt (tree t)
 case OMP_FOR:
 case OMP_SIMD:
 case CILK_SIMD:
+case CILK_FOR:
 case OMP_DISTRIBUTE:
 case OACC_LOOP:
 case OMP_SECTIONS:


Grüße,
 Thomas


pgpjkD_J5ZtEZ.pgp
Description: PGP signature

Re: [PATCH, Cilk+] CIlk_for enabling in the compiler

[Jakub Jelinek]

On Fri, Sep 05, 2014 at 11:41:07AM +0200, Thomas Schwinge wrote:
> Shouldn't CILK_FOR also be added to gcc/gimplify.c:is_gimple_stmt, next
> to all the other OMP_FOR variants?
> 
> diff --git gcc/gimplify.c gcc/gimplify.c
> index 2319fc3..a621824 100644
> --- gcc/gimplify.c
> +++ gcc/gimplify.c
> @@ -4426,6 +4426,7 @@ is_gimple_stmt (tree t)
>  case OMP_FOR:
>  case OMP_SIMD:
>  case CILK_SIMD:
> +case CILK_FOR:
>  case OMP_DISTRIBUTE:
>  case OACC_LOOP:
>  case OMP_SECTIONS:

Yes, and not just that, both CILK_SIMD and CILK_FOR are missing
e.g. in cp_gimplify_expr:
case OMP_FOR:
case OMP_SIMD:
case OMP_DISTRIBUTE:
  ret = cp_gimplify_omp_for (expr_p, pre_p);
  break;
or in cp_genericize_r:
  else if (TREE_CODE (stmt) == OMP_FOR
   || TREE_CODE (stmt) == OMP_SIMD
   || TREE_CODE (stmt) == OMP_DISTRIBUTE)
genericize_omp_for_stmt (stmt_p, walk_subtrees, data);

I'd suggest to grep for -w OMP_FOR and/or -w OMP_SIMD and
see if CILK_FOR or CILK_SIMD shouldn't be supported there too.

Jakub

Re: [PATCH 2/2] Enable elimination of zext/sext

[Richard Biener]

On Fri, Sep 5, 2014 at 3:33 AM, Kugan  wrote:
>>> Here is an attempt to do the value range computation in promoted_mode's
>>> type when it is overflowing. Bootstrapped on x86-84.
>>
>> Err - I think you misunderstood this as a suggestion to do this ;)
>> value-ranges should be computed according to the type not according
>> to the (promoted) mode.  Otherwise we will miss optimization
>> opportunities.
>
> Oops, sorry, I had my doubts about making trees aware of back-end stuff.
>
> Coming back to the original problem, what would be the best approach to
> handle this. Looking at the VRP pass, it seems to me that only MULT_EXPR
> and LSHIFT_EXPR are truncating values this way. All other operation are
> setting it to type_min, type_max. Can we rely on this ?

No, that doesn't sound like a good thing to do.

> Is this error not showing up in PROMOTED_MODE <= word_mode (and
> the mode precision of register from which we SUBREG is <= word_mode
> precision) is just a coincidence. Can we rely on this?

Sounds like a coincidence to me.

> Is there anyway we can fix this?

Well - the best way would be to expose the target specifics to GIMPLE
at some point in the optimization pipeline.  My guess would be that it's
appropriate after loop optimizations (but maybe before induction variable
optimization).

That is, have a pass that applies register promotion to all SSA names
in the function, inserting appropriate truncations and extensions.  That
way you'd never see (set (subreg...) on RTL.  The VRP and DOM
passes running after that pass would then be able to aggressively
optimize redundant truncations and extensions.

Effects on debug information are to be considered.  You can change
the type of SSA names in-place but you don't want to do that for
user DECLs (and we can't have the SSA name type and its DECL
type differ - and not sure if we might want to lift that restriction).

Richard.

> Thanks again,
> Kugan
>
>
>

[PATCH][2/2] Sanity check removed loops

[Richard Biener]

The following patch adds sanity checking for loops removed
via mark_loop_for_removal or fix_loop_structure to check
whether they reappear in the same place.

The simplest case is where the loop header stays the same
and we definitely should avoid all these cases.

The other case is where the old header becomes part of
a newly discovered loop.  That happens when you rotate
a loop for example.

The interesting bits of this are the new former_header field
in struct loop which holds onto the old header basic-block
so that even when it gets discarded its memory will not be
reused.  For the sanity checking we can then verify if
it is still a basic-block in the current function.

In theory we might be able to "autodetect" some loop
rotation cases as well as "restore" bogusly removed loops.
I'll see what the best solution is here after I (or somebody
else) has some testcases to look at.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

2014-09-05  Richard Biener  

* cfgloop.c (mark_loop_for_removal): Record former header
when ENABLE_CHECKING.
* cfgloop.h (strut loop): Add former_header member when
ENABLE_CHECKING.
* loop-init.c (fix_loop_structure): Sanity check loops
marked for removal if they re-appeared.

Index: trunk/gcc/cfgloop.c
===
*** trunk.orig/gcc/cfgloop.c2014-09-05 11:35:07.857399897 +0200
--- trunk/gcc/cfgloop.c 2014-09-05 11:47:56.118347003 +0200
*** bb_loop_depth (const_basic_block bb)
*** 1937,1943 
--- 1937,1947 
  void
  mark_loop_for_removal (loop_p loop)
  {
+ #ifdef ENABLE_CHECKING
+   loop->former_header = loop->header;
+ #endif
loop->header = NULL;
loop->latch = NULL;
loops_state_set (LOOPS_NEED_FIXUP);
  }
+ 
Index: trunk/gcc/cfgloop.h
===
*** trunk.orig/gcc/cfgloop.h2014-09-05 11:35:07.857399897 +0200
--- trunk/gcc/cfgloop.h 2014-09-05 11:47:56.118347003 +0200
*** struct GTY ((chain_next ("%h.next"))) lo
*** 193,198 
--- 193,206 
  
/* Number of iteration analysis data for RTL.  */
struct niter_desc *simple_loop_desc;
+ 
+ #ifdef ENABLE_CHECKING
+   /* For sanity checking during loop fixup we record here the former
+  loop header for loops marked for removal.  Note that this prevents
+  the basic-block from being collected but its index can still be
+  reused.  */
+   basic_block former_header;
+ #endif
  };
  
  /* Flags for state of loop structure.  */
Index: trunk/gcc/loop-init.c
===
*** trunk.orig/gcc/loop-init.c  2014-09-05 11:35:07.857399897 +0200
--- trunk/gcc/loop-init.c   2014-09-05 11:52:48.401326880 +0200
*** fix_loop_structure (bitmap changed_bbs)
*** 245,250 
--- 245,256 
}
  
/* Remove the loop.  */
+ #ifdef ENABLE_CHECKING
+   if (loop->header)
+   loop->former_header = loop->header;
+   else
+   gcc_assert (loop->former_header != NULL);
+ #endif
loop->header = NULL;
flow_loop_tree_node_remove (loop);
  }
*** fix_loop_structure (bitmap changed_bbs)
*** 272,277 
--- 278,312 
FOR_EACH_VEC_ELT (*get_loops (cfun), i, loop)
  if (loop && loop->header == NULL)
{
+ #ifdef ENABLE_CHECKING
+   if (dump_file
+   && ((unsigned) loop->former_header->index
+   < basic_block_info_for_fn (cfun)->length ()))
+ {
+   basic_block former_header
+ = BASIC_BLOCK_FOR_FN (cfun, loop->former_header->index);
+   /* If the old header still exists we want to check if the
+  original loop is re-discovered or the old header is now
+  part of a newly discovered loop.
+  In both cases we should have avoided removing the loop.  */
+   if (former_header == loop->former_header)
+ {
+   if (former_header->loop_father->header == former_header)
+ fprintf (dump_file, "fix_loop_structure: rediscovered "
+  "removed loop %d as loop %d with old header %d\n",
+  loop->num, former_header->loop_father->num,
+  former_header->index);
+   else if ((unsigned) former_header->loop_father->num
+>= old_nloops)
+ fprintf (dump_file, "fix_loop_structure: header %d of "
+  "removed loop %d is part of the newly "
+  "discovered loop %d with header %d\n",
+  former_header->index, loop->num,
+  former_header->loop_father->num,
+  former_header->loop_father->header->index);
+ }
+ }
+ #endif
(*get_loops (cfun))[i] = NULL;
flow_loop_free (loop);
}

Re: [PATCH][ARM/AArch64] Schedule alu_ext for Cortex-A53

[Ramana Radhakrishnan]

On 05/09/14 10:01, Kyrill Tkachov wrote:

Hi all,

We didn't schedule alu_ext and alus_ext anywhere for Cortex-A53 so this
patch handles it.
Tested arm-none-eabi and aarch64-none-elf.
Ok for trunk?


Ok - thanks.

Ramana


Thanks,
Kyrill

2014-09-05  Kyrylo Tkachov  

  * config/arm/cortex-a53.md (cortex_a53_alu_shift): Add alu_ext,
  alus_ext.

Re: Migrating gcc.c-torture

[Thomas Schwinge]

Hi!

On Fri, 22 Aug 2014 14:18:32 +0200, Bernd Schmidt  
wrote:
> On 07/29/2014 12:36 AM, Joseph S. Myers wrote:
> > On Thu, 24 Jul 2014, Jakub Jelinek wrote:
> >> Yeah.  I believe gcc.c-torture/compile/ has been converted already,
> >> so it is just about gcc.c-torture/execute/.

> >> So, please just tweak execute.exp, so that it does what it did until now
> >> (perhaps with the exception of *.x files support) in dg framework, and
> >> convert *.exp files into dg-* directives in the testcases.
> >
> > And note that this is bug 20567.  Existing dg-* directive uses in
> > gcc.c-torture/execute/ (which are currently ignored) may or may not be
> > correct, so they should be reviewed as part of such a migration to decide
> > whether they should stay or be removed.  (There aren't that many of them
> > to review.)

Should PR20567 now be updated?

> Here's another attempt.  [...]

> --- a/gcc/testsuite/gcc.c-torture/execute/execute.exp
> +++ b/gcc/testsuite/gcc.c-torture/execute/execute.exp
> @@ -22,28 +22,17 @@
>  # C torture test suite.

> -set-torture-options $C_TORTURE_OPTIONS {{}} $LTO_TORTURE_OPTIONS
> +# Main loop.
> +set saved-dg-do-what-default ${dg-do-what-default}
> +set dg-do-what-default "run"
> +gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cS\]]] "" "-w"
> +set dg-do-what-default ${saved-dg-do-what-default}

> -foreach src [lsort [glob -nocomplain $srcdir/$subdir/*.c]] {
> -# If we're only testing specific files and this isn't one of them, skip 
> it.
> -if ![runtest_file_p $runtests $src] then {
> - continue
> -}
> -
> -c-torture-execute $src
> -}

I noticed that this change causes that the »-Og -g« option combination
(which is part of C_TORTURE_OPTIONS) is no longer being tested with
gcc-dg-runtest.  (The same thing happend for all the tests that were
moved from gcc.c-torture/unsorted/ to gcc.c-torture/compile/.)  Would it
be desirable to restore testing of that option combination, maybe
generally for gcc-dg-runtest, or would that be overkill?


Grüße,
 Thomas


pgpKv0I9RWVwL.pgp
Description: PGP signature

Re: [PATCH][AArch64] One-liner: fix type of an add in SIMD registers

[Alan Lawrence]

Pushed r214946. (In the meantime the erroneous alu_reg had been changed to 
alu_sreg by r212750 https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00679.html .)


Marcus Shawcroft wrote:

On 20 August 2014 10:25, Alan Lawrence  wrote:

The SIMD-register variant is miscategorized as "alu_reg" despite not using
any ALU registers, and should be "neon_add" for e.g. scheduling.

Tested with check-gcc and check-g++ on aarch64-none-elf and
aarch64_be-none-elf.

gcc/ChangeLog:

* config/aarch64/aarch64.md (adddi3_aarch64): set type to neon_add.


OK and back port please.

/Marcus

Re: [patch] No allocation for empty unordered containers

[Jonathan Wakely]

On 14/08/14 21:22 +0200, François Dumont wrote:
   Then here is the patch to introduce default constructor with 
compiler computed noexcept qualification. Note that I also made 
allocator aware default constructor allocation free however noexcept 
qualification has to be manually written which I find quite a burden. 
Do you think we shall do so now ?


I don't really care about that constructor, no need to do it now.

The patch is OK to commit, thanks.

RE: [PATCH] PR fortran/62245 fix INT docs.

[VandeVondele Joost]

> >The last sentence above is not needed.

So, revised patch without the last sentence.

2014-09-05  Joost VandeVondele  

PR fortran/62245
* intrinsic.texi (INT): clarify result.

Index: fortran/intrinsic.texi
===
--- fortran/intrinsic.texi  (revision 214949)
+++ fortran/intrinsic.texi  (working copy)
@@ -7370,9 +7370,10 @@ the following rules:
 @item (A)
 If @var{A} is of type @code{INTEGER}, @code{INT(A) = A} 
 @item (B)
-If @var{A} is of type @code{REAL} and @math{|A| < 1}, @code{INT(A)} equals 
@code{0}. 
-If @math{|A| \geq 1}, then @code{INT(A)} equals the largest integer that does 
not exceed 
-the range of @var{A} and whose sign is the same as the sign of @var{A}.
+If @var{A} is of type @code{REAL} and @math{|A| < 1}, @code{INT(A)}
+equals @code{0}. If @math{|A| \geq 1}, then @code{INT(A)} is the integer
+whose magnitude is the largest integer that does not exceed the magnitude
+of @var{A} and whose sign is the same as the sign of @var{A}.
 @item (C)
 If @var{A} is of type @code{COMPLEX}, rule B is applied to the real part of 
@var{A}.
 @end table

Re: [patch committed testsuite sh] Tweak gcc.c-torture/execute/pr44683.c

[Kaz Kojima]

Mike Stump  wrote:
>> BTW, Jeff's comment on pr39228.c makes me think that this test
>> can be moved into execute/ieee.  Thought?
> 
> I don’t see a down side, specially if we know that the test case is picky 
> about ieee.

Thanks for suggestion.  The patch below simply moves it into
execute/ieee.  Tested on i686-linux and sh-linux.

Regards,
kaz
--
* gcc.c-torture/execute/pr44683.c: Move to ...
* gcc.c-torture/execute/ieee/pr44683.c: ... here.

diff -uprN ORIG/trunk/gcc/testsuite/gcc.c-torture/execute/ieee/pr44683.c 
trunk/gcc/testsuite/gcc.c-torture/execute/ieee/pr44683.c
--- ORIG/trunk/gcc/testsuite/gcc.c-torture/execute/ieee/pr44683.c   
1970-01-01 09:00:00.0 +0900
+++ trunk/gcc/testsuite/gcc.c-torture/execute/ieee/pr44683.c2014-09-05 
18:02:46.0 +0900
@@ -0,0 +1,18 @@
+int __attribute__((noinline,noclone))
+copysign_bug (double x)
+{
+  if (x != 0.0 && (x * 0.5 == x))
+return 1;
+  if (__builtin_copysign(1.0, x) < 0.0)
+return 2;
+  else
+return 3;
+}
+int main(void)
+{
+  double x = -0.0;
+  if (copysign_bug (x) != 2)
+__builtin_abort ();
+  return 0;
+}
+
diff -uprN ORIG/trunk/gcc/testsuite/gcc.c-torture/execute/pr44683.c 
trunk/gcc/testsuite/gcc.c-torture/execute/pr44683.c
--- ORIG/trunk/gcc/testsuite/gcc.c-torture/execute/pr44683.c2014-09-05 
18:02:46.0 +0900
+++ trunk/gcc/testsuite/gcc.c-torture/execute/pr44683.c 1970-01-01 
09:00:00.0 +0900
@@ -1,18 +0,0 @@
-int __attribute__((noinline,noclone))
-copysign_bug (double x)
-{
-  if (x != 0.0 && (x * 0.5 == x))
-return 1;
-  if (__builtin_copysign(1.0, x) < 0.0)
-return 2;
-  else
-return 3;
-}
-int main(void)
-{
-  double x = -0.0;
-  if (copysign_bug (x) != 2)
-__builtin_abort ();
-  return 0;
-}
-

Re: [PATCH][RFC] Restrict, take 42

[Richard Biener]

On Wed, 3 Sep 2014, Richard Biener wrote:

> 
> Ok, so with recent activity in that mgrid bug (PR55334) I tried
> to remember what solution we thought of after determining that
> ADD_RESTRICT is a no-go.
> 
> The following very prototypish patch implements the idea of
> computing known non-dependences and maintaining them over
> the compilation (mainly inlining / cloning for PR55334).
> 
> So the patch piggy-backs on PTA (bad - PTA doesn't compute
> must-aliases, so it will work only for a very limited set
> of testcases now - but at least it might work for
> non-register restrict stuff).
> 
> The representation of "non-dependences" is the most interesting
> bit of course.  We partition memory references into different
> cliques in which all references are independent.  And we
> split that clique again into sets of references based on the
> same pointer.
> 
> That allows us to disambiguate equal clique but distinct pointer
> memory references.
> 
> For restrict you'd put all(!) memory references in the BLOCK
> where the restrict pointer is live into the same clique
> and assign a distinct ptr based on which restrict pointer this
> is based on.  You make all references not based on any
> restrict pointer have ptr == 0 (not implemented in the prototype
> patch - they don't get a clique assigned).
> 
> The patch simplifies this by taking function scope as the
> only BLOCK to consider, thus inside a function the clique
> will be unique (before inlining).
> 
> I can see issues arising with assigning numbers in the frontend
> based on real BLOCKs and
>   
>   {
> int * restrict q;
> {
>   int * restrict p;
>   *p = *q;
> }
> {
>   int * restrict r;
>   *r = *q;
> }
> 
> that is, non-dependences based on pointers coming from different
> nested scopes.  The FE in this case would need to "duplicate"
> the ptr value for 'q' to not make *p and *r falsely a
> non-dependence.  But I think we're not planning to assign
> this in the C frontend family (maybe the Fortran FE though).
> 
> To preserve correctness cliques from inlined functions need to
> be remapped to an unused clique number so struct function
> gets a max_clique number.  (remapping not implemented in
> the prototype)
> 
> Any correctness / missed-optimization holes to punch?  That is,
> given a set of non-dependent reference pairs, can you assign
> that clique, ptr values in a correct and optimal way?
> (it somehow assumes transitivity, if the set is *a, *b; *b, *c;
> then *a, *c are also non-dependent)
> 
> It all depends on a conservative but agressive must-be-based-on
> analysis of course.  You'd meet that with the conservative
> may-be-based-on analysis from PTA and compute the proper
> non-dependences from that.
> 
> Comments welcome.
> 
> Patch tested on
> 
> static inline void foo (int * __restrict__ p, int * __restrict__ q)
> {
>   int i;
>   for (i = 0; i < 1024; ++i)
> p[i] = q[i];
> }
> 
> void bar (int *p, int *q)
> {
>   foo (p, q);
> }
> 
> where it still vectorizes the loop in bar without alias check.

Updated patch with a tiny fix to manage fixing PR55334 (IPA-CP
issue with mgrid) and renaming all-over-the-place.

Still lacks the clique remapping code in the inliner which is
required for correctness and still lacks code to deal with
disambiguating restrct vs. non-restrict accesses.

Improves mgrid performance by 10%, still fixes the above tiny
testcase but otherwise untested.

Richard.

2014-09-05  Richard Biener  

PR tree-optimization/55334

Index: trunk/gcc/function.h
===
*** trunk.orig/gcc/function.h   2014-09-05 14:05:43.79983 +0200
--- trunk/gcc/function.h2014-09-05 14:10:30.961758013 +0200
*** struct GTY(()) function {
*** 593,598 
--- 593,601 
   a string describing the reason for failure.  */
const char * GTY((skip)) cannot_be_copied_reason;
  
+   /* Last assigned dependence info clique.  */
+   unsigned short last_clique;
+ 
/* Collected bit flags.  */
  
/* Number of units of general registers that need saving in stdarg
Index: trunk/gcc/tree-inline.c
===
*** trunk.orig/gcc/tree-inline.c2014-09-05 14:05:43.79983 +0200
--- trunk/gcc/tree-inline.c 2014-09-05 14:10:10.303759435 +0200
*** remap_gimple_op_r (tree *tp, int *walk_s
*** 929,934 
--- 929,938 
  TREE_THIS_VOLATILE (*tp) = TREE_THIS_VOLATILE (old);
  TREE_SIDE_EFFECTS (*tp) = TREE_SIDE_EFFECTS (old);
  TREE_NO_WARNING (*tp) = TREE_NO_WARNING (old);
+ /* ???  Properly remap the clique to a new one.  */
+ if (MR_DEPENDENCE_CLIQUE (old) != 0)
+   MR_DEPENDENCE_CLIQUE (*tp) = MR_DEPENDENCE_CLIQUE (old);
+ MR_DEPENDENCE_BASE (*tp) = MR_DEPENDENCE_BASE (old);
  /* We cannot propagate the TREE_THIS_NOTRAP flag if we have
 remapped a parameter as the pr

Re: [PATCH 10/10] Use rtx_insn for various jump-handling functions and predicates

[Richard Sandiford]

David Malcolm  writes:
> diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
> index 7cddab7..57eb83b 100644
> --- a/gcc/config/arc/arc.c
> +++ b/gcc/config/arc/arc.c
> @@ -2849,8 +2849,8 @@ arc_print_operand (FILE *file, rtx x, int code)
> /* Is this insn in a delay slot sequence?  */
> if (!final_sequence || XVECLEN (final_sequence, 0) < 2
> || current_insn_predicate
> -   || CALL_P (XVECEXP (final_sequence, 0, 0))
> -   || simplejump_p (XVECEXP (final_sequence, 0, 0)))
> +   || CALL_P (final_sequence->insn (0))
> +   || simplejump_p (final_sequence-> insn (0)))
>   {
> /* This insn isn't in a delay slot sequence, or conditionalized
>independently of its position in a delay slot.  */

Sorry for the nit, but: stray space after "->".

Thanks,
Richard

Re: [PINGv4][PATCHv3] Fix vector tests on ARM platforms with disabled unaligned accesses

[Marat Zakirov]

On 09/04/2014 09:23 PM, Mike Stump wrote:

On Sep 4, 2014, at 4:14 AM, Ramana Radhakrishnan  
wrote:

--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2293,8 +2293,8 @@ proc check_effective_target_arm_little_endian { } {
proc check_effective_target_arm_vect_no_misalign { } {
 return [check_no_compiler_messages arm_vect_no_misalign assembly {
#if !defined(__arm__) \
-   || (defined(__ARMEL__) \
-   && (!defined(__thumb__) || defined(__thumb2__)))
+   || (defined(__ARM_FEATURE_UNALIGNED) \
+   && defined(__ARMEL__))
#error FOO
#endif
 }]


Ok by me. But please wait for a testsuite maintainer to approve.

Ok.

Generally the port people that have been around for a while know what strikes 
them as wrong or not and can just approve the patch directly.  I suspect you 
are one of those people.  :-)  If you have any doubts or concerns, you can 
always raise them or ask for some help reviewing.  Don’t worry, if I spot 
something I don’t like after someone else says Ok, I will bring up the issue 
for consideration.  Even if I do, it doesn’t mean I object in anyway to the 
first review.


Thank you all.

Committed revision 214956.

--Marat

gcc/testsuite/ChangeLog:

2014-07-23  Marat Zakirov  

	* gcc.dg/vect/vect-109.c: Skip predicate added.
	* gcc.dg/vect/vect-93.c: Test check fixed.
	* gcc.dg/vect/bb-slp-10.c: Likewise.
	* lib/target-supports.exp (check_effective_target_arm_vect_no_misalign):
	Check unaligned feature.

diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-10.c b/gcc/testsuite/gcc.dg/vect/bb-slp-10.c
index a1850ed..0090a4b 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-10.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-10.c
@@ -49,7 +49,7 @@ int main (void)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump-times "unsupported alignment in basic block." 1 "slp2" { xfail vect_element_align } } } */
+/* { dg-final { scan-tree-dump "unsupported alignment in basic block." "slp2" { xfail vect_element_align } } } */
 /* { dg-final { scan-tree-dump-times "basic block vectorized" 1 "slp2" { target vect_element_align } } } */
 /* { dg-final { cleanup-tree-dump "slp2" } } */
   
diff --git a/gcc/testsuite/gcc.dg/vect/vect-109.c b/gcc/testsuite/gcc.dg/vect/vect-109.c
index 854c970..c671175 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-109.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-109.c
@@ -1,3 +1,4 @@
+/* { dg-skip-if "" { vect_no_align } } */
 /* { dg-require-effective-target vect_int } */
 
 #include 
diff --git a/gcc/testsuite/gcc.dg/vect/vect-93.c b/gcc/testsuite/gcc.dg/vect/vect-93.c
index 65403eb..1065a6e 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-93.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-93.c
@@ -79,7 +79,7 @@ int main (void)
 /* { dg-final { scan-tree-dump-times "vectorized 2 loops" 1 "vect" { target vect_no_align } } } */
 
 /* in main: */
-/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 1 "vect" { target vect_no_align } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target vect_no_align } } } */
 /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 1 "vect" { xfail { vect_no_align } } } } */
 
 /* { dg-final { cleanup-tree-dump "vect" } } */
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index db65ebe..35076d2 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2293,8 +2293,8 @@ proc check_effective_target_arm_little_endian { } {
 proc check_effective_target_arm_vect_no_misalign { } {
 return [check_no_compiler_messages arm_vect_no_misalign assembly {
 	#if !defined(__arm__) \
-	|| (defined(__ARMEL__) \
-	&& (!defined(__thumb__) || defined(__thumb2__)))
+	|| (defined(__ARM_FEATURE_UNALIGNED) \
+	&& defined(__ARMEL__))
 	#error FOO
 	#endif
 }]

Re: [PATCH] PR fortran/62245 fix INT docs.

[Steve Kargl]

On Fri, Sep 05, 2014 at 11:16:02AM +, VandeVondele  Joost wrote:
> > >The last sentence above is not needed.
> 
> So, revised patch without the last sentence.
> 
> 2014-09-05  Joost VandeVondele  
> 
>   PR fortran/62245
>   * intrinsic.texi (INT): clarify result.
> 

OK.

-- 
Steve

RE: [PATCH] PR fortran/62245 fix INT docs.

[VandeVondele Joost]

> OK.

Committed revision 214958.

Re: [PATCH][ARM/AArch64] Add scheduling info for ARMv8-A FPU new instructions in Cortex-A53

[Ramana Radhakrishnan]

On Fri, Aug 22, 2014 at 11:36 AM, Kyrill Tkachov  wrote:
> Hi all,
>
> The Cortex-A53 scheduler description is missing rules for insn types used by
> instructions such as vrint*, vmaxnm, vminnm causing them to be assigned to
> the "nothing" unit.
>
> This patch causes such instructions to be treated the same way as other
> simple FPU instructions.
>
> Bootstrapped and tested on aarch64-linux and tested on arm-none-eabi as
> well.
>
> Ok for trunk?

Ok.

Ramana
>
> Thanks,
> Kyrill
>
> 2014-08-22  Kyrylo Tkachov  
>
> * config/arm/cortex-a53.md (cortex_a53_fpalu): Add f_rints, f_rintd,
> f_minmaxs, f_minmaxd types.

(Corrected patch) Simple patch for gcc/testsuite/gcc.target/aarch64/vdup_lane_2.c

[David Sherwood]

Apologies, resent with correct patch not containing ChangeLog changes.


Hi,

I have a simple patch for the vdup_lane_2.c test that fixes up the
force_simd macro so that it does
something sensible for execute type test cases. Is this ok to install?

Tested on aarch64 little and big endian.

Regards,
David Sherwood.

ChangeLog:
2014-09-02  David Sherwood  

    * gcc.target/aarch64/vdup_lane_2.c (force_simd): Emit simd mov.




test_fix.patch
Description: Binary data

[Ping v3][PATCH] Add patch for debugging compiler ICEs.

[Maxim Ostapenko]

Ping.

-Maxim
On 08/28/2014 11:31 AM, Maxim Ostapenko wrote:

Ping. Add Joseph S. Myers as driver maintainer.

-Maxim
 Original Message 
Subject: Fwd: [PATCH] Add patch for debugging compiler ICEs.
Date: Tue, 19 Aug 2014 17:57:51 +0400
From: Maxim Ostapenko 
To: Jeff Law , GCC Patches 
CC: tsaund...@mozilla.com, Yury Gribov , 
Slava Garbuzov , Maxim Ostapenko 





Ping.

-Maxim
 Original Message 
Subject: [PATCH] Add patch for debugging compiler ICEs.
Date: Mon, 04 Aug 2014 21:03:22 +0400
From: Maxim Ostapenko 
To: GCC Patches 
CC: Jeff Law , Jakub Jelinek ,
tsaund...@mozilla.com, Yury Gribov , Slava
Garbuzov 



Hi,

A years ago there was a discussion
(https://gcc.gnu.org/ml/gcc-patches/2004-01/msg02437.html) about
debugging compiler ICEs that resulted in a patch from Jakub, which dumps
useful information into temporary file, but for some reasons this patch
wasn't applied to trunk.

This is the resurrected patch with added GCC version information into
generated repro file.

I've updated the patch that I've posted earlier
(https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01649.html ) according to
recent upstream discussion
(https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00020.html).

The debugging functionality is disabled by default and can be enabled
with adding -freport-bug into compile options. It can be also enabled by
default with
--with-spec during GCC build.

There are several directions in which this can be improved e.g:

1) more user-friendly ways to report bugs (autosubmitting to Bugzilla, 
etc.)


2) generate repro in case of segfault.

but having basic functionality (autogenerating reprocase in temprorary
file) already seems quite useful.

-Maxim








2014-08-04  Jakub Jelinek  
	  Max Ostapenko  

	* common.opt: New option.
	* doc/invoke.texi: Describe new option.
	* diagnostic.c (diagnostic_action_after_output): Exit with
	ICE_EXIT_CODE instead of FATAL_EXIT_CODE.
	* gcc.c (execute): Don't free first string early, but at the end
	of the function.  Call retry_ice if compiler exited with
	ICE_EXIT_CODE.
	(main): Factor out common code.
	(print_configuration): New function.
	(try_fork): Likewise.
	(redirect_stdout_stderr): Likewise.
	(files_equal_p): Likewise.
	(check_repro): Likewise.
	(run_attempt): Likewise.
	(do_report_bug): Likewise.
	(append_text): Likewise.
	(try_generate_repro): Likewise

diff --git a/gcc/common.opt b/gcc/common.opt
index f7021102..1133e61 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1120,6 +1120,11 @@ fdump-noaddr
 Common Report Var(flag_dump_noaddr)
 Suppress output of addresses in debugging dumps
 
+freport-bug
+Common Driver Var(flag_report_bug)
+Collect and dump debug information into temporary file if ICE in C/C++
+compiler occured.
+
 fdump-passes
 Common Var(flag_dump_passes) Init(0)
 Dump optimization passes
diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index 73666d6..60ed607 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -494,7 +494,7 @@ diagnostic_action_after_output (diagnostic_context *context,
 	real_abort ();
   diagnostic_finish (context);
   fnotice (stderr, "compilation terminated.\n");
-  exit (FATAL_EXIT_CODE);
+  exit (ICE_EXIT_CODE);
 
 default:
   gcc_unreachable ();
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d15d4a9..f41a1d8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -6316,6 +6316,11 @@ feasible to use diff on debugging dumps for compiler invocations with
 different compiler binaries and/or different
 text / bss / data / heap / stack / dso start locations.
 
+@item -freport-bug
+@opindex freport-bug
+Collect and dump debug information into temporary file if ICE in C/C++
+compiler occured.
+
 @item -fdump-unnumbered
 @opindex fdump-unnumbered
 When doing debugging dumps, suppress instruction numbers and address output.
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 44d0416..e0c403d 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -43,6 +43,13 @@ compilation is specified by a string called a "spec".  */
 #include "params.h"
 #include "vec.h"
 #include "filenames.h"
+#ifdef HAVE_UNISTD_H
+#include 
+#endif
+
+#if !(defined (__MSDOS__) || defined (OS2) || defined (VMS))
+#define RETRY_ICE_SUPPORTED
+#endif
 
 /* By default there is no special suffix for target executables.  */
 /* FIXME: when autoconf is fixed, remove the host check - dj */
@@ -253,6 +260,9 @@ static void init_gcc_specs (struct obstack *, const char *, const char *,
 static const char *convert_filename (const char *, int, int);
 #endif
 
+#ifdef RETRY_ICE_SUPPORTED
+static void try_generate_repro (const char *prog, const char **argv);
+#endif
 static const char *getenv_spec_function (int, const char **);
 static const char *if_exists_spec_function (int, const char **);
 static const char *if_exists_else_spec_function (int, const char **);
@@ -2849,7 +2859,7 @@ execute (void)
 	}
 	}
 
-  if (string != commands[i].prog)
+  if (i &

[PATCH 4.9][AArch64] Backport r214953: Rename [u]int32x1_t to [u]int32_t (resp 16x1, 8x1)in arm_neon.h

[Alan Lawrence]

Some manual editing of patch required due to e.g. int64x1 changes present on 
trunk but not on the 4.9 branch; new patch attached.


I've done a quick smoke test of aarch64.exp+simd.exp (check-gcc) and the g++ 
neon ABI test, as these ought to catch any changes to Neon intrinsics; full 
testsuite running.


I repeat, this is source-code-compatibility breaking, but not ABI breaking; if 
it causes you any problems, it'll be the 4.9.x compiler shouting at you ;).


Ok assuming no regressions?

--Alan

Marcus Shawcroft wrote:

On 24 July 2014 11:18, Alan Lawrence  wrote:

The ACLE spec does not mention the int32x1_t, uint32x1_t, int16x1_t,
uint16x1_t, int8x1_t or uint8x1_t types currently in arm_neon.h, but just
'standard' types int32_t, int16_t, etc. This patch is a global
search-and-replace across arm_neon.h (and the tests that depend on it).

Regressed (check-gcc and check-g++) on aarch64-none-elf.



OK for trunk.


The question of backporting to 4.9 has been raised internally. There is no
ABI issue, as int32x1_t was merely a typedef to int32_t (etc.). However
there is a source code compatibility issue; code mentioning the 32x1 types,
i.e. not conforming to the ACLE spec, which previously compiled, will no
longer do so. My personal feeling is therefore not to backport this, but I
would welcome input from maintainers (and others)...?


I doubt that there is currently much code out there that will be
affected by this change and that it would be better to back port and
hence limit the amount of code written against the broken arm_neon.h
during the life of the 4.9.x series. If there are no objections to
back porting in the next couple of days then go ahead.

/Marcus

diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index c01669b..bafdbcf 100644
--- a/gcc/config/aarch64/arm_neon.h
+++ b/gcc/config/aarch64/arm_neon.h
@@ -39,9 +39,6 @@ typedef __builtin_aarch64_simd_hi int16x4_t
 typedef __builtin_aarch64_simd_si int32x2_t
   __attribute__ ((__vector_size__ (8)));
 typedef int64_t int64x1_t;
-typedef int32_t int32x1_t;
-typedef int16_t int16x1_t;
-typedef int8_t int8x1_t;
 typedef double float64x1_t;
 typedef __builtin_aarch64_simd_sf float32x2_t
   __attribute__ ((__vector_size__ (8)));
@@ -56,9 +53,6 @@ typedef __builtin_aarch64_simd_uhi uint16x4_t
 typedef __builtin_aarch64_simd_usi uint32x2_t
   __attribute__ ((__vector_size__ (8)));
 typedef uint64_t uint64x1_t;
-typedef uint32_t uint32x1_t;
-typedef uint16_t uint16x1_t;
-typedef uint8_t uint8x1_t;
 typedef __builtin_aarch64_simd_qi int8x16_t
   __attribute__ ((__vector_size__ (16)));
 typedef __builtin_aarch64_simd_hi int16x8_t
@@ -20925,42 +20919,42 @@ vqabsq_s64 (int64x2_t __a)
   return (int64x2_t) __builtin_aarch64_sqabsv2di (__a);
 }
 
-__extension__ static __inline int8x1_t __attribute__ ((__always_inline__))
-vqabsb_s8 (int8x1_t __a)
+__extension__ static __inline int8_t __attribute__ ((__always_inline__))
+vqabsb_s8 (int8_t __a)
 {
-  return (int8x1_t) __builtin_aarch64_sqabsqi (__a);
+  return (int8_t) __builtin_aarch64_sqabsqi (__a);
 }
 
-__extension__ static __inline int16x1_t __attribute__ ((__always_inline__))
-vqabsh_s16 (int16x1_t __a)
+__extension__ static __inline int16_t __attribute__ ((__always_inline__))
+vqabsh_s16 (int16_t __a)
 {
-  return (int16x1_t) __builtin_aarch64_sqabshi (__a);
+  return (int16_t) __builtin_aarch64_sqabshi (__a);
 }
 
-__extension__ static __inline int32x1_t __attribute__ ((__always_inline__))
-vqabss_s32 (int32x1_t __a)
+__extension__ static __inline int32_t __attribute__ ((__always_inline__))
+vqabss_s32 (int32_t __a)
 {
-  return (int32x1_t) __builtin_aarch64_sqabssi (__a);
+  return (int32_t) __builtin_aarch64_sqabssi (__a);
 }
 
 /* vqadd */
 
-__extension__ static __inline int8x1_t __attribute__ ((__always_inline__))
-vqaddb_s8 (int8x1_t __a, int8x1_t __b)
+__extension__ static __inline int8_t __attribute__ ((__always_inline__))
+vqaddb_s8 (int8_t __a, int8_t __b)
 {
-  return (int8x1_t) __builtin_aarch64_sqaddqi (__a, __b);
+  return (int8_t) __builtin_aarch64_sqaddqi (__a, __b);
 }
 
-__extension__ static __inline int16x1_t __attribute__ ((__always_inline__))
-vqaddh_s16 (int16x1_t __a, int16x1_t __b)
+__extension__ static __inline int16_t __attribute__ ((__always_inline__))
+vqaddh_s16 (int16_t __a, int16_t __b)
 {
-  return (int16x1_t) __builtin_aarch64_sqaddhi (__a, __b);
+  return (int16_t) __builtin_aarch64_sqaddhi (__a, __b);
 }
 
-__extension__ static __inline int32x1_t __attribute__ ((__always_inline__))
-vqadds_s32 (int32x1_t __a, int32x1_t __b)
+__extension__ static __inline int32_t __attribute__ ((__always_inline__))
+vqadds_s32 (int32_t __a, int32_t __b)
 {
-  return (int32x1_t) __builtin_aarch64_sqaddsi (__a, __b);
+  return (int32_t) __builtin_aarch64_sqaddsi (__a, __b);
 }
 
 __extension__ static __inline int64x1_t __attribute__ ((__always_inline__))
@@ -20969,22 +20963,22 @@ vqaddd_s64 (int64x1_t __a, int64x1_t __b)
   return (int64x1_t) __builtin_aarch64_sqaddd

libgo patch committed: Fix size for unsafe.Pointer GC instructions

[Ian Lance Taylor]

This patch to libgo fixes the size for the GC instructions for
unsafe.Pointer, which are hand coded.  Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian

diff -r 6b61234c2552 libgo/runtime/go-unsafe-pointer.c
--- a/libgo/runtime/go-unsafe-pointer.c	Wed Sep 03 15:44:43 2014 -0700
+++ b/libgo/runtime/go-unsafe-pointer.c	Fri Sep 05 07:41:55 2014 -0700
@@ -39,7 +39,7 @@
   sizeof REFLECTION - 1
 };
 
-const uintptr unsafe_Pointer_gc[] = {8, GC_APTR, 0, GC_END};
+const uintptr unsafe_Pointer_gc[] = {sizeof(void*), GC_APTR, 0, GC_END};
 
 const struct __go_type_descriptor unsafe_Pointer =
 {

[Patch, AArch64] Enable Address sanitizer and UB sanitizer

[Christophe Lyon]

Hi,

The attached patch enables the address and undefined behavior sanitizers.

I have tested it on AArch64 hardware, and asan.exp tests pass, but a
few ubsan.exp tests fail as follows:
FAIL: c-c++-common/ubsan/float-cast-overflow-1.c   -O3 -g  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-1.c   -O2 -flto
-flto-partition=none  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-2.c   -O3 -g  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-3.c   -O3 -g  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-4.c   -O2  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-4.c   -O3 -g  execution test
FAIL: c-c++-common/ubsan/overflow-int128.c   -O0  (internal compiler error)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O0  (test for excess errors)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O1  (internal compiler error)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O1  (test for excess errors)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O2  (internal compiler error)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O2  (test for excess errors)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O3 -fomit-frame-pointer
(internal compiler error)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O3 -fomit-frame-pointer
(test for excess errors)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O3 -g  (internal compiler error)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O3 -g  (test for excess errors)
FAIL: c-c++-common/ubsan/overflow-int128.c   -Os  (internal compiler error)
FAIL: c-c++-common/ubsan/overflow-int128.c   -Os  (test for excess errors)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O2 -flto
-flto-partition=none  (internal compiler error)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O2 -flto
-flto-partition=none  (test for excess errors)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O2 -flto  (internal
compiler error)
FAIL: c-c++-common/ubsan/overflow-int128.c   -O2 -flto  (test for excess errors)
FAIL: gcc.dg/ubsan/float-cast-overflow-bf.c   -O3 -g  execution test

I think all these failures need to be addressed separately, and should
not prevent from adding the functionality since most of them pass.

Note that an update of libsanitizer is required, to include at least
revision 209641 (which fixes internal_fork for AArch64).

OK for trunk?

Christophe.

2014-09-05  Christophe Lyon 
gcc/
* config/aarch64/aarch64-linux.h (ASAN_CC1_SPEC): Define.
(CC1_SPEC): Define.
* config/aarch64/aarch64.c (aarch64_asan_shadow_offset): New function.
(TARGET_ASAN_SHADOW_OFFSET): Define.

libsanitizer/
* configure.tgt: Add AArch64 pattern.
diff --git a/gcc/config/aarch64/aarch64-linux.h b/gcc/config/aarch64/aarch64-linux.h
index 8d20310..2278516 100644
--- a/gcc/config/aarch64/aarch64-linux.h
+++ b/gcc/config/aarch64/aarch64-linux.h
@@ -23,6 +23,12 @@
 
 #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64%{mbig-endian:_be}%{mabi=ilp32:_ilp32}.so.1"
 
+#undef  ASAN_CC1_SPEC
+#define ASAN_CC1_SPEC "%{%:sanitize(address):-funwind-tables}"
+
+#undef  CC1_SPEC
+#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC ASAN_CC1_SPEC
+
 #define CPP_SPEC "%{pthread:-D_REENTRANT}"
 
 #define LINUX_TARGET_LINK_SPEC  "%{h*}		\
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index c3c871e..39b9fd2 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -9826,6 +9826,14 @@ aarch64_expand_movmem (rtx *operands)
   return true;
 }
 
+/* Implement the TARGET_ASAN_SHADOW_OFFSET hook.  */
+
+static unsigned HOST_WIDE_INT
+aarch64_asan_shadow_offset (void)
+{
+  return (HOST_WIDE_INT_1 << 36);
+}
+
 #undef TARGET_ADDRESS_COST
 #define TARGET_ADDRESS_COST aarch64_address_cost
 
@@ -10072,6 +10080,9 @@ aarch64_expand_movmem (rtx *operands)
 #undef TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS
 #define TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS true
 
+#undef TARGET_ASAN_SHADOW_OFFSET
+#define TARGET_ASAN_SHADOW_OFFSET aarch64_asan_shadow_offset
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 #include "gt-aarch64.h"
diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt
index 6de4a65..2c302ab 100644
--- a/libsanitizer/configure.tgt
+++ b/libsanitizer/configure.tgt
@@ -35,6 +35,8 @@ case "${target}" in
 	;;
   arm*-*-linux*)
 	;;
+  aarch64*-*-linux*)
+	;;
   x86_64-*-darwin[1]* | i?86-*-darwin[1]*)
 	TSAN_SUPPORTED=no
 	;;

Fix for "FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o compile, (internal compiler error)"

[David Sherwood]

Hi,

I have a potential fix for a gcc testsuite failure for aarch64 in big
endian, i.e.

FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o compile, (internal
compiler error)
FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_y_tst.o compile, (internal
compiler error)

It is caused by the inappropriate choice of hard registers for paradoxical
sub registers in
big endian mode, for example if register 0 is chosen for a paradoxical TI
subreg on big
endian then we may end up attempting to reference register -1. Similarly, on
little endian
we could end up going beyond the upper bounds of the register file too.

My fix involves adding particular constraints in IRA on the choice of
register once paradoxical 
sub registers are encountered. However, Richard Sandiford also proposed an
alternative
solution that involves not constraining registers in IRA, but rather making
use of cost analysis
instead and letting LRA do the work. Not sure what your preference is 

Fix was tested on aarch64 on little and big endian with no regressions.

Regards,
David Sherwood.

2014-08-26  David Sherwood  

* ira-int.h (ira_allocno): Add "wmode" field.
* ira-build.c (create_insn_allocnos): Add new "parent" function
parameter.
* ira-conflicts.c (ira_build_conflicts): Add conflicts for registers
that cannot be accessed in wmode.


ira.patch
Description: Binary data

[wwwdocs] Buildstat update for 4.9

[Tom G. Christensen]

Latest results for 4.9.x

-tgc

Testresults for 4.9.1:
  aarch64-linux-gnu (cross)
  arm-unknown-linux-gnu
  hppa-unknown-linux-gnu
  i686-unknown-linux-gnu
  mips-unknown-linux-gnu
  mipsel-unknown-linux-gnu
  powerpc-unknown-linux-gnu
  sparc-unknown-linux-gnu
  x86_64-unknown-linux-gnu

Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/buildstat.html,v
retrieving revision 1.6
diff -u -r1.6 buildstat.html
--- buildstat.html  24 Aug 2014 10:15:58 -  1.6
+++ buildstat.html  5 Sep 2014 14:49:26 -
@@ -23,9 +23,18 @@
 
 
 
+aarch64-linux-gnu
+i686-pc-linux-gnu
+Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2014-09/msg00328.html";>4.9.1
+
+
+
+
 arm-unknown-linux-gnueabi
  
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg03094.html";>4.9.1,
 https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00051.html";>4.9.0
 
 
@@ -42,6 +51,7 @@
 hppa-unknown-linux-gnu
  
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg03008.html";>4.9.1,
 https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00210.html";>4.9.0
 
 
@@ -100,6 +110,7 @@
 i686-unknown-linux-gnu
  
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg02846.html";>4.9.1,
 https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg02200.html";>4.9.0
 
 
@@ -108,6 +119,7 @@
 mips-unknown-linux-gnu
  
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg03102.html";>4.9.1,
 https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00205.html";>4.9.0
 
 
@@ -116,6 +128,7 @@
 mipsel-unknown-linux-gnu
  
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg03115.html";>4.9.1,
 https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00096.html";>4.9.0
 
 
@@ -133,6 +146,7 @@
 powerpc-unknown-linux-gnu
  
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg03148.html";>4.9.1,
 https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00841.html";>4.9.0
 
 
@@ -176,6 +190,7 @@
 sparc-unknown-linux-gnu
  
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg03222.html";>4.9.1,
 https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg00150.html";>4.9.0
 
 
@@ -184,6 +199,7 @@
 x86_64-unknown-linux-gnu
  
 Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2014-08/msg02782.html";>4.9.1,
 https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg02573.html";>4.9.1,
 https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg02165.html";>4.9.0,
 https://gcc.gnu.org/ml/gcc-testresults/2014-04/msg01757.html";>4.9.0,

Re: (Corrected patch) Simple patch for gcc/testsuite/gcc.target/aarch64/vdup_lane_2.c

[Marcus Shawcroft]

On 5 September 2014 14:46, David Sherwood  wrote:
> Apologies, resent with correct patch not containing ChangeLog changes.
> 
>
> Hi,
>
> I have a simple patch for the vdup_lane_2.c test that fixes up the
> force_simd macro so that it does
> something sensible for execute type test cases. Is this ok to install?
>
> Tested on aarch64 little and big endian.
>
> Regards,
> David Sherwood.
>
> ChangeLog:
> 2014-09-02  David Sherwood  
>
> * gcc.target/aarch64/vdup_lane_2.c (force_simd): Emit simd mov.

OK, thanks
/Marcus

Re: Vimrc config with GNU formatting

[Yury Gribov]

On 09/04/2014 05:22 PM, Richard Biener wrote:

For some reason I use

set shiftwidth=4
set tabstop=8
set autoindent
set cinoptions={.5s,g0,p5,t0,(0,^-0.5s,n-0.5s

I note some differences to your

+  setlocal cinoptions=>4,n-2,{2,^-2,:2,=2,g0,h2,p5,t0,+2,(0,u0,w1,m1


Ah, the vimfu.

So the differences seem to boil down to
1) your config uses autoindent (mine does cindent)
2) my (well, Laurynas's) cinoptions additionally include 
>4,:2,=2,h2,+2,u0,w1,m1

3) your config sets tabstop whereas mine uses softtabstop
4) formatoptions cause autowrapping of comments at 80-th column

I'm not sure about 1), but 2) allows:
* case labels start under parent {
* correct indent on line break (should be 2, not 4)
which seem to match current GCC style.

Also due to 3) issuing a tab expands to 2 spaces
instead of real tab which is probably a Good Thing.

Your settings beat mine at m1 though - it should be removed
to allow vim to match closing ) with opening.

So I'd say that in general proposed patch handles more cases (with 
removed m1).


-Y

Re: [gomp4] Add tables generation

[Ilya Verbin]

Hi,

On 04 Sep 15:54, Thomas Schwinge wrote:
> Aha, it's gcc/gcc.c:LINK_PLUGIN_SPEC that is unconditionally adding the
> -fresolution option.  Here is a hack that seems to make it work, but that
> most certainly should be done differently:

Here is updated patch, which solves the problem with linker plugin.
I hope that it will not affect the regular LTO compilation.  At least, the
'make check' did not reveal any regression on the system with linker plugin.
Bootstrap also passed.  Ok for gomp-4_0-branch?

  -- Ilya


---
 gcc/cgraphunit.c| 38 ---
 gcc/lto-wrapper.c   | 69 ++---
 gcc/omp-low.c   |  6 +
 gcc/passes.c|  2 +-
 lto-plugin/lto-plugin.c | 25 +-
 5 files changed, 97 insertions(+), 43 deletions(-)

diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index f0c9f5c..b87e6dd 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -2040,13 +2040,25 @@ output_in_order (void)
   free (nodes);
 }
 
-/* Collect all global variables with "omp declare target" attribute into
-   OFFLOAD_VARS.  It will be streamed out in ipa_write_summaries.  */
+/* Check whether there is at least one function or global variable to offload.
+   Also collect all such global variables into OFFLOAD_VARS, the functions were
+   already collected in omp-low.c.  They will be streamed out in
+   ipa_write_summaries.  */
 
-static void
-init_offload_var_table (void)
+static bool
+initialize_offload (void)
 {
+  bool have_offload = false;
+  struct cgraph_node *node;
   struct varpool_node *vnode;
+
+  FOR_EACH_DEFINED_FUNCTION (node)
+if (lookup_attribute ("omp declare target", DECL_ATTRIBUTES (node->decl)))
+  {
+   have_offload = true;
+   break;
+  }
+
   FOR_EACH_DEFINED_VARIABLE (vnode)
 {
   if (!lookup_attribute ("omp declare target",
@@ -2054,13 +2066,17 @@ init_offload_var_table (void)
  || TREE_CODE (vnode->decl) != VAR_DECL
  || DECL_SIZE (vnode->decl) == 0)
continue;
+  have_offload = true;
   vec_safe_push (offload_vars, vnode->decl);
 }
+
+  return have_offload;
 }
 
 static void
 ipa_passes (void)
 {
+  bool have_offload = false;
   gcc::pass_manager *passes = g->get_passes ();
 
   set_cfun (NULL);
@@ -2068,6 +2084,14 @@ ipa_passes (void)
   gimple_register_cfg_hooks ();
   bitmap_obstack_initialize (NULL);
 
+  if (!in_lto_p && (flag_openacc || flag_openmp))
+{
+  have_offload = initialize_offload ();
+  /* OpenACC / OpenMP offloading requires LTO infrastructure.  */
+  if (have_offload)
+   flag_generate_lto = 1;
+}
+
   invoke_plugin_callbacks (PLUGIN_ALL_IPA_PASSES_START, NULL);
 
   if (!in_lto_p)
@@ -2108,11 +2132,7 @@ ipa_passes (void)
 
   if (!in_lto_p)
 {
-  init_offload_var_table ();
-
-  if ((flag_openacc || flag_openmp)
- && !(vec_safe_is_empty (offload_funcs)
-  && vec_safe_is_empty (offload_vars)))
+  if (have_offload)
{
  section_name_prefix = OMP_SECTION_NAME_PREFIX;
  ipa_write_summaries (true);
diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index 80d10f3..01e8f06 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -668,6 +668,11 @@ run_gcc (unsigned argc, char *argv[])
  close (fd);
  continue;
}
+  /* We may choose not to write out this .opts section in the future.  In
+that case we'll have to use something else to look for.  */
+  if (simple_object_find_section (sobj, OMP_SECTION_NAME_PREFIX "." "opts",
+ &offset, &length, &errmsg, &err))
+   have_offload = true;
   if (!simple_object_find_section (sobj, LTO_SECTION_NAME_PREFIX "." 
"opts",
   &offset, &length, &errmsg, &err))
{
@@ -675,11 +680,6 @@ run_gcc (unsigned argc, char *argv[])
  close (fd);
  continue;
}
-  /* We may choose not to write out this .opts section in the future.  In
-that case we'll have to use something else to look for.  */
-  if (simple_object_find_section (sobj, OMP_SECTION_NAME_PREFIX "." "opts",
- &offset, &length, &errmsg, &err))
-   have_offload = true;
   lseek (fd, file_offset + offset, SEEK_SET);
   data = (char *)xmalloc (length);
   read (fd, data, length);
@@ -871,7 +871,32 @@ run_gcc (unsigned argc, char *argv[])
   /* Remember at which point we can scrub args to re-use the commons.  */
   new_head_argc = obstack_object_size (&argv_obstack) / sizeof (void *);
 
-  if (lto_mode == LTO_MODE_LTO)
+  if (have_offload)
+{
+  compile_images_for_openmp_targets (argc, argv);
+  if (offload_names)
+   {
+ find_ompbeginend ();
+ for (i = 0; offload_names[i]; i++)
+   printf ("%s\n", offload_names[i]);
+ free_array_of_ptrs ((void **) offload_names, i);
+   }
+}
+
+  if (ompbegin)
+  

Re: Vimrc config with GNU formatting

[Yury Gribov]

On 09/05/2014 12:22 AM, Bernhard Reutner-Fischer wrote:

Not sure from whom i borrowed this, perhaps even from you richi, but the
gcc_style.vim pasted in the mail below seems to be floating around ;)

https://gcc.gnu.org/ml/gcc-patches/2012-12/msg01228.html


Nice! Interestingly enough this gives same results with my settings
(or at least I was not able to spot any difference).

Formatting of comments is still different though (mine are wrapped at 
80-th column).


Now I don't quite like the idea of plugin:
* .local.vimrc setting is more compatible with what we already have for 
Emacs

* gcc_style.vim won't work for new files (it requires GCC license agreement)
* gcc_style.vim enables GNU style globally, for all projects

IMHO localrc plugin is widespread enough that we can rely on it.


This automatically applies the "gcc style" if the first 25 lines of the
file being opened contains the syndicated "This file is part of GCC" so
should transparently not set GNU style on foreign stuff like sanitizer.


But as I mentioned also disables formatting for all new files.

-Y

Re: [PATCH 10/10] Use rtx_insn for various jump-handling functions and predicates

[David Malcolm]

On Fri, 2014-09-05 at 14:03 +0100, Richard Sandiford wrote:
> David Malcolm  writes:
> > diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
> > index 7cddab7..57eb83b 100644
> > --- a/gcc/config/arc/arc.c
> > +++ b/gcc/config/arc/arc.c
> > @@ -2849,8 +2849,8 @@ arc_print_operand (FILE *file, rtx x, int code)
> >   /* Is this insn in a delay slot sequence?  */
> >   if (!final_sequence || XVECLEN (final_sequence, 0) < 2
> >   || current_insn_predicate
> > - || CALL_P (XVECEXP (final_sequence, 0, 0))
> > - || simplejump_p (XVECEXP (final_sequence, 0, 0)))
> > + || CALL_P (final_sequence->insn (0))
> > + || simplejump_p (final_sequence-> insn (0)))
> > {
> >   /* This insn isn't in a delay slot sequence, or conditionalized
> >  independently of its position in a delay slot.  */
> 
> Sorry for the nit, but: stray space after "->".

Thanks; I fixed this before committing (r214970).

[wwwdocs] Buildstat update for 4.8

[Tom G. Christensen]

No new testresults just a small fixup for the update from Raghunath
Lolur.
His aarch64 build was cross built though the testsuite seems to have
been run using qemu (host=target).
I'm uncertain if this qualifies for mentioning the build host in the
second column, but for now the just posted 4.9 update adds it for his
recent build and so does this patch.

-tgc
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.html,v
retrieving revision 1.11
diff -u -r1.11 buildstat.html
--- buildstat.html  25 Aug 2014 07:42:07 -  1.11
+++ buildstat.html  5 Sep 2014 14:54:09 -
@@ -24,9 +24,9 @@
 
 
 aarch64-unknown-linux-gnu
- 
+i686-pc-linux-gnu
 Test results:
-https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01057.html";>4.8.3
+https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01057.html";>4.8.3,
 https://gcc.gnu.org/ml/gcc-testresults/2014-03/msg02123.html";>4.8.2
 
 

Re: Use -fbuilding-libgcc for more target macros used in libgcc

[Dominique Dhumieres]

On Thu, Sep 4, 2014 at 6:15 PM, Joseph S. Myers  wrote:
>
> gcc/c-family:
> 2014-09-05  Joseph Myers  
>
> * c-cppbuiltin.c (c_cpp_builtins): Also define
> __LIBGCC_EH_TABLES_CAN_BE_READ_ONLY__,
> __LIBGCC_EH_FRAME_SECTION_NAME__, __LIBGCC_JCR_SECTION_NAME__,
> __LIBGCC_CTORS_SECTION_ASM_OP__, __LIBGCC_DTORS_SECTION_ASM_OP__,
> __LIBGCC_TEXT_SECTION_ASM_OP__, __LIBGCC_INIT_SECTION_ASM_OP__,
> __LIBGCC_INIT_ARRAY_SECTION_ASM_OP__,
> __LIBGCC_STACK_GROWS_DOWNWARD__,
> __LIBGCC_DONT_USE_BUILTIN_SETJMP__,
> __LIBGCC_DWARF_ALT_FRAME_RETURN_COLUMN__,
> __LIBGCC_DWARF_FRAME_REGISTERS__,
> ...

This breaks bootstrap on x86_64-apple-darwin13, see

https://gcc.gnu.org/ml/gcc-bugs/2014-09/msg01135.html

TIA

Dominique

Re: [gofrontend-dev] gccgo and syscall.SysProcAttr.Cloneflags

[Ian Lance Taylor]

On Mon, Sep 1, 2014 at 4:18 AM, Michael Hudson-Doyle
 wrote:
>
> It's late for me and I don't have a proper test case but it seems to me
> that while gccgo's syscall lets you set Cloneflags on its SysProcAttr,
> but doesn't actually *do* anything with the flags.  Am I missing
> something?

You aren't missing anything.  I made an error in an libgo merge last
year.  This patch fixes the problem.  Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu.  Committed to mainline and 4.9
branch.

Ian

diff -r da369647d0ec libgo/go/syscall/exec_linux.go
--- a/libgo/go/syscall/exec_linux.go Fri Sep 05 07:42:57 2014 -0700
+++ b/libgo/go/syscall/exec_linux.go Fri Sep 05 08:05:22 2014 -0700
@@ -43,7 +43,7 @@
  // Declare all variables at top in case any
  // declarations require heap allocation (e.g., err1).
  var (
- r1 Pid_t
+ r1 uintptr
  err1   Errno
  nextfd int
  i  int
@@ -65,7 +65,7 @@
  // About to call fork.
  // No more allocation or calls of non-assembly functions.
  runtime_BeforeFork()
- r1, err1 = raw_fork()
+ r1, _, err1 = RawSyscall6(SYS_CLONE,
uintptr(SIGCHLD)|sys.Cloneflags, 0, 0, 0, 0, 0)
  if err1 != 0 {
  runtime_AfterFork()
  return 0, err1

[PATCH 1/2] add staticly checked label_nuses accessors

[tsaunders]

From: Trevor Saunders 

Hi,

 Doing this means we get to remove a fair chunk of runtime checking.

bootstrapped + regtested on x86_64-unknown-linux-gnu with no regressions.
config-list.mk with this and the next patch is ongoing. ok?

Trev

gcc/

* config/i386/i386.c, config/i386/i386.md, config/mep/mep.c,
config/mips/mips.c, config/nios2/nios2.c, config/s390/s390.c,
config/sh/sh.c, reorg.c: Use rtx_code_label::nuses and
rtx_code_label::set_nuses where possible.
* rtl.h (rtx_code_label::nuses): New member function.
(rtx_code_label::set_nuses): Likewise.
---
 gcc/config/i386/i386.c   | 56 
 gcc/config/i386/i386.md  | 14 ++--
 gcc/config/mep/mep.c |  2 +-
 gcc/config/mips/mips.c   |  2 +-
 gcc/config/nios2/nios2.c |  4 ++--
 gcc/config/s390/s390.c   |  4 ++--
 gcc/config/sh/sh.c   |  2 +-
 gcc/reorg.c  |  6 +++---
 gcc/rtl.h|  9 
 9 files changed, 54 insertions(+), 45 deletions(-)

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a117718..e2b4a00 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -12136,7 +12136,7 @@ ix86_expand_split_stack_prologue (void)
 }
 
   emit_label (label);
-  LABEL_NUSES (label) = 1;
+  label->set_nuses (1);
 
   /* If this function calls va_start, we now have to set the scratch
  register for the case where we do not call __morestack.  In this
@@ -12148,7 +12148,7 @@ ix86_expand_split_stack_prologue (void)
GEN_INT (UNITS_PER_WORD;
 
   emit_label (varargs_label);
-  LABEL_NUSES (varargs_label) = 1;
+  varargs_label->set_nuses (1);
 }
 }
 
@@ -23129,7 +23129,7 @@ expand_movmem_epilogue (rtx destmem, rtx srcmem,
  dest = change_address (destmem, SImode, destptr);
  emit_insn (gen_strmov (destptr, dest, srcptr, src));
  emit_label (label);
- LABEL_NUSES (label) = 1;
+ label->set_nuses (1);
}
   if (max_size > 2)
{
@@ -23138,7 +23138,7 @@ expand_movmem_epilogue (rtx destmem, rtx srcmem,
  dest = change_address (destmem, HImode, destptr);
  emit_insn (gen_strmov (destptr, dest, srcptr, src));
  emit_label (label);
- LABEL_NUSES (label) = 1;
+ label->set_nuses (1);
}
   if (max_size > 1)
{
@@ -23147,7 +23147,7 @@ expand_movmem_epilogue (rtx destmem, rtx srcmem,
  dest = change_address (destmem, QImode, destptr);
  emit_insn (gen_strmov (destptr, dest, srcptr, src));
  emit_label (label);
- LABEL_NUSES (label) = 1;
+ label->set_nuses (1);
}
 }
   else
@@ -23166,7 +23166,7 @@ expand_movmem_epilogue (rtx destmem, rtx srcmem,
  if (tmp != offset)
emit_move_insn (offset, tmp);
  emit_label (label);
- LABEL_NUSES (label) = 1;
+ label->set_nuses (1);
}
   if (max_size > 2)
{
@@ -23181,7 +23181,7 @@ expand_movmem_epilogue (rtx destmem, rtx srcmem,
  if (tmp != offset)
emit_move_insn (offset, tmp);
  emit_label (label);
- LABEL_NUSES (label) = 1;
+ label->set_nuses (1);
}
   if (max_size > 1)
{
@@ -23192,7 +23192,7 @@ expand_movmem_epilogue (rtx destmem, rtx srcmem,
  dest = change_address (destmem, QImode, tmp);
  emit_move_insn (dest, src);
  emit_label (label);
- LABEL_NUSES (label) = 1;
+ label->set_nuses (1);
}
 }
 }
@@ -23321,7 +23321,7 @@ expand_setmem_epilogue (rtx destmem, rtx destptr, rtx 
value, rtx vec_value,
  emit_insn (gen_strset (destptr, dest, value));
}
   emit_label (label);
-  LABEL_NUSES (label) = 1;
+  label->set_nuses (1);
 }
   if (max_size > 8)
 {
@@ -23339,7 +23339,7 @@ expand_setmem_epilogue (rtx destmem, rtx destptr, rtx 
value, rtx vec_value,
  emit_insn (gen_strset (destptr, dest, value));
}
   emit_label (label);
-  LABEL_NUSES (label) = 1;
+  label->set_nuses (1);
 }
   if (max_size > 4)
 {
@@ -23347,7 +23347,7 @@ expand_setmem_epilogue (rtx destmem, rtx destptr, rtx 
value, rtx vec_value,
   dest = change_address (destmem, SImode, destptr);
   emit_insn (gen_strset (destptr, dest, gen_lowpart (SImode, value)));
   emit_label (label);
-  LABEL_NUSES (label) = 1;
+  label->set_nuses (1);
 }
   if (max_size > 2)
 {
@@ -23355,7 +23355,7 @@ expand_setmem_epilogue (rtx destmem, rtx destptr, rtx 
value, rtx vec_value,
   dest = change_address (destmem, HImode, destptr);
   emit_insn (gen_strset (destptr, dest, gen_lowpart (HImode, value)));
   emit_label (label);
-  LABEL_NUSES (label) = 1;
+  label->set_nuses (1);
 }
   if (max_size > 1)
 {
@@ -23363,7 +23363,7 @@ expand_setmem_epilogue (rtx destmem, rtx destptr, rtx 
value, rtx vec_value,
   d

[PATCH 2/2] add static typed insn_deleted_p

[tsaunders]

From: Trevor Saunders 

Hi,
Same idea as the last patch.

also bootstrapped and regtested on x86_64-unknown-linux-gnu with config-list.mk
ongoing ok?


Trev

gcc/

* cfgrtl.c, combine.c, config/arc/arc.c, config/mcore/mcore.c,
config/rs6000/rs6000.c, config/sh/sh.c, cprop.c, dwarf2out.c,
emit-rtl.c, final.c, function.c, gcse.c, jump.c, reg-stack.c,
reload1.c, reorg.c, resource.c, sel-sched-ir.c: Replace INSN_DELETED_P
macro with staticly checked member functions.
* rtl.h (rtx_insn::deleted): New method.
(rtx_insn::set_deleted): Likewise.
(rtx_insn::set_undeleted): Likewise.
---
 gcc/cfgrtl.c   |  8 
 gcc/combine.c  |  2 +-
 gcc/config/arc/arc.c   |  4 ++--
 gcc/config/mcore/mcore.c   |  2 +-
 gcc/config/rs6000/rs6000.c |  2 +-
 gcc/config/sh/sh.c |  8 
 gcc/cprop.c|  6 +++---
 gcc/dwarf2out.c|  2 +-
 gcc/emit-rtl.c |  6 +++---
 gcc/final.c|  4 ++--
 gcc/function.c |  2 +-
 gcc/gcse.c |  2 +-
 gcc/jump.c | 20 ++--
 gcc/reg-stack.c|  2 +-
 gcc/reload1.c  |  2 +-
 gcc/reorg.c| 12 ++--
 gcc/resource.c |  3 +--
 gcc/rtl.h  | 13 +
 gcc/sel-sched-ir.c |  4 ++--
 19 files changed, 58 insertions(+), 46 deletions(-)

diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index bc6c965..49779fc 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -165,11 +165,11 @@ delete_insn (rtx uncast_insn)
   if (really_delete)
 {
   /* If this insn has already been deleted, something is very wrong.  */
-  gcc_assert (!INSN_DELETED_P (insn));
+  gcc_assert (!insn->deleted ());
   if (INSN_P (insn))
df_insn_delete (insn);
   remove_insn (insn);
-  INSN_DELETED_P (insn) = 1;
+  insn->set_deleted ();
 }
 
   /* If deleting a jump, decrement the use count of the label.  Deleting
@@ -254,7 +254,7 @@ delete_insn_chain (rtx start, rtx finish, bool clear_bb)
   else
delete_insn (current);
 
-  if (clear_bb && !INSN_DELETED_P (current))
+  if (clear_bb && !current->deleted ())
set_block_for_insn (current, NULL);
 
   if (current == start)
@@ -3278,7 +3278,7 @@ fixup_abnormal_edges (void)
  if (GET_CODE (PATTERN (insn)) != USE)
{
  /* We're not deleting it, we're moving it.  */
- INSN_DELETED_P (insn) = 0;
+ insn->set_undeleted ();
  SET_PREV_INSN (insn) = NULL_RTX;
  SET_NEXT_INSN (insn) = NULL_RTX;
 
diff --git a/gcc/combine.c b/gcc/combine.c
index 60524b5..67fd5b1 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1238,7 +1238,7 @@ combine_instructions (rtx_insn *f, unsigned int nregs)
continue;
 
  while (last_combined_insn
-&& INSN_DELETED_P (last_combined_insn))
+&& last_combined_insn->deleted ())
last_combined_insn = PREV_INSN (last_combined_insn);
  if (last_combined_insn == NULL_RTX
  || BARRIER_P (last_combined_insn)
diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 7cddab7..89d0c11 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -8624,7 +8624,7 @@ arc_unalign_branch_p (rtx branch)
 return 0;
   /* Do not do this if we have a filled delay slot.  */
   if (get_attr_delay_slot_filled (branch) == DELAY_SLOT_FILLED_YES
-  && !INSN_DELETED_P (NEXT_INSN (branch)))
+  && !NEXT_INSN (branch)->deleted ())
 return 0;
   note = find_reg_note (branch, REG_BR_PROB, 0);
   return (!note
@@ -8705,7 +8705,7 @@ arc_pad_return (void)
  rtx save_pred = current_insn_predicate;
  final_scan_insn (prev, asm_out_file, optimize, 1, NULL);
  cfun->machine->force_short_suffix = -1;
- INSN_DELETED_P (prev) = 1;
+ prev->set_deleted ();
  current_output_insn = insn;
  current_insn_predicate = save_pred;
}
diff --git a/gcc/config/mcore/mcore.c b/gcc/config/mcore/mcore.c
index aad0f1a..e2208b7 100644
--- a/gcc/config/mcore/mcore.c
+++ b/gcc/config/mcore/mcore.c
@@ -2536,7 +2536,7 @@ conditionalize_block (rtx_insn *first)
 {
   rtx_insn *newinsn;
 
-  if (INSN_DELETED_P (insn))
+  if (insn->deleted ())
continue;
   
   /* Try to form a conditional variant of the instruction and emit it.  */
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 6370304..28e47d2 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -34184,7 +34184,7 @@ replace_swap_with_copy (swap_web_entry *insn_entry, 
unsigned i)
 
   df_insn_delete (insn);
   remove_insn (insn);
-  INSN_DELETED_P (insn) = 1;
+  insn->set_deleted ();
 }
 
 /* Dump the swap table to DUMP_FILE.  */
diff --git 

Re: [PATCH v2 AArch64]: Re: [PATCH AArch64]: Add constraint letter for stack_protect_test pattern.

[Marcus Shawcroft]

On 4 September 2014 19:19, Venkataramanan Kumar
 wrote:
> Hi James,
>
> Yes we can just mark operand 3 as "&r".
>
> PFB, the updated patch.   Ok for trunk?
>
> regards,
> Venkat.
>
> gcc/ChangeLog
>
> 2014-09-04 Venkataramanan Kumar 
>
>   * config/aarch64/aarch64.md (stack_protect_test_) Add register
>   constraint for operand 0 and remove write only constraint from operand 
> 3.

OK include pr63190 in the ChangeLog entry and backport to 4.9 please.
Thanks
/Marcus

Re: [Patch, libgfortran, 4.5] PR25561, 37754: New low level I/O library

[Thomas Schwinge]

Hi!

On Tue, 06 Jan 2009 00:10:02 +0200, Janne Blomqvist  
wrote:
> attached is a substantially reworked low level I/O library for gfortran.
> [...]

Due to a recent improvement in GCC, it is now pointing out an issue in
the following code:

> 2009-01-05  Janne Blomqvist  
> 
> PR libfortran/25561 libfortran/37754
>   * [...]

> --- a/libgfortran/io/transfer.c
> +++ b/libgfortran/io/transfer.c
> [...]
>if ((dtp->common.flags & IOPARM_DT_HAS_SIZE) != 0)
> -dtp->u.p.size_used += (GFC_IO_INT) nread;
> +dtp->u.p.size_used += (GFC_IO_INT) *nbytes;
>  
> -  if (nread != *nbytes)
> -{  /* Short read, this shouldn't happen.  */
> -  if (likely (dtp->u.p.current_unit->pad_status == PAD_YES))
> -   *nbytes = nread;
> -  else
> +  if (norig != *nbytes)
> +{  
> +  /* Short read, this shouldn't happen.  */
> +  if (!dtp->u.p.current_unit->pad_status == PAD_YES)
> {
>   generate_error (&dtp->common, LIBERROR_EOR, NULL);
>   source = NULL;
> }
>  }
>  
> -  dtp->u.p.current_unit->strm_pos += (gfc_offset) nread;
> +  dtp->u.p.current_unit->strm_pos += (gfc_offset) *nbytes;
> [...]

../../../source/libgfortran/io/transfer.c: In function 'read_block_form':
../../../source/libgfortran/io/transfer.c:478:46: warning: logical not is 
only applied to the left hand side of comparison [-Wlogical-not-parentheses]
   if (!dtp->u.p.current_unit->pad_status == PAD_YES)
  ^

I assume the following is what is intended, but I have not made an
attempt to verify this:

diff --git libgfortran/io/transfer.c libgfortran/io/transfer.c
index af2932c..710de7a 100644
--- libgfortran/io/transfer.c
+++ libgfortran/io/transfer.c
@@ -475,7 +475,7 @@ read_block_form (st_parameter_dt *dtp, int * nbytes)
   if (norig != *nbytes)
 {
   /* Short read, this shouldn't happen.  */
-  if (!dtp->u.p.current_unit->pad_status == PAD_YES)
+  if (!(dtp->u.p.current_unit->pad_status == PAD_YES))
{
  generate_error (&dtp->common, LIBERROR_EOR, NULL);
  source = NULL;


Grüße,
 Thomas


pgpL5hMpJ4rVT.pgp
Description: PGP signature

RE: [PATCH] RE: gcc parallel make check

[VandeVondele Joost]

>> > Please sort the letters (LC_ALL=C sort) and where consecutive, use ranges.
>> > Thus \[0-9A-Zhjqvx-z\]*

OK, works fine with the attached patch, and looks cleaner in Make-lang.in.

Now, with the proper email address for gcc-patches... I wonder how many time 
I'll be punished for typos.

unmodified CL.

Joost



Index: contrib/generate_tcl_patterns.sh
===
--- contrib/generate_tcl_patterns.sh	(revision 0)
+++ contrib/generate_tcl_patterns.sh	(revision 0)
@@ -0,0 +1,108 @@
+#! /bin/sh
+
+#
+# based on a list of filenames as input,
+# generate regexps that match subsets trying to not exceed a
+# 'maxcount' parameter. Most useful to generate the
+# check_LANG_parallelize assignments needed to split
+# testsuite directories, defining prefix appropriately.
+#
+# Example usage:
+#   cd gcc/gcc/testsuite/gfortran.dg
+#   ls -1 | ../../../contrib/generate_tcl_patterns.sh 300 "dg.exp=gfortran.dg/"
+#
+# the first parameter is the maximum number of files.
+# the second parameter the prefix used for printing.
+#
+
+# Copyright (C) 2014 Free Software Foundation
+# Contributed by Joost VandeVondele 
+#
+# This file is part of GCC.
+#
+# GCC 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.
+#
+# GCC 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 GCC; see the file COPYING.  If not, write to
+# the Free Software Foundation, 51 Franklin Street, Fifth Floor,
+# Boston, MA 02110-1301, USA.
+
+gawk -v maxcount=$1 -v prefix=$2 '
+BEGIN{
+  # list of allowed starting chars for a file name in a dir to split
+  achars="0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
+  ranget="112233"
+}
+{
+  nfiles++ ; files[nfiles]=$1
+}
+END{
+  for(i=1; i<=length(achars); i++) count[substr(achars,i,1)]=0
+  for(i=1; i<=nfiles; i++) {
+ if (length(files[i]>0)) { count[substr(files[i],1,1)]++ }
+  };
+  asort(count,ordered)
+  countsingle=0
+  groups=0
+  label=""
+  for(i=length(achars);i>=1;i--) {
+countsingle=countsingle+ordered[i] 
+for(j=1;j<=length(achars);j++) {
+   if(count[substr(achars,j,1)]==ordered[i]) found=substr(achars,j,1)
+}
+count[found]=-1
+label=label found
+if(i==1) { val=maxcount+1 } else { val=ordered[i-1] }
+if(countsingle+val>maxcount) {
+  subset[label]=countsingle
+  print "Adding label: ", label, "matching files:" countsingle
+  groups++
+  countsingle=0
+  label=""
+}
+  }
+  print "patterns:"
+  asort(subset,ordered)
+  for(i=groups;i>=1;i--) {
+for(j in subset){
+  if(subset[j]==ordered[i]) found=j
+}
+subset[found]=-1
+if (length(found)==1) {
+   printf("%s%s* \\\n",prefix,found)
+} else {
+   sortandcompress()
+   printf("%s\\[%s\\]* \\\n",prefix,found)
+}
+  }
+}
+function sortandcompress(i,n,tmp,bestj)
+{
+  n=length(found)
+  for(i=1; i<=n; i++) tmp[i]=substr(found,i,1) 
+  asort(tmp)
+  for(i=1;i<=n;i++){
+ipos=index(achars,tmp[i])
+for(j=i;j<=n;j++){
+  jpos=index(achars,tmp[j])
+  if (jpos-ipos==j-i && substr(ranget,ipos,1)==substr(ranget,jpos,1)) bestj=j
+}
+if (bestj-i>3) {
+  tmp[i+1]="-" 
+  for(j=i+2;j

Re: [PATCH][2/2] Sanity check removed loops

[Andreas Schwab]

Richard Biener  writes:

> 2014-09-05  Richard Biener  
>
>   * cfgloop.c (mark_loop_for_removal): Record former header
>   when ENABLE_CHECKING.
>   * cfgloop.h (strut loop): Add former_header member when
>   ENABLE_CHECKING.
>   * loop-init.c (fix_loop_structure): Sanity check loops
>   marked for removal if they re-appeared.

In file included from ../../gcc/ggc.h:34:0,
 from ../../gcc/hash-table.h:199,
 from ../../gcc/hash-set.h:24,
 from ../../gcc/tree-core.h:24,
 from ../../gcc/tree.h:23,
 from gtype-desc.c:30:
gtype-desc.c: In function 'void gt_ggc_mx_loop(void*)':
gtype-desc.c:887:40: error: 'struct loop' has no member named 'former_header'
   gt_ggc_m_15basic_block_def ((*x).former_header);
^

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[gomp4] Revert more old Makefile/configure bits

[Bernd Schmidt]

This removes some remnants from the accel-gcc support that turned out 
not to be viable for ptx. Ilya Verbin has confirmed the patch doesn't 
break their setup either, so I've committed it on the branch.



Bernd
Index: ChangeLog.gomp
===
--- ChangeLog.gomp	(revision 214959)
+++ ChangeLog.gomp	(working copy)
@@ -1,3 +1,11 @@
+2014-09-05  Bernd Schmidt  
+
+	* Makefile.def (host_modules, flags_to_pass): Remove accel-gcc remnants.
+	* configure.ac: Don't call ACX_CANONICAL_ACCEL_TARGET.  Remove
+	target-gcc-configure-flags and accelerator-gcc-configure-flags options.
+	* Makefile.in: Regenerate.
+	* configure: Regenerate.
+
 2014-08-04  Bernd Schmidt  
 
 	* Makefile.def (accel-gcc host module): Remove, and all of its
Index: Makefile.def
===
--- Makefile.def	(revision 214959)
+++ Makefile.def	(working copy)
@@ -44,8 +44,7 @@ host_modules= { module= fixincludes; boo
 host_modules= { module= flex; no_check_cross= true; };
 host_modules= { module= gas; bootstrap=true; };
 host_modules= { module= gcc; bootstrap=true; 
-		extra_configure_flags='@extra_target_gcc_configure_flags@';
-		extra_make_flags="$(EXTRA_GCC_FLAGS) $(EXTRA_TARGET_GCC_FLAGS)"; };
+		extra_make_flags="$(EXTRA_GCC_FLAGS)"; };
 host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
 		extra_configure_flags='--disable-shared';
 		no_install= true;
@@ -221,7 +220,6 @@ flags_to_pass = { flag= sysconfdir ; };
 flags_to_pass = { flag= tooldir ; };
 flags_to_pass = { flag= build_tooldir ; };
 flags_to_pass = { flag= target_alias ; };
-flags_to_pass = { flag= accel_target_alias ; };
 
 // Build tools
 flags_to_pass = { flag= AWK ; };
Index: Makefile.in
===
--- Makefile.in	(revision 214959)
+++ Makefile.in	(working copy)
@@ -705,7 +705,6 @@ BASE_FLAGS_TO_PASS = \
 	"tooldir=$(tooldir)" \
 	"build_tooldir=$(build_tooldir)" \
 	"target_alias=$(target_alias)" \
-	"accel_target_alias=$(accel_target_alias)" \
 	"AWK=$(AWK)" \
 	"BISON=$(BISON)" \
 	"CC_FOR_BUILD=$(CC_FOR_BUILD)" \
@@ -10100,7 +10099,7 @@ configure-gcc:
 	  $$s/$$module_srcdir/configure \
 	  --srcdir=$${topdir}/$$module_srcdir \
 	  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
-	  --target=$${this_target} @extra_target_gcc_configure_flags@ \
+	  --target=$${this_target}  \
 	  || exit 1
 @endif gcc
 
@@ -10135,8 +10134,7 @@ configure-stage1-gcc:
 	  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
 	  --target=${target_alias} \
 	   \
-	  $(STAGE1_CONFIGURE_FLAGS) \
-	  @extra_target_gcc_configure_flags@
+	  $(STAGE1_CONFIGURE_FLAGS)
 @endif gcc-bootstrap
 
 .PHONY: configure-stage2-gcc maybe-configure-stage2-gcc
@@ -10169,8 +10167,7 @@ configure-stage2-gcc:
 	  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
 	  --target=${target_alias} \
 	   --with-build-libsubdir=$(HOST_SUBDIR)  \
-	  $(STAGE2_CONFIGURE_FLAGS) \
-	  @extra_target_gcc_configure_flags@
+	  $(STAGE2_CONFIGURE_FLAGS)
 @endif gcc-bootstrap
 
 .PHONY: configure-stage3-gcc maybe-configure-stage3-gcc
@@ -10203,8 +10200,7 @@ configure-stage3-gcc:
 	  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
 	  --target=${target_alias} \
 	   --with-build-libsubdir=$(HOST_SUBDIR)  \
-	  $(STAGE3_CONFIGURE_FLAGS) \
-	  @extra_target_gcc_configure_flags@
+	  $(STAGE3_CONFIGURE_FLAGS)
 @endif gcc-bootstrap
 
 .PHONY: configure-stage4-gcc maybe-configure-stage4-gcc
@@ -10237,8 +10233,7 @@ configure-stage4-gcc:
 	  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
 	  --target=${target_alias} \
 	   --with-build-libsubdir=$(HOST_SUBDIR)  \
-	  $(STAGE4_CONFIGURE_FLAGS) \
-	  @extra_target_gcc_configure_flags@
+	  $(STAGE4_CONFIGURE_FLAGS)
 @endif gcc-bootstrap
 
 .PHONY: configure-stageprofile-gcc maybe-configure-stageprofile-gcc
@@ -10271,8 +10266,7 @@ configure-stageprofile-gcc:
 	  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
 	  --target=${target_alias} \
 	   --with-build-libsubdir=$(HOST_SUBDIR)  \
-	  $(STAGEprofile_CONFIGURE_FLAGS) \
-	  @extra_target_gcc_configure_flags@
+	  $(STAGEprofile_CONFIGURE_FLAGS)
 @endif gcc-bootstrap
 
 .PHONY: configure-stagefeedback-gcc maybe-configure-stagefeedback-gcc
@@ -10305,8 +10299,7 @@ configure-stagefeedback-gcc:
 	  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
 	  --target=${target_alias} \
 	   --with-build-libsubdir=$(HOST_SUBDIR)  \
-	  $(STAGEfeedback_CONFIGURE_FLAGS) \
-	  @extra_target_gcc_configure_flags@
+	  $(STAGEfeedback_CONFIGURE_FLAGS)
 @endif gcc-bootstrap
 
 
@@ -10326,7 +10319,7 @@ all-gcc: configure-gcc
 	s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
 	$(HOST_EXPORTS)  \
 	(cd $(HOST_SUBDIR)/gcc && \
-	  $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) $(STAGE1_FLAGS_TO_PASS) $(EXTRA_GCC_FLAGS) $(EXTRA_TARGET_GCC_FLAGS) \
+	  $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTR

Re: [PATCH 1/2] add staticly checked label_nuses accessors

[Jeff Law]

On 09/05/14 09:32, tsaund...@mozilla.com wrote:

From: Trevor Saunders 

Hi,

  Doing this means we get to remove a fair chunk of runtime checking.

bootstrapped + regtested on x86_64-unknown-linux-gnu with no regressions.
config-list.mk with this and the next patch is ongoing. ok?

Trev

gcc/

* config/i386/i386.c, config/i386/i386.md, config/mep/mep.c,
config/mips/mips.c, config/nios2/nios2.c, config/s390/s390.c,
config/sh/sh.c, reorg.c: Use rtx_code_label::nuses and
rtx_code_label::set_nuses where possible.
* rtl.h (rtx_code_label::nuses): New member function.
(rtx_code_label::set_nuses): Likewise.
Is there some reason why we don't fix every reference to LABEL_NUSES to 
use the new member functions?  My concern here is that we've now got two 
ways actively used to get at that information, the old LABEL_NUSES and 
the new member functions.  Obviously we really just want one blessed way 
to get/set that information.  If this is a short term situation, then 
I'd be inclined to say OK, but I don't see further patches which sort 
out the ~200 or so LABEL_NUSES users.


THe approach David has taken for similar situations has been to first 
introduce the get/set methods, convert everything to set the get/set 
method, dealing with the type fallout that occurrs around that, then 
collapsing back to the old macro.  Is there some reason we can not or 
should not do that here?


jeff

Re: [PATCH 2/2] add static typed insn_deleted_p

[Jeff Law]

On 09/05/14 09:32, tsaund...@mozilla.com wrote:

From: Trevor Saunders 

Hi,
Same idea as the last patch.

also bootstrapped and regtested on x86_64-unknown-linux-gnu with config-list.mk
ongoing ok?


Trev

gcc/

* cfgrtl.c, combine.c, config/arc/arc.c, config/mcore/mcore.c,
config/rs6000/rs6000.c, config/sh/sh.c, cprop.c, dwarf2out.c,
emit-rtl.c, final.c, function.c, gcse.c, jump.c, reg-stack.c,
reload1.c, reorg.c, resource.c, sel-sched-ir.c: Replace INSN_DELETED_P
macro with staticly checked member functions.
* rtl.h (rtx_insn::deleted): New method.
(rtx_insn::set_deleted): Likewise.
(rtx_insn::set_undeleted): Likewise.
So in a similar manner, is there some reason that we continue to have 
INSN_DELETED_P as a macro?  Can we get to a point where either we don't 
have the macro because everything has been converted?  What's the plan 
for getting there?



jeff

Re: Vimrc config with GNU formatting

[Bernhard Reutner-Fischer]

On 5 September 2014 17:10, Yury Gribov  wrote:

> Now I don't quite like the idea of plugin:
> * .local.vimrc setting is more compatible with what we already have for
> Emacs
> * gcc_style.vim won't work for new files (it requires GCC license agreement)

true

> * gcc_style.vim enables GNU style globally, for all projects

How come? Please explain?
>
> IMHO localrc plugin is widespread enough that we can rely on it.

Sure.
>
>> This automatically applies the "gcc style" if the first 25 lines of the
>> file being opened contains the syndicated "This file is part of GCC" so
>> should transparently not set GNU style on foreign stuff like sanitizer.
>
>
> But as I mentioned also disables formatting for all new files.

Yes, you could if match(expand('%:p:h'), "gcc") != -1
or something like that but that's not pretty and robust either.

So I suppose the localrc idea is fine

cheers,

Re: [PATCH][2/2] Sanity check removed loops

[Jeff Law]

On 09/05/14 04:00, Richard Biener wrote:


The following patch adds sanity checking for loops removed
via mark_loop_for_removal or fix_loop_structure to check
whether they reappear in the same place.

The simplest case is where the loop header stays the same
and we definitely should avoid all these cases.

The other case is where the old header becomes part of
a newly discovered loop.  That happens when you rotate
a loop for example.

The interesting bits of this are the new former_header field
in struct loop which holds onto the old header basic-block
so that even when it gets discarded its memory will not be
reused.  For the sanity checking we can then verify if
it is still a basic-block in the current function.

In theory we might be able to "autodetect" some loop
rotation cases as well as "restore" bogusly removed loops.
I'll see what the best solution is here after I (or somebody
else) has some testcases to look at.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

2014-09-05  Richard Biener  

* cfgloop.c (mark_loop_for_removal): Record former header
when ENABLE_CHECKING.
* cfgloop.h (strut loop): Add former_header member when
ENABLE_CHECKING.
* loop-init.c (fix_loop_structure): Sanity check loops
marked for removal if they re-appeared.

Thanks for taking care of this

Jeff

Re: Migrating gcc.c-torture

[Mike Stump]

On Sep 5, 2014, at 3:10 AM, Thomas Schwinge  wrote:
> Should PR20567 now be updated?

Updated.

Re: [PATCH 1/2] add staticly checked label_nuses accessors

[Trevor Saunders]

On Fri, Sep 05, 2014 at 10:43:45AM -0600, Jeff Law wrote:
> On 09/05/14 09:32, tsaund...@mozilla.com wrote:
> >From: Trevor Saunders 
> >
> >Hi,
> >
> >  Doing this means we get to remove a fair chunk of runtime checking.
> >
> >bootstrapped + regtested on x86_64-unknown-linux-gnu with no regressions.
> >config-list.mk with this and the next patch is ongoing. ok?
> >
> >Trev
> >
> >gcc/
> >
> > * config/i386/i386.c, config/i386/i386.md, config/mep/mep.c,
> > config/mips/mips.c, config/nios2/nios2.c, config/s390/s390.c,
> > config/sh/sh.c, reorg.c: Use rtx_code_label::nuses and
> > rtx_code_label::set_nuses where possible.
> > * rtl.h (rtx_code_label::nuses): New member function.
> > (rtx_code_label::set_nuses): Likewise.
> Is there some reason why we don't fix every reference to LABEL_NUSES to use
> the new member functions?  My concern here is that we've now got two ways

 The reason I left some as is was because we didn't already have an
 rtx_code_label * there, so I was going to handle those later.  Though
 actually I guess we could adjust the macro to be

 #define LABEL_NUSES(l) as_a (l)->nuses ()

Whcih also has the advantage it doesn't compile if you pass in an
rtx_code_label *, and so you need to change to the newer form.

> actively used to get at that information, the old LABEL_NUSES and the new
> member functions.  Obviously we really just want one blessed way to get/set
> that information.  If this is a short term situation, then I'd be inclined
> to say OK, but I don't see further patches which sort out the ~200 or so
> LABEL_NUSES users.

because they haven't been written yet :) but I'd expect as types are
made more specific that situation will get better.

> THe approach David has taken for similar situations has been to first
> introduce the get/set methods, convert everything to set the get/set method,
> dealing with the type fallout that occurrs around that, then collapsing back
> to the old macro.  Is there some reason we can not or should not do that
> here?

I'd say we're doing the first parts of that here, but its not complete
yet.  That is I added the getters, and converted some but not all users
over.  There's certainly more patches to write though.

yes, basically the same thing is true for the other patch though we may
be much closer to finishing that conversion.

Trev

> 
> jeff
> 

Remove no-longer-needed fp-bit target macros

[Joseph S. Myers]

This patch removes some fp-bit target macros that are no longer
needed:

* __make_dp was not really designed as a target macro, but CRIS
  defined it in cris.h anyway for optimization purposes (so making it
  show up on lists of target macros).  Since CRIS no longer uses
  fp-bit, that definition is no longer needed.

* There were no non-default definitions of ROUND_TOWARDS_ZERO.

* There were no valid non-default definitions of
  LARGEST_EXPONENT_IS_NORMAL.  (One definition present for ARM to
  handle half-precision treated it as if it were a host-side macro,
  referring to definitions only present in host-side code, but this
  macro is only used in code built for the target, not the host.  In
  any case, fp-bit does not support half-precision, and as far as I
  can tell no ARM targets use fp-bit.)

The latter two macros are poisoned by this patch; it doesn't seem
worth poisoning the first given it wasn't intended as a target macro
anyway.

Note there is still plenty more dead code in fp-bit that's outside the
scope of the present patch series cleaning up uses of host-side target
macros in target-side code.  Specifically, all the TFmode support is
dead (both IEEE binary128 and IBM long double); fp-bit is only used
for SFmode and DFmode now.  (IBM long double support in fp-bit became
dead when the IRIX port was removed, binary128 support when MIPS
GNU/Linux moved to using soft-fp.)

Tested with no regressions with cross to powerpc-none-eabi.  OK to
commit?

gcc:
2014-09-05  Joseph Myers  

* defaults.h (LARGEST_EXPONENT_IS_NORMAL, ROUND_TOWARDS_ZERO):
Remove.
* doc/tm.texi.in (ROUND_TOWARDS_ZERO, LARGEST_EXPONENT_IS_NORMAL):
Remove.
* doc/tm.texi: Regenerate.
* system.h (LARGEST_EXPONENT_IS_NORMAL, ROUND_TOWARDS_ZERO):
Poison.
* config/arm/arm.h (LARGEST_EXPONENT_IS_NORMAL): Remove.
* config/cris/cris.h (__make_dp): Remove.

libgcc:
2014-09-05  Joseph Myers  

* fp-bit.c (pack_d, unpack_d): Remove LARGEST_EXPONENT_IS_NORMAL
and ROUND_TOWARDS_ZERO conditionals.

Index: gcc/config/arm/arm.h
===
--- gcc/config/arm/arm.h(revision 214954)
+++ gcc/config/arm/arm.h(working copy)
@@ -440,9 +440,6 @@ extern int arm_fpu_attr;
 #define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
 #endif
 
-#define LARGEST_EXPONENT_IS_NORMAL(bits) \
-((bits) == 16 && arm_fp16_format == ARM_FP16_FORMAT_ALTERNATIVE)
-
 #ifndef ARM_DEFAULT_ABI
 #define ARM_DEFAULT_ABI ARM_ABI_APCS
 #endif
Index: gcc/config/cris/cris.h
===
--- gcc/config/cris/cris.h  (revision 214954)
+++ gcc/config/cris/cris.h  (working copy)
@@ -80,15 +80,7 @@ along with GCC; see the file COPYING3.  If not see
 /* Which CPU version this is.  The parsed and adjusted cris_cpu_str.  */
 extern int cris_cpu_version;
 
-/* Changing the order used to be necessary to put the fourth __make_dp
-   argument (a DImode parameter) in registers, to fit with the libfunc
-   parameter passing scheme used for intrinsic functions.  FIXME: Check
-   performance.  */
-#ifdef IN_LIBGCC2
-#define __make_dp(a,b,c,d) __cris_make_dp(d,a,b,c)
-#endif
 
-
 /* Node: Driver */
 
 /* Also provide canonical vN definitions when user specifies an alias.  */
Index: gcc/defaults.h
===
--- gcc/defaults.h  (revision 214954)
+++ gcc/defaults.h  (working copy)
@@ -926,14 +926,6 @@ see the files COPYING3 and COPYING.RUNTIME respect
 #define PREFERRED_DEBUGGING_TYPE NO_DEBUG
 #endif
 
-#ifndef LARGEST_EXPONENT_IS_NORMAL
-#define LARGEST_EXPONENT_IS_NORMAL(SIZE) 0
-#endif
-
-#ifndef ROUND_TOWARDS_ZERO
-#define ROUND_TOWARDS_ZERO 0
-#endif
-
 #ifndef FLOAT_LIB_COMPARE_RETURNS_BOOL
 #define FLOAT_LIB_COMPARE_RETURNS_BOOL(MODE, COMPARISON) false
 #endif
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 214954)
+++ gcc/doc/tm.texi (working copy)
@@ -1341,27 +1341,6 @@ Return machine mode to be used for @code{_Unwind_W
 The default is to use @code{word_mode}.
 @end deftypefn
 
-@defmac ROUND_TOWARDS_ZERO
-If defined, this macro should be true if the prevailing rounding
-mode is towards zero.
-
-Defining this macro only affects the way @file{libgcc.a} emulates
-floating-point arithmetic.
-
-Not defining this macro is equivalent to returning zero.
-@end defmac
-
-@defmac LARGEST_EXPONENT_IS_NORMAL (@var{size})
-This macro should return true if floats with @var{size}
-bits do not have a NaN or infinity representation, but use the largest
-exponent for normal numbers instead.
-
-Defining this macro only affects the way @file{libgcc.a} emulates
-floating-point arithmetic.
-
-The default definition of this macro returns false for all sizes.
-@end defmac
-
 @deftypefn {Target Hook} bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree 
@var{rec

Re: Vimrc config with GNU formatting

[Segher Boessenkool]

On Fri, Sep 05, 2014 at 07:10:02PM +0400, Yury Gribov wrote:
> Now I don't quite like the idea of plugin:

Anything that will make this enabled automatically will meet a lot of
resistance.  Make something nice for contrib/ instead?


Segher

Encode Wnormalized= is c.opt

[Manuel López-Ibáñez]

This patch moves handling of Wnormalized= to c.opt.

There were two quirks when doing this:

1) I cannot use the cpplib.h type 'enum cpp_normalize_level' as Type()
because this will require including cpplib.h into options.h, which in
turn causes a lot of problems, thus I needed to use Type(int).
Similarly, I cannot use this type in the CPP option warn_normalize,
because C++ does not allow conversions from int to this enum.

2) The code in c_common_handle_option seems to say that -Wnormalized=
is equivalent to -Wnormalized=nfkc. However, -Wnormalized= was already
rejected as not valid. Moreover, it emits a note for
-Werror=normalized= saying that it is equivalent to -Wnormalized=nfc,
however, this note is never actually emitted since the code never
reaches that condition, so I chose to not even try to replicate the
note or allow -Wnormalized=. Surprisingly, -Werror=normalized= was
already equivalent to what -Werror=normalized would do, but
-Werror=normalized was rejected because -Wnormalized did not exist.
Thus, I added -Wnormalized to handle this corner case.

In summary, after the patch the only behavior changes are that
-Werror=normalized, -Wnormalized and -Wno-normalized work.

Bootstrapped and regression tested on x86_64-linux-gnu

OK?


gcc/ChangeLog:

2014-09-05  Manuel López-Ibáñez  

* doc/invoke.texi (Wnormalized=): Update.

libcpp/ChangeLog:

2014-09-05  Manuel López-Ibáñez  

* include/cpplib.h (struct cpp_options): Declare warn_normalize as
int instead of enum.

gcc/c-family/ChangeLog:

2014-09-05  Manuel López-Ibáñez  

* c.opt(Wnormalized): New.
(Wnormalized=): Use Enum and Reject Negative.
* c-opts.c (c_common_handle_option): Do not handle Wnormalized here.

gcc/testsuite/ChangeLog:

2014-09-05  Manuel López-Ibáñez  

* gcc.dg/cpp/warn-normalized-3.c: Delete useless dg-prune-output.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 214904)
+++ gcc/doc/invoke.texi (working copy)
@@ -260,11 +260,12 @@ Objective-C and Objective-C++ Dialects}.
 -Wno-int-to-pointer-cast -Wno-invalid-offsetof @gol
 -Winvalid-pch -Wlarger-than=@var{len}  -Wunsafe-loop-optimizations @gol
 -Wlogical-op -Wlogical-not-parentheses -Wlong-long @gol
 -Wmain -Wmaybe-uninitialized -Wmemset-transposed-args -Wmissing-braces @gol
 -Wmissing-field-initializers -Wmissing-include-dirs @gol
--Wno-multichar  -Wnonnull  -Wodr  -Wno-overflow  -Wopenmp-simd @gol
+-Wno-multichar  -Wnonnull  -Wnormalized=@r{[}none@r{|}id@r{|}nfc@r{|}nfkc@r{]} 
@gol
+ -Wodr  -Wno-overflow  -Wopenmp-simd @gol
 -Woverlength-strings  -Wpacked  -Wpacked-bitfield-compat  -Wpadded @gol
 -Wparentheses  -Wpedantic-ms-format -Wno-pedantic-ms-format @gol
 -Wpointer-arith  -Wno-pointer-to-int-cast @gol
 -Wredundant-decls  -Wno-return-local-addr @gol
 -Wreturn-type  -Wsequence-point  -Wshadow  -Wno-shadow-ivar @gol
@@ -4918,12 +4919,14 @@ warnings without this one, use @option{-
 @opindex Wmultichar
 Do not warn if a multicharacter constant (@samp{'FOOF'}) is used.
 Usually they indicate a typo in the user's code, as they have
 implementation-defined values, and should not be used in portable code.
 
-@item -Wnormalized=
+@item -Wnormalized@r{[}=@r{<}none@r{|}id@r{|}nfc@r{|}nfkc@r{>]}
 @opindex Wnormalized=
+@opindex Wnormalized
+@opindex Wno-normalized
 @cindex NFC
 @cindex NFKC
 @cindex character set, input normalization
 In ISO C and ISO C++, two identifiers are different if they are
 different sequences of characters.  However, sometimes when characters
@@ -4935,24 +4938,26 @@ the same sequence.  GCC can warn you if
 have not been normalized; this option controls that warning.
 
 There are four levels of warning supported by GCC@.  The default is
 @option{-Wnormalized=nfc}, which warns about any identifier that is
 not in the ISO 10646 ``C'' normalized form, @dfn{NFC}.  NFC is the
-recommended form for most uses.
+recommended form for most uses.  It is equivalent to
+@option{-Wnormalized}.
 
 Unfortunately, there are some characters allowed in identifiers by
 ISO C and ISO C++ that, when turned into NFC, are not allowed in 
 identifiers.  That is, there's no way to use these symbols in portable
 ISO C or C++ and have all your identifiers in NFC@.
 @option{-Wnormalized=id} suppresses the warning for these characters.
 It is hoped that future versions of the standards involved will correct
 this, which is why this option is not the default.
 
 You can switch the warning off for all characters by writing
-@option{-Wnormalized=none}.  You should only do this if you
-are using some other normalization scheme (like ``D''), because
-otherwise you can easily create bugs that are literally impossible to see.
+@option{-Wnormalized=none} or @option{-Wno-normalized}.  You should
+only do this if you are using some other normalization scheme (like
+``D''), because otherwise you can easily create bugs that are
+literally impossible to see.
 
 Some characters in ISO 1

auto generate cpp_reason to gcc OPT_W table

[Manuel López-Ibáñez]

This adds a new option property CppReason which maps to a warning
reason code in cpplib.h. This allows us to auto-generate
cpp_reason_option_codes[], which maps from CPP warning codes to GCC
ones, thus making a bit harder to forget to update this table (which
evidently has happened a lot in the past).

Unfortunately, to use cpp warning codes we need to include cpplib.h in
options.h and this would conflict with other parts of the compiler,
thus I protect the table with #ifdef GCC_C_COMMON_H, and make sure in
c-common.c that cpplib.h is not included before c-common.h.

This patch applies on top of the previous patch about Wnormalized= but
it is mostly independent of it.

Bootstrapped and regression tested on x86_64-linux-gnu

OK?

gcc/ChangeLog:

2014-09-05  Manuel López-Ibáñez  

* opth-gen.awk: Generate mapping from cpp message reasons to the
options that enable them.
* doc/options.texi (CppReason): Document.

gcc/c-family/ChangeLog:

2014-09-05  Manuel López-Ibáñez  

* c.opt: Add CppReason to various flags.
(Wdate-time): Re-sort.
* c-common.c: Include c-common.h earlier.
(struct reason_option_codes_t): Delete.
(c_option_controlling_cpp_error): Prefix global type and struct
with cpp_.
Index: gcc/doc/options.texi
===
--- gcc/doc/options.texi(revision 214904)
+++ gcc/doc/options.texi(working copy)
@@ -486,6 +486,11 @@ to determine if a precompiled header fil
 @item CPP(@var{var})
 The state of this option should be kept in sync with the preprocessor
 option @var{var}.  If this property is set, then properties @code{Var}
 and @code{Init} must be set as well.
 
+@item CppReason(@var{CPP_W_Enum})
+This warning option corresponds to @code{cpplib.h} warning reason code
+@var{CPP_W_Enum}.  This should only be used for warning options of the
+C-family front-ends.
+
 @end table
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt  (revision 214904)
+++ gcc/c-family/c.opt  (working copy)
@@ -290,23 +290,23 @@ Warn about casting functions to incompat
 Wbool-compare
 C ObjC C++ ObjC++ Var(warn_bool_compare) Warning LangEnabledBy(C ObjC C++ 
ObjC++,Wall)
 Warn about boolean expression compared with an integer value different from 
true/false
 
 Wbuiltin-macro-redefined
-C ObjC C++ ObjC++ CPP(warn_builtin_macro_redefined) 
Var(cpp_warn_builtin_macro_redefined) Init(1) Warning
+C ObjC C++ ObjC++ CPP(warn_builtin_macro_redefined) 
CppReason(CPP_W_BUILTIN_MACRO_REDEFINED) Var(cpp_warn_builtin_macro_redefined) 
Init(1) Warning
 Warn when a built-in preprocessor macro is undefined or redefined
 
 Wc90-c99-compat
-C ObjC CPP(cpp_warn_c90_c99_compat) Var(warn_c90_c99_compat) Init(-1) Warning
+C ObjC CPP(cpp_warn_c90_c99_compat) CppReason(CPP_W_C90_C99_COMPAT) 
Var(warn_c90_c99_compat) Init(-1) Warning
 Warn about features not present in ISO C90, but present in ISO C99
 
 Wc99-c11-compat
 C ObjC Var(warn_c99_c11_compat) Init(-1) Warning
 Warn about features not present in ISO C99, but present in ISO C11
 
 Wc++-compat
-C ObjC Var(warn_cxx_compat) CPP(warn_cxx_operator_names) Init(0) Warning
+C ObjC Var(warn_cxx_compat) CPP(warn_cxx_operator_names) 
CppReason(CPP_W_CXX_OPERATOR_NAMES) Init(0) Warning
 Warn about C constructs that are not in the common subset of C and C++
 
 Wc++0x-compat
 C++ ObjC++ Var(warn_cxx0x_compat) Warning LangEnabledBy(C++ ObjC++,Wall)
 Deprecated in favor of -Wc++11-compat
@@ -326,11 +326,11 @@ Warn about subscripts whose type is \"ch
 Wclobbered
 C ObjC C++ ObjC++ Var(warn_clobbered) Warning EnabledBy(Wextra)
 Warn about variables that might be changed by \"longjmp\" or \"vfork\"
 
 Wcomment
-C ObjC C++ ObjC++ CPP(warn_comments) Var(cpp_warn_comment) Init(0) Warning 
LangEnabledBy(C ObjC C++ ObjC++,Wall)
+C ObjC C++ ObjC++ CPP(warn_comments) CppReason(CPP_W_COMMENTS) 
Var(cpp_warn_comment) Init(0) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall)
 Warn about possibly nested block comments, and C++ comments spanning more than 
one physical line
 
 Wcomments
 C ObjC C++ ObjC++ Warning Alias(Wcomment)
 Synonym for -Wcomment
@@ -345,14 +345,22 @@ Warn for implicit type conversions that
 
 Wconversion-null
 C++ ObjC++ Var(warn_conversion_null) Init(1) Warning
 Warn for converting NULL from/to a non-pointer type
 
+Wcpp
+C ObjC C++ ObjC++ CppReason(CPP_W_WARNING_DIRECTIVE)
+; Documented in common.opt
+
 Wctor-dtor-privacy
 C++ ObjC++ Var(warn_ctor_dtor_privacy) Warning
 Warn when all constructors and destructors are private
 
+Wdate-time
+C ObjC C++ ObjC++ CPP(warn_date_time) CppReason(CPP_W_DATE_TIME) 
Var(cpp_warn_date_time) Init(0) Warning
+Warn about __TIME__, __DATE__ and __TIMESTAMP__ usage
+
 Wdeclaration-after-statement
 C ObjC Var(warn_declaration_after_statement) Init(-1) Warning
 Warn when a declaration is found after a statement
 
 Wdelete-incomplete
@@ -366,11 +374,11 @@ Warn about deleting polymorphic objects
 Wdelete-non

Go patch committed: Use precise type information on the heap

[Ian Lance Taylor]

This patch from Chris Manghane adds support for precise type information
to the gccgo garbage collector.  This is only the first step, as the
compiler does not pass the type information to the allocator in most
cases.  I think that right now the precise type information will only be
available for slices.  Also the precise type information is only ever
available on the heap, not on the stack, and not yet for global
variables.  Still, this is a key first step.

Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.

Ian


2014-09-03  Chris Manghane  

* go-gcc.cc (Gcc_backend::implicit_variable): Remove init
parameter.  Add is_hidden parameter.
(Gcc_backend::implicit_variable_set_init): New method.
(Gcc_backend::implicit_variable_reference): New method.


Index: gcc/go/go-gcc.cc
===
--- gcc/go/go-gcc.cc	(revision 214893)
+++ gcc/go/go-gcc.cc	(revision 214894)
@@ -389,9 +389,16 @@ class Gcc_backend : public Backend
 		 Location, Bstatement**);
 
   Bvariable*
-  implicit_variable(const std::string&, Btype*, Bexpression*, bool, bool,
+  implicit_variable(const std::string&, Btype*, bool, bool, bool,
 		size_t);
 
+  void
+  implicit_variable_set_init(Bvariable*, const std::string&, Btype*,
+			 bool, bool, bool, Bexpression*);
+
+  Bvariable*
+  implicit_variable_reference(const std::string&, Btype*);
+
   Bvariable*
   immutable_struct(const std::string&, bool, bool, Btype*, Location);
 
@@ -2505,45 +2512,101 @@ Gcc_backend::temporary_variable(Bfunctio
 
 Bvariable*
 Gcc_backend::implicit_variable(const std::string& name, Btype* type,
-			   Bexpression* init, bool is_constant,
+			   bool is_hidden, bool is_constant,
 			   bool is_common, size_t alignment)
 {
   tree type_tree = type->get_tree();
-  tree init_tree;
-  if (init == NULL)
-init_tree = NULL_TREE;
-  else
-init_tree = init->get_tree();
-  if (type_tree == error_mark_node || init_tree == error_mark_node)
+  if (type_tree == error_mark_node)
 return this->error_variable();
 
   tree decl = build_decl(BUILTINS_LOCATION, VAR_DECL,
  get_identifier_from_string(name), type_tree);
   DECL_EXTERNAL(decl) = 0;
-  TREE_PUBLIC(decl) = 0;
+  TREE_PUBLIC(decl) = !is_hidden;
   TREE_STATIC(decl) = 1;
+  TREE_USED(decl) = 1;
   DECL_ARTIFICIAL(decl) = 1;
   if (is_common)
 {
   DECL_COMMON(decl) = 1;
-  TREE_PUBLIC(decl) = 1;
-  gcc_assert(init_tree == NULL_TREE);
+
+  // When the initializer for one implicit_variable refers to another,
+  // it needs to know the visibility of the referenced struct so that
+  // compute_reloc_for_constant will return the right value.  On many
+  // systems calling make_decl_one_only will mark the decl as weak,
+  // which will change the return value of compute_reloc_for_constant.
+  // We can't reliably call make_decl_one_only yet, because we don't
+  // yet know the initializer.  This issue doesn't arise in C because
+  // Go initializers, unlike C initializers, can be indirectly
+  // recursive.  To ensure that compute_reloc_for_constant computes
+  // the right value if some other initializer refers to this one, we
+  // mark this symbol as weak here.  We undo that below in
+  // immutable_struct_set_init before calling mark_decl_one_only.
+  DECL_WEAK(decl) = 1;
 }
-  else if (is_constant)
+  if (is_constant)
 {
   TREE_READONLY(decl) = 1;
   TREE_CONSTANT(decl) = 1;
 }
-  DECL_INITIAL(decl) = init_tree;
-
   if (alignment != 0)
 {
   DECL_ALIGN(decl) = alignment * BITS_PER_UNIT;
   DECL_USER_ALIGN(decl) = 1;
 }
 
+  go_preserve_from_gc(decl);
+  return new Bvariable(decl);
+}
+
+// Set the initalizer for a variable created by implicit_variable.
+// This is where we finish compiling the variable.
+
+void
+Gcc_backend::implicit_variable_set_init(Bvariable* var, const std::string&,
+	Btype*, bool, bool, bool is_common,
+	Bexpression* init)
+{
+  tree decl = var->get_tree();
+  tree init_tree;
+  if (init == NULL)
+init_tree = NULL_TREE;
+  else
+init_tree = init->get_tree();
+  if (decl == error_mark_node || init_tree == error_mark_node)
+return;
+
+  DECL_INITIAL(decl) = init_tree;
+
+  // Now that DECL_INITIAL is set, we can't call make_decl_one_only.
+  // See the comment where DECL_WEAK is set in implicit_variable.
+  if (is_common)
+{
+  DECL_WEAK(decl) = 0;
+  make_decl_one_only(decl, DECL_ASSEMBLER_NAME(decl));
+}
+
+  resolve_unique_section(decl, 2, 1);
+
   rest_of_decl_compilation(decl, 1, 0);
+}
+
+// Return a reference to an implicit variable defined in another package.
 
+Bvariable*
+Gcc_backend::implicit_variable_reference(const std::string& name, Btype* btype)
+{
+  tree type_tree = btype->get_tree();
+  if (type_tree == error_mark_node)
+return this->error_variable();
+
+  tree decl 

[PATCH] rs6000: Fix for PR63187

[Segher Boessenkool]

I made a thinko in r214080.  That patch makes the "andi." pattern not match
for insns that can match "rlwinm", and also makes "rlwinm." not match insns
that can match "andi." (and similar for "andis." and "rldicl" etc.)  This
ensures we always choose the cheapest instruction.

However, the splitter for "andi." does not take this into account, and
generates a clobber always, leading to unrecognisable instructions.  This
patch fixes it.

Okay if it survives bootstrap+regcheck?


Segher


2014-09-05  Segher Boessenkool  

PR target/63187
* config/rs6000/rs6000.md (*and3_imm_dot, *and3_imm_dot2):
Do not allow any_mask_operand for operands[2].
(*and3_imm_mask_dot, *and3_imm_mask_dot2): New.


---
 gcc/config/rs6000/rs6000.md | 56 +++--
 1 file changed, 54 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 8f3549e..2df8e41 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -2736,7 +2736,8 @@ (define_insn_and_split "*and3_imm_dot"
(clobber (match_scratch:GPR 0 "=r,r"))
(clobber (match_scratch:CC 4 "=X,x"))]
   "(mode == Pmode || UINTVAL (operands[2]) <= 0x7fff)
-   && rs6000_gen_cell_microcode"
+   && rs6000_gen_cell_microcode
+   && !any_mask_operand (operands[2], mode)"
   "@
andi%e2. %0,%1,%u2
#"
@@ -2763,7 +2764,8 @@ (define_insn_and_split "*and3_imm_dot2"
 (match_dup 2)))
(clobber (match_scratch:CC 4 "=X,x"))]
   "(mode == Pmode || UINTVAL (operands[2]) <= 0x7fff)
-   && rs6000_gen_cell_microcode"
+   && rs6000_gen_cell_microcode
+   && !any_mask_operand (operands[2], mode)"
   "@
andi%e2. %0,%1,%u2
#"
@@ -2780,6 +2782,56 @@ (define_insn_and_split "*and3_imm_dot2"
(set_attr "dot" "yes")
(set_attr "length" "4,8")])
 
+(define_insn_and_split "*and3_imm_mask_dot"
+  [(set (match_operand:CC 3 "cc_reg_operand" "=x,??y")
+   (compare:CC (and:GPR (match_operand:GPR 1 "gpc_reg_operand" "%r,r")
+(match_operand:GPR 2 "logical_const_operand" 
"n,n"))
+   (const_int 0)))
+   (clobber (match_scratch:GPR 0 "=r,r"))]
+  "(mode == Pmode || UINTVAL (operands[2]) <= 0x7fff)
+   && rs6000_gen_cell_microcode
+   && any_mask_operand (operands[2], mode)"
+  "@
+   andi%e2. %0,%1,%u2
+   #"
+  "&& reload_completed && cc_reg_not_cr0_operand (operands[3], CCmode)"
+  [(set (match_dup 0)
+   (and:GPR (match_dup 1)
+(match_dup 2)))
+   (set (match_dup 3)
+   (compare:CC (match_dup 0)
+   (const_int 0)))]
+  ""
+  [(set_attr "type" "logical")
+   (set_attr "dot" "yes")
+   (set_attr "length" "4,8")])
+
+(define_insn_and_split "*and3_imm_mask_dot2"
+  [(set (match_operand:CC 3 "cc_reg_operand" "=x,??y")
+   (compare:CC (and:GPR (match_operand:GPR 1 "gpc_reg_operand" "%r,r")
+(match_operand:GPR 2 "logical_const_operand" 
"n,n"))
+   (const_int 0)))
+   (set (match_operand:GPR 0 "gpc_reg_operand" "=r,r")
+   (and:GPR (match_dup 1)
+(match_dup 2)))]
+  "(mode == Pmode || UINTVAL (operands[2]) <= 0x7fff)
+   && rs6000_gen_cell_microcode
+   && any_mask_operand (operands[2], mode)"
+  "@
+   andi%e2. %0,%1,%u2
+   #"
+  "&& reload_completed && cc_reg_not_cr0_operand (operands[3], CCmode)"
+  [(set (match_dup 0)
+   (and:GPR (match_dup 1)
+(match_dup 2)))
+   (set (match_dup 3)
+   (compare:CC (match_dup 0)
+   (const_int 0)))]
+  ""
+  [(set_attr "type" "logical")
+   (set_attr "dot" "yes")
+   (set_attr "length" "4,8")])
+
 
 (define_insn "*and3_mask"
   [(set (match_operand:GPR 0 "gpc_reg_operand" "=r,r")
-- 
1.8.1.4

Re: [PATCH] rs6000: Fix for PR63187

[David Edelsohn]

On Fri, Sep 5, 2014 at 1:48 PM, Segher Boessenkool
 wrote:
> I made a thinko in r214080.  That patch makes the "andi." pattern not match
> for insns that can match "rlwinm", and also makes "rlwinm." not match insns
> that can match "andi." (and similar for "andis." and "rldicl" etc.)  This
> ensures we always choose the cheapest instruction.
>
> However, the splitter for "andi." does not take this into account, and
> generates a clobber always, leading to unrecognisable instructions.  This
> patch fixes it.
>
> Okay if it survives bootstrap+regcheck?
>
>
> Segher
>
>
> 2014-09-05  Segher Boessenkool  
>
> PR target/63187
> * config/rs6000/rs6000.md (*and3_imm_dot, *and3_imm_dot2):
> Do not allow any_mask_operand for operands[2].
> (*and3_imm_mask_dot, *and3_imm_mask_dot2): New.

Okay.

Thanks, David

C++ PATCH for c++/62659 (rejects-valid with pointer to member function in template)

[Jason Merrill]

potential_constant_expression was getting confused by the (non-constant) 
object argument of the OFFSET_REF, but it isn't really involved in 
calculating the value of the PMF.


Tested x86_64-pc-linux-gnu, applying to trunk and 4.9.
commit cbf61fb5d2ae5db8ff4986e2124105cb899c0037
Author: Jason Merrill 
Date:   Fri Sep 5 11:36:34 2014 -0400

	PR c++/62659
	* semantics.c (potential_constant_expression_1): Handle un-folded
	pointer to member constants.

diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 01748da..776fa26 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -10348,6 +10348,11 @@ potential_constant_expression_1 (tree t, bool want_rval, tsubst_flags_t flags)
 designates an object with thread or automatic storage
 duration;  */
   t = TREE_OPERAND (t, 0);
+
+  if (TREE_CODE (t) == OFFSET_REF && PTRMEM_OK_P (t))
+	/* A pointer-to-member constant.  */
+	return true;
+
 #if 0
   /* FIXME adjust when issue 1197 is fully resolved.  For now don't do
  any checking here, as we might dereference the pointer later.  If
diff --git a/gcc/testsuite/g++.dg/template/ptrmem29.C b/gcc/testsuite/g++.dg/template/ptrmem29.C
new file mode 100644
index 000..7700c0b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/ptrmem29.C
@@ -0,0 +1,10 @@
+// PR c++/62659
+
+struct D {
+  typedef int (D::*cont_func)();
+  template  struct B;
+  template  void wait(B ***);
+
+  int done();
+  template  void fix() { wait<&D::done>(0); }
+};

Re: [PATCH][2/2] Sanity check removed loops

[H.J. Lu]

On Fri, Sep 5, 2014 at 3:00 AM, Richard Biener  wrote:
>
> The following patch adds sanity checking for loops removed
> via mark_loop_for_removal or fix_loop_structure to check
> whether they reappear in the same place.
>
> The simplest case is where the loop header stays the same
> and we definitely should avoid all these cases.
>
> The other case is where the old header becomes part of
> a newly discovered loop.  That happens when you rotate
> a loop for example.
>
> The interesting bits of this are the new former_header field
> in struct loop which holds onto the old header basic-block
> so that even when it gets discarded its memory will not be
> reused.  For the sanity checking we can then verify if
> it is still a basic-block in the current function.
>
> In theory we might be able to "autodetect" some loop
> rotation cases as well as "restore" bogusly removed loops.
> I'll see what the best solution is here after I (or somebody
> else) has some testcases to look at.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> Richard.
>
> 2014-09-05  Richard Biener  
>
> * cfgloop.c (mark_loop_for_removal): Record former header
> when ENABLE_CHECKING.
> * cfgloop.h (strut loop): Add former_header member when
> ENABLE_CHECKING.
> * loop-init.c (fix_loop_structure): Sanity check loops
> marked for removal if they re-appeared.
>

I think it caused:

FAIL: g++.dg/torture/pr57140.C   -O3 -fomit-frame-pointer  (internal
compiler error)
FAIL: g++.dg/torture/pr57140.C   -O3 -fomit-frame-pointer  (test for
excess errors)
FAIL: g++.dg/torture/pr57140.C   -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: g++.dg/torture/pr57140.C   -O3 -fomit-frame-pointer
-funroll-loops  (test for excess errors)
FAIL: g++.dg/torture/pr57140.C   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: g++.dg/torture/pr57140.C   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
FAIL: g++.dg/torture/pr57140.C   -O3 -g  (internal compiler error)
FAIL: g++.dg/torture/pr57140.C   -O3 -g  (test for excess errors)

on x86.

-- 
H.J.

Re: [PATCH] Relax check against commuting XOR and ASHIFTRT in combine.c

[Jeff Law]

On 07/17/14 10:56, Alan Lawrence wrote:

Ok, the attached tests are passing on x86_64-none-linux-gnu,
aarch64-none-elf, arm-none-eabi, and a bunch of smaller platforms for
which I've only built a stage 1 compiler (i.e. as far as necessary to
assemble). That's with either change to simplify_shift_const_1.

As to the addition of "result_mode != shift_mode", or removing the whole
check against XOR - I've now tested the latter:

bootstrapped on x86_64-none-linux-gnu, check-gcc and check-ada;
bootstrapped on arm-none-linux-gnueabihf;
bootstrapped on aarch64-none-linux-gnu;
cross-tested check-gcc on aarch64-none-elf;
cross-tested on arm-none-eabi;
(and Uros has bootstrapped on alpha and done a suite of tests, as per
https://gcc.gnu.org/ml/gcc-testresults/2014-07/msg01236.html).

 From a perspective of paranoia, I'd lean towards adding "result_mode !=
shift_mode", but for neatness removing the whole check against XOR is
nicer. So I'd defer to the maintainers as to whether one might be
preferable to the other...(but my unproven suspicion is that the two are
equivalent, and no case where result_mode != shift_mode is possible!)
So first, whether or not someone cares about Alpha-VMS isn't the issue 
at hand.  It's whether or not the new code is correct or not. 
Similarly the fact that the code generation paths are radically 
different now when compared to 2004 and we can't currently trigger the 
cases where the modes are different isn't the issue, again, it's whether 
or not your code is correct or not.


I think the key is to look at try_widen_shift_mode and realize that it 
can return a mode larger than the original mode of the operations. 
However, it only does so when it presented with a case where it knows 
the sign bit being shifted in from the left will be the same as the sign 
bit in the original mode.


In the case of an XOR when the sign bit set in shift_mode, that's not 
going to be the case.  We would violate the assumption made when we 
decided to widen the shift to shift_mode.


So your relaxation is safe when shift_mode == result_mode, but unsafe 
otherwise -- even though we don't currently have a testcase for the 
shift_mode != result_mode case, we don't want to break that.


So your updated patch is correct.  However, I would ask that you make 
one additional change.  Namely the comment before the two fragments of 
code you changed needs updating.  Something like


"... and the constant has its sign bit set in shift_mode and shift_mode
 is different than result_mode".

The 2nd comment should have similar clarifying comments.

You should also include your testcase for a cursory review.

So with the inclusion of the testcase and updated comments, we should be 
good to go.  However, please post the final patch for that cursory 
review of the testcase.


jeff

Re: [PATCH] Add XINSN macro and use it within NEXT_INSN/PREV_INSN (was Re: [PATCH] Force rtl templates to be inlined)

[Jeff Law]

On 09/04/14 14:22, Jakub Jelinek wrote:

On Thu, Sep 04, 2014 at 04:04:17PM -0400, David Malcolm wrote:

--- a/gcc/rtl.h
+++ b/gcc/rtl.h
@@ -195,6 +195,7 @@ union rtunion
unsigned int rt_uint;
const char *rt_str;
rtx rt_rtx;
+  rtx_insn *rt_insn;
rtvec rt_rtvec;
enum machine_mode rt_type;
addr_diff_vec_flags rt_addr_diff_vec_flags;
@@ -1208,6 +1209,7 @@ extern void rtl_check_failed_flag (const char *, 
const_rtx, const char *,
  #define XUINT(RTX, N)   (RTL_CHECK2 (RTX, N, 'i', 'n').rt_uint)
  #define XSTR(RTX, N)  (RTL_CHECK2 (RTX, N, 's', 'S').rt_str)
  #define XEXP(RTX, N)  (RTL_CHECK2 (RTX, N, 'e', 'u').rt_rtx)


Shouldn't XEXP be changed into RTL_CHECK1 (RTX, N, 'e').rt_rtx
then and the accessors of first operand of INSN_LIST and only operand of
LABEL_REF be changed to XINSN too?  Of course doesn't have to be done
immediately, can be done as a followup.

Yea, let's chase this as a follow-up.

Jeff

Re: [PATCH] Add XINSN macro and use it within NEXT_INSN/PREV_INSN (was Re: [PATCH] Force rtl templates to be inlined)

[Jeff Law]

On 09/04/14 15:19, David Malcolm wrote:


I suppose so, but I don't see an easy way of locating such XEXP users
beyond building with ENABLE_RTL_CHECKING, and checking on every
configuration, and trying to exercise all code paths.  Can we consider
that a *long-term* followup?
Well, XEXP isn't supposed to be used to access integer fields (we have 
XINT for that).  Any code doing so is already broken, IMHO.  And 
anything doing so is going to have some ugly cast from an rtx to some 
integer type -- a strong hint that the original author any any reviewer 
missed something :-)


So I'd be comfortable with a more limited set of testing (say bootstrap 
x86_64 and perhaps one or two other platforms).  Evaluate anything 
found, and assuming we're not finding anything terribly unexpected, go 
for it.





Use of XINSN does introduce a hole in the rtx-classes type-safety
scheme, in that it's only checked with ENABLE_RTL_CHECKING.
I see XINSN as a relatively short term wart.  Our goal ought to be to 
make it go away, but I can see how we need it in the immediate term.



Jeff

Re: [PATCH] Add XINSN macro and use it within NEXT_INSN/PREV_INSN (was Re: [PATCH] Force rtl templates to be inlined)

[Jeff Law]

On 09/04/14 14:04, David Malcolm wrote:

On Tue, 2014-09-02 at 19:50 +0200, Andi Kleen wrote:

I suspect the bulk of them currently are coming from the safe_as_a
 calls within NEXT_INSN and PREV_INSN; do you happen to have
information handy on that?


Yes that's right:

-   1.03%  lto1[.] bool 
is_a_helper::test(rtx_def*) 
▒
- bool is_a_helper::test(rtx_def*)  
 ▒
   - 92.20% bool is_a(rtx_def*) 
 ▒
  - 98.53% rtx_insn* safe_as_a(rtx_def*)
 ▒
 - 73.28% NEXT_INSN(rtx_insn const*)
 ▒


The is_a_helper for rtx_insn * is non-trivial, so it may be worth
avoiding it, even when inlined.

The attached patch rewrites the inline NEXT_INSN/PREV_INSN to avoid
doing the safe_as_a, instead tightening up the interface so that one can
only set them to an insn, and introducing a new XINSN access macro and
corresponding rt_insn member of the union.

Bootstrapped on x86_64-unknown-linux-gnu (Fedora 20), and has been
rebuilt as part of a config-list.mk build for all working configurations
(albeit with other patches for the latter case).

OK for trunk?
So is this just to deal with the overhead in the safe_as_a helper until 
we can strengthen more code?  And is that overhead significant in an 
optimized build?


Would an alternate approach be to make the checking in safe_as_a 
conditionalized on ENABLE_CHECKING?


jeff

Re: [PATCH] Add XINSN macro and use it within NEXT_INSN/PREV_INSN (was Re: [PATCH] Force rtl templates to be inlined)

[David Malcolm]

On Fri, 2014-09-05 at 12:45 -0600, Jeff Law wrote:
> On 09/04/14 14:04, David Malcolm wrote:
> > On Tue, 2014-09-02 at 19:50 +0200, Andi Kleen wrote:
> >>> I suspect the bulk of them currently are coming from the safe_as_a
> >>>  calls within NEXT_INSN and PREV_INSN; do you happen to have
> >>> information handy on that?
> >>
> >> Yes that's right:
> >>
> >> -   1.03%  lto1[.] bool 
> >> is_a_helper::test(rtx_def*)
> >>  ▒
> >> - bool is_a_helper::test(rtx_def*) 
> >>   ▒
> >>- 92.20% bool is_a(rtx_def*)
> >>   ▒
> >>   - 98.53% rtx_insn* safe_as_a(rtx_def*)   
> >>   ▒
> >>  - 73.28% NEXT_INSN(rtx_insn const*)   
> >>   ▒
> >
> > The is_a_helper for rtx_insn * is non-trivial, so it may be worth
> > avoiding it, even when inlined.
> >
> > The attached patch rewrites the inline NEXT_INSN/PREV_INSN to avoid
> > doing the safe_as_a, instead tightening up the interface so that one can
> > only set them to an insn, and introducing a new XINSN access macro and
> > corresponding rt_insn member of the union.
> >
> > Bootstrapped on x86_64-unknown-linux-gnu (Fedora 20), and has been
> > rebuilt as part of a config-list.mk build for all working configurations
> > (albeit with other patches for the latter case).
> >
> > OK for trunk?
> So is this just to deal with the overhead in the safe_as_a helper until 
> we can strengthen more code?  And is that overhead significant in an 
> optimized build?
> 
> Would an alternate approach be to make the checking in safe_as_a 
> conditionalized on ENABLE_CHECKING?

I wrote the attached patch to do that, but I don't yet have numbers to
back it up.

Bootstrapped with current settings, and smoketested with
--enable-checking=release (both on Fedora 20 x86_64).
>From 24b98616c4425a8ef380d2d5fef00f82af9df985 Mon Sep 17 00:00:00 2001
From: David Malcolm 
Date: Fri, 29 Aug 2014 17:04:49 -0400
Subject: [PATCH] Ensure that safe_as_a can have no performance overhead in a
 release build

gcc/
	* is-a.h (safe_as_a): Eliminate the conditional from the
	!defined(ENABLE_CHECKING) case, to ensure there can be no
	performance degradation of the release build.
---
 gcc/is-a.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/is-a.h b/gcc/is-a.h
index 176066b..f0c05b0 100644
--- a/gcc/is-a.h
+++ b/gcc/is-a.h
@@ -200,6 +200,7 @@ template 
 inline T
 safe_as_a (U *p)
 {
+#ifdef ENABLE_CHECKING
   if (p)
 {
   gcc_checking_assert (is_a  (p));
@@ -207,6 +208,9 @@ safe_as_a (U *p)
 }
   else
 return NULL;
+#else
+  return is_a_helper ::cast (p);
+#endif
 }
 
 /* A generic checked conversion from a base type U to a derived type T.  See
-- 
1.8.5.3

Re: [PATCH] Fix register corruption bug in ree

[Jeff Law]

On 09/04/14 08:05, Wilco Dijkstra wrote:

Hi,

While changing register costs for AArch64 (patches to follow), the test
gcc.target/aarch64/vect-mult.c fails. This is caused by ree inserting a TI mode 
copy of a DI
register. Since TI mode requires 2 registers, this results in silent corruption 
of the 2nd register.

After split2:

(insn 149 148 147 2 (set (reg:DI 3 x3 [90])
 (reg:DI 2 x2 [90])) vect-mull.c:78 34 {*movdi_aarch64}
  (nil))
(insn 152 127 153 2 (set (reg:TI 32 v0 [90])
 (zero_extend:TI (reg:DI 3 x3 [90]))) vect-mull.c:78 719 
{aarch64_movtilow_di}
  (nil))

Ree transforms this into:

(insn 149 148 157 2 (set (reg:TI 32 v0)
 (zero_extend:TI (reg:DI 2 x2 [90]))) vect-mull.c:78 719 
{aarch64_movtilow_di}
  (nil))
(insn 157 149 147 2 (set (reg:TI 3 x3)
 (reg:TI 32 v0)) vect-mull.c:78 -1
  (nil))

The TI mode in the second instruction means both x3 and x4 are assigned after 
expansion in split4
(rather than just x3 in the original instruction), corrupting x4. The fix is to 
ensure the inserted
copy will set only one register. Also ensure we always call 
get_extended_src_reg() rather than
assume there is always a single extend.

OK for commit?

Wilco

ChangeLog:
2014-09-04  Wilco Dijkstra  

* gcc/ree.c (combine_reaching_defs):
Ensure inserted copy writes a single register.
Thanks!  Jakub noticed a potential problem in this area a while back, 
but I never came up with any code to trigger and have kept that issue on 
my todo list ever since.


Rather than ensuring the inserted copy write a single register, it seems 
to me we're better off ensuring that the number of hard registers hasn't 
changed.  Obviously that's not much of an issue for things like aarch64, 
x86_64, but for the embedded 32 bit parts it's likely much more important.


So I think the test is something like

x = get_extended_src_reg (SET_SRC (PATTERN (cand->insn)))
if (HARD_REGNO_NREGS (REGNO (new_reg), cand->mode)
!= HARD_REGNO_NREGS  (REGNO (new_reg), GET_MODE (SET_DEST (*orig_set))
  return false;

Or something along those lines...

jeff

RE: [PATCH ARM]memset inlining patch for arm

[Evandro Menezes]

Bin,

This is perhaps a plus for Aarch64 as well.  Is there any plan to add a
64-bit version of this patch or should a bug be open for this?

Thank you,

-- 
Evandro Menezes  Austin, TX


-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On Behalf Of Bin Cheng
Sent: Thursday, September 04, 2014 1:08
To: gcc-patches@gcc.gnu.org
Subject: [PATCH ARM]memset inlining patch for arm

Hi,
This patch is posted/approved before at
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01398.html
Unfortunately, it was reverted because a latent bug revealed causing glibc
build failure and I didn't have enough time to fix back at that time.
Now with the potential bug resolved by
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00298.html , here I am sending
it for approval again.
The code in patch isn’t changed, all differences between this and previous
version are the test cases.
1) I tuned scanning strings in some test cases to resolve case failure when
testing against old arm processors.
2) I added a new case which is reduced from glibc build failure triggered by
this patch.

Pass test on cortex-m3.
Pass test on arm-none-linux-gnueabi
Bootstrap on arm-none-linux-gnueabihf
Pass test on arm-none-linux-gnueabihf with different test variants.

So is it OK?

Thanks,
bin

2014-09-04  Bin Cheng  

PR target/55701
* config/arm/arm.md (setmem): New pattern.
* config/arm/arm-protos.h (struct tune_params): New fields.
(arm_gen_setmem): New prototype.
* config/arm/arm.c (arm_slowmul_tune): Initialize new fields.
(arm_fastmul_tune, arm_strongarm_tune, arm_xscale_tune): Ditto.
(arm_9e_tune, arm_v6t2_tune, arm_cortex_tune): Ditto.
(arm_cortex_a8_tune, arm_cortex_a7_tune): Ditto.
(arm_cortex_a15_tune, arm_cortex_a53_tune): Ditto.
(arm_cortex_a57_tune, arm_cortex_a5_tune): Ditto.
(arm_cortex_a9_tune, arm_cortex_a12_tune): Ditto.
(arm_v7m_tune, arm_v6m_tune, arm_fa726te_tune): Ditto.
(arm_const_inline_cost): New function.
(arm_block_set_max_insns): New function.
(arm_block_set_non_vect_profit_p): New function.
(arm_block_set_vect_profit_p): New function.
(arm_block_set_unaligned_vect): New function.
(arm_block_set_aligned_vect): New function.
(arm_block_set_unaligned_non_vect): New function.
(arm_block_set_aligned_non_vect): New function.
(arm_block_set_vect, arm_gen_setmem): New functions.

gcc/testsuite/ChangeLog
2014-09-04  Bin Cheng  

PR target/55701
* gcc.target/arm/memset-inline-1.c: New test.
* gcc.target/arm/memset-inline-2.c: New test.
* gcc.target/arm/memset-inline-3.c: New test.
* gcc.target/arm/memset-inline-4.c: New test.
* gcc.target/arm/memset-inline-5.c: New test.
* gcc.target/arm/memset-inline-6.c: New test.
* gcc.target/arm/memset-inline-7.c: New test.
* gcc.target/arm/memset-inline-8.c: New test.
* gcc.target/arm/memset-inline-9.c: New test.
* gcc.target/arm/memset-inline-10.c: New test.

Re: [PATCH] Improve prepare_shrink_wrap to sink more instructions

[Jeff Law]

On 09/04/14 08:15, Jiong Wang wrote:

currently, the instruction sink in "prepare_shrink_wrap" is a bit
conservative
that some further optimization opportunities have been missed.

given the prologue use register A by:

   (store A, [sp + offset])

then given the entry_basic_block contains a simply register copy like:

   (move A, B)

current "prepare_shrink_wrap" will sink the move instruction as deep as
it can,
then the entry_basic_block could be marked as "don't need prologue".

while if we replace "(move A, B)" into either one of

   * "(move B, CONST_K)",
   * "(move B, (plus A, CONST_K))"

we still could do the same sink optimization, but *current gcc do not*.

pattern like (move B, CONST_K) are very normal for some RISC targets.

for example on AArch64, we could have the following pair:

   adrpx22, global_data_a
   add x0, x22, :lo12:global_data_a

if "adrp" be scheduled into the entry_basic_block then the write of x22 may
prevent shrink-wrap happen.

when judge whether one instruction is sink-able,
move_insn_for_shrink_wrap only
accept simply reg copy that both dest and src are REG_P, while the second
operand of adrp is actually a SYMBOL_REF, thus it's reject by the
optimization.

this patch relax the restriction on src to accept any one of the following:

   + REG
   + CONST_OBJ, like SYMBOL_REF
   + combination of single REG and any other CONST_OBJs.
 (reg def/use calculation will not affected by CONST_OBJs)

RISC backend may benefit more from this relax, although there still
be minor improvements on x86. for example, there are 17 more functions
shrink-wrapped during x86-64 bootstrap, like sort_bucket in ira-color.c.

test done
=
   no regression on aarch64-none-elf bare-metal.
   no regression on x86-64 check-gcc.
   both aarch64 and x86-64 bootstrap OK.

ok for install?

2014-09-04 Jiong Wang

gcc/
   * shrink-wrap.c (rtx_search_arg): New structure type.
   (rtx_search_arg_p): New typedef.
   (count_reg_const): New callback function.
   (move_insn_for_shrink_wrap): Relax the restriction on src operand.


Conceptually OK.  Some questions/concerns about the implementation.

It seems to me that what you're trying to describe on the RHS is
REG_P || CONSTANT_P

Note that CONSTANT_P will catch things like (high (symbol_ref)) and 
(lo_sum (reg) (symbol_ref)) which are often used to build addresses on 
some targets.


With that in mind, rather than using a for_each_rtx callback, test
if (REG_P (src) || CONSTANT_P (src))

Note that SRC, when it is a CONSTANT_P,  may have a variety of forms 
with embedded registers.  You'll need to verify that all of those 
registers are not assigned after the insn with the CONSTANT_P source 
operand.  Right now you only perform that check when SRC is a REG_P.


Jeff

Re: Remove no-longer-needed fp-bit target macros

[Hans-Peter Nilsson]

> From: "Joseph S. Myers" 
> Date: Fri, 5 Sep 2014 19:21:04 +0200

> This patch removes some fp-bit target macros that are no longer
> needed:
> 
> * __make_dp was not really designed as a target macro, but CRIS
>   defined it in cris.h anyway for optimization purposes

Minor correction here: it was out of necessity due to ABI
restrictions for gcc intrinsic functions, not for optimization
purposes.  Those restrictions may be long gone now, but it used
to be that parameters for gcc intrinsic functions ("libgcc
functions") were not allowed to be passed "by reference"; as
pointers.  I've lost the details but I think I'm right to blame
the gcc intrinsics interface, not the CRIS port.  (Other than me
not taking on removal of that restriction, of course.)

> (so making it
>   show up on lists of target macros).  Since CRIS no longer uses
>   fp-bit, that definition is no longer needed.

Certainly.  I just missed this when doing the soft-fp
conversion.  Thanks for being thorough.

brgds, H-P

Build breakage on darwin and pa64-hpux [was Re: Use -fbuilding-libgcc for more target macros used in libgcc]

[David Malcolm]

On Fri, 2014-09-05 at 01:15 +, Joseph S. Myers wrote:
> It is desirable for various reasons to stop target libraries from
> using host-side tm.h: making the headers work on both host and target
> (and on build as well) is fragile (especially when dealing with macros
> depending on command-line options, which need different definitions
> when being used for the target), prevents configuring and building
> target libraries separately from host-side tools (consider a process
> of bootstapping tools and libraries, where the host side of GCC should
> be built before building libc but the final versions of target
> libraries can only be configured and built after libc) and any target
> macro used in target-side code cannot be turned into a target hook.
> 
> Some target macros used only in target-side code can be moved into
> libgcc_tm.h; the trickier cases are macros that are actually used on
> both the host and the target.  We have a -fbuilding-libgcc option to
> cause GCC to predefine additional macros for such cases, to
> communicate the target macro setting to code built for the target.
> This patch moves various additional target macros used on both the
> host and the target to use this mechanism instead of using the target
> macro directly in code built for the target.
> 
> The set of macros converted is smaller than the list I put on
>  some time ago;
> as well as excluding some used on the target only for a single target
> architecture (where I think target-specific predefines if
> -fbuilding-libgcc would be reasonable), there are others I think
> should be investigated further to work out the best way to communicate
> the relevant information to libgcc.
> 
> In general the conversions of the libgcc code here are mechanical.  I
> removed conditional definitions of DWARF_FRAME_REGISTERS to
> FIRST_PSEUDO_REGISTER (defaults.h has such a definition, meaning in
> fact DWARF_FRAME_REGISTERS is always defined on the host and the
> definition and uses of __LIBGCC_DWARF_FRAME_REGISTERS__ can safely be
> unconditional).  This gets rid of uses of FIRST_PSEUDO_REGISTER in
> target-side code.  In the case of TARGET_VTABLE_USES_DESCRIPTORS, I
> made __LIBGCC_VTABLE_USES_DESCRIPTORS__ correspond to the host-side
> value rather than to whether TARGET_VTABLE_USES_DESCRIPTORS is defined
> by the target (note that defaults.h has a default definition of
> TARGET_VTABLE_USES_DESCRIPTORS if not already defined, but in a
> section of defaults.h that's only used on the host, so the #ifdef in
> the target-side code was effective despire the default definition and
> this is a correct translation to the -fbuilding-libgcc approach).
> 
> For ARM, CTORS_SECTION_ASM_OP and DTORS_SECTION_ASM_OP are defined (or
> not) in arm.h differently depending on IN_LIBGCC2.  So this patch has
> the effect that __LIBGCC_CTORS_SECTION_ASM_OP__ and
> __LIBGCC_DTORS_SECTION_ASM_OP__ will be defined in libgcc for EABI
> targets when the previous target macros were not.  But this is of no
> effect because in fact CTOR_LIST_BEGIN, CTOR_LIST_END, DTOR_LIST_BEGIN
> and DTOR_LIST_END being defined mean that nothing depends on whether
> __LIBGCC_CTORS_SECTION_ASM_OP__ and __LIBGCC_DTORS_SECTION_ASM_OP__
> are defined.  Rather than attempt a partial cleanup of the relevant
> code and comments in arm.h, it seems better to leave that until
> CTOR_LIST_BEGIN, CTOR_LIST_END, DTOR_LIST_BEGIN and DTOR_LIST_END move
> to libgcc_tm.h.  (I don't believe there are any other cases where the
> current definitions of affected target macros depend on whether tm.h
> is being used for the target.)
> 
> Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  OK to
> commit?
> 
> gcc/c-family:
> 2014-09-05  Joseph Myers  
> 
>   * c-cppbuiltin.c (c_cpp_builtins): Also define
>   __LIBGCC_EH_TABLES_CAN_BE_READ_ONLY__,
>   __LIBGCC_EH_FRAME_SECTION_NAME__, __LIBGCC_JCR_SECTION_NAME__,
>   __LIBGCC_CTORS_SECTION_ASM_OP__, __LIBGCC_DTORS_SECTION_ASM_OP__,
>   __LIBGCC_TEXT_SECTION_ASM_OP__, __LIBGCC_INIT_SECTION_ASM_OP__,
>   __LIBGCC_INIT_ARRAY_SECTION_ASM_OP__,
>   __LIBGCC_STACK_GROWS_DOWNWARD__,
>   __LIBGCC_DONT_USE_BUILTIN_SETJMP__,
>   __LIBGCC_DWARF_ALT_FRAME_RETURN_COLUMN__,
>   __LIBGCC_DWARF_FRAME_REGISTERS__,
>   __LIBGCC_EH_RETURN_STACKADJ_RTX__, __LIBGCC_JMP_BUF_SIZE__,
>   __LIBGCC_STACK_POINTER_REGNUM__ and
>   __LIBGCC_VTABLE_USES_DESCRIPTORS__ for -fbuilding-libgcc.
>   (builtin_define_with_value): Handle backslash-escaping in string
>   macro values.
> 
> libgcc:
> 2014-09-05  Joseph Myers  
> 
>   * Makefile.in (CRTSTUFF_CFLAGS): Add -fbuilding-libgcc.
>   * config/aarch64/linux-unwind.h (STACK_POINTER_REGNUM): Change all
>   uses to __LIBGCC_STACK_POINTER_REGNUM__.
>   (DWARF_ALT_FRAME_RETURN_COLUMN): Change all uses to
>   __LIBGCC_DWARF_ALT_FRAME_RETURN_COLUMN__.
>   * config/alpha/vms-unwind.h (DWARF_ALT_FRAME

[msp430] add missing option documentation

[DJ Delorie]

Minor bit of docs for an msp430 option.  OK for trunk and 4.9 branch?

* doc/invoke.texi (MSP430 Options): Add -minrt.

Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 214976)
+++ doc/invoke.texi (working copy)
@@ -834,13 +834,13 @@ Objective-C and Objective-C++ Dialects}.
 
 @emph{Moxie Options}
 @gccoptlist{-meb -mel -mno-crt0}
 
 @emph{MSP430 Options}
 @gccoptlist{-msim -masm-hex -mmcu= -mcpu= -mlarge -msmall -mrelax @gol
--mhwmult=}
+-mhwmult= -minrt}
 
 @emph{NDS32 Options}
 @gccoptlist{-mbig-endian -mlittle-endian @gol
 -mreduced-regs -mfull-regs @gol
 -mcmov -mno-cmov @gol
 -mperf-ext -mno-perf-ext @gol
@@ -18583,12 +18583,19 @@ routine.  This saves space in the genera
 inline.  This makes for bigger, but faster code.
 
 The hardware multiply routines disable interrupts whilst running and
 restore the previous interrupt state when they finish.  This makes
 them safe to use inside interrupt handlers as well as in normal code.
 
+@item -minrt
+@opindex minrt
+Enable the use of a minimum runtime environment - no static
+initializers or constructors.  This is intended for memory-constrained
+devices.  The compiler will include special symbols in some objects
+that tell the linker and runtime which code fragments are required.
+
 @end table
 
 @node NDS32 Options
 @subsection NDS32 Options
 @cindex NDS32 Options
 

Re: [PATCH 1/2] add staticly checked label_nuses accessors

[David Malcolm]

On Fri, 2014-09-05 at 10:43 -0600, Jeff Law wrote:
> On 09/05/14 09:32, tsaund...@mozilla.com wrote:
> > From: Trevor Saunders 
> >
> > Hi,
> >
> >   Doing this means we get to remove a fair chunk of runtime checking.
> >
> > bootstrapped + regtested on x86_64-unknown-linux-gnu with no regressions.
> > config-list.mk with this and the next patch is ongoing. ok?
> >
> > Trev
> >
> > gcc/
> >
> > * config/i386/i386.c, config/i386/i386.md, config/mep/mep.c,
> > config/mips/mips.c, config/nios2/nios2.c, config/s390/s390.c,
> > config/sh/sh.c, reorg.c: Use rtx_code_label::nuses and
> > rtx_code_label::set_nuses where possible.
> > * rtl.h (rtx_code_label::nuses): New member function.
> > (rtx_code_label::set_nuses): Likewise.
> Is there some reason why we don't fix every reference to LABEL_NUSES to 
> use the new member functions?  My concern here is that we've now got two 
> ways actively used to get at that information, the old LABEL_NUSES and 
> the new member functions.  Obviously we really just want one blessed way 
> to get/set that information.  If this is a short term situation, then 
> I'd be inclined to say OK, but I don't see further patches which sort 
> out the ~200 or so LABEL_NUSES users.
> 
> THe approach David has taken for similar situations has been to first 
> introduce the get/set methods, convert everything to set the get/set 
> method, dealing with the type fallout that occurrs around that, then 
> collapsing back to the old macro.  Is there some reason we can not or 
> should not do that here?

If it's a macro that's simply a direct field access into a struct (e.g.
BB_HEADER), then yes, but for those that are wrappers around e.g. XEXP
I've been keeping them as inline functions, so that the type system
detects incorrect node types as compile-time errors.

One other aspect of my approach is that (believe it or not) I'm trying
to minimize the size of the changes, to avoid introducing pain when
backporting bugfixes from trunk to the branches.

My goal here is type-safety, with readability as a secondary benefit.  I
think it's a good idea for us to add methods that let us replace e.g.
XEXP (x, 0) accessors with descriptive names, and have been doing so,
and I prefer doing this as methods for new code.  However, when the
accessor already has a descriptive name, like LABEL_NUSES, I think it's
enough to convert them to inline functions and tighten up the params and
return type to express things.  I'm not sure the cost/benefit of
*additionally* converting them to be methods is worth it, given that it
means changing the spelling at every callsite.

Dave

Remove SF_SIZE etc. target macros

[Joseph S. Myers]

This patch replaces the target macros SF_SIZE, DF_SIZE, XF_SIZE and
TF_SIZE, used to tell libgcc the number of bits in the mantissas of
floating-point modes, with __LIBGCC_SF_MANT_DIG__ etc. macros defined
if -fbuilding-libgcc for all floating-point modes.  Various libgcc
logic to determine default values of the macros based on other target
macros such as LIBGCC2_LONG_DOUBLE_TYPE_SIZE can thus be removed.

Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  OK to
commit?

gcc:
2014-09-05  Joseph Myers  

* config/i386/cygming.h (TF_SIZE): Remove.
* config/i386/darwin.h (TF_SIZE): Remove.
* config/i386/dragonfly.h (TF_SIZE): Remove.
* config/i386/freebsd.h (TF_SIZE): Remove.
* config/i386/gnu-user-common.h (TF_SIZE): Remove.
* config/i386/openbsdelf.h (TF_SIZE): Remove.
* config/i386/sol2.h (TF_SIZE): Remove.
* config/ia64/hpux.h (XF_SIZE, TF_SIZE): Remove.
* config/ia64/linux.h (TF_SIZE): Remove.
* doc/tm.texi.in (SF_SIZE, DF_SIZE, XF_SIZE, TF_SIZE): Remove.
* doc/tm.texi: Regenerate.
* system.h (SF_SIZE, DF_SIZE, XF_SIZE, TF_SIZE): Poison.

gcc/c-family:
2014-09-05  Joseph Myers  

* c-cppbuiltin.c (c_cpp_builtins): Define macros for mantissa
digits of floating-point modes if -fbuilding-libgcc.

libgcc:
2014-09-05  Joseph Myers  

* libgcc2.c (SF_SIZE): Change all uses to __LIBGCC_SF_MANT_DIG__.
(DF_SIZE): Change all uses to __LIBGCC_DF_MANT_DIG__.
(XF_SIZE): Change all uses to __LIBGCC_XF_MANT_DIG__.
(TF_SIZE): Change all uses to __LIBGCC_TF_MANT_DIG__.
* libgcc2.h (SF_SIZE): Change to __LIBGCC_SF_MANT_DIG__.  Give
error if not defined and LIBGCC2_HAS_SF_MODE is defined.
(DF_SIZE): Change to __LIBGCC_DF_MANT_DIG__.  Give error if not
defined and LIBGCC2_HAS_DF_MODE is defined.
(XF_SIZE): Change to __LIBGCC_XF_MANT_DIG__.  Give error if not
defined and LIBGCC2_HAS_XF_MODE is defined.
(TF_SIZE): Change to __LIBGCC_TF_MANT_DIG__.  Give error if not
defined and LIBGCC2_HAS_TF_MODE is defined.

Index: gcc/c-family/c-cppbuiltin.c
===
--- gcc/c-family/c-cppbuiltin.c (revision 214954)
+++ gcc/c-family/c-cppbuiltin.c (working copy)
@@ -944,6 +944,20 @@ c_cpp_builtins (cpp_reader *pfile)
   /* For libgcc-internal use only.  */
   if (flag_building_libgcc)
 {
+  /* Properties of floating-point modes for libgcc2.c.  */
+  for (enum machine_mode mode = GET_CLASS_NARROWEST_MODE (MODE_FLOAT);
+  mode != VOIDmode;
+  mode = GET_MODE_WIDER_MODE (mode))
+   {
+ const char *name = GET_MODE_NAME (mode);
+ char *macro_name
+   = (char *) alloca (strlen (name)
+  + sizeof ("__LIBGCC__MANT_DIG__"));
+ sprintf (macro_name, "__LIBGCC_%s_MANT_DIG__", name);
+ builtin_define_with_int_value (macro_name,
+REAL_MODE_FORMAT (mode)->p);
+   }
+
   /* For libgcc crtstuff.c and libgcc2.c.  */
   builtin_define_with_int_value ("__LIBGCC_EH_TABLES_CAN_BE_READ_ONLY__",
 EH_TABLES_CAN_BE_READ_ONLY);
Index: gcc/config/i386/cygming.h
===
--- gcc/config/i386/cygming.h   (revision 214954)
+++ gcc/config/i386/cygming.h   (working copy)
@@ -343,7 +343,6 @@ do {\
 #undef LIBGCC2_HAS_TF_MODE
 #define LIBGCC2_HAS_TF_MODE 1
 #define LIBGCC2_TF_CEXT q
-#define TF_SIZE 113
 
 /* Output function declarations at the end of the file.  */
 #undef TARGET_ASM_FILE_END
Index: gcc/config/i386/darwin.h
===
--- gcc/config/i386/darwin.h(revision 214954)
+++ gcc/config/i386/darwin.h(working copy)
@@ -157,7 +157,6 @@ extern int darwin_emit_branch_islands;
 #undef LIBGCC2_HAS_TF_MODE
 #define LIBGCC2_HAS_TF_MODE 1
 #define LIBGCC2_TF_CEXT q
-#define TF_SIZE 113
 
 #undef TARGET_ASM_FILE_END
 #define TARGET_ASM_FILE_END darwin_file_end
Index: gcc/config/i386/dragonfly.h
===
--- gcc/config/i386/dragonfly.h (revision 214954)
+++ gcc/config/i386/dragonfly.h (working copy)
@@ -93,7 +93,6 @@ see the files COPYING3 and COPYING.RUNTIME respect
 #undef LIBGCC2_HAS_TF_MODE
 #define LIBGCC2_HAS_TF_MODE 1
 #define LIBGCC2_TF_CEXT q
-#define TF_SIZE 113
 
 /* Static stack checking is supported by means of probes.  */
 #define STACK_CHECK_STATIC_BUILTIN 1
Index: gcc/config/i386/freebsd.h
===
--- gcc/config/i386/freebsd.h   (revision 214954)
+++ gcc/config/i386/freebsd.h   (working copy)
@@ -135,7 +135,6 @@ along with GCC; see the file COPYING3.  If not see
 #undef LIBGCC2_HAS_TF_MODE
 #define LIBGCC2_HAS_TF_MODE 

Re: [PATCH 1/2] add staticly checked label_nuses accessors

[Trevor Saunders]

On Fri, Sep 05, 2014 at 05:57:13PM -0400, David Malcolm wrote:
> On Fri, 2014-09-05 at 10:43 -0600, Jeff Law wrote:
> > On 09/05/14 09:32, tsaund...@mozilla.com wrote:
> > > From: Trevor Saunders 
> > >
> > > Hi,
> > >
> > >   Doing this means we get to remove a fair chunk of runtime checking.
> > >
> > > bootstrapped + regtested on x86_64-unknown-linux-gnu with no regressions.
> > > config-list.mk with this and the next patch is ongoing. ok?
> > >
> > > Trev
> > >
> > > gcc/
> > >
> > >   * config/i386/i386.c, config/i386/i386.md, config/mep/mep.c,
> > >   config/mips/mips.c, config/nios2/nios2.c, config/s390/s390.c,
> > >   config/sh/sh.c, reorg.c: Use rtx_code_label::nuses and
> > >   rtx_code_label::set_nuses where possible.
> > >   * rtl.h (rtx_code_label::nuses): New member function.
> > >   (rtx_code_label::set_nuses): Likewise.
> > Is there some reason why we don't fix every reference to LABEL_NUSES to 
> > use the new member functions?  My concern here is that we've now got two 
> > ways actively used to get at that information, the old LABEL_NUSES and 
> > the new member functions.  Obviously we really just want one blessed way 
> > to get/set that information.  If this is a short term situation, then 
> > I'd be inclined to say OK, but I don't see further patches which sort 
> > out the ~200 or so LABEL_NUSES users.
> > 
> > THe approach David has taken for similar situations has been to first 
> > introduce the get/set methods, convert everything to set the get/set 
> > method, dealing with the type fallout that occurrs around that, then 
> > collapsing back to the old macro.  Is there some reason we can not or 
> > should not do that here?
> 
> If it's a macro that's simply a direct field access into a struct (e.g.
> BB_HEADER), then yes, but for those that are wrappers around e.g. XEXP
> I've been keeping them as inline functions, so that the type system
> detects incorrect node types as compile-time errors.
> 
> One other aspect of my approach is that (believe it or not) I'm trying
> to minimize the size of the changes, to avoid introducing pain when
> backporting bugfixes from trunk to the branches.
> 
> My goal here is type-safety, with readability as a secondary benefit.  I
> think it's a good idea for us to add methods that let us replace e.g.
> XEXP (x, 0) accessors with descriptive names, and have been doing so,
> and I prefer doing this as methods for new code.  However, when the
> accessor already has a descriptive name, like LABEL_NUSES, I think it's
> enough to convert them to inline functions and tighten up the params and
> return type to express things.  I'm not sure the cost/benefit of
> *additionally* converting them to be methods is worth it, given that it
> means changing the spelling at every callsite.

So, in this case it seems to me you basically have two options

A. change the macro to an inline function, and fix up all the callers to
pass the right type.  Then rebase that into some sort of reasonable
patch series.

b. add a function with a different name and convert users piece meal,
and then remove the old macro (I guess you can then rename the new
function to the old macro if you like).

of those I prefer b because it means you can convert call sites one at a
time and its easy to know which have been delt with.

I also do think the advantages of using members outways the cost.

For one thing functions with all caps names are just weird.  I think the
more important reason though is that it will help make rtx_insn be a
separate class sometime in the far future, since at some point we can
make its inheritance from rtx_def protected to chase down things that
try to convert from rtx_insn to rtx.  There's also the argument that its
inconsistant to have some things be members and others be functions.

Trev

> 
> Dave
> 

Re: Build breakage on darwin and pa64-hpux [was Re: Use -fbuilding-libgcc for more target macros used in libgcc]

[Dominique Dhumieres]

...
> I believe the above hunk in r214954 ...
> ... broke the build for the
> following configurations in contrib/config-list.mk: ...

See pr63188 for darwin. The same patch should probably
fix the problem for hppa64-hpux* too.

Dominique

Re: Build breakage on darwin and pa64-hpux [was Re: Use -fbuilding-libgcc for more target macros used in libgcc]

[Mike Stump]

On Sep 5, 2014, at 3:59 PM, Dominique Dhumieres  wrote:
> See pr63188 for darwin. The same patch should probably
> fix the problem for hppa64-hpux* too.

Thanks.

Committed revision 214983.

Index: ChangeLog
===
--- ChangeLog   (revision 214981)
+++ ChangeLog   (working copy)
@@ -1,3 +1,9 @@
+2014-09-05  Dominique Dhumieres  
+
+   PR target/63188
+   * config/darwin.h (INIT_SECTION_ASM_OP): Define to "".
+   * config/pa/pa64-hpux.h (INIT_SECTION_ASM_OP): Likewise.
+
 2014-09-05  Easwaran Raman  
 
PR rtl-optimization/62146
Index: config/darwin.h
===
--- config/darwin.h (revision 214981)
+++ config/darwin.h (working copy)
@@ -499,7 +499,7 @@ extern GTY(()) int darwin_ms_struct;
 #define NO_PROFILE_COUNTERS1
 
 #undef INIT_SECTION_ASM_OP
-#define INIT_SECTION_ASM_OP
+#define INIT_SECTION_ASM_OP ""
 
 #undef INVOKE__main
 
Index: config/pa/pa64-hpux.h
===
--- config/pa/pa64-hpux.h   (revision 214981)
+++ config/pa/pa64-hpux.h   (working copy)
@@ -336,7 +336,7 @@ do {
\
the sections are not actually used.  However, we still must provide
defines to select the proper code path.  */
 #undef INIT_SECTION_ASM_OP
-#define INIT_SECTION_ASM_OP
+#define INIT_SECTION_ASM_OP ""
 #undef FINI_SECTION_ASM_OP
 #define FINI_SECTION_ASM_OP