Re: [PATCH] rs6000: Disparage CTR and LR in movcc_internal1

[Segher Boessenkool]

On Tue, Sep 27, 2016 at 02:29:46PM +0930, Alan Modra wrote:
> On Tue, Sep 27, 2016 at 12:33:59AM +, Segher Boessenkool wrote:
> > * config/rs6000/rs6000.md (movcc_internal1): Disparage using CTR or LR.
> 
> Actually, not disparage, but ignore when choosing register
> preferences.

@cindex @samp{*} in constraint
@item *
Says that the following character should be ignored when choosing
register preferences.  @samp{*} has no effect on the meaning of the
constraint as a constraint, and no effect on reloading.  For LRA
@samp{*} additionally disparages slightly the alternative if the
following character matches the operand.

I should just have said "add *", much clearer :-)

> >  (define_insn "*movcc_internal1"
> > -  [(set (match_operand:CC 0 "nonimmediate_operand" 
> > "=y,x,?y,y,r,r,r,r,r,cl,r,m")
> > -   (match_operand:CC 1 "general_operand" "y,r,r,O,x,y,r,I,h,r,m,r"))]
> > +  [(set (match_operand:CC 0 "nonimmediate_operand"
> > +   "=y,x,?y,y,r,r,r,r,r,*c*l,r,m")
> > +   (match_operand:CC 1 "general_operand"
> > +   " y,r, r,O,x,y,r,I,h,   r,m,r"))]
> 
> What about that "h" lurking there?

I haven't seen it do the wrong thing (yet).  There are various other mov
patterns that allow "h" as source like this, btw; if you want to change
it here, please see if you can change all?


Segher

Re: [PATCH] rs6000: Disparage CTR and LR in movcc_internal1

[Alan Modra]

On Tue, Sep 27, 2016 at 12:33:59AM +, Segher Boessenkool wrote:
>   * config/rs6000/rs6000.md (movcc_internal1): Disparage using CTR or LR.

Actually, not disparage, but ignore when choosing register
preferences.

>  (define_insn "*movcc_internal1"
> -  [(set (match_operand:CC 0 "nonimmediate_operand" 
> "=y,x,?y,y,r,r,r,r,r,cl,r,m")
> - (match_operand:CC 1 "general_operand" "y,r,r,O,x,y,r,I,h,r,m,r"))]
> +  [(set (match_operand:CC 0 "nonimmediate_operand"
> + "=y,x,?y,y,r,r,r,r,r,*c*l,r,m")
> + (match_operand:CC 1 "general_operand"
> + " y,r, r,O,x,y,r,I,h,   r,m,r"))]

What about that "h" lurking there?

-- 
Alan Modra
Australia Development Lab, IBM

Re: Re: [PATCH] Fixed up missing semicolons.

[lhmouse]

In case my previous mail is swallowed by mailman:

I am not familiar with your convention. Elsewhere, I usually
don't use my full name. If people suggest I use a full name
when submitting patches, I am glad to go with that.

My name is Liu Hao (LH for short). The word 'Mouse' is
a homophony joke in Chinese and does not mean anything
significant.

--   
Best regards,
lh_mouse
2016-09-27

Re: [PATCH] Fix PR tree-optimization/77550

[Christophe Lyon]

On 26 September 2016 at 22:09, Bernd Edlinger  wrote:
> On 09/26/16 21:19, Christophe Lyon wrote:
>>
>> Sorry for the delay, I've been travelling.
>>
>> Compilation is:
>> .../xg++ 
>> -B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/gcc/testsuite/g++/../../
>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/g++.dg/pr77550.C
>> g++_tg.o -fno-diagnostics-show-caret -fdiagnostics-color=never
>> -nostdinc++ 
>> -I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/arm-none-eabi
>> -I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include
>> -I/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++
>> -I/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/include/backward
>> -I/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/util
>> -fmessage-length=0 -std=c++14 -O3
>> -L/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/./libstdc++-v3/src/.libs
>> -B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/./libstdc++-v3/src/.libs
>> -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o
>> ./pr77550.exe
>>
>> Then, during execution, I have:
>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>> and that's all
>>
>> My gcc configuration flags are:
>> --target=arm-none-eabi --disable-libgomp --disable-libmudflap
>> --disable-libcilkrts --enable-checking --enable-languages=c,c++
>> --with-newlib --disable-tls --with-mode=arm --with-cpu=cortex-a9
>>
>> Christophe
>>
>
> Interesting.  At this point it might be OK to open a new PR.
>
OK, this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748

> So far, I cannot reproduce, but I used also cortex-a9 but
> target=arm-linux-gnueabihf.
>
It does work for me with this configuration.
arm-non-eabi makes the difference.

> Could you please start the command above manually and add
> -save-temps ?
>
>
> Thanks
> Bernd.

Re: [v3 PATCH] Implement LWG 2729 for pair.

[Ville Voutilainen]

On 27 September 2016 at 03:21, Ville Voutilainen
 wrote:
> On 27 September 2016 at 03:16, Christophe Lyon
>  wrote:
>>   20_util/declval/requirements/1_neg.cc  (test for errors, line 2263)
>>   20_util/declval/requirements/1_neg.cc (test for excess errors)
>>   20_util/make_signed/requirements/typedefs_neg.cc  (test for errors, line 
>> 1928)
>>   20_util/make_signed/requirements/typedefs_neg.cc (test for excess errors)
>>   20_util/make_unsigned/requirements/typedefs_neg.cc  (test for
>> errors, line 1781)
>>   20_util/make_unsigned/requirements/typedefs_neg.cc  (test for
>> errors, line 1824)
>>   20_util/make_unsigned/requirements/typedefs_neg.cc (test for excess errors)
>>
>> Error messages include:
>> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/type_traits:2270:
>> error: static assertion failed: declval() must not be used!
>>
>> Is it just because the pattern in dg-error is *-*-* ?
>
>
> Argh, I'll take a look. These errors come from the testsuite expecting
> certain line numbers in certain
> library headers, and adding code to said headers shifts the error lines.

I have committed the attached patch as obvious. Pardons all around for
failing to run the full suite properly.
diff --git a/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc 
b/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
index f2a0dbf..9989a79 100644
--- a/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
@@ -19,7 +19,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-error "static assertion failed" "" { target *-*-* } 2263 }
+// { dg-error "static assertion failed" "" { target *-*-* } 2270 }
 
 #include 
 
diff --git 
a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc 
b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
index 6914eb4..3a097c3 100644
--- a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
@@ -48,4 +48,4 @@ void test01()
 // { dg-error "required from here" "" { target *-*-* } 40 }
 // { dg-error "required from here" "" { target *-*-* } 42 }
 
-// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1928 }
+// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1935 }
diff --git 
a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc 
b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
index 81ff92a..4e64166 100644
--- a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
@@ -48,5 +48,5 @@ void test01()
 // { dg-error "required from here" "" { target *-*-* } 40 }
 // { dg-error "required from here" "" { target *-*-* } 42 }
 
-// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1824 }
-// { dg-error "declaration of" "" { target *-*-* } 1781 }
+// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1831 }
+// { dg-error "declaration of" "" { target *-*-* } 1788 }

[PATCH] rs6000: Disparage CTR and LR in movcc_internal1

[Segher Boessenkool]

Hi!

LRA likes to use CTR and LR to store CCmode values.  Not such a good
idea.  All other similar patterns disparage using CTR and LR; do so
here, too.

Committing to trunk.


Segher


2016-09-27  Segher Boessenkool  

* config/rs6000/rs6000.md (movcc_internal1): Disparage using CTR or LR.

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

diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 7b995ac..a9fabc1 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -6653,8 +6653,10 @@ (define_expand "movcc"
   "")
 
 (define_insn "*movcc_internal1"
-  [(set (match_operand:CC 0 "nonimmediate_operand" 
"=y,x,?y,y,r,r,r,r,r,cl,r,m")
-   (match_operand:CC 1 "general_operand" "y,r,r,O,x,y,r,I,h,r,m,r"))]
+  [(set (match_operand:CC 0 "nonimmediate_operand"
+   "=y,x,?y,y,r,r,r,r,r,*c*l,r,m")
+   (match_operand:CC 1 "general_operand"
+   " y,r, r,O,x,y,r,I,h,   r,m,r"))]
   "register_operand (operands[0], CCmode)
|| register_operand (operands[1], CCmode)"
   "@
-- 
1.9.3

Re: [v3 PATCH] Implement LWG 2729 for pair.

[Ville Voutilainen]

On 27 September 2016 at 03:16, Christophe Lyon
 wrote:
>   20_util/declval/requirements/1_neg.cc  (test for errors, line 2263)
>   20_util/declval/requirements/1_neg.cc (test for excess errors)
>   20_util/make_signed/requirements/typedefs_neg.cc  (test for errors, line 
> 1928)
>   20_util/make_signed/requirements/typedefs_neg.cc (test for excess errors)
>   20_util/make_unsigned/requirements/typedefs_neg.cc  (test for
> errors, line 1781)
>   20_util/make_unsigned/requirements/typedefs_neg.cc  (test for
> errors, line 1824)
>   20_util/make_unsigned/requirements/typedefs_neg.cc (test for excess errors)
>
> Error messages include:
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/type_traits:2270:
> error: static assertion failed: declval() must not be used!
>
> Is it just because the pattern in dg-error is *-*-* ?


Argh, I'll take a look. These errors come from the testsuite expecting
certain line numbers in certain
library headers, and adding code to said headers shifts the error lines.

Re: [v3 PATCH] Implement LWG 2729 for pair.

[Christophe Lyon]

Hi,


On 26 September 2016 at 14:54, Jonathan Wakely  wrote:
> On 24/09/16 21:13 +0300, Ville Voutilainen wrote:
>>
>> So, this has been applied to trunk, and also applies cleanly to the
>> gcc-6 branch, and we need
>> to backport it to fix PR libstdc++/77537. Ok for the gcc-6 branch?
>
>
> Yes, OK for gcc-6-branch too, as it fixes a regression since 5.x
>
>

I'm seeing regressions on the gcc-6-branch since this was committed,
on arm and aarch64 targets.
  - PASS now FAIL [PASS => FAIL]:

  20_util/declval/requirements/1_neg.cc  (test for errors, line 2263)
  20_util/declval/requirements/1_neg.cc (test for excess errors)
  20_util/make_signed/requirements/typedefs_neg.cc  (test for errors, line 1928)
  20_util/make_signed/requirements/typedefs_neg.cc (test for excess errors)
  20_util/make_unsigned/requirements/typedefs_neg.cc  (test for
errors, line 1781)
  20_util/make_unsigned/requirements/typedefs_neg.cc  (test for
errors, line 1824)
  20_util/make_unsigned/requirements/typedefs_neg.cc (test for excess errors)

Error messages include:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/gcc3/aarch64-none-linux-gnu/libstdc++-v3/include/type_traits:2270:
error: static assertion failed: declval() must not be used!

Is it just because the pattern in dg-error is *-*-* ?

Christophe

Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756

[Christophe Lyon]

Hi Jonathan,


On 23 September 2016 at 12:41, Jonathan Wakely  wrote:
> On 22/09/16 20:22 +0200, Christophe Lyon wrote:
>>
>> On 22 September 2016 at 15:25, Jonathan Wakely  wrote:
>>>
>>> On 22/09/16 12:15 +0100, Jonathan Wakely wrote:


 On 22/09/16 11:16 +0100, Jonathan Wakely wrote:
>
>
> (Somebody should fix PR58938 so exception_ptr is portable).



 Christophe, would you be able to test this patch?

 It uses a single global mutex for exception_ptr objects, which doesn't
 scale well but that probably isn't a problem for processors without
 lock-free atomics for single words.

 This also solves the problem of mismatched -march options, where the
 header is compiled for a CPU that supports the atomics but
 libstdc++.so was built for an older CPU that doesn't support them, and
 linking fails (as in https://gcc.gnu.org/PR58938#c13).
>>>
>>>
>>>
>>> We'd also need something like this extra piece, to ensure we don't
>>> leak exceptions. Currently __gxx_exception_cleanup assumes that if
>>> ATOMIC_INT_LOCK_FREE < 2 the referenceCount can never be greater than
>>> 1, because there are not exception_ptr objects that could increase it.
>>>
>>> If we enable exception_ptr unconditionally then that assumption
>>> doesn't hold. This patch uses the exception_ptr code to do the
>>> cleanup, under the same mutex as any other increments and decrements
>>> of the reference count.
>>>
>>> It's a bit of a hack though.
>>>
>> Should I have applied this one on top of the other?
>>
>> I ran a validation with it alone, and
>> arm-none-eabi with default mode, cpu, and fpu does not build:
>
>
> That's expected, the second patch requires the first one (you can't
> use exception_ptr unconditionally if it's only defined conditionally
> :-)
>
>
>> In file included from
>>
>> /tmp/9260164_29.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_throw.cc:27:0:
>>
>> /tmp/9260164_29.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/exception_ptr.h:43:4:
>> error: #error This platform does
>> not support exception propagation.
>> #  error This platform does not support exception propagation.
>>^
>> make[4]: *** [eh_throw.lo] Error 1
>>
>>
>> In addition, on arm-none-eabi --with-mode=thumb --with-cpu=cortex-a9,
>> I've noticed a regression in c++
>>  - PASS now FAIL [PASS => FAIL]:
>>
>>  g++.dg/opt/pr36449.C  -std=gnu++11 execution test
>>  g++.dg/opt/pr36449.C  -std=gnu++14 execution test
>>  g++.dg/opt/pr36449.C  -std=gnu++98 execution test
>>
>> My logs show:
>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>
>
> Strange, I don't see how my patch could cause that.
>

I've run validations with the 2 patches applied, and you can see the
results here:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/240339-pr58938-v3/report-build-info.html

As you can see there are several regressions, including:
  18_support/exception_ptr/40296.cc (test for excess errors)
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc:
In function 'bool test01()':
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc:25:
error: 'exception_ptr' is not a member of 'std'
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc:25:
note: suggested alternative: 'fexcept_t'
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/18_support/exception_ptr/40296.cc:27:
error: 'p' was not declared in this scope

when compiling with -march=armv5t on arm*linux* targets.

On arm-none-eabi, I still see the regressions I reported when gcc is configured
--with-mode=thumb --with-cpu=cortex-a9
  g++.dg/opt/pr36449.C  -std=gnu++11 execution test
  g++.dg/opt/pr36449.C  -std=gnu++14 execution test
  g++.dg/opt/pr36449.C  -std=gnu++98 execution test
I have no detail besides
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

Finally, on arm-none-eabi using default mode/cpu, some tests no longer
compile because:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(eh_ptr.o):
In function `__gx
x_dependent_exception_cleanup':
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_ptr.cc:241:
undefined reference to `__atomic_fetch_sub_4'
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/./libstdc++-v3/src/.libs/libstdc++.a(eh_ptr.o):
In function `eh_p
tr_mutex':
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_ptr.cc:39:
undefined reference to `__sync_synchronize'
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_ptr.cc:39:
undefined reference to `__sync_synchronize'
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_ptr.cc:39:
undefined reference to `__sync_synchronize'

[BUILDROBOT] tic6x-uclinux: undefined reference to `gnu_libc_printf_pointer_format(tree_node*, char const**)' (was: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905))

[Jan-Benedict Glaw]

Hi Martin,

On Thu, 2016-09-08 13:03:12 -0600, Martin Sebor  wrote:
> Attached is another update to the patch to address the last round
> of comments and suggestions, most notably to:
[...]

with the currently committed version, the tic6x-uclinux target fails,
see ie.
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=630308 :

g++-g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o cc1 c/c-lang.o 
c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o 
c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o 
c/c-array-notation.o c/c-fold.o c-family/c-common.o c-family/c-cppbuiltin.o 
c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o 
c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o 
c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o 
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o 
c-family/c-cilkplus.o c-family/array-notation-common.o c-family/cilk.o 
c-family/c-ubsan.o default-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a 
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a 
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a 
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a   -lmpc -lmpfr -lgmp 
-rdynamic -ldl  -L./../zlib -lz
c6x.o:(.data+0x778): undefined reference to 
`gnu_libc_printf_pointer_format(tree_node*, char const**)'
collect2: error: ld returned 1 exit status
/home/jbglaw/repos/gcc/gcc/c/Make-lang.in:84: recipe for target 'cc1' failed
make[1]: *** [cc1] Error 1
make[1]: Leaving directory '/home/jbglaw/build/tic6x-uclinux/build-gcc/gcc'
Makefile:4252: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2


Add another one for uClibc?

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
  Signature of:  Zensur im Internet? Nein danke!
  the second  :


signature.asc
Description: Digital signature

Re: [PATCH, LRA] Fix PR 77714

[Vladimir N Makarov]

On 09/26/2016 09:55 AM, Bernd Edlinger wrote:

Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?




Yes.  Thank you for working on the problem, Bernd.

Re: debug container mutex association

[François Dumont]

Fixed with attached patch.

François


On 26/09/2016 13:56, Andreas Schwab wrote:

FAIL: 23_containers/list/debug/invalidation/4.cc (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20160926/Build/m68k-linux/libstdc++-v3/include/debug/safe_sequence.tcc:89:
 error: 'void __gnu_debug::_Safe_iterator_base::_M_detach_single()' is 
protected within this context
/daten/aranym/gcc/gcc-20160926/Build/m68k-linux/libstdc++-v3/include/debug/safe_sequence.tcc:112:
 error: 'void __gnu_debug::_Safe_iterator_base::_M_detach_single()' is 
protected within this context

Andreas.



Index: include/debug/safe_base.h
===
--- include/debug/safe_base.h	(revision 240509)
+++ include/debug/safe_base.h	(working copy)
@@ -121,11 +121,11 @@
 void
 _M_detach();
 
+  public:
 /** Likewise, but not thread-safe. */
 void
 _M_detach_single() throw ();
 
-  public:
 /** Determines if we are attached to the given sequence. */
 bool
 _M_attached_to(const _Safe_sequence_base* __seq) const

Re: Implement -Wimplicit-fallthrough (version 9)

[Rainer Orth]

Hi Marek,

> On Mon, Sep 26, 2016 at 03:34:40PM +0200, Rainer Orth wrote:
>> Hi Marek,
>> 
>> > All right.  I'll commit the patch on Monday.
>> 
>> this patch caused quite some breakage: Ada, Solaris/x86 and SPARC don't
>> bootstrap any longer. 
>  
> Sorry about that.  I had tested Ada + x86_64/ppc64/aarch64, but couldn't
> test neither Solaris nor SPARC.

the Solaris/x86 and SPARC issues were minor; I was just astonished to
see that so much didn't work on the Ada side.

>> The following patch allows i386-pc-solaris2.12 and sparc-sun-solaris2.12
>> bootstraps continue.
>> 
>> Strangely, I needed to use gcc_fallthrough () in i386.c; a mere /* FALLTHRU 
>> */
>> had no effect.
>  
> Yes, this is expected.  /* FALLTHRU */ comments only work if the next token
> is a case label or default label.

Ok, that explains what's going on.  I guess it would be good to make
this explicit in invoke.texi since someone else is guaranteed to stumble
across this as well.

Thanks.
Rainer

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

Re: Implement -Wimplicit-fallthrough (version 9)

[Rainer Orth]

Hi Jakub,

> On Mon, Sep 26, 2016 at 03:34:40PM +0200, Rainer Orth wrote:
>> Ok for mainline if the bootstraps pass (with appropriate changelog
>> entries, of course)?
>
> Yes.

testing completed successfully, so I've installed the patch with this
ChangeLog entry:

2016-09-26  Rainer Orth  

gcc:
* config/i386/i386.c (ix86_print_operand)
[HAVE_AS_IX86_CMOV_SUN_SYNTAX]: Add gcc_fallthrough.
* config/sparc/sparc.c (check_pic): Add fallthrough comment.
(epilogue_renumber): Likewise.

gcc/ada:
* gcc-interface/decl.c: Fix fall through comment formatting.
* gcc-interface/misc.c: Likewise.
* gcc-interface/trans.c: Likewise.
* gcc-interface/utils.c: Likewise.
* gcc-interface/utils2.c: Likewise.

>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -17917,6 +17917,7 @@ ix86_print_operand (FILE *file, rtx x, i
>>  #ifdef HAVE_AS_IX86_CMOV_SUN_SYNTAX
>>if (ASSEMBLER_DIALECT == ASM_ATT)
>>  putc ('.', file);
>> +  gcc_fallthrough ();
>>  #endif
>
> Where have you been adding the /*FALLTHROUGH*/ ?  Before #endif or after it?

Before: seemed natural to me.

Rainer

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

Re: [PATCH] Fix PR tree-optimization/77550

[Bernd Edlinger]

On 09/26/16 21:19, Christophe Lyon wrote:
>
> Sorry for the delay, I've been travelling.
>
> Compilation is:
> .../xg++ 
> -B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/gcc/testsuite/g++/../../
> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/g++.dg/pr77550.C
> g++_tg.o -fno-diagnostics-show-caret -fdiagnostics-color=never
> -nostdinc++ 
> -I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/arm-none-eabi
> -I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include
> -I/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++
> -I/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/include/backward
> -I/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/util
> -fmessage-length=0 -std=c++14 -O3
> -L/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/./libstdc++-v3/src/.libs
> -B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/./libstdc++-v3/src/.libs
> -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o
> ./pr77550.exe
>
> Then, during execution, I have:
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> and that's all
>
> My gcc configuration flags are:
> --target=arm-none-eabi --disable-libgomp --disable-libmudflap
> --disable-libcilkrts --enable-checking --enable-languages=c,c++
> --with-newlib --disable-tls --with-mode=arm --with-cpu=cortex-a9
>
> Christophe
>

Interesting.  At this point it might be OK to open a new PR.

So far, I cannot reproduce, but I used also cortex-a9 but
target=arm-linux-gnueabihf.

Could you please start the command above manually and add
-save-temps ?


Thanks
Bernd.

Re: [Patch, avr] Backport fix for PR 65210 to gcc-5-branch

[Denis Chertykov]

Approved.
Please commit.

2016-09-26 15:30 GMT+03:00 Senthil Kumar Selvaraj
:
> Ping!
>
> Regards
> Senthil
> Senthil Kumar Selvaraj writes:
>
>> Hi,
>>
>>   Is it ok to backport PR 65210 to gcc-5-branch? The patch is already in
>>   6.x and trunk.
>>
>> Regards
>> Senthil
>>
>> gcc/ChangeLog
>>
>> 2016-09-22  Senthil Kumar Selvaraj  
>>
>>   Backport from trunk r227496
>>
>>   PR target/65210
>>   * config/avr/avr.c (avr_eval_addr_attrib): Look for io_low
>>   attribute as well.
>>
>> gcc/testsuite/ChangeLog
>>
>> 2016-09-22  Senthil Kumar Selvaraj  
>>
>>   Backport from trunk r227496
>>
>>   PR target/65210
>>   * gcc.target/avr/pr65210.c: New test.
>>
>> Index: gcc/config/avr/avr.c
>> ===
>> --- gcc/config/avr/avr.c  (revision 240340)
>> +++ gcc/config/avr/avr.c  (working copy)
>> @@ -9122,6 +9122,8 @@
>>if (SYMBOL_REF_FLAGS (x) & SYMBOL_FLAG_IO)
>>   {
>> attr = lookup_attribute ("io", DECL_ATTRIBUTES (decl));
>> +   if (!attr || !TREE_VALUE (attr))
>> + attr = lookup_attribute ("io_low", DECL_ATTRIBUTES (decl));
>> gcc_assert (attr);
>>   }
>>if (!attr || !TREE_VALUE (attr))
>>Index: gcc/testsuite/gcc.target/avr/pr65210.c
>> ===
>> --- gcc/testsuite/gcc.target/avr/pr65210.c(nonexistent)
>> +++ gcc/testsuite/gcc.target/avr/pr65210.c(working copy)
>> @@ -0,0 +1,7 @@
>> +/* { dg-do compile } */
>> +
>> +/* This testcase exposes PR65210. Usage of the io_low attribute
>> +   causes assertion failure because code only looks for the io
>> +   attribute if SYMBOL_FLAG_IO is set. */
>> +
>> +volatile char q __attribute__((io_low,address(0x81)));
>

Re: [PATCH] Fix PR tree-optimization/77550

[Christophe Lyon]

On 22 September 2016 at 22:30, Bernd Edlinger  wrote:
> On 09/22/16 21:30, Christophe Lyon wrote:
>> On 21 September 2016 at 22:20, Bernd Edlinger  
>> wrote:
>>> On 09/21/16 21:57, Christophe Lyon wrote:
 Hi,

 The new testcase pr77550.C fails on arm:
 /testsuite/g++.dg/pr77550.C:39:43: error: 'operator new' takes type
 'size_t' ('unsigned int') as first parameter [-fpermissive]
 compiler exited with status 1

 Christophe

>>>
>>> Yes, I see, thanks.  This should fix it.
>>>
>>> OK for trunk, gcc-6 after a while ?
>>>
>>>
>>> Bernd.
>>
>> Hi,
>>
>> The test now compiles and runs OK on most arm configurations, but
>> on arm-none-eabi --with-cpu=cortex-a9, execution fails:
>> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>> FAIL: g++.dg/pr77550.C   execution test
>>
>> And on arm-none-eabi with default cpu, the test still does not compile.
>>
>> Christophe
>>
>
> Hmm.  This test case is hardly worth it, because on my armv7hf target
> it doesn't even reproduce the original problem :(
>
> Could you send me the exact compile-flags and the error message
> please?
>

Sorry for the delay, I've been travelling.

Compilation is:
.../xg++ 
-B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/gcc/testsuite/g++/../../
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/g++.dg/pr77550.C
g++_tg.o -fno-diagnostics-show-caret -fdiagnostics-color=never
-nostdinc++ 
-I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/arm-none-eabi
-I/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include
-I/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++
-I/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/include/backward
-I/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=c++14 -O3
-L/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/./libstdc++-v3/src/.libs
-B/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/./libstdc++-v3/src/.libs
-Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm -o
./pr77550.exe

Then, during execution, I have:
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
and that's all

My gcc configuration flags are:
--target=arm-none-eabi --disable-libgomp --disable-libmudflap
--disable-libcilkrts --enable-checking --enable-languages=c,c++
--with-newlib --disable-tls --with-mode=arm --with-cpu=cortex-a9

Christophe


>
> Bernd.

Re: [PATCH 6/17][ARM] Add data processing intrinsics for float16_t.

[Christophe Lyon]

On 26 September 2016 at 15:19, Christophe Lyon
 wrote:
> On 26 September 2016 at 15:03, Ramana Radhakrishnan
>  wrote:
>> On Mon, Sep 26, 2016 at 1:48 PM, Christophe Lyon
>>  wrote:
>>> On 26 September 2016 at 11:43, Matthew Wahab  
>>> wrote:
 Hello,

 On 25/09/16 14:00, Christophe Lyon wrote:
>>>
>>>
>>> This patch adds the new intrinsics:
>>>   vbsl_f16, vbslq_f16, vdup_n_f16, vdupq_n_f16, vdup_lane_f16,
>>>   vdupq_lane_f16, vext_f16, vextq_f16, vmov_n_f16, vmovq_n_f16,
>>>   vrev64_f16, vrev64q_f16, vtrn_f16, vtrnq_f16, vuzp_f16, vuzpq_f16,
>>>   vzip_f16, vzipq_f16.
>>>
>>> This patch also updates the advsimd-intrinsics testsuite to test the f16
>>> variants for ARM targets. These intrinsics are only implemented in the
>>> ARM target so the tests are disabled for AArch64 using an extra
>>> condition on a new convenience macro FP16_SUPPORTED. This patch also
>>> disables, for the ARM target, the testsuite defined macro vdup_n_f16 as
>>> it is no longer needed.
>
>
> Since you committed this patch, I've noticed that libgcc fails to build
> when GCC is configured:
> --target arm-none-eabi and default cpu
> /tmp/9649048_29.tmpdir/ccuBwQJJ.s: Assembler messages:
> /tmp/9649048_29.tmpdir/ccuBwQJJ.s:64: Error: selected processor does
> not support ARM mode `movwlt r0,32768'
> /tmp/9649048_29.tmpdir/ccuBwQJJ.s:65: Error: selected processor does
> not support ARM mode `movwge r0,32767'
> make[4]: *** [_ssaddHQ.o] Error 1
> make[4]: Leaving directory
>
> `/tmp/9649048_29.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc1/arm-none-eabi/fpu/libgcc'
>


 I can't reproduce the failure, could you send the configure arguments for
 the build.

>>>
>>> If I'm not mistaken, that is:
>>>  --target=arm-none-eabi  --disable-nls --disable-libgomp
>>> --disable-libmudflap --disable-libcilkrts --enable-checking
>>> --enable-languages=c,c++ --with-newlib
>>>
>>> Maybe you've disabled multilibs?
>>
>>
>> I'm pretty sure I built this as part of reviewing all these patches
>> with --with-mutlib-list=aprofile and didnt' see any failures. Not sure
>> what's going on here.
>>
>
> I'm not using very recent binutils, (can't remember if that's 2.25 or 2.26,
> and I can't easily check remotely). Maybe something changed in
> the assembler?
>
I checked, and I am still using 2.25. Was there a change in gas
in this area since then?

Christophe

>> Ramana
>>>
 I've tried assembling the string 'movw r0, 32768' and get the error when
 -march=armv6kz or earlier. I suspect the new movhi and/or movhf patterns
 added earlier in the series need the architecture level added as a
 precondition but I'll need to look into it.

 Matthew
>>>
>>> Thanks,
>>>
>>> Christophe

[PATCH RESEND 2/2] Extend -falign-FOO=N to N[,M[,N2[,M2]]]

[Denys Vlasenko]

falign-functions=N is too simplistic.

Ingo Molnar ran some tests and it seems that on latest x86 CPUs, 64-byte 
alignment
of functions runs fastest (he tried many other possibilites):
this way, after a call CPU can fetch a lot of insns in the first cacheline fill.

However, developers are less than thrilled by the idea of a slam-dunk 64-byte
aligning everything. Too much waste:
On 05/20/2015 02:47 AM, Linus Torvalds wrote:
> At the same time, I have to admit that I abhor a 64-byte function
> alignment, when we have a fair number of functions that are (much)
> smaller than that.
>
> Is there some way to get gcc to take the size of the function into
> account? Because aligning a 16-byte or 32-byte function on a 64-byte
> alignment is just criminally nasty and wasteful.

This change makes it possible to align functions to 64-byte boundaries *if*
this does not introduce huge amount of padding.

Example syntax is -falign-functions=64,9: "align to 64 by skipping up to
9 bytes (not inclusive)". IOW: "after a call insn, CPU will always be able
to fetch at least 9 bytes of insns".

x86 had a tweak: -falign-functions=N with N > 8 was adding secondary alignment.
For example, falign-functions=10 was emitting this before every function:
.p2align 4,,9
.p2align 3
This tweak was removed by the previous patch. Now it is reinstated
by the logic that if falign-functions=N[,M] is specified and N > 8,
then default value of N2 is 8, not 1. But now this can be suppressed by
falign-functions=N,M,1 - which wasn't possible before.
In general, optional N2,M2 pair can be used to generate any secondary
alignment user wants.

Testing:

Tested that with -falign-functions=N (tried 8, 15, 16, 17...) the alignment
directives are the same before and after the patch.
Tested that -falign-functions=N,N (two equal parameters) works exactly
like -falign-functions=N.

No change from past behavior:
Tested that "-falign-functions" uses an arch-dependent alignment.
Tested that "-O2" uses an arch-dependent alignment.
Tested that "-O2 -falign-functions=N" uses explicitly given alignment.

2016-09-26  Denys Vlasenko  

* common.opt (-falign-functions=): Accept a string instead of integer.
(-falign-jumps=): Likewise.
(-falign-labels=): Likewise.
(-falign-loops=): Likewise.
* flags.h (struct target_flag_state): Revamp how alignment data is stored:
for each of four alignment types, store two pairs of log/maxskip values.
* toplev.c (read_uint): New function.
(read_log_maxskip): New function.
(parse_N_M): New function.
(init_alignments): Set align_FOO[0/1].log/maxskip from
specified falign-FOO=N[,M[,N[,M]]] options.
* varasm.c (assemble_start_function): Call two ASM_OUTPUT_MAX_SKIP_ALIGN
macros, first for N,M and second time for N2,M2 from
falign-functions=N,M,N2,M2. This generates 0, 1, or 2 align directives.
* config/aarch64/aarch64-protos.h (struct tune_params):
Change foo_align members from integers to strings.
* config/i386/i386.c (struct ptt): Likewise.
* config/aarch64/aarch64.c (_tunings):
Change foo_align field values from integers to strings.
* config/i386/i386.c (processor_target_table): Likewise.
* config/arm/arm.c (arm_override_options_after_change_1):
Fix if() condition to detect that -falign-functions is specified.
* config/i386/i386.c (ix86_default_align): Likewise.
* common/config/i386/i386-common.c (ix86_handle_option):
Remove conversion of malign_foo's to falign_foo's.
The warning is still emitted.
* doc/invoke.texi: Update option documentation.
* testsuite/gcc.target/i386/falign-functions.c: New file.

Index: gcc/common/config/i386/i386-common.c
===
--- gcc/common/config/i386/i386-common.c(revision 239860)
+++ gcc/common/config/i386/i386-common.c(working copy)
@@ -998,36 +998,17 @@ ix86_handle_option (struct gcc_options *opts,
}
   return true;
 
-
-  /* Comes from final.c -- no real reason to change it.  */
-#define MAX_CODE_ALIGN 16
-
 case OPT_malign_loops_:
   warning_at (loc, 0, "-malign-loops is obsolete, use -falign-loops");
-  if (value > MAX_CODE_ALIGN)
-   error_at (loc, "-malign-loops=%d is not between 0 and %d",
- value, MAX_CODE_ALIGN);
-  else
-   opts->x_align_loops = 1 << value;
   return true;
 
 case OPT_malign_jumps_:
   warning_at (loc, 0, "-malign-jumps is obsolete, use -falign-jumps");
-  if (value > MAX_CODE_ALIGN)
-   error_at (loc, "-malign-jumps=%d is not between 0 and %d",
- value, MAX_CODE_ALIGN);
-  else
-   opts->x_align_jumps = 1 << value;
   return true;
 
 case OPT_malign_functions_:
   warning_at (loc, 0,
  "-malign-functions is obsolete, use -falign-functions");
-  if (value > 

[PATCH RESEND 1/2] Temporary remove "at least 8 byte alignment" code from x86

[Denys Vlasenko]

This change drops forced alignment to 8 if requested alignment is higher
than 8: before the patch, -falign-functions=9 was generating

.p2align 4,,8
.p2align 3

which means: "align to 16 if the skip is 8 bytes or less; else align to 8".
After this change, ".p2align 3" is not emitted.

This behavior will be implemented differently by the next patch.

2016-09-26  Denys Vlasenko  

* config/i386/freebsd.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Remove "If N
is large, do at least 8 byte alignment" code.
* config/i386/gnu-user.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/iamcu.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/openbsdelf.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.
* config/i386/x86-64.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Likewise.

Index: gcc/config/i386/freebsd.h
===
--- gcc/config/i386/freebsd.h   (revision 239390)
+++ gcc/config/i386/freebsd.h   (working copy)
@@ -92,25 +92,17 @@ along with GCC; see the file COPYING3.  If not see
 
 /* A C statement to output to the stdio stream FILE an assembler
command to advance the location counter to a multiple of 1<= (1<<(LOG))) \
+fprintf ((FILE), "\t.p2align %d\n", (LOG));\
+  else \
fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP)); \
-   /* Make sure that we have at least 8 byte alignment if > 8 byte \
-  alignment is preferred.  */  \
-   if ((LOG) > 3   \
-   && (1 << (LOG)) > ((MAX_SKIP) + 1)  \
-   && (MAX_SKIP) >= 7) \
- fputs ("\t.p2align 3\n", (FILE)); \
-  }
\
 }  \
   } while (0)
 #endif
Index: gcc/config/i386/gnu-user.h
===
--- gcc/config/i386/gnu-user.h  (revision 239390)
+++ gcc/config/i386/gnu-user.h  (working copy)
@@ -94,24 +94,16 @@ along with GCC; see the file COPYING3.  If not see
 
 /* A C statement to output to the stdio stream FILE an assembler
command to advance the location counter to a multiple of 1<= (1<<(LOG))) \
+fprintf ((FILE), "\t.p2align %d\n", (LOG));\
+  else \
fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP)); \
-   /* Make sure that we have at least 8 byte alignment if > 8 byte \
-  alignment is preferred.  */  \
-   if ((LOG) > 3   \
-   && (1 << (LOG)) > ((MAX_SKIP) + 1)  \
-   && (MAX_SKIP) >= 7) \
- fputs ("\t.p2align 3\n", (FILE)); \
-  }
\
 }  \
   } while (0)
 #endif
Index: gcc/config/i386/iamcu.h
===
--- gcc/config/i386/iamcu.h (revision 239390)
+++ gcc/config/i386/iamcu.h (working copy)
@@ -62,23 +62,15 @@ see the files COPYING3 and COPYING.RUNTIME respect
 
 /* A C statement to output to the stdio stream FILE an assembler
command to advance the location counter to a multiple of 1<= (1<<(LOG))) \
+fprintf ((FILE), "\t.p2align %d\n", (LOG));\
+  else \
fprintf ((FILE), "\t.p2align %d,,%d\n", (LOG), (MAX_SKIP)); \
-   /* Make sure that we have at least 8 byte alignment if > 8 byte \
-  alignment is preferred.  */  \
-   if ((LOG) > 3   \
-   && (1 << (LOG)) > ((MAX_SKIP) + 1)  \
-   && (MAX_SKIP) >= 7) \
- fputs ("\t.p2align 3\n", (FILE)); \
-  }
\
 }  \
   } while (0)
 
Index: gcc/config/i386/openbsdelf.h
===
--- gcc/config/i386/openbsdelf.h(revision 239390)
+++ gcc/config/i386/openbsdelf.h(working copy)
@@ -63,24 +63,16 @@ along with GCC; see the file COPYING3.  If not see
 
 /* A C statement to output to the stdio stream FILE an assembler

[Committed] PR fortran/77420

[Steve Kargl]

This is a follow-up commit to really fix PR fortran/77420.
The code has been in my tree for 2 weeks and has passed
numerous regression tests.

2016-09-26  Steven G. Kargl  

PR fortran/77420
* trans-common.c:  Handle array elements in equivalence when
the lower and upper bounds of array spec are NULL.
 
2016-09-26  Steven G. Kargl  

PR fortran/77420
* gfortran.dg/pr77420_1.f90: New test.
* gfortran.dg/pr77420_2.f90: Ditto.
* gfortran.dg/pr77420_3.f90: New test. Requires ...
* gfortran.dg/pr77420_4.f90: this file.

-- 
Steve
Index: gcc/fortran/trans-common.c
===
--- gcc/fortran/trans-common.c	(revision 240140)
+++ gcc/fortran/trans-common.c	(working copy)
@@ -805,13 +805,21 @@ element_number (gfc_array_ref *ar)
   if (ar->dimen_type[i] != DIMEN_ELEMENT)
 gfc_internal_error ("element_number(): Bad dimension type");
 
-  mpz_sub (n, *get_mpz (ar->start[i]), *get_mpz (as->lower[i]));
+  if (as && as->lower[i])
+	mpz_sub (n, *get_mpz (ar->start[i]), *get_mpz (as->lower[i]));
+  else
+	mpz_sub_ui (n, *get_mpz (ar->start[i]), 1);
  
   mpz_mul (n, n, multiplier);
   mpz_add (offset, offset, n);
  
-  mpz_sub (extent, *get_mpz (as->upper[i]), *get_mpz (as->lower[i]));
-  mpz_add_ui (extent, extent, 1);
+  if (as && as->upper[i] && as->lower[i])
+	{
+	  mpz_sub (extent, *get_mpz (as->upper[i]), *get_mpz (as->lower[i]));
+	  mpz_add_ui (extent, extent, 1);
+	}
+  else
+	mpz_set_ui (extent, 0);
  
   if (mpz_sgn (extent) < 0)
 mpz_set_ui (extent, 0);
Index: gcc/testsuite/gfortran.dg/pr77420_1.f90
===
--- gcc/testsuite/gfortran.dg/pr77420_1.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr77420_1.f90	(working copy)
@@ -0,0 +1,15 @@
+! { dg-do compile }
+module test_equivalence
+  real, private :: array1(100)
+  real, private :: array2(100)
+  equivalence(array1(3),array2(3))
+end module test_equivalence
+
+module mymodule
+  use test_equivalence
+  real, dimension(:), allocatable :: array1
+end module mymodule
+
+program test
+  use mymodule
+end program test
Index: gcc/testsuite/gfortran.dg/pr77420_2.f90
===
--- gcc/testsuite/gfortran.dg/pr77420_2.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr77420_2.f90	(working copy)
@@ -0,0 +1,15 @@
+! { dg-do compile }
+module test_equivalence
+  real, private :: array1(100)
+  real, private :: array2(100)
+  equivalence(array1,array2)
+end module test_equivalence
+
+module mymodule
+  use test_equivalence
+  real, dimension(:), allocatable :: array1
+end module mymodule
+
+program test
+  use mymodule
+end program test
Index: gcc/testsuite/gfortran.dg/pr77420_3.f90
===
--- gcc/testsuite/gfortran.dg/pr77420_3.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr77420_3.f90	(working copy)
@@ -0,0 +1,9 @@
+! { dg-do link }
+! { dg-additional-sources pr77420_4.f90 }
+!
+module h5global
+  implicit none
+  integer :: h5p_default_f, h5p_flags
+  equivalence(h5p_flags, h5p_default_f)
+end module h5global
+! { dg-final { cleanup-modules "h5global" } }
Index: gcc/testsuite/gfortran.dg/pr77420_4.f90
===
--- gcc/testsuite/gfortran.dg/pr77420_4.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr77420_4.f90	(working copy)
@@ -0,0 +1,10 @@
+! { dg-do compile { target { ! *-*-* } } }
+!
+program bug
+  use H5GLOBAL
+  implicit none
+  integer :: i
+  i=H5P_DEFAULT_F
+end program bug
+
+

Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math

[Toon Moene]

On 09/26/2016 04:01 PM, Fritz Reese wrote:


All,

Attached is a patch extending the GNU Fortran front-end to support
some additional math intrinsics, enabled with a new compile flag
-fdec-math. The flag adds the COTAN intrinsic (cotangent), as well as
degree versions of all trigonometric intrinsics (SIND, TAND, ACOSD,
etc...). This extension allows for further compatibility with legacy
code that depends on the compiler to support such intrinsic functions.


Don't you want an option name like -fdegree-trigon-math ? Note that 
option name lengths are hardly a problem, as most end up in scripts and 
make files ... Whether support for COTAN (in radians) should be part of 
this option - I rather had it not.


Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

Re: [PATCH, 1/7] Move memory model declarations in memmodel.h

[Richard Biener]

On September 26, 2016 7:39:13 PM GMT+02:00, Thomas Preudhomme 
 wrote:
>On 26/09/16 18:22, Thomas Preudhomme wrote:
>>
>> I committed as is because emit-rtl.h uses enum memmodel so all files
>that
>> includes it must be updated. This gets worse because tm.h uses
>emit-rtl.h so all
>> target needs to be updated as well. The diff was becoming big so I
>decided to
>> keep it separate. I'll post the patch once it's complete and have
>gone through a
>> few bootstrap.
>
>I'm wondering whether memmodel.h should also be listed in
>PLUGIN_HEADERS in 
>gcc/Makefile.in?

Yes.

>Best regards,
>
>Thomas

Re: [PATCH GCC][v2]Simplify alias check code generation in vectorizer

[Richard Biener]

On September 26, 2016 5:46:28 PM GMT+02:00, Bernd Edlinger 
 wrote:
>Hi,
>
>>@@ -2310,7 +2313,8 @@ create_intersect_range_checks_index
>(loop_vec_info loop_vinfo, tree *cond_expr,
>>   gcc_assert (TREE_CODE (DR_STEP (dr_a.dr)) == INTEGER_CST);
>> 
>>   bool neg_step = tree_int_cst_compare (DR_STEP (dr_a.dr),
>size_zero_node) < 0;
>>-  unsigned HOST_WIDE_INT abs_step = tree_to_uhwi (DR_STEP (dr_a.dr));
>>+  unsigned HOST_WIDE_INT abs_step =
>>+absu_hwi (tree_to_shwi (DR_STEP (dr_a.dr)));
>>   if (neg_step)
>> abs_step = -abs_step;
>
>Hmmm...
>
>but you must remove the neg_step if you do this.

The negation, yes.  Neg_step is used later as well.

Richard.

>Right?
>
>
>Bernd.

Re: [PATCH 5/5] rs6000: Separate shrink-wrapping

[David Edelsohn]

On Fri, Sep 23, 2016 at 4:21 AM, Segher Boessenkool
 wrote:
> This implements the hooks for separate shrink-wrapping for rs6000.
> It handles GPRs and LR.  The GPRs get a component number corresponding
> to their register number; LR gets component number 0.
>
>
> 2016-09-23  Segher Boessenkool  
>
> * config/rs6000/rs6000.c (machine_function): Add new fields
> gpr_is_wrapped_separately and lr_is_wrapped_separately.
> (TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS,
> TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB,
> TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS,
> TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS,
> TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS,
> TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Define.
> (rs6000_get_separate_components): New function.
> (rs6000_components_for_bb): New function.
> (rs6000_disqualify_components): New function.
> (rs6000_emit_prologue_components): New function.
> (rs6000_emit_epilogue_components): New function.
> (rs6000_set_handled_components): New function.
> (rs6000_emit_prologue): Don't emit LR save if 
> lr_is_wrapped_separately.
> Don't emit GPR saves if gpr_is_wrapped_separately for that register.
> (rs6000_emit_epilogue): Don't emit GPR restores if
> gpr_is_wrapped_separately for that register.  Don't make a
> REG_CFA_RESTORE note for registers we did not restore, either.

The rs6000 bits are okay when the rest of the shrink-wrapping
infrastructure is approved.

Thanks, David

Re: [PATCH, 1/7] Move memory model declarations in memmodel.h

[Thomas Preudhomme]

On 26/09/16 18:22, Thomas Preudhomme wrote:


I committed as is because emit-rtl.h uses enum memmodel so all files that
includes it must be updated. This gets worse because tm.h uses emit-rtl.h so all
target needs to be updated as well. The diff was becoming big so I decided to
keep it separate. I'll post the patch once it's complete and have gone through a
few bootstrap.


I'm wondering whether memmodel.h should also be listed in PLUGIN_HEADERS in 
gcc/Makefile.in?


Best regards,

Thomas

Re: [PATCH, 1/7] Move memory model declarations in memmodel.h

[Thomas Preudhomme]

On 26/09/16 11:53, Richard Biener wrote:

On Mon, 26 Sep 2016, Thomas Preudhomme wrote:




On 26/09/16 10:15, Richard Biener wrote:

On Thu, 22 Sep 2016, Thomas Preudhomme wrote:


Hi,

This patch is part of a patch series to add support for ARMv8-M[1] to GCC.
This specific patch moves memory model declarations in memmodel.h.

Currently, is_mm_* memory model related functions are declared in tree.h
which
prevents using them in constraints machine description files. This patch
move
this functions into a new memmodel.h header to allow such a thing and
update
all users of this function to include the new header.


Ok.  I wonder whether we can move the memmodel stuff from coretypes
as well then?


It's not needed for using what's in there in constraints.md but would be good
for consistency I think. Do you want me to add it to the patch or make a
separate one and commit this one?


If it's trivial to include then go with this patch, if it requires work
then as followup is fine with me.


I committed as is because emit-rtl.h uses enum memmodel so all files that 
includes it must be updated. This gets worse because tm.h uses emit-rtl.h so all 
target needs to be updated as well. The diff was becoming big so I decided to 
keep it separate. I'll post the patch once it's complete and have gone through a 
few bootstrap.


Best regards,

Thomas

Re: parallel/algo.h cleanup

[Jonathan Wakely]

On 25/09/16 17:23 +0200, François Dumont wrote:

Hi

   Trivial patch to cleanup parallel/algo.h by generalizing usage of 
std::__iterator_category.


   * include/parallel/algo.h: Generalize usage of 
std::__iterator_category.

   Adjust whitespaces.


N.B. for a patch of this size it would have been easier to review the
whitespace changes separately from the substantial changes.



   Tested under Linux x86_64 parallel mode.


OK for trunk, but please also test normal mode before committing. It
shouldn't cause any problems, but best to be sure.

Re: [wwwdocs] Add some missing C++17 features

[Jonathan Wakely]

On 26/09/16 18:35 +0200, Jakub Jelinek wrote:

Hi!

The following patch adds some missing C++1z features to the table (wording
from
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#recs.cpp17
except for P0386R2 which is too new for that (Jon, can you look up the
feature test macro if any from newer SD-6 draft?).


The latest draft of SD-6 says __cpp_inline_variables >= 201606 for
that.


Dunno what to do with P0400R0 that clang cxx_status.html lists too.


IMHO we don't need a separate entry for that.

Re: [PATCH 1/5] separate shrink-wrap: New command-line flag, status flag, hooks, and doc

[Jeff Law]

On 09/23/2016 02:21 AM, Segher Boessenkool wrote:

This patch adds a new command-line flag "-fshrink-wrap-separate", a status
flag "shrink_wrapped_separate", hooks for abstracting the target components,
and documentation for all those.


2016-09-23  Segher Boessenkool  

* common.opt (-fshrink-wrap-separate): New flag.
* doc/invoke.texi: Document it.
* doc/tm.texi.in (Shrink-wrapping separate components): New subsection.
* doc/tm.texi: Regenerate.
* emit-rtl.h (struct rtl_data): New field shrink_wrapped_separate.
* target.def (shrink_wrap): New hook vector.
(get_separate_components, components_for_bb, disqualify_components,
emit_prologue_components, emit_epilogue_components,
set_handled_components): New hooks.

---
 gcc/common.opt  |  4 
 gcc/doc/invoke.texi | 11 +-
 gcc/doc/tm.texi | 63 +
 gcc/doc/tm.texi.in  | 38 
 gcc/emit-rtl.h  |  4 
 gcc/target.def  | 57 
 6 files changed, 176 insertions(+), 1 deletion(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index fa1c036..1a38d12 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2189,6 +2189,10 @@ Common Report Var(flag_shrink_wrap) Optimization
 Emit function prologues only before parts of the function that need it,
 rather than at the top of the function.

+fshrink-wrap-separate
+Common Report Var(flag_shrink_wrap_separate) Init(1) Optimization
+Shrink-wrap parts of the prologue and epilogue separately.
+
 fsignaling-nans
 Common Report Var(flag_signaling_nans) Optimization SetByCombined
 Disable optimizations observable by IEEE signaling NaNs.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 8eb5eff..464b737 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -397,7 +397,8 @@ Objective-C and Objective-C++ Dialects}.
 -fschedule-insns -fschedule-insns2 -fsection-anchors @gol
 -fselective-scheduling -fselective-scheduling2 @gol
 -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops @gol
--fsemantic-interposition -fshrink-wrap -fsignaling-nans @gol
+-fsemantic-interposition -fshrink-wrap -fshrink-wrap-separate @gol
+-fsignaling-nans @gol
 -fsingle-precision-constant -fsplit-ivs-in-unroller @gol
 -fsplit-paths @gol
 -fsplit-wide-types -fssa-backprop -fssa-phiopt @gol
@@ -6396,6 +6397,7 @@ compilation time.
 -fmove-loop-invariants @gol
 -freorder-blocks @gol
 -fshrink-wrap @gol
+-fshrink-wrap-separate @gol
 -fsplit-wide-types @gol
 -fssa-backprop @gol
 -fssa-phiopt @gol
@@ -7306,6 +7308,13 @@ Emit function prologues only before parts of the 
function that need it,
 rather than at the top of the function.  This flag is enabled by default at
 @option{-O} and higher.

+@item -fshrink-wrap-separate
+@opindex fshrink-wrap-separate
+Shrink-wrap separate parts of the prologue and epilogue separately, so that
+those parts are only executed when needed.
+This option is on by default, but has no effect unless @option{-fshrink-wrap}
+is also turned on.
This option also has no effect if the target has not implemented support 
for separate shrink wrapping.   Or something like that seems appropriate 
here.


I think with that change this patch is fine and can be committed with 
the main part once approved.


jeff

Re: [PATCH 5/5] rs6000: Separate shrink-wrapping

[Jeff Law]

On 09/23/2016 02:21 AM, Segher Boessenkool wrote:

This implements the hooks for separate shrink-wrapping for rs6000.
It handles GPRs and LR.  The GPRs get a component number corresponding
to their register number; LR gets component number 0.


2016-09-23  Segher Boessenkool  

* config/rs6000/rs6000.c (machine_function): Add new fields
gpr_is_wrapped_separately and lr_is_wrapped_separately.
(TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS,
TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB,
TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS,
TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS,
TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS,
TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Define.
(rs6000_get_separate_components): New function.
(rs6000_components_for_bb): New function.
(rs6000_disqualify_components): New function.
(rs6000_emit_prologue_components): New function.
(rs6000_emit_epilogue_components): New function.
(rs6000_set_handled_components): New function.
(rs6000_emit_prologue): Don't emit LR save if lr_is_wrapped_separately.
Don't emit GPR saves if gpr_is_wrapped_separately for that register.
(rs6000_emit_epilogue): Don't emit GPR restores if
gpr_is_wrapped_separately for that register.  Don't make a
REG_CFA_RESTORE note for registers we did not restore, either.
Just to be explicit, I'm assuming you and the other ppc port maintainers 
will handle final review/approval on this.  I've referred back to this 
patch to see how the various target independent bits interact, but I 
haven't looked closely at this patch.


jeff

Re: [PATCH 2/5] dce: Don't dead-code delete separately wrapped restores

[Jeff Law]

On 09/23/2016 02:21 AM, Segher Boessenkool wrote:

If there is a separately wrapped register restore on some path that
is dead (say, control goes into an endless loop after it), then we
cannot delete that restore because that would confuse the DWARF CFI
(if there is another path joining after this).
This happens with gcc.dg/torture/pr53168.c, for example.


2016-09-23  Segher Boessenkool  

* dce.c (delete_unmarked_insns): Don't delete instructions with
a REG_CFA_RESTORE note.

OK and can go in now IMHO.
jeff

Re: [PATCH 3/5] regrename: Don't rename restores

[Jeff Law]

On 09/23/2016 02:21 AM, Segher Boessenkool wrote:

A restore is supposed to restore some certain register.  Restoring it
into some other register will not work.  Don't.


2016-09-23  Segher Boessenkool  

* regrename.c (build_def_use): Invalidate chains that have a
REG_CFA_RESTORE on some instruction.

---
 gcc/regrename.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/gcc/regrename.c b/gcc/regrename.c
index 54c7768..00a5d02 100644
--- a/gcc/regrename.c
+++ b/gcc/regrename.c
@@ -1867,6 +1867,12 @@ build_def_use (basic_block bb)
scan_rtx (insn,  (note, 0), NO_REGS, terminate_dead,
  OP_IN);
  }
+
+ /* Step 8: Kill the chains involving register restores.  Those
+should restore _that_ register.  */
+ for (note = REG_NOTES (insn); note; note = XEXP (note, 1))
+   if (REG_NOTE_KIND (note) == REG_CFA_RESTORE)
+ scan_rtx (insn,  (note, 0), NO_REGS, mark_all_read, OP_IN);
}
   else if (DEBUG_INSN_P (insn)
   && !VAR_LOC_UNKNOWN_P (INSN_VAR_LOCATION_LOC (insn)))
Seems like a good thing regardless of the shrink-wrapping changes. 
There's a comment about 200 lines earlier (egad) which outlines the 
steps.  Can you please add a comment there too.


It would probably be a good idea to refactor build_def_use a bit, but 
I'd understand if you don't want to tackle that.  I don't think that 
desire should block this patch.


As I've said before, I'm not sure we're getting CFA notes right, 
particularly on the older ports, but I don't think that should block 
this patch.



With the earlier comment update change this is OK.

jeff

[wwwdocs] Add some missing C++17 features

[Jakub Jelinek]

Hi!

The following patch adds some missing C++1z features to the table (wording
from
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#recs.cpp17
except for P0386R2 which is too new for that (Jon, can you look up the
feature test macro if any from newer SD-6 draft?).
Dunno what to do with P0400R0 that clang cxx_status.html lists too.

My understanding is that N4051 has been implemented with
2014-07-25  Edward Smith-Rowland  <3dw...@verizon.net>

Implement N4051 - Allow typename in a template template parameter
P0002R1 with
2016-09-14  Marek Polacek  

* typeck.c (cp_build_unary_op): Diagnose incrementing boolean
expressions.  Tweak an error message.
and P0061R1 with
2014-10-01  Edward Smith-Rowland  <3dw...@verizon.net>

Implement SD-6: SG10 Feature Test Recommendations
* internal.h (lexer_state, spec_nodes): Add in__has_include__.

Ok for wwwdocs?

Index: cxx-status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-status.html,v
retrieving revision 1.21
diff -u -p -r1.21 cxx-status.html
--- cxx-status.html 26 Sep 2016 15:56:46 -  1.21
+++ cxx-status.html 26 Sep 2016 16:29:47 -
@@ -102,6 +102,18 @@
__cpp_static_assert = 201411 
 
 
+  New Rules for auto deduction from braced-init-list
+  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3922.html;>N3922
 
+  No
+  
+
+
+  Allow typename in a template template parameter
+  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4051.html;>N4051
 
+  5
+  
+
+
[[fallthrough]] attribute 
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0188r1.pdf;>P0188R1
   7
@@ -226,6 +238,42 @@
   No
   __cpp_structured_bindings >= 201606
 
+
+  Remove Deprecated Use of the register Keyword
+  http://wg21.link/p0001;>P0001R1 
+  No
+  
+
+
+  Remove Deprecated operator++(bool)
+  http://wg21.link/p0002;>P0002R1 
+  7
+  
+
+
+  Make exception specifications be part of the type system
+  http://wg21.link/p0012;>P0012R1 
+  No
+  __cpp_noexcept_function_type >= 201510
+
+
+  __has_include for C++17
+  http://wg21.link/p0061;>P0061R1 
+  5
+  
+
+
+  Rewording inheriting constructors (core issue 1941 et al)
+  http://wg21.link/p0136;>P0136R1 
+  No
+  __cpp_inheriting_constructors >= 201511
+
+
+  Inline variables
+  http://wg21.link/p0386;>P0386R2 
+  No
+  ???
+
   
 
   Technical Specifications

Jakub

Re: Ping Re: Make max_align_t respect _Float128 [version 3]

[Jeff Law]

On 09/19/2016 09:58 AM, Joseph Myers wrote:

Ping.  This patch
 is pending
review.

OK.

I never like adding more conditionals to stddef.h, but it's likely 
unavoidable in this case.


jeff

Re: [PATCH] Disable sim build for ARC in top-level configure.ac

[Jeff Law]

On 09/22/2016 06:12 AM, Anton Kolesov wrote:

Hi,

This disables "sim" build for ARC, otherwise it is required to
pass --disable-sim to top-level configure.

Anton


0001-Disable-sim-builds-for-ARC-in-top-level-configure.ac.patch


From 1fb11bf060ef0bccb0dd949fbf7ea63c763f008d Mon Sep 17 00:00:00 2001
From: Anton Kolesov 
Date: Tue, 21 Jun 2016 13:51:36 +0300
Subject: [PATCH] Disable sim build for ARC in top-level configure.ac

Sim doesn't support ARC, so it should be disabled by default for it.

2016-09-22  Anton Kolesov  

* configure.ac: Disable sim for ARC.
* configure: Regenerate.

Thanks.  Installed on the trunk.

jeff

Re: [PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

[Andreas Schwab]

On Sep 26 2016, Bernhard Reutner-Fischer  wrote:

> On 26 September 2016 10:27:13 CEST, Andreas Schwab  wrote:
>>On Sep 22 2016, Bernhard Reutner-Fischer  wrote:
>>
>>> On 22 September 2016 11:11:42 CEST, Andreas Schwab 
>>wrote:
On Sep 22 2016, Sebastian Huber 
wrote:

> diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
> index 6d897be..d7db435 100644
> --- a/libstdc++-v3/acinclude.m4
> +++ b/libstdc++-v3/acinclude.m4
> @@ -3490,9 +3490,10 @@ EOF
>AC_LANG_RESTORE
>  
># Set atomicity_dir to builtins if all but the long long test
above passes.
> -  if test "$glibcxx_cv_atomic_bool" = yes \
> +  if { test "$glibcxx_cv_atomic_bool" = yes \
>   && test "$glibcxx_cv_atomic_short" = yes \
> - && test "$glibcxx_cv_atomic_int" = yes; then
> + && test "$glibcxx_cv_atomic_int" = yes } \

You need a semicolon (or newline) before }.
>>>
>>> Please remind me why you need curly braces at all?
>>
>>Shell operand precedence is non-intuitive.
>
> [ ... -a ... -a ... ] as per at least SUSv4.

That is even worse.  POSIX marks it as obsolescent.

Andreas.

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

Re: [PATCH] Fixed up missing semicolons.

[Jeff Law]

On 09/23/2016 09:28 AM, lhmouse wrote:

Hi GCC developers,
Today I was trying bootstrapping GCC 7.0.0 and stage 1 compilation
failed because of two missing semicolons. After this patch was applied,
xgcc could be built successfully, although it still failed the self-test.

--
Best regards,
lh_mouse
2016-09-23



From 1133ae49102751b24cfd0368986a63f482afe8d0 Mon Sep 17 00:00:00 2001
From: lhmouse 
Date: Fri, 23 Sep 2016 19:11:03 +0800
Subject: [PATCH] Fixed up missing semicolons.

Thanks.  I've applied this to the trunk.

I don't have your full name for the ChangeLog entry.  If you want to 
pass that along, I'll fix it retroactively.


jeff

Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math

[Tobias Burnus]

Fritz Reese wrote:
> Attached is a patch extending the GNU Fortran front-end to support
> some additional math intrinsics, enabled with a new compile flag
> -fdec-math. The flag adds the COTAN intrinsic (cotangent), as well as
> degree versions of all trigonometric intrinsics (SIND, TAND, ACOSD,
> etc...).
>
> + /* There is no builtin mpc_cot, so compute x = 1 / tan (x).  */
> + val = >value.complex;
> + mpc_tan (*val, *val, GFC_MPC_RND_MODE);
> + mpc_div (*val, one, *val, GFC_MPC_RND_MODE);

The internet remarks: TAN(x) for x -> pi/2 goes to +inf or -inf - while
COTAN(pi/2) == 0. For values near pi/2, using cos(x)/sin(x) should be
numerically better than 1/tan(x). [Cf. mpfr_sin_cos  and BUILT_IN_SINCOS.]

I am not sure how big the prevision difference really is. A quick test
showed results which didn't look to bad:

implicit none
real(8), volatile  :: x
x = 3.14159265358d0/2.0d0
print '(g0)', cotan(x), cos(x)/sin(x), cotan(x)-cos(x)/sin(x)
end

yields:

0.48965888601467483E-011
0.48965888601467475E-011
0.80779356694631609E-027

Usint N[1/Tan[314159265358/10^11/2],200], Mathematica shows
  4.8966192313216916397514812338... * 10^12.
I am not quite sure whether I should expect that already the 5th digit
differs from the results above.


> mpfr_set_d (tmp, 180.0l, GFC_RND_MODE);

With some fonts the L after 180.0 looks like a one; I was initially
puzzled why one uses not 180 but 180.01. Hence, I'd prefer an "L" instead
of an "l".

However, the second argument of mpfr_set_d is a "double" and 180.0 is
already a double. Hence, one can even completely get rid of the "l".



Regarding the decimal trigonometric functions, the internet suggests to
use
   sin (fmod ((x), 360) * M_PI / 180)
instead of
   sin (x * M_PI / 180)
to yield better results for angles which are larger than +/-360 degrees.


Cheers,

Tobias

[wwwdocs] [[fallthrough]] attribute is supported in GCC 7

[Marek Polacek]

... so update C++1z Language Features.

Applying.

Index: projects/cxx-status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-status.html,v
retrieving revision 1.20
diff -u -r1.20 cxx-status.html
--- projects/cxx-status.html23 Sep 2016 17:40:54 -  1.20
+++ projects/cxx-status.html26 Sep 2016 11:29:33 -
@@ -104,7 +104,7 @@
 
[[fallthrough]] attribute 
   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0188r1.pdf;>P0188R1
-  No (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652;>bug 7652)
+  7
__has_cpp_attribute(fallthrough)
 
 

Marek

Re: [PATCH v2] [RTEMS] Always use atomic builtins for libstdc++

[Bernhard Reutner-Fischer]

On 26 September 2016 10:27:13 CEST, Andreas Schwab  wrote:
>On Sep 22 2016, Bernhard Reutner-Fischer  wrote:
>
>> On 22 September 2016 11:11:42 CEST, Andreas Schwab 
>wrote:
>>>On Sep 22 2016, Sebastian Huber 
>>>wrote:
>>>
 diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
 index 6d897be..d7db435 100644
 --- a/libstdc++-v3/acinclude.m4
 +++ b/libstdc++-v3/acinclude.m4
 @@ -3490,9 +3490,10 @@ EOF
AC_LANG_RESTORE
  
# Set atomicity_dir to builtins if all but the long long test
>>>above passes.
 -  if test "$glibcxx_cv_atomic_bool" = yes \
 +  if { test "$glibcxx_cv_atomic_bool" = yes \
   && test "$glibcxx_cv_atomic_short" = yes \
 - && test "$glibcxx_cv_atomic_int" = yes; then
 + && test "$glibcxx_cv_atomic_int" = yes } \
>>>
>>>You need a semicolon (or newline) before }.
>>
>> Please remind me why you need curly braces at all?
>
>Shell operand precedence is non-intuitive.

[ ... -a ... -a ... ] as per at least SUSv4.

thanks

Re: [PR77719] Fix ICE in pp_string, at pretty-print.c:955

[Jeff Law]

On 09/25/2016 08:39 PM, kugan wrote:



On 25/09/16 04:50, kugan wrote:

Hi,

In make_new_ssa_for_def (tree-reassoc.c) we should use gimple_get_lhs to
get lhs instead of gimple_assign_lhs as stmt can be builtins too.
Attached patch fixes this.

Testcase from PR (attached) seems to fail. I dont any fortran so I didnt
try fixing it. Any help here is appreciate. The log is:


Here is a patch with the testcase based on the feedback from Joost
VandeVondele and Dominique d'Humieres. Bootstrapped and regression
tested on x86_64-linux-gnu with no new regressions.

Is this OK for trunk?

Thanks,
kugan

gcc/testsuite/ChangeLog:

2016-09-25  Kugan Vivekanandarajah  

* gfortran.dg/pr77719.f90: New test.

gcc/ChangeLog:

2016-09-25  Kugan Vivekanandarajah  

* tree-ssa-reassoc.c (make_new_ssa_for_def): Use gimple_get_lhs to
get lhs
instead of gimple_assign_lhs as stmt can be builtins too.


OK.
jeff

Re: C++ PATCH for __has_cpp_attribute and fallthrough

[Jason Merrill]

OK.

On Mon, Sep 26, 2016 at 8:23 AM, Marek Polacek  wrote:
> This patch updates __has_cpp_attribute for fallthrough, which is now 
> supported.
>
> The system.h hunk should aid people building trunk GCC with older GCC 7 not
> supporting this attribute yet.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2016-09-26  Marek Polacek  
>
> * c-lex.c (c_common_has_attribute): Handle attribute fallthrough.
>
> * system.h: Use __has_attribute to check whether the fallthrough
> attribute is supported.
>
> * g++.dg/cpp1z/feat-cxx1z.C: Test attribute fallthrough.
>
> diff --git gcc/c-family/c-lex.c gcc/c-family/c-lex.c
> index 829c18b..5c6496e 100644
> --- gcc/c-family/c-lex.c
> +++ gcc/c-family/c-lex.c
> @@ -350,7 +350,8 @@ c_common_has_attribute (cpp_reader *pfile)
>   else if (is_attribute_p ("deprecated", attr_name))
> result = 201309;
>   else if (is_attribute_p ("maybe_unused", attr_name)
> -  || is_attribute_p ("nodiscard", attr_name))
> +  || is_attribute_p ("nodiscard", attr_name)
> +  || is_attribute_p ("fallthrough", attr_name))
> result = 201603;
>   if (result)
> attr_name = NULL_TREE;
> diff --git gcc/system.h gcc/system.h
> index 8ca71cf..0952e4f 100644
> --- gcc/system.h
> +++ gcc/system.h
> @@ -746,8 +746,12 @@ extern void fancy_abort (const char *, int, const char 
> *) ATTRIBUTE_NORETURN;
>  #define gcc_unreachable() (fancy_abort (__FILE__, __LINE__, __FUNCTION__))
>  #endif
>
> -#if GCC_VERSION >= 7000
> -# define gcc_fallthrough() __attribute__((fallthrough))
> +#if GCC_VERSION >= 7000 && defined(__has_attribute)
> +# if __has_attribute(fallthrough)
> +#  define gcc_fallthrough() __attribute__((fallthrough))
> +# else
> +#  define gcc_fallthrough()
> +# endif
>  #else
>  # define gcc_fallthrough()
>  #endif
> diff --git gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C 
> gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C
> index 982572e..71c8c7d 100644
> --- gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C
> +++ gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C
> @@ -370,6 +370,12 @@
>  #error "__has_cpp_attribute(nodiscard) != 201603"
>  #  endif
>
> +#  if ! __has_cpp_attribute(fallthrough)
> +#error "__has_cpp_attribute(fallthrough)"
> +#  elif __has_cpp_attribute(fallthrough) != 201603
> +#error "__has_cpp_attribute(fallthrough) != 201603"
> +#  endif
> +
>  #else
>  #  error "__has_cpp_attribute"
>  #endif
>
> Marek

Re: Implement -Wimplicit-fallthrough (version 9)

[Jason Merrill]

It seems unfortunate that the warning doesn't accept /* ... fall
through ... */ as a fallthrough comment.

Jason

Re: [Patch, reload, tentative, PR 71627] Tweak conditions in find_valid_class_1

[Bernd Schmidt]

On 09/16/2016 09:02 PM, Senthil Kumar Selvaraj wrote:

  Does this make sense? I ran a reg test for the avr target with a
  slightly older version of this patch, it did not show any regressions.
  If this is the right fix, I'll make sure to run reg tests on x86_64
  after backporting to a gcc version where that target used reload.


It's hard to say, and could have different effects on different targets.
One thing though, at the very least the reg_class_size test would have 
to be adapted - the idea is to find the largest class, and there's a 
risk here of ending up with a large class that only has one valid register.


You'll also want to verify this against
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54814


Bernd

Re: [PATCH GCC][v2]Simplify alias check code generation in vectorizer

[Bernd Edlinger]

Hi,

>@@ -2310,7 +2313,8 @@ create_intersect_range_checks_index (loop_vec_info 
>loop_vinfo, tree *cond_expr,
>   gcc_assert (TREE_CODE (DR_STEP (dr_a.dr)) == INTEGER_CST);
> 
>   bool neg_step = tree_int_cst_compare (DR_STEP (dr_a.dr), size_zero_node) < 
> 0;
>-  unsigned HOST_WIDE_INT abs_step = tree_to_uhwi (DR_STEP (dr_a.dr));
>+  unsigned HOST_WIDE_INT abs_step =
>+absu_hwi (tree_to_shwi (DR_STEP (dr_a.dr)));
>   if (neg_step)
> abs_step = -abs_step;

Hmmm...

but you must remove the neg_step if you do this.

Right?


Bernd.

Re: [PATCH, GCC] Deal with singular sentences in builtin-sprintf-warn-1.c regex

[Jeff Law]

On 09/26/2016 03:55 AM, Thomas Preudhomme wrote:

How about this reworked patch?

Best regards,

Thomas

On 23/09/16 17:17, Martin Sebor wrote:

On 09/23/2016 09:42 AM, Thomas Preudhomme wrote:

Sorry, forgot the patch. Please find it attached.

Best regards,

Thomas

On 23/09/16 16:40, Thomas Preudhomme wrote:

Hi,

New builtin-sprintf-warn-1.c testcase contains a few regex of the form
"\[0-9\]+
bytes" or ". bytes". This does not account for the case where the
number of byte
is 0 in which case byte would be in the singular form. This caused a
FAIL on
arm-none-eabi targets. This patch makes the s optional in all cases
where the
number of bytes is unknown.

I did not commit this fix as obvious as people might want to only do
the changes
for lines where the number of bytes *could* be 0 so I prefer to get
review.


Thanks for the patch.  The %p fixes look correct to me (someone
else needs to approve the final patch).

For the INT_MAX tests, I think it's a sign of a bug in the pass if
for the following call

  sprintf (buf, "X%*c", INT_MAX, '1');

GCC prints

  warning: directive output of 0 byte causes result to exceed 'INT_MAX'

My guess is that the bug is specific to a 32-bit compiler (I can't
reproduce it in a 64-bit one with -m32).  Let me build one and look
into fixing it.

Martin



ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2016-09-23  Thomas Preud'homme  

* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust regex to
accept
singular form of byte when quantity is unknown.


Is this ok for trunk?

Best regards,

Thomas




accept_single_form_byte.patch


diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
index 
e098be92bb0377414b1f9cacf5e4d2a3398e74ec..efa69b8a8b29da4ed3253e19ba646168a6a1ca58
 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
@@ -98,9 +98,9 @@ void test_sprintf_p_const (void)

   /* The exact output for %p is unspecified by C.  Two formats are known:
  same as %tx (for example AIX) and same as %#tx (for example Solaris).  */
-  T (0, "%p", (void*)0x1);/* { dg-warning ".%p. directive writing . bytes 
into a region of size 0" } */
-  T (1, "%p", (void*)0x12);   /* { dg-warning ".%p. directive writing . bytes 
into a region of size 1" } */
-  T (2, "%p", (void*)0x123);  /* { dg-warning ".%p. directive writing . bytes 
into a region of size 2" } */
+  T (0, "%p", (void*)0x1);/* { dg-warning ".%p. directive writing . bytes? 
into a region of size 0" } */
+  T (1, "%p", (void*)0x12);   /* { dg-warning ".%p. directive writing . bytes? 
into a region of size 1" } */
+  T (2, "%p", (void*)0x123);  /* { dg-warning ".%p. directive writing . bytes? 
into a region of size 2" } */


This is fine.

jeff

Re: [PATCH GCC][v2]Simplify alias check code generation in vectorizer

[Robin Dapp]

> And also please mention https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77724 
> and perhaps
> add its testcase, too.
> 

Patch according to Richard's suggestion, included test case. The test
case works unpatched on x86-64 but fails on s390. Is gcc.dg/vect the
proper place for it? (I didn't manage to run it independently in this
directory via RUNTESTFLAGS=vect.exp=... or otherwise)

Bootstrapped on x86 and s390.

--

gcc/ChangeLog:

2016-09-26  Robin Dapp  

* tree-vect-loop-manip.c (create_intersect_range_checks_index):
Add tree_fits_shwi_p check.


gcc/testsuite/ChangeLog:

2016-09-26  Robin Dapp  

* gcc.dg/vect/pr77724.c: New test.
diff --git a/gcc/testsuite/gcc.dg/vect/pr77724.c b/gcc/testsuite/gcc.dg/vect/pr77724.c
new file mode 100644
index 000..3039b5a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr77724.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O3" { target { { i?86-*-* x86_64-*-* } && ia32 } } } */
+/* { dg-options "-O3 -march=z13" { target s390*-*-* } } */
+
+int a[81];
+int b, c;
+
+void
+fn1()
+{
+  int d = b;
+  for (; c; --c)
+a[c + d] = a[c];
+}
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index 8203040..147a90f 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -2301,6 +2301,9 @@ create_intersect_range_checks_index (loop_vec_info loop_vinfo, tree *cond_expr,
   if (!tree_fits_uhwi_p (dr_a.seg_len) || !tree_fits_uhwi_p (dr_b.seg_len))
 return false;
 
+  if (!tree_fits_shwi_p (DR_STEP (dr_a.dr)))
+return false;
+
   if (!operand_equal_p (DR_BASE_OBJECT (dr_a.dr), DR_BASE_OBJECT (dr_b.dr), 0))
 return false;
 
@@ -2310,7 +2313,8 @@ create_intersect_range_checks_index (loop_vec_info loop_vinfo, tree *cond_expr,
   gcc_assert (TREE_CODE (DR_STEP (dr_a.dr)) == INTEGER_CST);
 
   bool neg_step = tree_int_cst_compare (DR_STEP (dr_a.dr), size_zero_node) < 0;
-  unsigned HOST_WIDE_INT abs_step = tree_to_uhwi (DR_STEP (dr_a.dr));
+  unsigned HOST_WIDE_INT abs_step =
+absu_hwi (tree_to_shwi (DR_STEP (dr_a.dr)));
   if (neg_step)
 abs_step = -abs_step;
 

Re: [PATCH, RFC] gcov: dump in a static dtor instead of in an atexit handler

[Martin Liška]

On 08/12/2016 04:08 PM, Martin Liška wrote:
> On 08/10/2016 02:53 PM, Nathan Sidwell wrote:
>> On 08/10/16 06:43, Martin Liška wrote:
>>> Hello.
>>>
>>> There are multiple PRs (mentioned in ChangeLog) which suffer from missing 
>>> capability of gcov
>>> to save counters for functions with constructor/destructor attributes. I 
>>> done that by simply
>>> replacing atexit handler (gcov_exit) with a new static destructor 
>>> (__gcov_exit), which has
>>> priority 99 (I did the same for __gcov_init). However, I'm not sure whether 
>>> it's possible
>>> that a ctor defined in a source file can be potentially executed before 
>>> __gcov_init (w/ the default
>>> priority)?
>>>
>>> Patch survives:
>>> make check -k -j10 RUNTESTFLAGS="gcov.exp"
>>> make check -k -j10 RUNTESTFLAGS="tree-prof.exp"
>>>
>>> I've just also verified that a DSO gcov dump works as before. I'm attaching 
>>> a test-case which
>>> tests both static ctors/dtors, as well as C++ ctors/dtors.
>>
>> Does a coverage bootstrap (--enable-coverage) still succeed?
> 
> Well, looks results are more unstable than I thought.
> Even running 'make -j1' in objdir/x86_64-pc-linux-gnu/libgcc repeatedly 
> generates different results.
> I'll dig in after weekend.
> 
> Martin

Hi.

So the I found reason of inconsistencies, running multiple times -fselftest is 
enough to
find that memory allocation related functions can be executed different times.
Small example:

--- /tmp/r1/ggc-page.c.gcov 2016-09-26 16:54:53.060921496 +0200
+++ /tmp/r2/ggc-page.c.gcov 2016-09-26 16:55:52.470058958 +0200
@@ -636,8 +636,8 @@
 -:  631:#else
307718:  632:  page_table table = G.lookup;
307718:  633:  uintptr_t high_bits = (uintptr_t) p & ~ (uintptr_t) 
0x;
-   307718:  634:  while (table->high_bits != high_bits)
-#:  635:table = table->next;
+   307794:  634:  while (table->high_bits != high_bits)
+   38:  635:table = table->next;
307718:  636:  base = >table[0];
 -:  637:#endif
 -:  638:
@@ -661,15 +661,15 @@
 -:  656:#else
 -:  657:  page_table table;
  2134:  658:  uintptr_t high_bits = (uintptr_t) p & ~ (uintptr_t) 
0x;
- 2134:  659:  for (table = G.lookup; table; table = table->next)
- 2133:  660:if (table->high_bits == high_bits)
- 2133:  661:  goto found;
+ 2322:  659:  for (table = G.lookup; table; table = table->next)
+ 2320:  660:if (table->high_bits == high_bits)
+ 2132:  661:  goto found;
 -:  662:
 -:  663:  /* Not found -- allocate a new table.  */
-1:  664:  table = XCNEW (struct page_table_chain);
-1:  665:  table->next = G.lookup;
-1:  666:  table->high_bits = high_bits;
-1:  667:  G.lookup = table;
+2:  664:  table = XCNEW (struct page_table_chain);
+2:  665:  table->next = G.lookup;
+2:  666:  table->high_bits = high_bits;
+2:  667:  G.lookup = table;
  2134:  668:found:
  2134:  669:  base = >table[0];
 -:  670:#endif
--- /tmp/r1/ggc-page.c.gcov 2016-09-26 16:54:53.060921496 +0200
+++ /tmp/r2/ggc-page.c.gcov 2016-09-26 16:58:22.440931009 +0200
@@ -679,7 +679,7 @@
  2134:  674:  L2 = LOOKUP_L2 (p);
 -:  675:
  2134:  676:  if (base[L1] == NULL)
-3:  677:base[L1] = XCNEWVEC (page_entry *, PAGE_L2_SIZE);
+2:  677:base[L1] = XCNEWVEC (page_entry *, PAGE_L2_SIZE);
 -:  678:
  2134:  679:  base[L1][L2] = entry;
  2134:  680:}

It's reasonable to me that it can change. However, the patch I would like to 
install
does not cause any new differences.

Martin

> 
>>
>> I think this is a good idea, but we should document the changed behavior. (I 
>> don't think the current behaviour's documented).

I'm adding a new hunk that documents the behavior.

Is the patch ready to be installed?
Thanks,
Martin

>>
>>
>> nathan
> 

>From 686e65a923288c2c5055a9edb61e6f0648d6a2a3 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Wed, 10 Aug 2016 12:18:45 +0200
Subject: [PATCH] gcov: dump in a static dtor instead of in an atexit handler

gcc/testsuite/ChangeLog:

2016-08-10  Martin Liska  

	PR gcov-profile/7970
	PR gcov-profile/16855
	PR gcov-profile/44779
	* g++.dg/gcov/pr16855.C: New test.

gcc/ChangeLog:

2016-08-10  Martin Liska  

	PR gcov-profile/7970
	PR gcov-profile/16855
	PR gcov-profile/44779
	* coverage.c (build_gcov_exit_decl): New function.
	(coverage_obj_init): Call the function and generate __gcov_exit
	destructor.
	* doc/gcov.texi: Document when __gcov_exit function is called.

libgcc/ChangeLog:

2016-08-10  Martin Liska  

	PR gcov-profile/7970
	PR gcov-profile/16855
	PR gcov-profile/44779
	* libgcov-driver.c (__gcov_init): Do not register a atexit
	handler.
	(__gcov_exit): Rename from gcov_exit.
	* libgcov.h (__gcov_exit): Declare.
---
 gcc/coverage.c  | 27 +++--
 

Re: PATCH to use the new gimple_call_internal_p overload

[Jeff Law]

On 09/26/2016 07:53 AM, Marek Polacek wrote:

In my recent -Wimplicit-fallthrough patch I introduced a new overload
gimple_call_internal_p to check whether a stmt is a specific internal
function.  So use this predicate in the rest of the codebase, too.

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

2016-09-26  Marek Polacek  

* ipa-inline-analysis.c (find_foldable_builtin_expect): Use
gimple_call_internal_p.
* ipa-split.c (find_return_bb): Likewise.
(execute_split_functions): Likewise.
* omp-low.c (dump_oacc_loop_part): Likewise.
(oacc_loop_xform_head_tail): Likewise.
* predict.c (predict_loops): Likewise.
* sanopt.c (pass_sanopt::execute): Likewise.
* tree-cfg.c (get_abnormal_succ_dispatcher): Likewise.
* tree-parloops.c (oacc_entry_exit_ok_1): Likewise.
* tree-stdarg.c (gimple_call_ifn_va_arg_p): Remove function.
(expand_ifn_va_arg_1): Use gimple_call_internal_p.
(expand_ifn_va_arg): Likewise.
* tree-vect-loop.c (vect_determine_vectorization_factor): Likewise.
(optimize_mask_stores): Likewise.
* tree-vect-stmts.c (vect_simd_lane_linear): Likewise.
(vect_transform_stmt): Likewise.
* tree-vectorizer.c (vect_loop_vectorized_call): Likewise.
* tsan.c (instrument_memory_accesses): Likewise.

OK.  Thanks for cleaning this up.

jeff

Re: Implement -Wimplicit-fallthrough (version 9)

[Arnaud Charlet]

> this patch caused quite some breakage: Ada, Solaris/x86 and SPARC don't
> bootstrap any longer. 
> 
> The following patch allows i386-pc-solaris2.12 and
> sparc-sun-solaris2.12
> bootstraps continue.
> 
> Strangely, I needed to use gcc_fallthrough () in i386.c; a mere /* FALLTHRU
> */
> had no effect.
> 
> Ok for mainline if the bootstraps pass (with appropriate changelog
> entries, of course)?

Ada part is OK

Re: Split c-common.c?

[Jeff Law]

On 09/26/2016 07:38 AM, Marek Polacek wrote:

On Mon, Sep 26, 2016 at 03:26:28PM +0200, Jakub Jelinek wrote:

On Mon, Sep 26, 2016 at 03:22:08PM +0200, Marek Polacek wrote:

Before I spend time on this, I wanted to check if you consider this a good
idea.  Since c-common.c has grown a lot and is quite large now, I think we
might split it into c-warn.c, where various warning routines would go.  What do
you think?


Perhaps c-attribs.c for the attribute handling stuff too?


Yeah.  The way I envision c-common.c is to contain shared c-family routines
such as c_common_type_for_*, c_save_expr, max_align_t_align, and similar, but
the warnings/diagnostics might use their own file.

Works for me.

jeff

Re: [patch, avr, pr71676 and pr71678] Issues with casesi expand

[Georg-Johann Lay]

On 26.09.2016 15:19, Pitchumani Sivanupandi wrote:

Attached patch for PR71676 and PR71678.

PR71676 is for AVR target that generates wrong code when switch case index is
more than 16 bits.

Switch case index of larger than SImode are checked for out of range before
'casesi' expand. RTL expand of casesi gets index as SImode, but index is
compared in HImode and ignores upper 16bits.

Attached patch changes the expansion for casesi to make the index comparison
in SImode and code generation accordingly.

PR71678 is ICE because below pattern in 'casesi' is not recognized.
(set (reg:HI 47)
 (minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0)
   (reg:HI 45)))

Fix of PR71676 avoids the above pattern as it changes the comparison
to SImode.


But this means that all comparisons are now performed in SImode which is a 
great performance loss for most programs which will switch on 16-bit values.


IMO we need a less intrusive (w.r.t. performance) approach.

Johann



Regtested using avrtest. No regression found.

If OK, could someone commit please?

Is this OK for gcc-5-branch?

Regards,
Pitchumani

gcc/ChangeLog

2016-09-26  Pitchumani Sivanupandi  

PR target/71676
PR target/71678
* config/avr/avr.md (casesi): Change index compare to SI mode.

gcc/testsuite/ChangeLog

2016-09-26  Pitchumani Sivanupandi  

PR target/71676
PR target/71678
* gcc.target/avr/pr71676-1.c: New test.
* gcc.target/avr/pr71676.c: New test.
* gcc.target/avr/pr71678.c: New test.

Re: [PATCH][regrename][sel-sched] Fix bogus use of HARD_FRAME_POINTER_REGNUM (was: Fix arm bootstrap)

[Bernd Schmidt]

On 09/26/2016 04:34 PM, Kyrill Tkachov wrote:

Hi all,

This patch implements the minimal fixes for the issues that
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01547.html was supposed to
address
as suggested by Alexander.

Bootstrapped and tested on aarch64-none-linux-gnu and
arm-none-linux-gnueabihf.

Is this ok for trunk?

Thanks,
Kyrill

2016-09-26  Kyrylo Tkachov  
Alexander Monakov  

* regrename.c (rename_chains): Check
HARD_FRAME_POINTER_IS_FRAME_POINTER rather than
HARD_FRAME_POINTER_REGNUM when picking unavailable registers.
* sel-sched.c (mark_unavailable_hard_regs): Likewise.


Oh well, it's the minimal fix. Ok.


Bernd

[PATCH][regrename][sel-sched] Fix bogus use of HARD_FRAME_POINTER_REGNUM (was: Fix arm bootstrap)

[Kyrill Tkachov]

Hi all,

This patch implements the minimal fixes for the issues that
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01547.html was supposed to address
as suggested by Alexander.

Bootstrapped and tested on aarch64-none-linux-gnu and arm-none-linux-gnueabihf.

Is this ok for trunk?

Thanks,
Kyrill

2016-09-26  Kyrylo Tkachov  
Alexander Monakov  

* regrename.c (rename_chains): Check
HARD_FRAME_POINTER_IS_FRAME_POINTER rather than
HARD_FRAME_POINTER_REGNUM when picking unavailable registers.
* sel-sched.c (mark_unavailable_hard_regs): Likewise.
diff --git a/gcc/regrename.c b/gcc/regrename.c
index 54c7768efa226139c340868e42b784fb011a19b9..3509e8bab81bcbaeee124347bef21468ec80ec48 100644
--- a/gcc/regrename.c
+++ b/gcc/regrename.c
@@ -481,7 +481,7 @@ rename_chains (void)
   if (fixed_regs[reg] || global_regs[reg]
 	  || (!HARD_FRAME_POINTER_IS_FRAME_POINTER && frame_pointer_needed
 	  && reg == HARD_FRAME_POINTER_REGNUM)
-	  || (HARD_FRAME_POINTER_REGNUM && frame_pointer_needed
+	  || (HARD_FRAME_POINTER_IS_FRAME_POINTER && frame_pointer_needed
 	  && reg == FRAME_POINTER_REGNUM))
 	continue;
 
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 25a100ee34f6ceaceda2814ae281cadf8b29e688..009e7831ecc0822ff83c63c6214a11917a3e2d27 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -1185,7 +1185,7 @@ mark_unavailable_hard_regs (def_t def, struct reg_rename *reg_rename_p,
   || global_regs[regno]
   || (!HARD_FRAME_POINTER_IS_FRAME_POINTER && frame_pointer_needed
 	  && regno == HARD_FRAME_POINTER_REGNUM)
-  || (HARD_FRAME_POINTER_REGNUM && frame_pointer_needed
+  || (HARD_FRAME_POINTER_IS_FRAME_POINTER && frame_pointer_needed
 	  && regno == FRAME_POINTER_REGNUM)
   || (reload_completed && cl == NO_REGS))
 {

[PATCH] Cleanup of input.c

[Bernd Edlinger]

Hi,

this started, because I saw get_next_line returns -1 on error, instead
of false: PR 77699.

But when I was there I also saw that read_line_num is using memmove on
non-aliased src & dest, instead of memcpy.  But then I see that
also adding a NUL byte is superfluos, and all the copying as well


So the result is a cleanup of input.c that avoids lots of copying
altogether, because it is no longer necessary to do so.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
2016-09-26  Bernd Edlinger  

	PR preprocessor/77699
	* input.c (maybe_grow): Don't allocate one byte extra headroom.
	(get_next_line): Return false on error.
	(read_next_line): Removed, use get_next_line instead.
	(read_line_num): Don't copy the line.
	(location_get_source_line): Don't use static data.


Index: gcc/input.c
===
--- gcc/input.c	(revision 240471)
+++ gcc/input.c	(working copy)
@@ -432,7 +432,7 @@ maybe_grow (fcache *c)
 return;
 
   size_t size = c->size == 0 ? fcache_buffer_size : c->size * 2;
-  c->data = XRESIZEVEC (char, c->data, size + 1);
+  c->data = XRESIZEVEC (char, c->data, size);
   c->size = size;
 }
 
@@ -534,7 +534,7 @@ get_next_line (fcache *c, char **line, ssize_t *li
 }
 
   if (ferror (c->fp))
-return -1;
+return false;
 
   /* At this point, we've found the end of the of line.  It either
  points to the '\n' or to one byte after the last byte of the
@@ -597,36 +597,6 @@ get_next_line (fcache *c, char **line, ssize_t *li
   return true;
 }
 
-/* Reads the next line from FILE into *LINE.  If *LINE is too small
-   (or NULL) it is allocated (or extended) to have enough space to
-   containe the line.  *LINE_LENGTH must contain the size of the
-   initial*LINE buffer.  It's then updated by this function to the
-   actual length of the returned line.  Note that the returned line
-   can contain several zero bytes.  Also note that the returned string
-   is allocated in static storage that is going to be re-used by
-   subsequent invocations of read_line.  */
-
-static bool
-read_next_line (fcache *cache, char ** line, ssize_t *line_len)
-{
-  char *l = NULL;
-  ssize_t len = 0;
-
-  if (!get_next_line (cache, , ))
-return false;
-
-  if (*line == NULL)
-*line = XNEWVEC (char, len);
-  else
-if (*line_len < len)
-	*line = XRESIZEVEC (char, *line, len);
-
-  memcpy (*line, l, len);
-  *line_len = len;
-
-  return true;
-}
-
 /* Consume the next bytes coming from the cache (or from its
underlying file if there are remaining unread bytes in the file)
until we reach the next end-of-line (or end-of-file).  There is no
@@ -651,7 +621,7 @@ goto_next_line (fcache *cache)
 
 static bool
 read_line_num (fcache *c, size_t line_num,
-	   char ** line, ssize_t *line_len)
+	   char **line, ssize_t *line_len)
 {
   gcc_assert (line_num > 0);
 
@@ -705,12 +675,8 @@ read_line_num (fcache *c, size_t line_num,
 	{
 	  /* We have the start/end of the line.  Let's just copy
 		 it again and we are done.  */
-	  ssize_t len = i->end_pos - i->start_pos + 1;
-	  if (*line_len < len)
-		*line = XRESIZEVEC (char, *line, len);
-	  memmove (*line, c->data + i->start_pos, len);
-	  (*line)[len - 1] = '\0';
-	  *line_len = --len;
+	  *line = c->data + i->start_pos;
+	  *line_len = i->end_pos - i->start_pos;
 	  return true;
 	}
 
@@ -735,7 +701,7 @@ read_line_num (fcache *c, size_t line_num,
 
   /* The line we want is the next one.  Let's read and copy it back to
  the caller.  */
-  return read_next_line (c, line, line_len);
+  return get_next_line (c, line, line_len);
 }
 
 /* Return the physical source line that corresponds to FILE_PATH/LINE in a
@@ -748,8 +714,8 @@ const char *
 location_get_source_line (const char *file_path, int line,
 			  int *line_len)
 {
-  static char *buffer;
-  static ssize_t len;
+  char *buffer;
+  ssize_t len;
 
   if (line == 0)
 return NULL;

[Committed] S/390: Add missing fallthrough comments.

[Andreas Krebbel]

gcc/ChangeLog:

2016-09-26  Andreas Krebbel  

* config/s390/s390.c (s390_rtx_costs): Add /* fallthrough */.
(s390_sched_score): Likewise.
---
 gcc/config/s390/s390.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 0b0e360..3bdb648 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -3467,6 +3467,7 @@ s390_rtx_costs (rtx x, machine_mode mode, int outer_code,
  *total = COSTS_N_INSNS (2);
  return true;
}
+  /* fallthrough */
 case ASHIFT:
 case ASHIFTRT:
 case LSHIFTRT:
@@ -13855,6 +13856,7 @@ s390_sched_score (rtx_insn *insn)
score += 5;
   if ((mask & S390_SCHED_ATTR_MASK_GROUPALONE) != 0)
score += 10;
+  /* fallthrough */
 case 1:
   /* Prefer not cracked insns while trying to put together a
 group.  */
-- 
2.9.1

Re: [PATCH] Bits from Early LTO debug merge -- move stuff from late to early finish

[Richard Biener]

On Fri, 23 Sep 2016, Richard Biener wrote:

> On Fri, 23 Sep 2016, Richard Biener wrote:
> 
> > On Thu, 22 Sep 2016, Richard Biener wrote:
> > 
> > > 
> > > This merges moving of unused type pruning from late to early finish as 
> > > well as handling of debug types and dwarf2 dups elimination.  It adds
> > > a flag to DIEs so we can mark them as removed in case sth after
> > > early finish tries to lookup a DIE for a removed DIE again - we shouldn't
> > > re-use the removed DIE (w/o parent) there.
> > > 
> > > I suppose at some point we should re-think how pruning of "unused"
> > > stuff is supposed to work.  Given my grand plan is to get rid of
> > > debug hooks and allow FEs direct control over the DWARF it should
> > > be ultimatively their decision what to remove (err, not create, in
> > > the first place).
> > > 
> > > Bootstrap and regtest running on x86_64-unknown-linux-gnu, ok for trunk?
> > 
> > Testing this separately shows the need to port another hunk.  If we
> > prune types early we have to make sure to not re-create them late
> > via typedefs in BLOCKs.
> > 
> > Index: gcc/dwarf2out.c
> > ===
> > --- gcc/dwarf2out.c (revision 240363)
> > +++ gcc/dwarf2out.c (working copy)
> > @@ -23255,7 +23242,13 @@ process_scope_var (tree stmt, tree decl,
> >  die = lookup_decl_die (decl_or_origin);
> >else if (TREE_CODE (decl_or_origin) == TYPE_DECL
> > && TYPE_DECL_IS_STUB (decl_or_origin))
> > -die = lookup_type_die (TREE_TYPE (decl_or_origin));
> > +{
> > +  /* Avoid re-creating the DIE late if it was optimized
> > +as unused early (this BLOCK reference does not count as "use").  
> > */
> > +  die = lookup_type_die (TREE_TYPE (decl_or_origin));
> > +  if (! die)
> > +   return;
> > +}
> >else
> >  die = NULL;
> 
> Testing went fine if you consider moving
> 
> +  /* Generate separate CUs for each of the include files we've seen.
> + They will go into limbo_die_list.  */
> +  if (flag_eliminate_dwarf2_dups)
> +break_out_includes (comp_unit_die ());
> 
> not being part of this patch.  I did statistics over patched/unpatched
> GCC by means of
> 
> readelf -wi gcc/.o | grep 'DW_TAG_[_a-z]*type' | wc -l
> 
> and the difference is in the noise (diff unpatched patched):
> 
> -gcc/alias.o 2639
> +gcc/alias.o 2640
> -gcc/auto-profile.o 4941
> -gcc/bb-reorder.o 2243
> +gcc/auto-profile.o 4945
> +gcc/bb-reorder.o 2315
> -gcc/bt-load.o 1837
> +gcc/bt-load.o 1836
> -gcc/cfg.o 1350
> +gcc/cfg.o 1349
> ...
> 
> There are DW_TAG_typedef no longer occuring (from vec.o):
> 
>  <1>: Abbrev Number: 180 (DW_TAG_subprogram)
>DW_AT_specification: <0x6a3a>
>DW_AT_inline  : 3  (declared as inline and inlined)
>DW_AT_sibling : <0xe7ff>
>  <2>: Abbrev Number: 63 (DW_TAG_formal_parameter)
>DW_AT_name: (indirect string, offset: 0x3f48): alloc
>DW_AT_decl_file   : 5
>DW_AT_decl_line   : 1050
>DW_AT_type: <0x6d>
>  <2>: Abbrev Number: 51 (DW_TAG_typedef)
>DW_AT_name: (indirect string, offset: 0x1435f): 
> vec_embedde
> d
>DW_AT_decl_file   : 5
>DW_AT_decl_line   : 1052
>DW_AT_type: <0x665a>
>  <2>: Abbrev Number: 0
> 
> The DW_TAG_typedef is missing in the patched variant.  This DIE is
> not refered to in the the unpatched variant (I didn't check why we
> don't prune it).
> 
> There appear some extra stray DW_TAG_typedef DIEs though:
> 
>  <13><11a28>: Abbrev Number: 207 (DW_TAG_typedef)
>  <13><11a2a>: Abbrev Number: 0
> 
> I'll check where those come from.

Ok, so the former is from premark_used_types having no effect for
early debug as it is called in gen_subprogram_die before we had a chance
to generate type DIEs from its blocks.  The fix is to simply move it
until after that.

The latter is because we re-create those in place of the removed ones
in process_scope_var so the fix is to extend the mitigation that
was added for the TYPE_DECL_IS_STUB to all types (or type decls).
Note this change is also pending from Pierre-Marie to force re-parenting
of existing TYPE_DECLs for Ada.

With those fixes the stats for all stage3 gcc/*.o files look like

-gcc/gcov-tool.o 506
+gcc/gcov-tool.o 512
-gcc/graphite-isl-ast-to-gimple.o 2262
+gcc/graphite-isl-ast-to-gimple.o 2264
-gcc/plugin.o 648
+gcc/plugin.o 650

those are new DIEs per premark_types_used_by_global_vars_helper
due to the same issue we have more DIEs early now -- optimization
didn't get a chance to remove anything but trivially unreachable
stuff.  I believe we did not yet address that "regression" caused
by the early debug merge in any way (and this adds a tiny bit to it).

Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?

Thanks,
Richard.

2016-09-26  Richard Biener  

* dwarf2out.c (struct die_struct): Add removed flag.
(lookup_type_die): If the DIE is 

[PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math

[Fritz Reese]

All,

Attached is a patch extending the GNU Fortran front-end to support
some additional math intrinsics, enabled with a new compile flag
-fdec-math. The flag adds the COTAN intrinsic (cotangent), as well as
degree versions of all trigonometric intrinsics (SIND, TAND, ACOSD,
etc...). This extension allows for further compatibility with legacy
code that depends on the compiler to support such intrinsic functions.

I would definitely like some peer review on this patch to ensure my
implementation has no unintended mathematical side-effects, such as
rounding errors, or oversights with complex math: I implement the
degree-valued functions by simply converting the argument or result to
degrees/radians as appropriate by multiplying by the factor pi/180 (or
180/pi). In the constant case this is done using mpfr/mpc, and in the
non-constant case the factor multiplication expression is just
inserted into the expression tree where appropriate. The new COTAN
intrinsic is implemented using mpfr_cot in the constant case, and by
replacing the call with a 1/tan expression in the non-constant case
(and in the complex case, since there is no mpc_cot). See the new
functions in simplify.c/iresolve.c for specifics.

I also added a new macro MATH_ALIAS_BUILTIN used in mathbuiltins.def
to define the new COTAN intrinsic. This macro defines a new isym, but
keeps everything else defined normally by DEFINE_MATH_BUILTIN the same
as an existing isym (TAN in this case). The reason for this is to
avoid having to define a new BUILT_IN_COTAN in gcc/builtins.def (or
any other context). As I described above, the simplify/resolve code
for COTAN just wraps TAN. I am not 100% convinced this is the "right"
or "best" way to do this - so feel free to me know if there are any
problems with this approach.

By the way, I don't use intrinsic.c (make_alias) for these because
they need their own simplification/resolution routines to handle the
degree-radian conversion.

As usual the patched compiler bootstraps and regtests on
x86_64-redhat-linux. Questions, comments and concerns are very
welcome. Barring any, is this OK for trunk?

---
Fritz Reese


2016-09-26  Fritz Reese  

New flag -fdec-math for COTAN and degree trig intrinsics.

gcc/fortran/
* lang.opt: New flag -fdec-math.
* options.c (set_dec_flags): Enable with -fdec.
* invoke.texi, gfortran.texi, intrinsic.texi: Update documentation.
* trans-intrinsic.c (MATH_ALIAS_BUILTLIN): New macro for math aliases.
* f95-lang.c (MATH_ALIAS_BUILTIN): New macro for math aliases.
* mathbuiltins.def (MATH_ALIAS_BUILTIN): Use for cotan.
* intrinsics.c (add_functions, do_simplify): New intrinsics
with -fdec-math.
* gfortran.h (gfc_isym_id): New isym GFC_ISYM_COTAN.
* gfortran.h (gfc_resolve_atan2d, gfc_resolve_cotan,
gfc_resolve_trigd, gfc_resolve_atrigd): New prototypes.
* iresolve.c (resolve_trig_call, get_degrees, get_radians,
is_trig_resolved, gfc_resolve_cotan, gfc_resolve_trigd,
gfc_resolve_atrigd, gfc_resolve_atan2d): New functions.
* intrinsics.h (gfc_simplify_atan2d, gfc_simplify_atrigd,
gfc_simplify_cotan, gfc_simplify_trigd): New prototypes.
* simplify.c (simplify_trig_call, degrees_f, radians_f,
gfc_simplify_cotan, gfc_simplify_trigd, gfc_simplify_atrigd,
gfc_simplify_atan2d): New functions.

gcc/testsuite/gfortran.dg/
* dec_math.f90: New testsuite.
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index 2b58173..7229d8d 100644
--- a/gcc/fortran/f95-lang.c
+++ b/gcc/fortran/f95-lang.c
@@ -559,6 +559,8 @@ gfc_define_builtin (const char *name, tree type, enum built_in_function code,
 DO_DEFINE_MATH_BUILTIN (code, name, argtype, mfunc_) \
 DO_DEFINE_MATH_BUILTIN (C##code, "c" name, argtype, mfunc_c)
 
+/* Defined in trans-intrinsic.c.  */
+#define MATH_ALIAS_BUILTIN(newid, id, name, type)
 
 /* Create function types for builtin functions.  */
 
@@ -1244,6 +1246,7 @@ gfc_init_builtin_functions (void)
   targetm.init_builtins ();
 }
 
+#undef MATH_ALIAS_BUILTIN
 #undef DEFINE_MATH_BUILTIN_C
 #undef DEFINE_MATH_BUILTIN
 
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index d6b92a6..f8f3d4a 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -391,6 +391,7 @@ enum gfc_isym_id
   GFC_ISYM_CONVERSION,
   GFC_ISYM_COS,
   GFC_ISYM_COSH,
+  GFC_ISYM_COTAN,
   GFC_ISYM_COUNT,
   GFC_ISYM_CPU_TIME,
   GFC_ISYM_CSHIFT,
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 3ebe3c7..4f8d2d6 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1466,6 +1466,7 @@ without warning.
 * Form feed as whitespace::
 * TYPE as an alias for PRINT::
 * %LOC as an rvalue::
+* Extended math intrinsics::
 @end menu
 
 @node Old-style kind specifications
@@ -2519,6 +2520,33 @@ integer :: i
 call sub(%loc(i))
 @end smallexample
 
+@node Extended 

[PATCH, LRA] Fix PR 77714

[Bernd Edlinger]

Hi!

This fixes another fallout of the recent change in the pattern matching,
which makes LRA choose a different alternative for this insn:

(insn 48 21 23 3 (set (reg/f:SI 102 sfp)
 (reg/f:SI 7 r7)) 808 {*thumb1_movsi_insn}
  (nil))

This is replaced as a special case to set((sfp)(r7-sfp_fp_elim_off)).
LRA choses thumb1_addsi3, alt 2 instead of alt 1, because sfp != r7,
while elimination of sfp->r7.

Unfortunately the insn gets a REG_EQUAL note temporarily attached,
which is spoiled by the elimination, so the reg-note is no longer
usable, and the instruction gets deleted in the final transformation.

So, as it looks like, this was a latent bug, as it is not OK to have
an alias on any RTX, except on a simple REG.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
2016-09-26  Bernd Edlinger  

	PR rlt-optimization/77714
	* lra-eliminations.c (eliminate_regs_in_insn): Avoid alias on
	REG_EQUAL note.

Index: gcc/lra-eliminations.c
===
--- gcc/lra-eliminations.c	(revision 240471)
+++ gcc/lra-eliminations.c	(working copy)
@@ -981,7 +981,7 @@ eliminate_regs_in_insn (rtx_insn *insn, bool repla
 		  }
 		lra_update_insn_recog_data (insn);
 		/* Add offset note for future updates.  */
-		add_reg_note (insn, REG_EQUAL, src);
+		add_reg_note (insn, REG_EQUAL, copy_rtx (src));
 		return;
 		  }
 	  }

PATCH to use the new gimple_call_internal_p overload

[Marek Polacek]

In my recent -Wimplicit-fallthrough patch I introduced a new overload
gimple_call_internal_p to check whether a stmt is a specific internal
function.  So use this predicate in the rest of the codebase, too.

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

2016-09-26  Marek Polacek  

* ipa-inline-analysis.c (find_foldable_builtin_expect): Use
gimple_call_internal_p.
* ipa-split.c (find_return_bb): Likewise.
(execute_split_functions): Likewise.
* omp-low.c (dump_oacc_loop_part): Likewise.
(oacc_loop_xform_head_tail): Likewise.
* predict.c (predict_loops): Likewise.
* sanopt.c (pass_sanopt::execute): Likewise.
* tree-cfg.c (get_abnormal_succ_dispatcher): Likewise.
* tree-parloops.c (oacc_entry_exit_ok_1): Likewise.
* tree-stdarg.c (gimple_call_ifn_va_arg_p): Remove function.
(expand_ifn_va_arg_1): Use gimple_call_internal_p.
(expand_ifn_va_arg): Likewise.
* tree-vect-loop.c (vect_determine_vectorization_factor): Likewise.
(optimize_mask_stores): Likewise.
* tree-vect-stmts.c (vect_simd_lane_linear): Likewise.
(vect_transform_stmt): Likewise.
* tree-vectorizer.c (vect_loop_vectorized_call): Likewise.
* tsan.c (instrument_memory_accesses): Likewise.

diff --git gcc/ipa-inline-analysis.c gcc/ipa-inline-analysis.c
index 132779d..8228e8a 100644
--- gcc/ipa-inline-analysis.c
+++ gcc/ipa-inline-analysis.c
@@ -2398,9 +2398,7 @@ find_foldable_builtin_expect (basic_block bb)
 {
   gimple *stmt = gsi_stmt (bsi);
   if (gimple_call_builtin_p (stmt, BUILT_IN_EXPECT)
- || (is_gimple_call (stmt)
- && gimple_call_internal_p (stmt)
- && gimple_call_internal_fn (stmt) == IFN_BUILTIN_EXPECT))
+ || gimple_call_internal_p (stmt, IFN_BUILTIN_EXPECT))
 {
   tree var = gimple_call_lhs (stmt);
   tree arg = gimple_call_arg (stmt, 0);
diff --git gcc/ipa-split.c gcc/ipa-split.c
index ac8b478..0c25fca 100644
--- gcc/ipa-split.c
+++ gcc/ipa-split.c
@@ -788,9 +788,7 @@ find_return_bb (void)
   /* For -fsanitize=thread, allow also TSAN_FUNC_EXIT () in the return
 bb.  */
   else if ((flag_sanitize & SANITIZE_THREAD)
-  && is_gimple_call (stmt)
-  && gimple_call_internal_p (stmt)
-  && gimple_call_internal_fn (stmt) == IFN_TSAN_FUNC_EXIT)
+  && gimple_call_internal_p (stmt, IFN_TSAN_FUNC_EXIT))
;
   else
break;
@@ -1840,9 +1838,7 @@ execute_split_functions (void)
}
 
  if ((flag_sanitize & SANITIZE_THREAD)
- && is_gimple_call (stmt)
- && gimple_call_internal_p (stmt)
- && gimple_call_internal_fn (stmt) == IFN_TSAN_FUNC_EXIT)
+ && gimple_call_internal_p (stmt, IFN_TSAN_FUNC_EXIT))
{
  /* We handle TSAN_FUNC_EXIT for splitting either in the
 return_bb, or in its immediate predecessors.  */
diff --git gcc/omp-low.c gcc/omp-low.c
index bf52d84..422f2b2 100644
--- gcc/omp-low.c
+++ gcc/omp-low.c
@@ -19047,9 +19047,7 @@ dump_oacc_loop_part (FILE *file, gcall *from, int depth,
 {
   gimple *stmt = gsi_stmt (gsi);
 
-  if (is_gimple_call (stmt)
- && gimple_call_internal_p (stmt)
- && gimple_call_internal_fn (stmt) == IFN_UNIQUE)
+  if (gimple_call_internal_p (stmt, IFN_UNIQUE))
{
  enum ifn_unique_kind k
= ((enum ifn_unique_kind) TREE_INT_CST_LOW
@@ -19271,10 +19269,8 @@ oacc_loop_xform_head_tail (gcall *from, int level)
   for (gimple_stmt_iterator gsi = gsi_for_stmt (from);;)
 {
   gimple *stmt = gsi_stmt (gsi);
-  
-  if (is_gimple_call (stmt)
- && gimple_call_internal_p (stmt)
- && gimple_call_internal_fn (stmt) == IFN_UNIQUE)
+
+  if (gimple_call_internal_p (stmt, IFN_UNIQUE))
{
  enum ifn_unique_kind k
= ((enum ifn_unique_kind)
@@ -19285,9 +19281,7 @@ oacc_loop_xform_head_tail (gcall *from, int level)
  else if (k == kind && stmt != from)
break;
}
-  else if (is_gimple_call (stmt)
-  && gimple_call_internal_p (stmt)
-  && gimple_call_internal_fn (stmt) == IFN_GOACC_REDUCTION)
+  else if (gimple_call_internal_p (stmt, IFN_GOACC_REDUCTION))
*gimple_call_arg_ptr (stmt, 3) = replacement;
 
   gsi_next ();
diff --git gcc/predict.c gcc/predict.c
index b3d1697..463fd0b 100644
--- gcc/predict.c
+++ gcc/predict.c
@@ -2024,9 +2024,7 @@ predict_loops (void)
   && gimple_expr_code (call_stmt) == NOP_EXPR
   && TREE_CODE (gimple_assign_rhs1 (call_stmt)) == SSA_NAME)
 call_stmt = SSA_NAME_DEF_STMT (gimple_assign_rhs1 (call_stmt));
-  if (gimple_code (call_stmt) == GIMPLE_CALL
-  && gimple_call_internal_p (call_stmt)
-  && 

Re: Implement -Wimplicit-fallthrough (version 9)

[Marek Polacek]

On Mon, Sep 26, 2016 at 03:34:40PM +0200, Rainer Orth wrote:
> Hi Marek,
> 
> > All right.  I'll commit the patch on Monday.
> 
> this patch caused quite some breakage: Ada, Solaris/x86 and SPARC don't
> bootstrap any longer. 
 
Sorry about that.  I had tested Ada + x86_64/ppc64/aarch64, but couldn't
test neither Solaris nor SPARC.

> The following patch allows i386-pc-solaris2.12 and sparc-sun-solaris2.12
> bootstraps continue.
> 
> Strangely, I needed to use gcc_fallthrough () in i386.c; a mere /* FALLTHRU */
> had no effect.
 
Yes, this is expected.  /* FALLTHRU */ comments only work if the next token
is a case label or default label.

> Ok for mainline if the bootstraps pass (with appropriate changelog
> entries, of course)?

LGTM, though I can't approve.

Thanks a lot.

Marek

Re: Implement -Wimplicit-fallthrough (version 9)

[Jakub Jelinek]

On Mon, Sep 26, 2016 at 03:34:40PM +0200, Rainer Orth wrote:
> Ok for mainline if the bootstraps pass (with appropriate changelog
> entries, of course)?

Yes.

> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -17917,6 +17917,7 @@ ix86_print_operand (FILE *file, rtx x, i
>  #ifdef HAVE_AS_IX86_CMOV_SUN_SYNTAX
> if (ASSEMBLER_DIALECT == ASM_ATT)
>   putc ('.', file);
> +   gcc_fallthrough ();
>  #endif

Where have you been adding the /*FALLTHROUGH*/ ?  Before #endif or after it?

Jakub

Re: Split c-common.c?

[Marek Polacek]

On Mon, Sep 26, 2016 at 03:26:28PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 26, 2016 at 03:22:08PM +0200, Marek Polacek wrote:
> > Before I spend time on this, I wanted to check if you consider this a good
> > idea.  Since c-common.c has grown a lot and is quite large now, I think we
> > might split it into c-warn.c, where various warning routines would go.  
> > What do
> > you think?
> 
> Perhaps c-attribs.c for the attribute handling stuff too?

Yeah.  The way I envision c-common.c is to contain shared c-family routines
such as c_common_type_for_*, c_save_expr, max_align_t_align, and similar, but
the warnings/diagnostics might use their own file.

Marek

Re: Implement -Wimplicit-fallthrough (version 9)

[Rainer Orth]

Hi Marek,

> All right.  I'll commit the patch on Monday.

this patch caused quite some breakage: Ada, Solaris/x86 and SPARC don't
bootstrap any longer. 

The following patch allows i386-pc-solaris2.12 and sparc-sun-solaris2.12
bootstraps continue.

Strangely, I needed to use gcc_fallthrough () in i386.c; a mere /* FALLTHRU */
had no effect.

Ok for mainline if the bootstraps pass (with appropriate changelog
entries, of course)?

Rainer


diff --git a/gcc/ada/gcc-interface/decl.c b/gcc/ada/gcc-interface/decl.c
--- a/gcc/ada/gcc-interface/decl.c
+++ b/gcc/ada/gcc-interface/decl.c
@@ -596,7 +596,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	gnu_expr
 	  = gnat_to_gnu_external (Expression (Declaration_Node (gnat_entity)));
 
-  /* ... fall through ... */
+  /* fall through */
 
 case E_Exception:
 case E_Loop_Parameter:
@@ -3369,7 +3369,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	  break;
 	}
 
-  /* ... fall through ... */
+  /* fall through */
 
 case E_Record_Subtype:
   /* If Cloned_Subtype is Present it means this record subtype has
@@ -3804,7 +3804,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
 	break;
 	}
 
-  /* ... fall through ... */
+  /* fall through */
 
 case E_Allocator_Type:
 case E_Access_Type:
@@ -6882,7 +6882,7 @@ choices_to_gnu (tree operand, Node_Id ch
 	  break;
 	}
 
-	  /* ... fall through ... */
+	  /* fall through */
 
 	case N_Character_Literal:
 	case N_Integer_Literal:
@@ -8089,7 +8089,7 @@ annotate_value (tree gnu_size)
   else
 	return Uint_Minus_1;
 
-  /* Fall through... */
+  /* fall through */
 
 default:
   return No_Uint;
diff --git a/gcc/ada/gcc-interface/misc.c b/gcc/ada/gcc-interface/misc.c
--- a/gcc/ada/gcc-interface/misc.c
+++ b/gcc/ada/gcc-interface/misc.c
@@ -157,7 +157,7 @@ gnat_handle_option (size_t scode, const 
 case OPT_gant:
   warning (0, "%<-gnat%> misspelled as %<-gant%>");
 
-  /* ... fall through ... */
+  /* fall through */
 
 case OPT_gnat:
 case OPT_gnatO:
@@ -486,13 +486,13 @@ gnat_print_type (FILE *file, tree node, 
   else
 	print_node (file, "index type", TYPE_INDEX_TYPE (node), indent + 4);
 
-  /* ... fall through ... */
+  /* fall through */
 
 case ENUMERAL_TYPE:
 case BOOLEAN_TYPE:
   print_node_brief (file, "RM size", TYPE_RM_SIZE (node), indent + 4);
 
-  /* ... fall through ... */
+  /* fall through */
 
 case REAL_TYPE:
   print_node_brief (file, "RM min", TYPE_RM_MIN_VALUE (node), indent + 4);
diff --git a/gcc/ada/gcc-interface/trans.c b/gcc/ada/gcc-interface/trans.c
--- a/gcc/ada/gcc-interface/trans.c
+++ b/gcc/ada/gcc-interface/trans.c
@@ -844,7 +844,7 @@ lvalue_required_p (Node_Id gnat_node, tr
 		 && Ekind (Entity (gnat_temp)) == E_Enumeration_Literal))
 	  return 1;
 
-  /* ... fall through ... */
+  /* fall through */
 
 case N_Slice:
   /* Only the array expression can require an lvalue.  */
@@ -890,7 +890,7 @@ lvalue_required_p (Node_Id gnat_node, tr
 	if (!constant)
 	  return 1;
 
-  /* ... fall through ... */
+  /* fall through */
 
 case N_Type_Conversion:
 case N_Qualified_Expression:
@@ -914,7 +914,7 @@ lvalue_required_p (Node_Id gnat_node, tr
   get_unpadded_type (Etype (gnat_parent)),
   true, false, true);
 
-  /* ... fall through ... */
+  /* fall through */
 
 default:
   return 0;
@@ -1681,7 +1681,7 @@ Attribute_to_gnu (Node_Id gnat_node, tre
 	  break;
 	}
 
-  /* ... fall through ... */
+  /* fall through */
 
 case Attr_Access:
 case Attr_Unchecked_Access:
@@ -1938,7 +1938,7 @@ Attribute_to_gnu (Node_Id gnat_node, tre
 	  break;
 	}
 
-  /* ... fall through ... */
+  /* fall through */
 
 case Attr_Length:
   {
@@ -2393,7 +2393,7 @@ Attribute_to_gnu (Node_Id gnat_node, tre
   /* We treat Model as identical to Machine.  This is true for at least
 	 IEEE and some other nice floating-point systems.  */
 
-  /* ... fall through ... */
+  /* fall through */
 
 case Attr_Machine:
   /* The trick is to force the compiler to store the result in memory so
@@ -2537,7 +2537,7 @@ Case_Statement_to_gnu (Node_Id gnat_node
 		  break;
 		}
 
-	  /* ... fall through ... */
+	  /* fall through */
 
 	case N_Character_Literal:
 	case N_Integer_Literal:
@@ -4007,7 +4007,7 @@ node_is_atomic (Node_Id gnat_node)
 	  && Has_Atomic_Components (Entity (Prefix (gnat_node
 	return true;
 
-  /* ... fall through ... */
+  /* fall through */
 
 case N_Explicit_Dereference:
   return Is_Atomic (Etype (gnat_node));
@@ -4123,7 +4123,7 @@ atomic_access_required_p (Node_Id gnat_n
   /* Nothing to do if we are the prefix of an attribute, since we do not
 	 want an atomic access for things like 'Size.  */
 
-  /* ... fall through ... */
+  /* fall through */
 
 case N_Reference:
   /* The N_Reference node is like an attribute.  */
@@ 

Re: Split c-common.c?

[Jakub Jelinek]

On Mon, Sep 26, 2016 at 03:22:08PM +0200, Marek Polacek wrote:
> Before I spend time on this, I wanted to check if you consider this a good
> idea.  Since c-common.c has grown a lot and is quite large now, I think we
> might split it into c-warn.c, where various warning routines would go.  What 
> do
> you think?

Perhaps c-attribs.c for the attribute handling stuff too?

Jakub

Re: [PATCH 5/17][ARM] Enable HI mode moves for floating point values.

[Matthew Wahab]

On 26/09/16 14:15, Christophe Lyon wrote:

Hi,

Sorry for the delay, I've been travelling.

On 27 July 2016 at 15:57, Ramana Radhakrishnan
 wrote:

On Tue, May 17, 2016 at 3:29 PM, Matthew Wahab
 wrote:

The handling of 16-bit integer data-movement in the ARM backend doesn't
make full use of the VFP instructions when they are available, even when
the values are for use in VFP operations.

This patch adds support for using the VFP instructions and registers
when moving 16-bit integer and floating point data between registers and
between registers and memory.


With this patch, I've noticed 2 regressions which still seem present on
trunk.

When GCC is configured with:
  --target=arm-none-linux-gnueabihf  --disable-libgomp
--disable-libmudflap --disable-libcilkrts --enable-checking
--enable-languages=c,c++,fortran --with-float=hard
--enable-build-with-cxx --with-mode=arm --with-cpu=cortex-a9
--with-fpu=vfp

and the tests run with -march=armv5t in RUNTESTFLAGS

FAIL: gcc.target/arm/constant-pool.c (test for excess errors)
because:
/ccepmUiD.s:29: Error: selected processor does not support ARM mode
`movw r0,4660'

FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 compilation,  -O2
because:
/cc76h4mz.s: Assembler messages:
/cc76h4mz.s:413: Error: selected processor does not support ARM mode
`movw r3,8224'
/cc76h4mz.s:496: Error: selected processor does not support ARM mode
`movw r2,8224'
/cc76h4mz.s:578: Error: selected processor does not support ARM mode
`movw ip,8224'

Christophe


I suspect that this is the same MOVW problem as on the next patch in the series.

Matthew

Split c-common.c?

[Marek Polacek]

Before I spend time on this, I wanted to check if you consider this a good
idea.  Since c-common.c has grown a lot and is quite large now, I think we
might split it into c-warn.c, where various warning routines would go.  What do
you think?

Marek

[patch, avr, pr71676 and pr71678] Issues with casesi expand

[Pitchumani Sivanupandi]

Attached patch for PR71676 and PR71678.

PR71676 is for AVR target that generates wrong code when switch case 
index is

more than 16 bits.

Switch case index of larger than SImode are checked for out of range before
'casesi' expand. RTL expand of casesi gets index as SImode, but index is
compared in HImode and ignores upper 16bits.

Attached patch changes the expansion for casesi to make the index comparison
in SImode and code generation accordingly.

PR71678 is ICE because below pattern in 'casesi' is not recognized.
(set (reg:HI 47)
 (minus:HI (subreg:HI (subreg:SI (reg:DI 44) 0) 0)
   (reg:HI 45)))

Fix of PR71676 avoids the above pattern as it changes the comparison
to SImode.

Regtested using avrtest. No regression found.

If OK, could someone commit please?

Is this OK for gcc-5-branch?

Regards,
Pitchumani

gcc/ChangeLog

2016-09-26  Pitchumani Sivanupandi  

PR target/71676
PR target/71678
* config/avr/avr.md (casesi): Change index compare to SI mode.

gcc/testsuite/ChangeLog

2016-09-26  Pitchumani Sivanupandi  

PR target/71676
PR target/71678
* gcc.target/avr/pr71676-1.c: New test.
* gcc.target/avr/pr71676.c: New test.
* gcc.target/avr/pr71678.c: New test.

diff --git a/gcc/config/avr/avr.md b/gcc/config/avr/avr.md
index 97f3561..4b1bf9c 100644
--- a/gcc/config/avr/avr.md
+++ b/gcc/config/avr/avr.md
@@ -5155,12 +5155,12 @@
 
 (define_expand "casesi"
   [(parallel [(set (match_dup 6)
-   (minus:HI (subreg:HI (match_operand:SI 0 "register_operand" "") 0)
- (match_operand:HI 1 "register_operand" "")))
+   (minus:SI (match_operand:SI 0 "register_operand" "")
+ (match_operand:SI 1 "register_operand" "")))
   (clobber (scratch:QI))])
(parallel [(set (cc0)
(compare (match_dup 6)
-(match_operand:HI 2 "register_operand" "")))
+(match_operand:SI 2 "register_operand" "")))
   (clobber (match_scratch:QI 9 ""))])
 
(set (pc)
@@ -5179,20 +5179,20 @@
   (clobber (match_dup 8))])]
   ""
   {
-operands[6] = gen_reg_rtx (HImode);
+operands[6] = gen_reg_rtx (SImode);
 
 if (AVR_HAVE_EIJMP_EICALL)
   {
-operands[7] = operands[6];
+operands[7] = simplify_gen_subreg (HImode, operands[6], SImode, 0);
 operands[8] = all_regs_rtx[24];
 operands[10] = gen_rtx_REG (HImode, REG_Z);
   }
 else
   {
-operands[7] = gen_rtx_PLUS (HImode, operands[6],
+operands[7] = gen_rtx_PLUS (HImode, simplify_gen_subreg (HImode, operands[6], SImode, 0),
 gen_rtx_LABEL_REF (VOIDmode, operands[3]));
 operands[8] = const0_rtx;
-operands[10] = operands[6];
+operands[10] = simplify_gen_subreg (HImode, operands[6], SImode, 0);
   }
   })
 
diff --git a/gcc/testsuite/gcc.target/avr/pr71676-1.c b/gcc/testsuite/gcc.target/avr/pr71676-1.c
new file mode 100644
index 000..9a74909
--- /dev/null
+++ b/gcc/testsuite/gcc.target/avr/pr71676-1.c
@@ -0,0 +1,332 @@
+/* { dg-do run } */
+/* { dg-options "-Os -Wno-overflow" } */
+
+#include "exit-abort.h"
+volatile unsigned char y;
+
+unsigned char __attribute__((noinline)) foo1 (char x)
+{
+switch (x)
+{
+  case (char)0x11: y = 7; break;
+  case (char)0x12: y = 4; break;
+  case (char)0x13: y = 8; break;
+  case (char)0x14: y = 21; break;
+  case (char)0x15: y = 65; break;
+  case (char)0x16: y = 27; break;
+  case (char)0x17: y = 72; break;
+  case (char)0x18: y = 39; break;
+  default: y=0;
+}
+return y;
+}
+
+unsigned char __attribute__((noinline)) foo2 (char x)
+{
+switch (x)
+{
+  case 0x01: y = 7; break;
+  case 0x02: y = 4; break;
+  case 0x03: y = 8; break;
+  case 0x04: y = 21; break;
+  case 0x05: y = 65; break;
+  case 0x06: y = 27; break;
+  case 0x07: y = 72; break;
+  case 0x08: y = 39; break;
+  default: y=0;
+}
+return y;
+}
+
+unsigned char __attribute__((noinline)) foo3 (char x)
+{
+switch (x)
+{
+  case 0x101L: y = 7; break;
+  case 0x102L: y = 4; break;
+  case 0x103L: y = 8; break;
+  case 0x104L: y = 21; break;
+  case 0x105L: y = 65; break;
+  case 0x106L: y = 27; break;
+  case 0x107L: y = 72; break;
+  case 0x108L: y = 39; break;
+  default: y=0;
+}
+return y;
+}
+
+unsigned char __attribute__((noinline)) foo4 (char x)
+{
+switch (x)
+{
+  case 0x10001LL: y = 7; break;
+  case 0x10002LL: y = 4; break;
+  case 0x10003LL: y = 8; break;
+  case 0x10004LL: y = 21; break;
+  case 0x10005LL: y = 65; break;
+  case 0x10006LL: y = 27; break;
+  case 0x10007LL: y = 72; break;
+  case 0x10008LL: y = 

Re: [PATCH 6/17][ARM] Add data processing intrinsics for float16_t.

[Christophe Lyon]

On 26 September 2016 at 15:03, Ramana Radhakrishnan
 wrote:
> On Mon, Sep 26, 2016 at 1:48 PM, Christophe Lyon
>  wrote:
>> On 26 September 2016 at 11:43, Matthew Wahab  
>> wrote:
>>> Hello,
>>>
>>> On 25/09/16 14:00, Christophe Lyon wrote:
>>
>>
>> This patch adds the new intrinsics:
>>   vbsl_f16, vbslq_f16, vdup_n_f16, vdupq_n_f16, vdup_lane_f16,
>>   vdupq_lane_f16, vext_f16, vextq_f16, vmov_n_f16, vmovq_n_f16,
>>   vrev64_f16, vrev64q_f16, vtrn_f16, vtrnq_f16, vuzp_f16, vuzpq_f16,
>>   vzip_f16, vzipq_f16.
>>
>> This patch also updates the advsimd-intrinsics testsuite to test the f16
>> variants for ARM targets. These intrinsics are only implemented in the
>> ARM target so the tests are disabled for AArch64 using an extra
>> condition on a new convenience macro FP16_SUPPORTED. This patch also
>> disables, for the ARM target, the testsuite defined macro vdup_n_f16 as
>> it is no longer needed.


 Since you committed this patch, I've noticed that libgcc fails to build
 when GCC is configured:
 --target arm-none-eabi and default cpu
 /tmp/9649048_29.tmpdir/ccuBwQJJ.s: Assembler messages:
 /tmp/9649048_29.tmpdir/ccuBwQJJ.s:64: Error: selected processor does
 not support ARM mode `movwlt r0,32768'
 /tmp/9649048_29.tmpdir/ccuBwQJJ.s:65: Error: selected processor does
 not support ARM mode `movwge r0,32767'
 make[4]: *** [_ssaddHQ.o] Error 1
 make[4]: Leaving directory

 `/tmp/9649048_29.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc1/arm-none-eabi/fpu/libgcc'

>>>
>>>
>>> I can't reproduce the failure, could you send the configure arguments for
>>> the build.
>>>
>>
>> If I'm not mistaken, that is:
>>  --target=arm-none-eabi  --disable-nls --disable-libgomp
>> --disable-libmudflap --disable-libcilkrts --enable-checking
>> --enable-languages=c,c++ --with-newlib
>>
>> Maybe you've disabled multilibs?
>
>
> I'm pretty sure I built this as part of reviewing all these patches
> with --with-mutlib-list=aprofile and didnt' see any failures. Not sure
> what's going on here.
>

I'm not using very recent binutils, (can't remember if that's 2.25 or 2.26,
and I can't easily check remotely). Maybe something changed in
the assembler?

> Ramana
>>
>>> I've tried assembling the string 'movw r0, 32768' and get the error when
>>> -march=armv6kz or earlier. I suspect the new movhi and/or movhf patterns
>>> added earlier in the series need the architecture level added as a
>>> precondition but I'll need to look into it.
>>>
>>> Matthew
>>
>> Thanks,
>>
>> Christophe

Re: [PATCH 5/17][ARM] Enable HI mode moves for floating point values.

[Christophe Lyon]

Hi,

Sorry for the delay, I've been travelling.

On 27 July 2016 at 15:57, Ramana Radhakrishnan
 wrote:
> On Tue, May 17, 2016 at 3:29 PM, Matthew Wahab
>  wrote:
>> The handling of 16-bit integer data-movement in the ARM backend doesn't
>> make full use of the VFP instructions when they are available, even when
>> the values are for use in VFP operations.
>>
>> This patch adds support for using the VFP instructions and registers
>> when moving 16-bit integer and floating point data between registers and
>> between registers and memory.
>>
>> Tested the series for arm-none-linux-gnueabihf with native bootstrap and
>> make check and for arm-none-eabi and armeb-none-eabi with make check on
>> an ARMv8.2-A emulator. Tested this patch for arm-none-linux-gnueabihf
>> with native bootstrap and make check and for arm-none-eabi with
>> check-gcc on an ARMv8.2-A emulator.
>>
>> Ok for trunk?
>

With this patch, I've noticed 2 regressions which still seem present on
trunk.

When GCC is configured with:
 --target=arm-none-linux-gnueabihf  --disable-libgomp
--disable-libmudflap --disable-libcilkrts --enable-checking
--enable-languages=c,c++,fortran --with-float=hard
--enable-build-with-cxx --with-mode=arm --with-cpu=cortex-a9
--with-fpu=vfp

and the tests run with -march=armv5t in RUNTESTFLAGS

FAIL: gcc.target/arm/constant-pool.c (test for excess errors)
because:
/ccepmUiD.s:29: Error: selected processor does not support ARM mode
`movw r0,4660'

FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 compilation,  -O2
because:
/cc76h4mz.s: Assembler messages:
/cc76h4mz.s:413: Error: selected processor does not support ARM mode
`movw r3,8224'
/cc76h4mz.s:496: Error: selected processor does not support ARM mode
`movw r2,8224'
/cc76h4mz.s:578: Error: selected processor does not support ARM mode
`movw ip,8224'

Christophe


>
> OK. ( the test function where this will make a difference is testhisf
> for the record) ...
>
> Ramana
>> Matthew
>>
>> 2016-05-17  Jiong Wang  
>> Matthew Wahab  
>>
>> * config/arm/arm.c (output_move_vfp): Weaken assert to allow
>> HImode.
>> (arm_hard_regno_mode_ok): Allow HImode values in VFP registers.
>> * config/arm/arm.md (*movhi_insn_arch4) Disable when VFP registers
>> are
>> available.
>> (*movhi_bytes): Likewise.
>> * config/arm/vfp.md (*arm_movhi_vfp): New.
>> (*thumb2_movhi_vfp): New.
>>
>> testsuite/
>> 2016-05-17  Matthew Wahab  
>>
>> * gcc.target/arm/short-vfp-1.c: New.
>>

Re: [PATCH 6/17][ARM] Add data processing intrinsics for float16_t.

[Matthew Wahab]

On 26/09/16 14:03, Ramana Radhakrishnan wrote:

On Mon, Sep 26, 2016 at 1:48 PM, Christophe Lyon
 wrote:

On 26 September 2016 at 11:43, Matthew Wahab  wrote:

Hello,

On 25/09/16 14:00, Christophe Lyon wrote:



This patch adds the new intrinsics:
   vbsl_f16, vbslq_f16, vdup_n_f16, vdupq_n_f16, vdup_lane_f16,
   vdupq_lane_f16, vext_f16, vextq_f16, vmov_n_f16, vmovq_n_f16,
   vrev64_f16, vrev64q_f16, vtrn_f16, vtrnq_f16, vuzp_f16, vuzpq_f16,
   vzip_f16, vzipq_f16.

This patch also updates the advsimd-intrinsics testsuite to test the f16
variants for ARM targets. These intrinsics are only implemented in the
ARM target so the tests are disabled for AArch64 using an extra
condition on a new convenience macro FP16_SUPPORTED. This patch also
disables, for the ARM target, the testsuite defined macro vdup_n_f16 as
it is no longer needed.



Since you committed this patch, I've noticed that libgcc fails to build
when GCC is configured:
--target arm-none-eabi and default cpu
/tmp/9649048_29.tmpdir/ccuBwQJJ.s: Assembler messages:
/tmp/9649048_29.tmpdir/ccuBwQJJ.s:64: Error: selected processor does
not support ARM mode `movwlt r0,32768'
/tmp/9649048_29.tmpdir/ccuBwQJJ.s:65: Error: selected processor does
not support ARM mode `movwge r0,32767'
make[4]: *** [_ssaddHQ.o] Error 1
make[4]: Leaving directory

`/tmp/9649048_29.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc1/arm-none-eabi/fpu/libgcc'




I can't reproduce the failure, could you send the configure arguments for
the build.



If I'm not mistaken, that is:
  --target=arm-none-eabi  --disable-nls --disable-libgomp
--disable-libmudflap --disable-libcilkrts --enable-checking
--enable-languages=c,c++ --with-newlib

Maybe you've disabled multilibs?



I'm pretty sure I built this as part of reviewing all these patches
with --with-mutlib-list=aprofile and didnt' see any failures. Not sure
what's going on here.



I think the problem is that the new patterns use MOVW, which is a Thumb-2 
instruction, but don't check for Thumb-2 support in the target. I'm testing a 
patch to fix this.


Matthew

Re: [PATCH] Increase lto-min-partition

[Wilco Dijkstra]

Prathamesh Kulkarni  wrote:

> Hi Wilco,
> I am working on LTO varpool partitioning to improve performance for
> section anchors.
> I posted a preliminary patch posted at:
> https://gcc.gnu.org/ml/gcc/2016-07/msg00033.html
> Unfortunately I haven't yet been able to benchmark it on ARM yet.
> I am planning to restart working on it again soon.

Thanks, I'll have a look. However I'm not 100% convinced smarter symbol
partitioning is the best way forward. Although it should help, it doesn't take 
into
account which symbols are currently suitable as anchors (-fcommon
is still the default, and big arrays are not suitable). And you still have to 
make
difficult choices for symbols that are frequently used across most partitions.

So I believe the best solution is to assign anchors early on so that all 
partitions
can make use of anchors. Assuming we sort symbols on size and frequency,
it should be feasible to use a single anchor for all simple integer global 
variables
across the whole application. Assigning early should also allow common
variables to be used in anchors, further increasing the benefit.

Do you think that is feasible?

> Building with a single partition is not scalable. LTO build of
> chromium with x86->arm
> cross with a single partition results in "branch out of range"
> assembler error. I added lto-max-partition
> primarily to work around that limitation.

Yes, GCC doesn't split huge compilation units into multiple text sections
so that the linker can insert long branch veneers. So it's a workaround
for LTO but most RISC targets can still hit the same issue with a single
huge file.

Wilco

Re: [PATCH 6/17][ARM] Add data processing intrinsics for float16_t.

[Ramana Radhakrishnan]

On Mon, Sep 26, 2016 at 1:48 PM, Christophe Lyon
 wrote:
> On 26 September 2016 at 11:43, Matthew Wahab  
> wrote:
>> Hello,
>>
>> On 25/09/16 14:00, Christophe Lyon wrote:
>
>
> This patch adds the new intrinsics:
>   vbsl_f16, vbslq_f16, vdup_n_f16, vdupq_n_f16, vdup_lane_f16,
>   vdupq_lane_f16, vext_f16, vextq_f16, vmov_n_f16, vmovq_n_f16,
>   vrev64_f16, vrev64q_f16, vtrn_f16, vtrnq_f16, vuzp_f16, vuzpq_f16,
>   vzip_f16, vzipq_f16.
>
> This patch also updates the advsimd-intrinsics testsuite to test the f16
> variants for ARM targets. These intrinsics are only implemented in the
> ARM target so the tests are disabled for AArch64 using an extra
> condition on a new convenience macro FP16_SUPPORTED. This patch also
> disables, for the ARM target, the testsuite defined macro vdup_n_f16 as
> it is no longer needed.
>>>
>>>
>>> Since you committed this patch, I've noticed that libgcc fails to build
>>> when GCC is configured:
>>> --target arm-none-eabi and default cpu
>>> /tmp/9649048_29.tmpdir/ccuBwQJJ.s: Assembler messages:
>>> /tmp/9649048_29.tmpdir/ccuBwQJJ.s:64: Error: selected processor does
>>> not support ARM mode `movwlt r0,32768'
>>> /tmp/9649048_29.tmpdir/ccuBwQJJ.s:65: Error: selected processor does
>>> not support ARM mode `movwge r0,32767'
>>> make[4]: *** [_ssaddHQ.o] Error 1
>>> make[4]: Leaving directory
>>>
>>> `/tmp/9649048_29.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc1/arm-none-eabi/fpu/libgcc'
>>>
>>
>>
>> I can't reproduce the failure, could you send the configure arguments for
>> the build.
>>
>
> If I'm not mistaken, that is:
>  --target=arm-none-eabi  --disable-nls --disable-libgomp
> --disable-libmudflap --disable-libcilkrts --enable-checking
> --enable-languages=c,c++ --with-newlib
>
> Maybe you've disabled multilibs?


I'm pretty sure I built this as part of reviewing all these patches
with --with-mutlib-list=aprofile and didnt' see any failures. Not sure
what's going on here.

Ramana
>
>> I've tried assembling the string 'movw r0, 32768' and get the error when
>> -march=armv6kz or earlier. I suspect the new movhi and/or movhf patterns
>> added earlier in the series need the architecture level added as a
>> precondition but I'll need to look into it.
>>
>> Matthew
>
> Thanks,
>
> Christophe

Re: [v3 PATCH] Implement LWG 2729 for pair.

[Jonathan Wakely]

On 24/09/16 21:13 +0300, Ville Voutilainen wrote:

So, this has been applied to trunk, and also applies cleanly to the
gcc-6 branch, and we need
to backport it to fix PR libstdc++/77537. Ok for the gcc-6 branch?


Yes, OK for gcc-6-branch too, as it fixes a regression since 5.x

Re: [PATCH GCC][v2]Simplify alias check code generation in vectorizer

[Markus Trippelsdorf]

On 2016.09.26 at 13:14 +0200, Richard Biener wrote:
> On Mon, Sep 26, 2016 at 11:21 AM, Robin Dapp  wrote:
> >> Comments added.  Bootstrap and test, is it reasonable?
> >
> > This introduces an ICE on s390x with a Fortran testcase, because
> > of an assertion failure in tree_to_uhwi (DR_STEP (dr_a.dr)) for
> > DR_STEP (dr_a.dr) = -8(OVF).
> >
> > The attached patch fixes this by introducing an additional
> > tree_fits_uhwi_p().
> >
> > ok to commit?
> 
> no, this disables handling of negative step.  I think it should
> check for tree_fits_shwi_p () instead and adjust the code to do
> 
>   unsigned HOST_WIDE_INT abs_step = absu_hwi (tree_to_shwi (DR_STEP 
> (dr_a.dr)));
> 

And also please mention https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77724 and 
perhaps
add its testcase, too.

-- 
Markus

Re: [PATCH 6/17][ARM] Add data processing intrinsics for float16_t.

[Christophe Lyon]

On 26 September 2016 at 11:43, Matthew Wahab  wrote:
> Hello,
>
> On 25/09/16 14:00, Christophe Lyon wrote:


 This patch adds the new intrinsics:
   vbsl_f16, vbslq_f16, vdup_n_f16, vdupq_n_f16, vdup_lane_f16,
   vdupq_lane_f16, vext_f16, vextq_f16, vmov_n_f16, vmovq_n_f16,
   vrev64_f16, vrev64q_f16, vtrn_f16, vtrnq_f16, vuzp_f16, vuzpq_f16,
   vzip_f16, vzipq_f16.

 This patch also updates the advsimd-intrinsics testsuite to test the f16
 variants for ARM targets. These intrinsics are only implemented in the
 ARM target so the tests are disabled for AArch64 using an extra
 condition on a new convenience macro FP16_SUPPORTED. This patch also
 disables, for the ARM target, the testsuite defined macro vdup_n_f16 as
 it is no longer needed.
>>
>>
>> Since you committed this patch, I've noticed that libgcc fails to build
>> when GCC is configured:
>> --target arm-none-eabi and default cpu
>> /tmp/9649048_29.tmpdir/ccuBwQJJ.s: Assembler messages:
>> /tmp/9649048_29.tmpdir/ccuBwQJJ.s:64: Error: selected processor does
>> not support ARM mode `movwlt r0,32768'
>> /tmp/9649048_29.tmpdir/ccuBwQJJ.s:65: Error: selected processor does
>> not support ARM mode `movwge r0,32767'
>> make[4]: *** [_ssaddHQ.o] Error 1
>> make[4]: Leaving directory
>>
>> `/tmp/9649048_29.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc1/arm-none-eabi/fpu/libgcc'
>>
>
>
> I can't reproduce the failure, could you send the configure arguments for
> the build.
>

If I'm not mistaken, that is:
 --target=arm-none-eabi  --disable-nls --disable-libgomp
--disable-libmudflap --disable-libcilkrts --enable-checking
--enable-languages=c,c++ --with-newlib

Maybe you've disabled multilibs?

> I've tried assembling the string 'movw r0, 32768' and get the error when
> -march=armv6kz or earlier. I suspect the new movhi and/or movhf patterns
> added earlier in the series need the architecture level added as a
> precondition but I'll need to look into it.
>
> Matthew

Thanks,

Christophe

Re: [PATCH GCC][v2]Simplify alias check code generation in vectorizer

[Bin.Cheng]

On Mon, Sep 26, 2016 at 10:21 AM, Robin Dapp  wrote:
>> Comments added.  Bootstrap and test, is it reasonable?
>
> This introduces an ICE on s390x with a Fortran testcase, because
> of an assertion failure in tree_to_uhwi (DR_STEP (dr_a.dr)) for
> DR_STEP (dr_a.dr) = -8(OVF).
>
> The attached patch fixes this by introducing an additional
> tree_fits_uhwi_p().
>
> ok to commit?
Hi Robin,
Unfortunately I won't have code access now, could you please work out
a patch as suggested by Richard?  Thanks very much for fixing this.

Thanks,
bin
>
> Regards
>  Robin
>
> --
>
> gcc/ChangeLog:
>
> 2016-09-26  Robin Dapp  
>
> * tree-vect-loop-manip.c (create_intersect_range_checks_index):
> Add tree_fits_uhwi_p check.

Re: [Patch, reload, tentative, PR 71627] Tweak conditions in find_valid_class_1

[Senthil Kumar Selvaraj]

Ping!

Regards
Senthil

Senthil Kumar Selvaraj writes:

> Hi,
>
>   The below patch fixes what I think are a couple of problems with
>   reload.c:find_valid_class_1.
>
>   First, even if no regno is in_hard_reg_set_p, it goes ahead and
>   considers rclass as valid. bad is set only if a regno is in the reg
>   class *and* HARD_REGNO_MODE_OK is false - if both are false, bad isn't
>   set and the reload gets a wrong rclass. If that happens to be the best
>   one, this eventually leads to find_reg running out of registers to
>   spill, because the chosen rclass won't have enough regs.
>
>   Second, it expects every regno in rclass to be valid for mode i.e., if
>   any regno fails HARD_REGNO_MODE_OK, it rejects the rclass. The
>   comments in the original commit for find_valid_class_1 say atleast one
>   regno is ok. This was updated to say "class which contains only
>   registers" when in_hard_reg_set_p was introduced in place of just
>   TEST_HARD_REG_BIT.
>
>   Is it meant to really test all regs? For the avr target, all regs are
>   8 bits wide, and HARD_REGNO_MODE_OK returns false for odd regnos if
>   mode != QImode. With the current code, it ignores a bunch of otherwise
>   perfectly legal reg classes.
>
>   To fix the first problem, the patch adds regno_in_rclass_mode to track
>   whether there's atleast one regno in hard_reg_set_p. To fix the second
>   problem, the patch sets bad initially, and resets it if
>   HARD_REGNO_MODE_OK succeeded for a regno, thus breaking the loop.
>
>   Of course, if both my points above are valid, we can do away with
>   regno_in_rclass_mode, just bad would do.
>
>   Does this make sense? I ran a reg test for the avr target with a
>   slightly older version of this patch, it did not show any regressions.
>   If this is the right fix, I'll make sure to run reg tests on x86_64
>   after backporting to a gcc version where that target used reload.
>
> Regards
> Senthil
>
>
> Index: reload.c
> ===
> --- reload.c  (revision 240185)
> +++ reload.c  (working copy)
> @@ -714,17 +714,22 @@
>  
>for (rclass = 1; rclass < N_REG_CLASSES; rclass++)
>  {
> -  int bad = 0;
> -  for (regno = 0; regno < FIRST_PSEUDO_REGISTER && !bad; regno++)
> - {
> -   if (in_hard_reg_set_p (reg_class_contents[rclass], mode, regno)
> -   && !HARD_REGNO_MODE_OK (regno, mode))
> - bad = 1;
> - }
> -  
> -  if (bad)
> - continue;
> +  int bad = 1;
> +  int regno_in_rclass_mode = 0;
>  
> +  for (regno = 0; regno < FIRST_PSEUDO_REGISTER && bad; regno++)
> +{
> +  if (in_hard_reg_set_p (reg_class_contents[rclass], mode, regno))
> +{
> +  regno_in_rclass_mode = 1;
> +  if (HARD_REGNO_MODE_OK (regno, mode))
> +bad = 0;
> +}
> +}
> +
> +  if (bad || !regno_in_rclass_mode)
> +continue;
> +
>cost = register_move_cost (outer, (enum reg_class) rclass, dest_class);
>  
>if ((reg_class_size[rclass] > best_size

Re: [Patch, avr] Backport fix for PR 65210 to gcc-5-branch

[Senthil Kumar Selvaraj]

Ping!

Regards
Senthil
Senthil Kumar Selvaraj writes:

> Hi,
>
>   Is it ok to backport PR 65210 to gcc-5-branch? The patch is already in
>   6.x and trunk.
>
> Regards
> Senthil
>
> gcc/ChangeLog
>
> 2016-09-22  Senthil Kumar Selvaraj  
>
>   Backport from trunk r227496
>
>   PR target/65210
>   * config/avr/avr.c (avr_eval_addr_attrib): Look for io_low
>   attribute as well.
>
> gcc/testsuite/ChangeLog
>
> 2016-09-22  Senthil Kumar Selvaraj  
>
>   Backport from trunk r227496
>
>   PR target/65210
>   * gcc.target/avr/pr65210.c: New test.
>
> Index: gcc/config/avr/avr.c
> ===
> --- gcc/config/avr/avr.c  (revision 240340)
> +++ gcc/config/avr/avr.c  (working copy)
> @@ -9122,6 +9122,8 @@
>if (SYMBOL_REF_FLAGS (x) & SYMBOL_FLAG_IO)
>   {
> attr = lookup_attribute ("io", DECL_ATTRIBUTES (decl));
> +   if (!attr || !TREE_VALUE (attr))
> + attr = lookup_attribute ("io_low", DECL_ATTRIBUTES (decl));
> gcc_assert (attr);
>   }
>if (!attr || !TREE_VALUE (attr))
>Index: gcc/testsuite/gcc.target/avr/pr65210.c
> ===
> --- gcc/testsuite/gcc.target/avr/pr65210.c(nonexistent)
> +++ gcc/testsuite/gcc.target/avr/pr65210.c(working copy)
> @@ -0,0 +1,7 @@
> +/* { dg-do compile } */
> +
> +/* This testcase exposes PR65210. Usage of the io_low attribute
> +   causes assertion failure because code only looks for the io
> +   attribute if SYMBOL_FLAG_IO is set. */
> +
> +volatile char q __attribute__((io_low,address(0x81)));

C++ PATCH for __has_cpp_attribute and fallthrough

[Marek Polacek]

This patch updates __has_cpp_attribute for fallthrough, which is now supported.

The system.h hunk should aid people building trunk GCC with older GCC 7 not
supporting this attribute yet.

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

2016-09-26  Marek Polacek  

* c-lex.c (c_common_has_attribute): Handle attribute fallthrough.

* system.h: Use __has_attribute to check whether the fallthrough
attribute is supported.

* g++.dg/cpp1z/feat-cxx1z.C: Test attribute fallthrough.

diff --git gcc/c-family/c-lex.c gcc/c-family/c-lex.c
index 829c18b..5c6496e 100644
--- gcc/c-family/c-lex.c
+++ gcc/c-family/c-lex.c
@@ -350,7 +350,8 @@ c_common_has_attribute (cpp_reader *pfile)
  else if (is_attribute_p ("deprecated", attr_name))
result = 201309;
  else if (is_attribute_p ("maybe_unused", attr_name)
-  || is_attribute_p ("nodiscard", attr_name))
+  || is_attribute_p ("nodiscard", attr_name)
+  || is_attribute_p ("fallthrough", attr_name))
result = 201603;
  if (result)
attr_name = NULL_TREE;
diff --git gcc/system.h gcc/system.h
index 8ca71cf..0952e4f 100644
--- gcc/system.h
+++ gcc/system.h
@@ -746,8 +746,12 @@ extern void fancy_abort (const char *, int, const char *) 
ATTRIBUTE_NORETURN;
 #define gcc_unreachable() (fancy_abort (__FILE__, __LINE__, __FUNCTION__))
 #endif
 
-#if GCC_VERSION >= 7000
-# define gcc_fallthrough() __attribute__((fallthrough))
+#if GCC_VERSION >= 7000 && defined(__has_attribute)
+# if __has_attribute(fallthrough)
+#  define gcc_fallthrough() __attribute__((fallthrough))
+# else
+#  define gcc_fallthrough()
+# endif
 #else
 # define gcc_fallthrough()
 #endif
diff --git gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C 
gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C
index 982572e..71c8c7d 100644
--- gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C
+++ gcc/testsuite/g++.dg/cpp1z/feat-cxx1z.C
@@ -370,6 +370,12 @@
 #error "__has_cpp_attribute(nodiscard) != 201603"
 #  endif
 
+#  if ! __has_cpp_attribute(fallthrough)
+#error "__has_cpp_attribute(fallthrough)"
+#  elif __has_cpp_attribute(fallthrough) != 201603
+#error "__has_cpp_attribute(fallthrough) != 201603"
+#  endif
+
 #else
 #  error "__has_cpp_attribute"
 #endif

Marek

Re: [PATCH] Increase lto-min-partition

[Wilco Dijkstra]

Markus Trippelsdorf wrote: 
> On 2016.09.26 at 09:42 +0200, Richard Biener wrote:
> > On Sat, Sep 24, 2016 at 10:52 AM, Markus Trippelsdorf
> >  wrote:
> > > On 2016.09.23 at 15:29 +0200, Richard Biener wrote:

> > > If for example you limit partitions to 4 on a 4-core machine with 8GB
> > > memory, you would start swapping when building Firefox.
> >
> > > And even lto-partitions=8 is slower than the default of 32:

If certain applications swap with 8 partitions, other applications that are
4 times larger will still swap with 32 partitions, agreed?

Ie. it implies the max partition size is way too large, not that 32 partitions
is best. You'd set it as large as possible to avoid the overhead of having
lots of partitions, but small enough so that a typical machine wouldn't swap.

> Also see the comment in gcc/lto/lto-partition.c:

 428    We compute the expected size of a partition as:
 429
 430  max (total_size / lto_partitions, min_partition_size)

That looks a bit too simplistic with current default settings... So up to
32000 instructions (ie. binary size of ~130KB) it uses as many partitions
as possible of 1 insns, after that it uses 32 partitions until 3200
instructions...

Wilco

Re: debug container mutex association

[Andreas Schwab]

FAIL: 23_containers/list/debug/invalidation/4.cc (test for excess errors)
Excess errors:
/daten/aranym/gcc/gcc-20160926/Build/m68k-linux/libstdc++-v3/include/debug/safe_sequence.tcc:89:
 error: 'void __gnu_debug::_Safe_iterator_base::_M_detach_single()' is 
protected within this context
/daten/aranym/gcc/gcc-20160926/Build/m68k-linux/libstdc++-v3/include/debug/safe_sequence.tcc:112:
 error: 'void __gnu_debug::_Safe_iterator_base::_M_detach_single()' is 
protected within this context

Andreas.

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

[PATCH, OBVIOUS] Fix documentation of gcov tool

[Martin Liška]

gcov program produces a different output compared to what's mentioned
in documentation. Attached patch changes that.

Installed as obvious.
Martin
>From 76d40ef712b42b60f74087a6ecbd6ee163554d5b Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 26 Sep 2016 13:51:55 +0200
Subject: [PATCH] Fix documentation of gcov tool

gcc/ChangeLog:

2016-09-26  Martin Liska  

	* doc/gcov.texi: Update program output of gcov tool.
---
 gcc/doc/gcov.texi | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/gcc/doc/gcov.texi b/gcc/doc/gcov.texi
index a0a7af7..1523cb1 100644
--- a/gcc/doc/gcov.texi
+++ b/gcc/doc/gcov.texi
@@ -367,8 +367,9 @@ is what you see when you use the basic @command{gcov} facility:
 $ gcc -fprofile-arcs -ftest-coverage tmp.c
 $ a.out
 $ gcov tmp.c
-90.00% of 10 source lines executed in file tmp.c
-Creating tmp.c.gcov.
+File 'tmp.c'
+Lines executed:90.00% of 10
+Creating 'tmp.c.gcov'
 @end smallexample
 
 The file @file{tmp.c.gcov} contains output from @command{gcov}.
@@ -452,11 +453,12 @@ When you use the @option{-b} option, your output looks like this:
 
 @smallexample
 $ gcov -b tmp.c
-90.00% of 10 source lines executed in file tmp.c
-80.00% of 5 branches executed in file tmp.c
-80.00% of 5 branches taken at least once in file tmp.c
-50.00% of 2 calls executed in file tmp.c
-Creating tmp.c.gcov.
+File 'tmp.c'
+Lines executed:90.00% of 10
+Branches executed:80.00% of 5
+Taken at least once:80.00% of 5
+Calls executed:50.00% of 2
+Creating 'tmp.c.gcov'
 @end smallexample
 
 Here is a sample of a resulting @file{tmp.c.gcov} file:
-- 
2.9.2

Re: [Patch, fortran] Clean up of error recovery in DTIO procedures

[Paul Richard Thomas]

Dear Rainer and Dominique,

Committed as obvious in revision 240493.

Thanks for doing the testing.

Cheers

Paul

2016-09-26  Paul Thomas  

PR fortran/48298
* interface.c (gfc_find_specific_dtio_proc) : Return NULL if
the derived type is broken, as indicated by a flavor other than
FL_DERIVED.

On 26 September 2016 at 10:26, Paul Richard Thomas
 wrote:
> Dear Rainer,
>
> Thanks to you and Dominique for the confirmation that the patch works. I
> will commit it sometime today.
>
> Regards
>
> Paul
>
>
> On 26 Sep 2016 10:23 a.m., "Rainer Orth" 
> wrote:
>
> Hi Paul,
>
>> Dominique has informed me that the earlier patch did not fix this problem.
>
> indeed, it just shifted the SEGV to a different place.
>
>> Although I still cannot reproduce the problem on FC21, I think that I
>> can see what the problem is. The declared type of 'chairman' is
>> thoroughly broken when it arrives at
>> interface.c(gfc_find_specific_dtio_proc). It doesn't even have the
>> right name! The key signature is that its flavor is FL_UNKNOWN. The
>> attached prevents the code coming anywhere near the call that causes
>> the segfault and regtests OK.
>
> I've now managed to run a sparc-sun-solaris2.10 bootstrap with the patch
> included and the failures are gone indeed.
>
> Thanks.
> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

Re: debug container mutex association

[Jonathan Wakely]

On 20/09/16 09:57 +0100, Jonathan Wakely wrote:

On 19/09/16 21:56 +0200, François Dumont wrote:

Hi

  Following our conversation here is a much simpler patch. I just 
consider that all debug containers will have the same alignment.


  Even if I submit this patch as a whole I will commit into pieces, 
at least one for the pure cleanup parts and one for the debug.cc 
change.


  Among those changes there is:
-   __gnu_cxx::__scoped_lock(this->_M_get_mutex());
+   __gnu_cxx::__scoped_lock __l(this->_M_get_mutex());

  I would appreciate if you could tell me what was happening with 
the initial expression. I don't understand why it is compiling. I 
even tried the same in debug.cc and started having compilation 
errors.


  * include/debug/bitset (bitset::reference::reference(const _Base_ref&,
  bitset*)): Remove __unused__ attribute.
  * include/debug/safe_base.h (_Safe_iterator_base): Make
  _Safe_sequence_base a friend.
  (_Safe_iterator_base::_M_attach): Make protected.
  (_Safe_iterator_base::_M_attach_single): Likewise.
  (_Safe_iterator_base::_M_detach): Likewise.
  (_Safe_iterator_base::_M_detach_single): Likewise.
  (_Safe_sequence_base): Make _Safe_iterator_base a friend.
(_Safe_sequence_base::_Safe_sequence_base(_Safe_sequence_base&&)): New.
  (_Safe_sequence_base::_M_swap): Make protected.
  (_Safe_sequence_base::_M_attach): Make private.
  (_Safe_sequence_base::_M_attach_single): Likewise.
  (_Safe_sequence_base::_M_detach): Likewise.
  (_Safe_sequence_base::_M_detach_single): Likewise.
  * include/debug/safe_container.h
  (_Safe_container::_Safe_container(_Safe_container&&)): Make default.
  * include/debug/safe_iterator.h
  (_Safe_iterator::operator++()): Name __scoped_lock instance.
  * include/debug/safe_iterator.tcc: Remove trailing line.
  * include/debug/safe_unordered_base.h
  (_Safe_local_iterator_base::_M_attach): Make protected.
  (_Safe_local_iterator_base::_M_attach_single): Likewise.
  (_Safe_local_iterator_base::_M_detach): Likewise.
  (_Safe_local_iterator_base::_M_detach_single): Likewise.
  (_Safe_unordered_container_base): Make _Safe_local_iterator_base 
friend.

  (_Safe_unordered_container_base::_M_attach_local): Make private.
  (_Safe_unordered_container_base::_M_attach_local_single): Likewise.
  (_Safe_unordered_container_base::_M_detach_local): Likewise.
  (_Safe_unordered_container_base::_M_detach_local_single): Likewise.
  * src/c++11/debug.cc: Include debug/vector. Include cctype. Remove
  functional.
  (get_safe_base_mutex): Get mutex based on address lowest non nil bits.
  * testsuite/23_containers/vector/debug/mutex_association.cc: New.

Tested under Linux x86_64.

Ok to commit ?


Yes, OK for trunk.  Thanks for revising it, I think this is a much
bettter fix.


This caused a new FAIL:

FAIL: 23_containers/list/debug/invalidation/4.cc (test for excess errors)
UNRESOLVED: 23_containers/list/debug/invalidation/4.cc compilation failed to 
produce executable

Re: [PATCH GCC][v2]Simplify alias check code generation in vectorizer

[Richard Biener]

On Mon, Sep 26, 2016 at 11:21 AM, Robin Dapp  wrote:
>> Comments added.  Bootstrap and test, is it reasonable?
>
> This introduces an ICE on s390x with a Fortran testcase, because
> of an assertion failure in tree_to_uhwi (DR_STEP (dr_a.dr)) for
> DR_STEP (dr_a.dr) = -8(OVF).
>
> The attached patch fixes this by introducing an additional
> tree_fits_uhwi_p().
>
> ok to commit?

no, this disables handling of negative step.  I think it should
check for tree_fits_shwi_p () instead and adjust the code to do

  unsigned HOST_WIDE_INT abs_step = absu_hwi (tree_to_shwi (DR_STEP (dr_a.dr)));

Richard.

> Regards
>  Robin
>
> --
>
> gcc/ChangeLog:
>
> 2016-09-26  Robin Dapp  
>
> * tree-vect-loop-manip.c (create_intersect_range_checks_index):
> Add tree_fits_uhwi_p check.

Re: [PATCH, 1/7] Move memory model declarations in memmodel.h

[Richard Biener]

On Mon, 26 Sep 2016, Thomas Preudhomme wrote:

> 
> 
> On 26/09/16 10:15, Richard Biener wrote:
> > On Thu, 22 Sep 2016, Thomas Preudhomme wrote:
> > 
> > > Hi,
> > > 
> > > This patch is part of a patch series to add support for ARMv8-M[1] to GCC.
> > > This specific patch moves memory model declarations in memmodel.h.
> > > 
> > > Currently, is_mm_* memory model related functions are declared in tree.h
> > > which
> > > prevents using them in constraints machine description files. This patch
> > > move
> > > this functions into a new memmodel.h header to allow such a thing and
> > > update
> > > all users of this function to include the new header.
> > 
> > Ok.  I wonder whether we can move the memmodel stuff from coretypes
> > as well then?
> 
> It's not needed for using what's in there in constraints.md but would be good
> for consistency I think. Do you want me to add it to the patch or make a
> separate one and commit this one?

If it's trivial to include then go with this patch, if it requires work
then as followup is fine with me.

Thanks,
Richard.

> > 
> > Thanks,
> > Richard.
> 
> Best regards,
> 
> Thomas
> 
> > 
> > > ChangeLog entries are as follows:
> > > 
> > > *** gcc/ChangeLog ***
> > > 
> > > 2016-04-20  Thomas Preud'homme  
> > > 
> > > * tree.h (memmodel_from_int, memmodel_base, is_mm_relaxed,
> > > is_mm_consume, is_mm_acquire, is_mm_release, is_mm_acq_rel,
> > > is_mm_seq_cst, is_mm_sync): Move to ...
> > > * memmodel.h: This.  New file.
> > > * builtins.c: Include memmodel.h.
> > > * optabs.c: Likewise.
> > > * tsan.c: Likewise.
> > > * config/aarch64/aarch64.c: Likewise.
> > > * config/alpha/alpha.c: Likewise.
> > > * config/arm/arm.c: Likewise.
> > > * config/i386/i386.c: Likewise.
> > > * config/ia64/ia64.c: Likewise.
> > > * config/mips/mips.c: Likewise.
> > > * config/rs6000/rs6000.c: Likewise.
> > > * config/sparc/sparc.c: Likewise.
> > > * genconditions.c: Include memmodel.h in generated file.
> > > * genemit.c: Likewise.
> > > * genoutput.c: Likewise.
> > > * genpeep.c: Likewise.
> > > * genpreds.c: Likewise.
> > > * genrecog.c: Likewise.
> > > 
> > > 
> > > *** gcc/c-family/ChangeLog ***
> > > 
> > > 2016-04-20  Thomas Preud'homme  
> > > 
> > > * c-common.c: Include memmodel.h.
> > > 
> > > 
> > > Is this ok for trunk?
> > > 
> > > Best regards,
> > > 
> > > Thomas
> > > 
> > 
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

[PATCH] Remove HIST_TYPE_CONST_DELTA counter type (PR, gcov-profile/23332).

[Martin Liška]

Following patch removes old type of GCOV counter that was used in times
when RTL instrumentation was done. Patch is preapproved by Honza.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Martin
>From 75d56f7882d1bc40f7c638462bb6fec3b84c3732 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 23 Sep 2016 10:27:11 +0200
Subject: [PATCH] Remove HIST_TYPE_CONST_DELTA counter type (PR
 gcov-profile/23332).

gcc/ChangeLog:

2016-09-23  Martin Liska  

	PR gcov-profile/23332
	* profile.c (instrument_values): Do not handle
	HIST_TYPE_CONST_DELTA.
	* tree-profile.c (gimple_gen_const_delta_profiler):
	Remove.
	* value-prof.c (dump_histogram_value): Do not handle
	HIST_TYPE_CONST_DELTA.
	(stream_in_histogram_value): Likewise.
	(gimple_find_values_to_profile): Likewise.
	* value-prof.h (enum hist_type): Likewise.
---
 gcc/profile.c  |  4 
 gcc/tree-profile.c | 16 
 gcc/value-prof.c   | 27 ---
 gcc/value-prof.h   |  4 
 4 files changed, 51 deletions(-)

diff --git a/gcc/profile.c b/gcc/profile.c
index 4519e7d..791225b 100644
--- a/gcc/profile.c
+++ b/gcc/profile.c
@@ -179,10 +179,6 @@ instrument_values (histogram_values values)
 	  gimple_gen_one_value_profiler (hist, t, 0);
 	  break;
 
-	case HIST_TYPE_CONST_DELTA:
-	  gimple_gen_const_delta_profiler (hist, t, 0);
-	  break;
-
  	case HIST_TYPE_INDIR_CALL:
  	case HIST_TYPE_INDIR_CALL_TOPN:
  	  gimple_gen_ic_profiler (hist, t, 0);
diff --git a/gcc/tree-profile.c b/gcc/tree-profile.c
index 69b48e5..1f45b99 100644
--- a/gcc/tree-profile.c
+++ b/gcc/tree-profile.c
@@ -471,22 +471,6 @@ gimple_gen_time_profiler (unsigned tag, unsigned base,
   gsi_insert_before (, call, GSI_NEW_STMT);
 }
 
-/* Output instructions as GIMPLE trees for code to find the most common value
-   of a difference between two evaluations of an expression.
-   VALUE is the expression whose value is profiled.  TAG is the tag of the
-   section for counters, BASE is offset of the counter position.  */
-
-void
-gimple_gen_const_delta_profiler (histogram_value value ATTRIBUTE_UNUSED,
-			   unsigned tag ATTRIBUTE_UNUSED,
-			   unsigned base ATTRIBUTE_UNUSED)
-{
-  /* FIXME implement this.  */
-  if (flag_checking)
-internal_error ("unimplemented functionality");
-  gcc_unreachable ();
-}
-
 /* Output instructions as GIMPLE trees to increment the average histogram
counter.  VALUE is the expression whose value is profiled.  TAG is the
tag of the section for counters, BASE is offset of the counter position.  */
diff --git a/gcc/value-prof.c b/gcc/value-prof.c
index a4653aa..e794e6d 100644
--- a/gcc/value-prof.c
+++ b/gcc/value-prof.c
@@ -95,12 +95,6 @@ along with GCC; see the file COPYING3.  If not see
 
Limitations / FIXME / TODO:
* Only one histogram of each type can be associated with a statement.
-   * Currently, HIST_TYPE_CONST_DELTA is not implemented.
- (This type of histogram was originally used to implement a form of
- stride profiling based speculative prefetching to improve SPEC2000
- scores for memory-bound benchmarks, mcf and equake.  However, this
- was an RTL value-profiling transformation, and those have all been
- removed.)
* Some value profile transformations are done in builtins.c (?!)
* Updating of histograms needs some TLC.
* The value profiling code could be used to record analysis results
@@ -306,19 +300,6 @@ dump_histogram_value (FILE *dump_file, histogram_value hist)
   fprintf (dump_file, ".\n");
   break;
 
-case HIST_TYPE_CONST_DELTA:
-  fprintf (dump_file, "Constant delta ");
-  if (hist->hvalue.counters)
-	{
-	   fprintf (dump_file, "value:%" PRId64
-		" match:%" PRId64
-		" wrong:%" PRId64,
-		(int64_t) hist->hvalue.counters[0],
-		(int64_t) hist->hvalue.counters[1],
-		(int64_t) hist->hvalue.counters[2]);
-	}
-  fprintf (dump_file, ".\n");
-  break;
 case HIST_TYPE_INDIR_CALL:
   fprintf (dump_file, "Indirect call ");
   if (hist->hvalue.counters)
@@ -426,10 +407,6 @@ stream_in_histogram_value (struct lto_input_block *ib, gimple *stmt)
 	  ncounters = 3;
 	  break;
 
-	case HIST_TYPE_CONST_DELTA:
-	  ncounters = 4;
-	  break;
-
 	case HIST_TYPE_IOR:
 case HIST_TYPE_TIME_PROFILE:
 	  ncounters = 1;
@@ -2080,10 +2057,6 @@ gimple_find_values_to_profile (histogram_values *values)
 	  hist->n_counters = 3;
 	  break;
 
-	case HIST_TYPE_CONST_DELTA:
-	  hist->n_counters = 4;
-	  break;
-
  	case HIST_TYPE_INDIR_CALL:
  	  hist->n_counters = 3;
 	  break;
diff --git a/gcc/value-prof.h b/gcc/value-prof.h
index d426d83..07e2b3b 100644
--- a/gcc/value-prof.h
+++ b/gcc/value-prof.h
@@ -28,8 +28,6 @@ enum hist_type
   HIST_TYPE_POW2,	/* Histogram of power of 2 values.  */
   HIST_TYPE_SINGLE_VALUE, /* Tries to identify the value that is (almost)
 			   always constant.  */
-  HIST_TYPE_CONST_DELTA, /* Tries to identify the (almost) always constant
-			   

Re: [PATCH, 1/7] Move memory model declarations in memmodel.h

[Thomas Preudhomme]

On 26/09/16 10:15, Richard Biener wrote:

On Thu, 22 Sep 2016, Thomas Preudhomme wrote:


Hi,

This patch is part of a patch series to add support for ARMv8-M[1] to GCC.
This specific patch moves memory model declarations in memmodel.h.

Currently, is_mm_* memory model related functions are declared in tree.h which
prevents using them in constraints machine description files. This patch move
this functions into a new memmodel.h header to allow such a thing and update
all users of this function to include the new header.


Ok.  I wonder whether we can move the memmodel stuff from coretypes
as well then?


It's not needed for using what's in there in constraints.md but would be good 
for consistency I think. Do you want me to add it to the patch or make a 
separate one and commit this one?




Thanks,
Richard.


Best regards,

Thomas




ChangeLog entries are as follows:

*** gcc/ChangeLog ***

2016-04-20  Thomas Preud'homme  

* tree.h (memmodel_from_int, memmodel_base, is_mm_relaxed,
is_mm_consume, is_mm_acquire, is_mm_release, is_mm_acq_rel,
is_mm_seq_cst, is_mm_sync): Move to ...
* memmodel.h: This.  New file.
* builtins.c: Include memmodel.h.
* optabs.c: Likewise.
* tsan.c: Likewise.
* config/aarch64/aarch64.c: Likewise.
* config/alpha/alpha.c: Likewise.
* config/arm/arm.c: Likewise.
* config/i386/i386.c: Likewise.
* config/ia64/ia64.c: Likewise.
* config/mips/mips.c: Likewise.
* config/rs6000/rs6000.c: Likewise.
* config/sparc/sparc.c: Likewise.
* genconditions.c: Include memmodel.h in generated file.
* genemit.c: Likewise.
* genoutput.c: Likewise.
* genpeep.c: Likewise.
* genpreds.c: Likewise.
* genrecog.c: Likewise.


*** gcc/c-family/ChangeLog ***

2016-04-20  Thomas Preud'homme  

* c-common.c: Include memmodel.h.


Is this ok for trunk?

Best regards,

Thomas

Re: [v3 PATCH] PR libstdc++/77727

[Jonathan Wakely]

On 26/09/16 02:06 +0300, Ville Voutilainen wrote:

   PR libstdc++/77727
   * include/std/optional (optional(const optional<_Up>&)):
   Default-initialize the base and use emplace.
   (optional(optional<_Up>&&)): Likewise.
   * testsuite/20_util/optional/cons/77727.cc: New.


OK, thanks.

[C++] fix some nits

[Nathan Sidwell]

In working on PR66443, I encountered a few nits.  Fixed thusly:

1) a misaligned } in init.c

2) process_subob_fn used goto...label, when regular if {return} works fine.  (I 
guess the control flow got simplified at some point)


3) implicitly_declare_fn repeats a lambda deleted fn check that 
synthesized_method_walk has already done.


The last one was the most suspicious, I checked that constexpr_p and deleted_p 
already had the expected values when that if triggered, and that tests actually 
got there.  bootstrap and testing showed the check redundant.


Committed to trunk.

nathan
2016-09-26  Nathan Sidwell  

	* init.c (expand_default_init): Fix } indentation.
	* method.c (process_subob_fn): Simplify control structure to
	remove gotos.
	(implicitly_declare_fn): Remove duplicated lambda ctor check.

Index: init.c
===
--- init.c	(revision 240488)
+++ init.c	(working copy)
@@ -1747,7 +1747,7 @@ expand_default_init (tree binfo, tree tr
 	ctor_name = base_ctor_identifier;
   rval = build_special_member_call (exp, ctor_name, , binfo, flags,
 	complain);
-  }
+}
 
   if (parms != NULL)
 release_tree_vector (parms);
Index: method.c
===
--- method.c	(revision 240488)
+++ method.c	(working copy)
@@ -1129,7 +1129,11 @@ process_subob_fn (tree fn, tree *spec_p,
 		  bool diag, tree arg, bool dtor_from_ctor = false)
 {
   if (!fn || fn == error_mark_node)
-goto bad;
+{
+  if (deleted_p)
+	*deleted_p = true;
+  return;
+}
 
   if (spec_p)
 {
@@ -1162,12 +1166,6 @@ process_subob_fn (tree fn, tree *spec_p,
 	  explain_invalid_constexpr_fn (fn);
 	}
 }
-
-  return;
-
- bad:
-  if (deleted_p)
-*deleted_p = true;
 }
 
 /* Subroutine of synthesized_method_walk to allow recursion into anonymous
@@ -1931,12 +1929,6 @@ implicitly_declare_fn (special_function_
   DECL_DEFAULTED_FN (fn) = 1;
   if (cxx_dialect >= cxx11)
 {
-  /* "The closure type associated with a lambda-expression has a deleted
-	 default constructor and a deleted copy assignment operator."  */
-  if ((kind == sfk_constructor
-	   || kind == sfk_copy_assignment)
-	  && LAMBDA_TYPE_P (type))
-	deleted_p = true;
   DECL_DELETED_FN (fn) = deleted_p;
   DECL_DECLARED_CONSTEXPR_P (fn) = constexpr_p;
 }

Re: Deprecating Libstdc++ Profile Mode

[Jonathan Wakely]

As discussed on the libstdc++ list (see below) I'm formally
deprecating the Profile Mode, and will commit this patch to the
wwwdocs.

I don't plan to actually remove the code until SystemTap trace points
have been added to the rest of the library to make the Profile Mode
instrumentation redundant, but I want to announce the deprecation now.


On 18/09/16 22:31 +0200, François Dumont wrote:
   No problem about it. I always considered this mode as a good idea 
but never got/took time to work on it. It already provides some hint 
on how application should be changed but without any clear report of 
someone using it I understand that it is preferable to get rid of it.


François


On 17/09/2016 00:17, Jonathan Wakely wrote:

Libstdc++ features a "Profile Mode", see
https://gcc.gnu.org/onlinedocs/libstdc++/manual/profile_mode.html

We've been carrying thousands of lines of code for years, with no
useful tools for doing anything with the performance instrumentation.

Furthermore, many of the profile mode containers don't even contain
any instrumentation (e.g. array, bitset, deque, forward_list). This
means we have to maintain them, and add new functions as the standard
evolves, for absolutely no benefit. (In fact we haven't been doing
that, so the profile mode containers are missing lots of C++14 and
C++17 features).

I know François has objected to removing the profile mode before, but
all that's happened since then is some refactoring, and no progress on
any tools to analyse the profile data and do anything with it.

I propose removing the Profile Mode containers and adding SystemTap
trace points to the normal containers instead. That will allow users
to measure the same actions as Profile Mode tracks, but without any
ABI impact, or needing to recompile the entire program. If anybody
ever comes up with any useful heuristics to analyse the profile data
they can use data recorded by SystemTap, instead of Profile Mode.

So I want to deprecate Profile Mode for GCC 7, and remove it at a
future date when all the same profiling data (and probably even more)
can be gathered using SystemTap instead.

I don't want to keep this code in the repository even if somebody else
is willing to maintain it. Let's please just remove it.




Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.14
diff -u -r1.14 changes.html
--- htdocs/gcc-7/changes.html	19 Sep 2016 18:29:16 -	1.14
+++ htdocs/gcc-7/changes.html	26 Sep 2016 10:30:55 -
@@ -28,6 +28,10 @@
   has_trivial_default_constructor,
   has_trivial_copy_constructor and
   has_trivial_copy_assign have been removed.
+  The libstdc++
+  https://gcc.gnu.org/onlinedocs/libstdc++/manual/profile_mode.html;>Profile
+  Mode has been deprecated and will be removed in a future version.
+  
 
 
 

[wwwdocs] Replace outdated C++ FAQ URL and fix grammar.

[Jonathan Wakely]

Marshall Cline's FAQ at parashift.com has been superseded by the
isocpp.org FAQ.

I've also replaced "resp.", as
https://en.wiktionary.org/wiki/resp.#Usage_notes agrees that this
usage isn't correct. Maybe it would be even better at the end of the
sentence, but this is OK too.


Index: htdocs/faq.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v
retrieving revision 1.221
diff -u -r1.221 faq.html
--- htdocs/faq.html	27 Jun 2015 19:26:46 -	1.221
+++ htdocs/faq.html	26 Sep 2016 10:22:43 -
@@ -9,9 +9,9 @@
 GCC Frequently Asked Questions
 
 This FAQ tries to answer specific questions concerning GCC. For
-general information regarding C, C++, resp. Fortran please check the 
-http://c-faq.com/;>comp.lang.c FAQ,
-http://www.parashift.com/c++-faq/;>C++ FAQ,
+general information regarding C, C++, and Fortran respectively, please check
+the http://c-faq.com/;>comp.lang.c FAQ,
+https://isocpp.org/faq/;>C++ FAQ,
 and the http://www.fortran.com/fortran/info.html;>Fortran
 Information page.
 

[PATCH] Remove redefinition of __cpp_lib_array_constexpr

[Jonathan Wakely]

I mistakenly defined this macro before I committed the feature, and
then we ended up with two (slightly different) definitions.

* include/bits/range_access.h (__cpp_lib_array_constexpr): Do not
redefine macro defined in .

Tested powerpc64le-linux, committed to trunk.

commit 2ee4111bd25d1685a2e092256c85776c52b6f628
Author: redi 
Date:   Mon Sep 26 10:17:53 2016 +

Remove redefinition of __cpp_lib_array_constexpr

* include/bits/range_access.h (__cpp_lib_array_constexpr): Do not
redefine macro defined in .

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@240488 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/libstdc++-v3/include/bits/range_access.h 
b/libstdc++-v3/include/bits/range_access.h
index 27cc8ed..95c3d52 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -38,10 +38,6 @@ namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
-#if __cplusplus >= 201402L
-# define __cpp_lib_array_constexpr 201603L
-#endif
-
   /**
*  @brief  Return an iterator pointing to the first element of
*  the container.

Re: [PATCH] Implement C++17 node extraction and insertion (P0083R5)

[Jonathan Wakely]

On 21/09/16 14:48 +0100, Jonathan Wakely wrote:

This implements container node extraction/insertion, and merging. The
patch includes Debug Mode support and pretty printers for the node
handles.


This adds some assertions to check for the mistake of trying to
extract the end iterator.

Tested powerpc64le-linux, comitted to trunk.


commit 1073944c341d022d501c07b7881e7c6ead0b1fca
Author: Jonathan Wakely 
Date:   Mon Sep 26 10:35:52 2016 +0100

Add assertions to extract(const_iterator) functions

	* include/bits/stl_map.h (map::extract(const_iterator)): Assert that
	iterator is not past-the-end.
	* include/bits/stl_multimap.h (multimap::extract(const_iterator)):
	Likewise.
	* include/bits/stl_multiset.h (multiset::extract(const_iterator)):
	Likewise.
	* include/bits/stl_set.h (set::extract(const_iterator)): Likewise.
	* include/bits/unordered_map.h (unordered_map::extract(const_iterator))
	(unordered_multimap::extract(const_iterator)): Likewise.
	* include/bits/unordered_set.h (unordered_set::extract(const_iterator))
	(unordered_multiset::extract(const_iterator)): Likewise.

diff --git a/libstdc++-v3/include/bits/stl_map.h b/libstdc++-v3/include/bits/stl_map.h
index f9482e2..9a0454a 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -605,7 +605,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /// Extract a node.
   node_type
   extract(const_iterator __pos)
-  { return _M_t.extract(__pos); }
+  {
+	__glibcxx_assert(__pos != end());
+	return _M_t.extract(__pos);
+  }
 
   /// Extract a node.
   node_type
diff --git a/libstdc++-v3/include/bits/stl_multimap.h b/libstdc++-v3/include/bits/stl_multimap.h
index 2b56824..c794b9b 100644
--- a/libstdc++-v3/include/bits/stl_multimap.h
+++ b/libstdc++-v3/include/bits/stl_multimap.h
@@ -606,7 +606,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /// Extract a node.
   node_type
   extract(const_iterator __pos)
-  { return _M_t.extract(__pos); }
+  {
+	__glibcxx_assert(__pos != end());
+	return _M_t.extract(__pos);
+  }
 
   /// Extract a node.
   node_type
diff --git a/libstdc++-v3/include/bits/stl_multiset.h b/libstdc++-v3/include/bits/stl_multiset.h
index d7312df..d3219eb 100644
--- a/libstdc++-v3/include/bits/stl_multiset.h
+++ b/libstdc++-v3/include/bits/stl_multiset.h
@@ -549,7 +549,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /// Extract a node.
   node_type
   extract(const_iterator __pos)
-  { return _M_t.extract(__pos); }
+  {
+	__glibcxx_assert(__pos != end());
+	return _M_t.extract(__pos);
+  }
 
   /// Extract a node.
   node_type
diff --git a/libstdc++-v3/include/bits/stl_set.h b/libstdc++-v3/include/bits/stl_set.h
index fd96dd4..140db39 100644
--- a/libstdc++-v3/include/bits/stl_set.h
+++ b/libstdc++-v3/include/bits/stl_set.h
@@ -565,7 +565,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /// Extract a node.
   node_type
   extract(const_iterator __pos)
-  { return _M_t.extract(__pos); }
+  {
+	__glibcxx_assert(__pos != end());
+	return _M_t.extract(__pos);
+  }
 
   /// Extract a node.
   node_type
diff --git a/libstdc++-v3/include/bits/unordered_map.h b/libstdc++-v3/include/bits/unordered_map.h
index ab8a762..6776090 100644
--- a/libstdc++-v3/include/bits/unordered_map.h
+++ b/libstdc++-v3/include/bits/unordered_map.h
@@ -421,7 +421,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /// Extract a node.
   node_type
   extract(const_iterator __pos)
-  { return _M_h.extract(__pos); }
+  {
+	__glibcxx_assert(__pos != end());
+	return _M_h.extract(__pos);
+  }
 
   /// Extract a node.
   node_type
@@ -1534,7 +1537,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /// Extract a node.
   node_type
   extract(const_iterator __pos)
-  { return _M_h.extract(__pos); }
+  {
+	__glibcxx_assert(__pos != end());
+	return _M_h.extract(__pos);
+  }
 
   /// Extract a node.
   node_type
diff --git a/libstdc++-v3/include/bits/unordered_set.h b/libstdc++-v3/include/bits/unordered_set.h
index e5bb2be..9905257 100644
--- a/libstdc++-v3/include/bits/unordered_set.h
+++ b/libstdc++-v3/include/bits/unordered_set.h
@@ -482,7 +482,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /// Extract a node.
   node_type
   extract(const_iterator __pos)
-  { return _M_h.extract(__pos); }
+  {
+	__glibcxx_assert(__pos != end());
+	return _M_h.extract(__pos);
+  }
 
   /// Extract a node.
   node_type
@@ -1190,7 +1193,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   /// Extract a node.
   node_type
   extract(const_iterator __pos)
-  { return _M_h.extract(__pos); }
+  {
+	__glibcxx_assert(__pos != end());
+	return _M_h.extract(__pos);
+  }
 
   /// Extract a node.
   node_type

Re: [PATCH] Fix handling of -fsanitize-recover* options.

[Jakub Jelinek]

On Mon, Sep 26, 2016 at 11:56:01AM +0200, Martin Liška wrote:
>  @item -fsanitize=kernel-address
>  @opindex fsanitize=kernel-address
> @@ -10169,17 +10170,19 @@ details. The run-time behavior can be influenced 
> using the @env{TSAN_OPTIONS}
>  environment variable; see
>  @url{https://github.com/google/sanitizers/wiki/ThreadSanitizerFlags} for a 
> list of
>  supported options.
> +The option can't be combined with @option{-fsanitize=address}
> +and @option{-fsanitize=leak}.

Shouldn't that be or instead of and, or and/or ?

> -   flags |= sanitizer_opts[i].flag;
> +   {
> + /* Do not enable -fsanitize-recover=unreachable and
> +-fsanitize-recover=return if -fsanitize-recover=undefined
> +is selected.  */
> + if (sanitizer_opts[i].flag == SANITIZE_UNDEFINED)
> +   flags |= SANITIZE_UNDEFINED
> + & ~(SANITIZE_UNREACHABLE | SANITIZE_RETURN);

The formatting looks wrong.  Either it should be
  flags |= (SANITIZE_UNDEFINED
& ~(SANITIZE_UNREACHABLE | SANITIZE_RETURN));
or at least
  flags |= SANITIZE_UNDEFINED
   & ~(SANITIZE_UNREACHABLE | SANITIZE_RETURN);

Ok with those nits fixed.

Jakub

Re: [PATCH] Fix handling of -fsanitize-recover* options.

[Martin Liška]

On 09/23/2016 02:48 PM, Jakub Jelinek wrote:
> On Fri, Sep 23, 2016 at 01:53:48PM +0200, Martin Liška wrote:
>> 3) -fsanitize=leak is combinable with -fsanitize=address or
>>-fsanitize=thread
> 
> Is it really combinable with -fsanitize=thread?  I thought only libasan
> or liblsan provides the leak checker.  Anyway, I can't find where in the
> patch you change this.

You're right, I also verified clang behavior. Thus I've enhanced documentation
to mention all incompatibilities between sanitizers and new tests are introduced
for that.

> 
>> --- a/gcc/flag-types.h
>> +++ b/gcc/flag-types.h
>> @@ -203,25 +203,25 @@ enum vect_cost_model {
>>  /* Different instrumentation modes.  */
>>  enum sanitize_code {
>>/* AddressSanitizer.  */
>> -  SANITIZE_ADDRESS = 1 << 0,
>> -  SANITIZE_USER_ADDRESS = 1 << 1,
>> -  SANITIZE_KERNEL_ADDRESS = 1 << 2,
>> +  SANITIZE_ADDRESS = 1UL<< 0,
> 
> Formatting, space in between UL and << (many times).

Sure, fixed.

> 
>> @@ -1516,11 +1518,18 @@ parse_sanitizer_options (const char *p, location_t 
>> loc, int scode,
>>error_at (loc, "-fsanitize=all option is not valid");
>>}
>>  else
>> -  flags |= ~(SANITIZE_USER_ADDRESS | SANITIZE_THREAD
>> - | SANITIZE_LEAK);
>> +  flags |= ~(SANITIZE_THREAD | SANITIZE_LEAK
>> + | SANITIZE_UNREACHABLE | SANITIZE_RETURN);
> 
> This change will turn on -fsanitize-recove=address for 
> -fsanitize-recover=all, right?
> That is quite a significant behavior change, isn't it?  Have you checked
> what clang does here?

Yes, I've just followed what we have written in our documentation and clang does
the same.

> 
>>}
>>  else if (value)
>> -  flags |= sanitizer_opts[i].flag;
>> +  {
>> +flags |= sanitizer_opts[i].flag;
>> +/* Do not enable -fsanitize-recover=unreachable and
>> +   -fsanitize-recover=return if -fsanitize-recover=undefined
>> +   is selected.  */
>> +if (sanitizer_opts[i].flag == SANITIZE_UNDEFINED)
>> +  flags &= ~(SANITIZE_UNREACHABLE | SANITIZE_RETURN);
> 
> This looks wrong.  If you want to complain about
> -fsanitize-recover=unreachable, the above would be silent about
> -fsanitize-recover=unreachable -fsanitize-recover=undefined.
> Shouldn't it be instead
>   if (sanitizer_opts[i].flag == SANITIZE_UNDEFINED)
> flags |= SANITIZE_UNDEFINED & ~(SANITIZE_UNREACHABLE | SANITIZE_RETURN);
>   else
> flags |= sanitizer_opts[i].flag;
> ?

Yes, my approach was wrong ;) your looks better. I'm adding a new test-case to 
cover
your sample.

Sending v2 of the patch.

Martin

> 
>   Jakub
> 

>From a0576e31bb6c93ce9253240daf1d8c4187acd66b Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 23 Sep 2016 10:16:10 +0200
Subject: [PATCH] Fix handling of -fsanitize-recover* options.

gcc/ChangeLog:

2016-09-23  Martin Liska  

	* common.opt: Exclude SANITIZE_UNREACHABLE and SANITIZE_RETURN
	from default sanitize recover values.
	* doc/invoke.texi: Fix documentation related to -fsanitize=leak,
	-fsanitize=address, -fsanitize=thread and -fsanitize-recover.
	* flag-types.h: Replace couple of 1 << x to 1UL << x, make it
	consistent.
	* opts.c (finish_options): Do a generic loop over options
	that can be recovered.
	(parse_sanitizer_options): Exclude SANITIZE_UNREACHABLE and
	SANITIZE_RETURN.
	(common_handle_option): Likewise.
	* opts.h: Declare can_recover to sanitizer_opts_s.

gcc/testsuite/ChangeLog:

2016-09-26  Martin Liska  

	* c-c++-common/ubsan/sanitize-recover-1.c: New test.
	* c-c++-common/ubsan/sanitize-recover-2.c: New test.
	* c-c++-common/ubsan/sanitize-recover-3.c: New test.
	* c-c++-common/ubsan/sanitize-recover-4.c: New test.
	* c-c++-common/ubsan/sanitize-recover-5.c: New test.
	* c-c++-common/ubsan/sanitize-recover-6.c: New test.
	* c-c++-common/ubsan/sanitize-recover-7.c: New test.
	* c-c++-common/ubsan/sanitize-recover-8.c: New test.
	* c-c++-common/ubsan/sanitize-recover-9.c: New test.
---
 gcc/common.opt |  2 +-
 gcc/doc/invoke.texi| 14 ++--
 gcc/flag-types.h   | 32 
 gcc/opts.c | 91 +-
 gcc/opts.h |  1 +
 .../c-c++-common/ubsan/sanitize-recover-1.c|  6 ++
 .../c-c++-common/ubsan/sanitize-recover-2.c|  6 ++
 .../c-c++-common/ubsan/sanitize-recover-3.c|  4 +
 .../c-c++-common/ubsan/sanitize-recover-4.c|  4 +
 .../c-c++-common/ubsan/sanitize-recover-5.c|  6 ++
 .../c-c++-common/ubsan/sanitize-recover-6.c|  4 +
 .../c-c++-common/ubsan/sanitize-recover-7.c|  6 ++
 .../c-c++-common/ubsan/sanitize-recover-8.c|  6 ++
 .../c-c++-common/ubsan/sanitize-recover-9.c|  6 ++
 14 

Re: [PATCH, GCC] Deal with singular sentences in builtin-sprintf-warn-1.c regex

[Thomas Preudhomme]

How about this reworked patch?

Best regards,

Thomas

On 23/09/16 17:17, Martin Sebor wrote:

On 09/23/2016 09:42 AM, Thomas Preudhomme wrote:

Sorry, forgot the patch. Please find it attached.

Best regards,

Thomas

On 23/09/16 16:40, Thomas Preudhomme wrote:

Hi,

New builtin-sprintf-warn-1.c testcase contains a few regex of the form
"\[0-9\]+
bytes" or ". bytes". This does not account for the case where the
number of byte
is 0 in which case byte would be in the singular form. This caused a
FAIL on
arm-none-eabi targets. This patch makes the s optional in all cases
where the
number of bytes is unknown.

I did not commit this fix as obvious as people might want to only do
the changes
for lines where the number of bytes *could* be 0 so I prefer to get
review.


Thanks for the patch.  The %p fixes look correct to me (someone
else needs to approve the final patch).

For the INT_MAX tests, I think it's a sign of a bug in the pass if
for the following call

  sprintf (buf, "X%*c", INT_MAX, '1');

GCC prints

  warning: directive output of 0 byte causes result to exceed 'INT_MAX'

My guess is that the bug is specific to a 32-bit compiler (I can't
reproduce it in a 64-bit one with -m32).  Let me build one and look
into fixing it.

Martin



ChangeLog entry is as follows:

*** gcc/testsuite/ChangeLog ***

2016-09-23  Thomas Preud'homme  

* gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust regex to
accept
singular form of byte when quantity is unknown.


Is this ok for trunk?

Best regards,

Thomas


diff --git a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
index e098be92bb0377414b1f9cacf5e4d2a3398e74ec..efa69b8a8b29da4ed3253e19ba646168a6a1ca58 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
@@ -98,9 +98,9 @@ void test_sprintf_p_const (void)
 
   /* The exact output for %p is unspecified by C.  Two formats are known:
  same as %tx (for example AIX) and same as %#tx (for example Solaris).  */
-  T (0, "%p", (void*)0x1);/* { dg-warning ".%p. directive writing . bytes into a region of size 0" } */
-  T (1, "%p", (void*)0x12);   /* { dg-warning ".%p. directive writing . bytes into a region of size 1" } */
-  T (2, "%p", (void*)0x123);  /* { dg-warning ".%p. directive writing . bytes into a region of size 2" } */
+  T (0, "%p", (void*)0x1);/* { dg-warning ".%p. directive writing . bytes? into a region of size 0" } */
+  T (1, "%p", (void*)0x12);   /* { dg-warning ".%p. directive writing . bytes? into a region of size 1" } */
+  T (2, "%p", (void*)0x123);  /* { dg-warning ".%p. directive writing . bytes? into a region of size 2" } */
 
   /* GLIBC and uClibc treat the ' ' flag with the "%p" directive the same
  as with signed integer conversions (i.e., it prepends a space).  Other

Re: [PATCH 6/17][ARM] Add data processing intrinsics for float16_t.

[Matthew Wahab]

Hello,

On 25/09/16 14:00, Christophe Lyon wrote:


This patch adds the new intrinsics:
  vbsl_f16, vbslq_f16, vdup_n_f16, vdupq_n_f16, vdup_lane_f16,
  vdupq_lane_f16, vext_f16, vextq_f16, vmov_n_f16, vmovq_n_f16,
  vrev64_f16, vrev64q_f16, vtrn_f16, vtrnq_f16, vuzp_f16, vuzpq_f16,
  vzip_f16, vzipq_f16.

This patch also updates the advsimd-intrinsics testsuite to test the f16
variants for ARM targets. These intrinsics are only implemented in the
ARM target so the tests are disabled for AArch64 using an extra
condition on a new convenience macro FP16_SUPPORTED. This patch also
disables, for the ARM target, the testsuite defined macro vdup_n_f16 as
it is no longer needed.


Since you committed this patch, I've noticed that libgcc fails to build
when GCC is configured:
--target arm-none-eabi and default cpu
/tmp/9649048_29.tmpdir/ccuBwQJJ.s: Assembler messages:
/tmp/9649048_29.tmpdir/ccuBwQJJ.s:64: Error: selected processor does
not support ARM mode `movwlt r0,32768'
/tmp/9649048_29.tmpdir/ccuBwQJJ.s:65: Error: selected processor does
not support ARM mode `movwge r0,32767'
make[4]: *** [_ssaddHQ.o] Error 1
make[4]: Leaving directory
`/tmp/9649048_29.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc1/arm-none-eabi/fpu/libgcc'




I can't reproduce the failure, could you send the configure arguments for the 
build.


I've tried assembling the string 'movw r0, 32768' and get the error when 
-march=armv6kz or earlier. I suspect the new movhi and/or movhf patterns added 
earlier in the series need the architecture level added as a precondition but 
I'll need to look into it.


Matthew