Re: [fortran, patch] IEEE intrinsic modules (ping)

[Andreas Schwab]

FX  writes:

> Index: gcc/testsuite/gfortran.dg/ieee/ieee_6.f90
> ===
> --- gcc/testsuite/gfortran.dg/ieee/ieee_6.f90 (revision 0)
> +++ gcc/testsuite/gfortran.dg/ieee/ieee_6.f90 (revision 0)
> @@ -0,0 +1,78 @@
> +! { dg-do run }
> +!
> +! This test will fail on older x86_64 glibc (< 2.20), due to this bug:
> +! https://sourceware.org/bugzilla/show_bug.cgi?id=16198
> +! We usually won't see it anyway, because on such systems x86_64 assembly
> +! (libgfortran/config/fpu-387.h) is used.
> +!
> +  use :: ieee_arithmetic
> +  implicit none
> +
> +  type(ieee_status_type) :: s1, s2
> +  logical :: flags(5), halt(5)
> +  type(ieee_round_type) :: mode
> +  real :: x
> +
> +  ! Test IEEE_GET_STATUS and IEEE_SET_STATUS
> +
> +  call ieee_set_flag(ieee_all, .false.)
> +  call ieee_set_rounding_mode(ieee_down)
> +  call ieee_set_halting_mode(ieee_all, .false.)
> +
> +  call ieee_get_status(s1)
> +  call ieee_set_status(s1)
> +
> +  call ieee_get_flag(ieee_all, flags)
> +  if (any(flags)) call abort
> +  call ieee_get_rounding_mode(mode)
> +  if (mode /= ieee_down) call abort
> +  call ieee_get_halting_mode(ieee_all, halt)
> +  if (any(halt)) call abort
> +
> +  call ieee_set_rounding_mode(ieee_to_zero)
> +  call ieee_set_flag(ieee_underflow, .true.)

This may raise inexact, see C11 7.6.2.3.  Installed as obvious.

Andreas.

* gfortran.dg/ieee/ieee_6.f90: Allow inexact together with
underflow.

Index: gfortran.dg/ieee/ieee_6.f90
===
--- gfortran.dg/ieee/ieee_6.f90 (revision 212119)
+++ gfortran.dg/ieee/ieee_6.f90 (working copy)
@@ -40,7 +40,9 @@
 
   call ieee_get_flag(ieee_all, flags)
   if (.not. (all(flags .eqv. [.false.,.false.,.true.,.true.,.false.]) &
- .or. all(flags .eqv. [.false.,.false.,.true.,.false.,.false.]))) 
call abort
+ .or. all(flags .eqv. [.false.,.false.,.true.,.true.,.true.]) &
+ .or. all(flags .eqv. [.false.,.false.,.true.,.false.,.false.]) &
+ .or. all(flags .eqv. [.false.,.false.,.true.,.false.,.true.]))) 
call abort
   call ieee_get_rounding_mode(mode)
   if (mode /= ieee_to_zero) call abort
   call ieee_get_halting_mode(ieee_all, halt)
@@ -50,7 +52,9 @@
 
   call ieee_get_flag(ieee_all, flags)
   if (.not. (all(flags .eqv. [.false.,.false.,.true.,.true.,.false.]) &
- .or. all(flags .eqv. [.false.,.false.,.true.,.false.,.false.]))) 
call abort
+ .or. all(flags .eqv. [.false.,.false.,.true.,.true.,.true.]) &
+ .or. all(flags .eqv. [.false.,.false.,.true.,.false.,.false.]) &
+ .or. all(flags .eqv. [.false.,.false.,.true.,.false.,.true.]))) 
call abort
   call ieee_get_rounding_mode(mode)
   if (mode /= ieee_to_zero) call abort
   call ieee_get_halting_mode(ieee_all, halt)
@@ -69,7 +73,9 @@
 
   call ieee_get_flag(ieee_all, flags)
   if (.not. (all(flags .eqv. [.false.,.false.,.true.,.true.,.false.]) &
- .or. all(flags .eqv. [.false.,.false.,.true.,.false.,.false.]))) 
call abort
+ .or. all(flags .eqv. [.false.,.false.,.true.,.true.,.true.]) &
+ .or. all(flags .eqv. [.false.,.false.,.true.,.false.,.false.]) &
+ .or. all(flags .eqv. [.false.,.false.,.true.,.false.,.true.]))) 
call abort
   call ieee_get_rounding_mode(mode)
   if (mode /= ieee_to_zero) call abort
   call ieee_get_halting_mode(ieee_all, halt)

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

Re: Warn when returning the address of a temporary (middle-end) v2

[Marc Glisse]

( https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01692.html )

On Sun, 22 Jun 2014, Marc Glisse wrote:


Hello,

I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html

and here is a new patch. I made an effort to isolate a path in at least one 
subcase so it doesn't look too strange that the warning is in this file. 
Computing the dominance info just to tweak the warning message may be a bit 
excessive. I kept the same option as the front-ends, I don't know if we want 
a different one, or maybe a Wmaybe-... version. There will be cases where we 
get a duplicate warning from -Wtarget-lifetime in fortran, but none in the 
testsuite, and I would rather have 2 warnings than miss such broken code. The 
uninit-G testcase is about initialization, not returning, so I am changing 
that, even if it is unnecessary with the current version of the patch (only 
activated at -O2).


Bootstrap+testsuite (--enable-languages=all,obj-c++,ada,go) on 
x86_64-unknown-linux-gnu.


(by the way, contrib/compare_tests is confused when I use all languages, it 
prints "comm: file 1 is not in sorted order" and tons of spurious 
differences)


2014-06-23  Marc Glisse  

PR c++/60517
gcc/c/
* c-typeck.c (c_finish_return): Return 0 instead of the address of
a local variable.
gcc/cp/
* typeck.c (maybe_warn_about_returning_address_of_local): Return
whether it is returning the address of a local variable.
(check_return_expr): Return 0 instead of the address of a local
variable.
gcc/c-family/
* c.opt (-Wreturn-local-addr): Move to common.opt.
gcc/
* common.opt (-Wreturn-local-addr): Moved from c.opt.
* gimple-ssa-isolate-paths.c: Include diagnostic-core.h.
(isolate_path): New argument to avoid inserting a trap.
(find_implicit_erroneous_behaviour): Handle returning the address
of a local variable.
(find_explicit_erroneous_behaviour): Likewise.
(gimple_ssa_isolate_erroneous_paths): Calculate dominance info.
gcc/testsuite/
* c-c++-common/addrtmp.c: New file.
* c-c++-common/uninit-G.c: Adapt.


After looking at PR 61597, I updated the 2 conditions to:

+ if ((TREE_CODE (valbase) == VAR_DECL
+  && !is_global_var (valbase))
+ || TREE_CODE (valbase) == PARM_DECL)

a PARM_DECL is a local variable and returning its address is wrong, isn't 
it?


(also passes bootstrap+testsuite)

--
Marc Glisse

Re: [i386] Replace builtins with vector extensions

[Ulrich Drepper]

On Sat, Jun 28, 2014 at 6:53 PM, Marc Glisse  wrote:
> There is always a risk, but then even with builtins I think there was a
> small risk that an RTL optimization would mess things up. It is indeed
> higher if we expose the operation to the optimizers earlier, but it would be
> a bug if an "optimization" replaced a vector operation by something worse.
> Also, I am only proposing to handle the most trivial operations this way,
> not more complicated ones (like v[0]+=s) where we would be likely to fail
> generating the right instruction. And the pragma should ensure that the
> function will always be compiled in a mode where the vector instruction is
> available.
>
> ARM did the same and I don't think I have seen a bug reporting a regression
> about it (I haven't really looked though).

I think the Arm definitions come from a different angle.  It's new,
there is no assumed semantics.  For the x86 intrinsics Intel defines
that _mm_xxx() generates one of a given opcodes if there is a match.
If I want to generate a specific code sequence I use the intrinsics.
Otherwise I could already today use the vector type semantics myself.

Don't get me wrong, I like the idea to have the optimization of the
intrinsics happening.  But perhaps not unconditionally or at least not
without preventing them.

I know this will look ugly, but how about a macro
__GCC_X86_HONOR_INTRINSICS to enable the current code and have by
default your proposed use of the vector arithmetic in place?  This
wouldn't allow removing support for the built-ins but it would also
open the door to some more risky optimizations to be enabled by
default.

Re: [fortran, patch] IEEE intrinsic modules (ping)

[FX]

> This may raise inexact, see C11 7.6.2.3.  Installed as obvious.

Thanks!

FX

Re: [i386] Replace builtins with vector extensions

[Marc Glisse]

On Sun, 29 Jun 2014, Ulrich Drepper wrote:


I think the Arm definitions come from a different angle.  It's new,
there is no assumed semantics.


Is it that new? I thought it was implemented based on a rather precise 
specification by ARM. Again, I don't really know arm.



For the x86 intrinsics Intel defines
that _mm_xxx() generates one of a given opcodes if there is a match.
If I want to generate a specific code sequence I use the intrinsics.


We already sometimes generate a different instruction than the name of the 
instrinsic suggests, or combine consecutive intrinsics into something 
else. I use inline asm when I want a specific code sequence.



Otherwise I could already today use the vector type semantics myself.


Well, the main reasons I use the intrinsics are:
1) the code compiles with visual studio
2) use the esoteric instructions (anything without a trivial mapping in C)


Don't get me wrong, I like the idea to have the optimization of the
intrinsics happening.  But perhaps not unconditionally or at least not
without preventing them.

I know this will look ugly, but how about a macro
__GCC_X86_HONOR_INTRINSICS to enable the current code and have by
default your proposed use of the vector arithmetic in place?  This
wouldn't allow removing support for the built-ins but it would also
open the door to some more risky optimizations to be enabled by
default.


That's a pretty big drawback. Instead of simplifying the implementation, 
it makes it more complicated. We also have to document the macro, update 
the testsuite so it tests the intrinsics in both modes, etc.


I understand the concern, and I would probably implement 
__GCC_X86_HONOR_INTRINSICS (though the testsuite part scares me as I have 
so little understanding of how it works, so I may need help), but I'd like 
to make sure first that the simpler approach is not acceptable, possibly 
with strong constraints on which operations are ok (_mm_load[hl]_pd could 
be removed from the patch for instance).


As another comparison, clang's version of *intrin.h uses the vector 
extensions much more than I am proposing.


--
Marc Glisse

Re: Optimize type streaming

[Dominique Dhumieres]

In addition of pr61644 and pr61646, this commit breaks a lot of
fortran tests with -flto -O0.

TIA

Dominique

FAIL: gfortran.dg/actual_array_constructor_1.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/alloc_comp_assign_6.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/allocatable_function_1.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/allocatable_function_5.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/allocatable_function_6.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/allocatable_function_7.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/array_1.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/array_constructor_type_10.f03  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/array_constructor_type_7.f03  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/array_memset_2.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/array_temporaries_3.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/assumed_charlen_arg_1.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/assumed_charlen_sharing.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/auto_array_1.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/automatic_default_init_1.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/bounds_check_array_ctor_1.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/bounds_check_array_ctor_2.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/bounds_check_array_ctor_4.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/bounds_check_array_ctor_6.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/bounds_check_array_ctor_7.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/bounds_check_array_ctor_8.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/bounds_check_strlen_2.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/char_expr_3.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/char_initialiser_actual.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/char_length_5.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/char_result_1.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/char_result_13.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/char_result_2.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/class_array_7.f03  -g -flto  (internal compiler error)
FAIL: gfortran.dg/deferred_type_component_1.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/deferred_type_component_2.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/elemental_subroutine_10.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/elemental_subroutine_9.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/extends_1.f03  -g -flto  (internal compiler error)
FAIL: gfortran.dg/extends_2.f03  -g -flto  (internal compiler error)
FAIL: gfortran.dg/extends_3.f03  -g -flto  (internal compiler error)
FAIL: gfortran.dg/fmt_cache_3.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/fmt_en.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/fmt_g0_5.f08  -g -flto  (internal compiler error)
FAIL: gfortran.dg/implicit_12.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/interface_assignment_2.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/intrinsic_actual_4.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/large_real_kind_1.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/mapping_3.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/merge_char_3.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/minmax_char_1.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/missing_optional_dummy_1.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/namelist_14.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/namelist_27.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/namelist_28.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/namelist_59.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/namelist_69.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/namelist_70.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/negative_automatic_size.f90  -g -flto  (internal compiler 
error)
FAIL: gfortran.dg/pr47008.f03  -g -flto  (internal compiler error)
FAIL: gfortran.dg/pr61335.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/pure_byref_1.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/read_list_eof_1.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/realloc_on_assign_4.f03  -g -flto  (internal compiler error)
FAIL: gfortran.dg/repeat_2.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/round_3.f08  -g -flto  (internal compiler error)
FAIL: gfortran.dg/save_2.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/select_char_1.f90  -g -flto  (internal compiler error)
FAIL: gfortran.dg/selected_char_kind_1.f90  -g -flto  (i

[wwwdocs] Clean up references to Bugzilla, use https,...

[Gerald Pfeifer]

Consistently use bug tracker versus bug database, Bugzilla (where
possible), or the like.  Avoid some references altogether and refer
to our bugs/ pages instead of directly linking to Bugzilla in some.
Use https for all remaining links to our Bugzilla instance.

Committed.

Gerald

Index: news.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/news.html,v
retrieving revision 1.143
diff -u -r1.143 news.html
--- news.html   28 Jun 2014 08:14:41 -  1.143
+++ news.html   29 Jun 2014 11:16:00 -
@@ -745,7 +745,7 @@
 https://gcc.gnu.org/ml/gcc/2000-10/msg00573.html";>new, hand-crafted
 recursive-descent C++ parser sponsored by the Los Alamos National
 Laboratory.  The new parser is more standard conforming and fixes many bugs
-(about 100 in our bug database alone) from the old YACC-derived parser.
+(about 100 in our bug tracker alone) from the old YACC-derived parser.
 
 
 December 4, 2002
Index: style.mhtml
===
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.124
diff -u -r1.124 style.mhtml
--- style.mhtml 11 Jun 2014 17:45:30 -  1.124
+++ style.mhtml 29 Jun 2014 11:16:00 -
@@ -224,7 +224,7 @@
>
   Known bugs
   How to report
-  https://gcc.gnu.org/bugzilla/";>Bug database
+  https://gcc.gnu.org/bugzilla/";>Bug tracker
   · Management
   
   
Index: bugs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/index.html,v
retrieving revision 1.114
diff -u -r1.114 index.html
--- bugs/index.html 28 Jun 2014 23:30:27 -  1.114
+++ bugs/index.html 29 Jun 2014 11:16:00 -
@@ -129,10 +129,10 @@
 Where to post it
 
 Please submit your bug report directly to the
-http://gcc.gnu.org/bugzilla/";>GCC bug database.
+https://gcc.gnu.org/bugzilla/";>GCC bug tracker.
 
 
-The GCC bug database requires you to create an account with a valid
+The GCC bug tracker requires you to create an account with a valid
 e-mail address.  This is not merely to be annoying.  It's because in
 the past spammers have filed fake bug reports, and fake attachments to
 real bug reports, to distribute malware and to add links to their spam
Index: bugs/management.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/management.html,v
retrieving revision 1.30
diff -u -r1.30 management.html
--- bugs/management.html3 Jan 2013 05:09:54 -   1.30
+++ bugs/management.html29 Jun 2014 11:16:00 -
@@ -1,11 +1,11 @@
 
 
 
-Maintaining the GCC Bugzilla database
+Managing Bugs (Bugzilla and the Testsuite)
 
 
 
-Managing Bugs (Bugzilla and the testsuite)
+Managing Bugs (Bugzilla and the Testsuite)
 
 This section contains information mostly intended for GCC
 contributors.
@@ -14,16 +14,17 @@
 
 If you find a bug, but you are not fixing it (yet):
 
-Create a (minimal) testcase and add a bug report including it to
-the bug database (Bugzilla).
+Create a (minimal) testcase and file a bug report including it to
+our bug tracker.
 Enter the version number of the compiler in the Known To
 Fail field.  If you are reporting the bug against a release
 branch, or the trunk, enter the version number of the next planned
 release from that branch.
 
 
-If you want to provide additional information about a bug in
-the database:
+If you want to provide additional information about an existing
+bug report: 
+
 
 If the bug is a segmentation fault in the compiler,
 provide information about its location.
@@ -42,9 +43,9 @@
 
 Check in your fixes.
 If there is already a testcase in the testsuite, remove the XFAIL.
-Else, create a minimal testcase (maybe the bug database already provides one)
+Else, create a minimal testcase (maybe the bug tracker already provides one)
 and add it to our testsuite, marking it as PASS.
-If there is an associated bug report in the database, close it.
+If there is an associated bug report in the tracker, close it.
 If, after your fix, the bug is present on some release branches
 but not others, update the Known To Fail and Known To
 Work fields to indicate which versions still have the bug.
@@ -57,7 +58,7 @@
 
 The status and resolution fields define and track the life cycle of a
 bug.  In addition to their http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html";>regular
+href="https://gcc.gnu.org/bugzilla/page.cgi?id=fields.html";>regular
 descriptions, we also use two adition status values:
 
 
@@ -150,7 +151,7 @@
 Keywords
 
 These are used to further classify the problem reports. Follow the link
-for a http://gcc.gnu.org/bugzilla/describekeywords.cgi";>complete
+for a https://gcc.gnu.org/bugzilla/describekeywords.cgi";>complete
 list of the keywords including descriptions.
 
 
Index: bugs/reghunt.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/reghunt.html,v
retr

[wwwdocs,libstdc++] Remove libstdc++/lib3styles.css

[Gerald Pfeifer]

We don't use this any more, so let's remove it.

Gerald

2014-06-29  Gerald Pfeifer  
 
* lib3styles.css: Remove.
* index.html: Remove reference to lib3styles.css.

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/libstdc++/index.html,v
retrieving revision 1.38
diff -u -r1.38 index.html
--- index.html  14 Apr 2012 17:10:35 -  1.38
+++ index.html  29 Jun 2014 11:43:53 -
@@ -2,7 +2,6 @@
 
  
  Standard C++ Library v3
- 
 
 
 
Index: lib3styles.css
===
RCS file: lib3styles.css
diff -N lib3styles.css
--- lib3styles.css  4 Apr 2011 17:56:25 -   1.2
+++ /dev/null   1 Jan 1970 00:00:00 -
@@ -1,6 +0,0 @@
-.centered { text-align: center }
-.tocheader { font-size: large }
-.fineprint { font-size: x-small }
-.larger { font-size: large }
-
-PRE { text-align: left ; margin-left: 1em }

[Patch, Fortran] Coarray fixes for select type/associate and type of derived components

[Tobias Burnus]

This patch fixes some issues with polymorphic coarrays. I still have to 
fix at least one issue.


Fixed by the patch:

a) The temporary pointer generated with SELECT TYPE has to be a coarray. 
That's fixed with the resolve.c patch. The comment is also bogus: The 
comment is correct – and gfortran correctly detects coindexed variables 
as selector. However, in the code in question, the selector is not 
coindexed but the variable in the coindexed section is.


b) It doesn't make sense to try to initialize the temporary pointer of 
SELECT TYPE (or ASSOCIATE), thus we have to exclude it also in trans-decl.c


c) As the temporary variable is internally a pointer, the assert in 
trans-array.c also has to accept a pointer – even though coarrays with 
token in the descriptor can only be allocatable. But for code like 
"a(1)[1])", "a(1)" is not longer a pointer – and one ends up having an 
akind of unknown. Instead of adding all kind of values, I simply removed 
the assert.


d) In trans-intrinsic.c, one has a similar issue. We now avoid an ICE by 
checking whether the variable is set before accessing it.


e) For caf(:)[i]%a, we had the dtype of the descriptor of "caf" instead 
of "...%a". That's now fixed.


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

Tobias

PS: Still to be done for coarrays: Nonallocatable polymorphic coarray 
dummies. For those, the offset and the token is passed as additional 
argument – but that's not yet correctly handled with ASSOCIATE/SELECT TYPE.
Also to be done are more type-conversion checks (beyond those which are 
implicitly checked by this patch) – and the handling of vector subscripts.
2014-06-29  Tobias Burnus  

	* resolve.c (resolve_assoc_var): Fix corank setting.
	* trans-array.c (gfc_conv_descriptor_token): Change assert.
	for select-type temporaries.
	* trans-decl.c (generate_coarray_sym_init): Skip for
	attr.select_type_temporary. 
	* trans-expr.c (gfc_conv_procedure_call): Fix for
	select-type temporaries.
	* trans-intrinsic.c (get_caf_token_offset): Ditto.
	(gfc_conv_intrinsic_caf_get, gfc_conv_intrinsic_caf_send): Set
	the correct dtype.
	* trans-types.h (gfc_get_dtype_rank_type): New.
	* trans-types.c (gfc_get_dtype_rank_type): Ditto.

2014-06-29  Tobias Burnus  

	* gfortran.dg/coarray/coindexed_3.f90: New.

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index ca20c29..15d8dab 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -7912,10 +7912,7 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target)
   sym->as = gfc_get_array_spec ();
   sym->as->rank = target->rank;
   sym->as->type = AS_DEFERRED;
-
-  /* Target must not be coindexed, thus the associate-variable
-	 has no corank.  */
-  sym->as->corank = 0;
+  sym->as->corank = gfc_get_corank (target);
 }
 
   /* Mark this as an associate variable.  */
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 5558217..0e01899 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -298,7 +298,6 @@ gfc_conv_descriptor_token (tree desc)
 
   type = TREE_TYPE (desc);
   gcc_assert (GFC_DESCRIPTOR_TYPE_P (type));
-  gcc_assert (GFC_TYPE_ARRAY_AKIND (type) == GFC_ARRAY_ALLOCATABLE);
   gcc_assert (gfc_option.coarray == GFC_FCOARRAY_LIB);
   field = gfc_advance_chain (TYPE_FIELDS (type), CAF_TOKEN_FIELD);
 
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index cbcd52d..93c59b1 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -4670,7 +4670,8 @@ generate_coarray_sym_init (gfc_symbol *sym)
   tree tmp, size, decl, token;
 
   if (sym->attr.dummy || sym->attr.allocatable || !sym->attr.codimension
-  || sym->attr.use_assoc || !sym->attr.referenced)
+  || sym->attr.use_assoc || !sym->attr.referenced
+  || sym->attr.select_type_temporary)
 return;
 
   decl = sym->backend_decl;
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 7ee0206..dba51b0 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -4813,7 +4813,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
 	  caf_type = TREE_TYPE (caf_decl);
 
 	  if (GFC_DESCRIPTOR_TYPE_P (caf_type)
-	  && GFC_TYPE_ARRAY_AKIND (caf_type) == GFC_ARRAY_ALLOCATABLE)
+	  && (GFC_TYPE_ARRAY_AKIND (caf_type) == GFC_ARRAY_ALLOCATABLE
+		  || GFC_TYPE_ARRAY_AKIND (caf_type) == GFC_ARRAY_POINTER))
 	tmp = gfc_conv_descriptor_token (caf_decl);
 	  else if (DECL_LANG_SPECIFIC (caf_decl)
 		   && GFC_DECL_TOKEN (caf_decl) != NULL_TREE)
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index a1dfdfb..5aa5683 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -1179,7 +1179,8 @@ get_caf_token_offset (tree *token, tree *offset, tree caf_decl, tree se_expr,
 
   /* Offset between the coarray base address and the address wanted.  */
   if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (caf_decl))
-  && GFC_TYPE_ARRAY_AKIND (TREE_TYPE (caf_decl

[wwwdocs] Remove disabled http://gcc.gnu.org/benchresults/

[Gerald Pfeifer]

This has been commented for more than twelve years.  Yank it for
real.

Applied.

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/benchmarks/index.html,v
retrieving revision 1.31
diff -u -r1.31 index.html
--- index.html  28 Jun 2014 08:14:41 -  1.31
+++ index.html  29 Jun 2014 12:27:59 -
@@ -14,17 +14,6 @@
 benchmarks.
 
 
-
-
 SPEC 2000
 
 

[PATCH] gcc/c/c-decl.c: Let NEWDECL dereference shared data to fix segment fault issue.

[Chen Gang]

NEWDECL dereferences shared data of OLDDECL, or when free NEWDECL, also
have effect with OLDDECL. At present, only fix the related reference for
current issue. If find another related issue, can follow this fix.

The related git number is 71e19e54060804493e13748613077b0e69c0cfd9, and
the related information:

  root@gchen:/upstream/linux# cat elevator.i
  extern int __attribute__ ((__section__(".init.text"))) elv_register(void)
  {
   return 0;
  }
  extern typeof(elv_register) elv_register;
  root@gchen:/upstream/linux# /usr/local/libexec/gcc/score-elf/4.10.0/cc1 
elevator.i
   elv_register
  Analyzing compilation unit
  Segmentation fault (core dumped)
  root@gchen:/upstream/linux# /usr/local/bin/score-elf-gcc -v
  Using built-in specs.
  COLLECT_GCC=/usr/local/bin/score-elf-gcc
  COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/score-elf/4.10.0/lto-wrapper
  Target: score-elf
  Configured with: ../gcc/configure --without-header --disable-nls 
--enable-language=c --disable-threads --disable-shared --enable-werror=no 
target_configargs=enable_vtable_verify=yes --target=score-elf --enable-obsolete 
: (reconfigured) ../gcc/configure --without-header --disable-nls 
--enable-language=c --disable-threads --disable-shared --enable-werror=no 
target_configargs=enable_vtable_verify=yes --target=score-elf --enable-obsolete 
--enable-debug --disable-release
  Thread model: single
  gcc version 4.10.0 20140625 (experimental) (GCC)

After this patch, can let Linux kernel pass defconfig under score.


Signed-off-by: Chen Gang 
---
 gcc/ChangeLog  |  5 +
 gcc/c/c-decl.c | 11 +++
 2 files changed, 16 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 34e7c93..241a7b7 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2014-06-29  Chen Gang 
+
+   * c/c-decl.cl (merge_decls): NEWDECL dereferences shared data of
+   OLDDECL, or when free NEWDECL, also have effect with OLDDECL.
+
 2014-06-28  Jan Hubicka  
 
* tree-streamer-out.c (pack_ts_type_common_value_fields): Stream if type
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index def10a2..373e5fb 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -2552,6 +2552,17 @@ merge_decls (tree newdecl, tree olddecl, tree newtype, 
tree oldtype)
  || (TREE_CODE (olddecl) == VAR_DECL
  && TREE_STATIC (olddecl
 make_decl_rtl (olddecl);
+
+  /* NEWDECL dereferences shared data of OLDDECL, or after free NEWDECL,
+ also have effect with OLDDECL  */
+  if (TREE_CODE (newdecl) == FUNCTION_DECL)
+{
+  DECL_FUNCTION_SPECIFIC_TARGET (newdecl) = NULL;
+  DECL_FUNCTION_SPECIFIC_OPTIMIZATION (newdecl) = NULL;
+  DECL_STRUCT_FUNCTION (newdecl) = NULL;
+  DECL_RESULT (newdecl) = NULL;
+  DECL_INITIAL (newdecl) = NULL;
+}
 }
 
 /* Handle when a new declaration NEWDECL has the same name as an old
-- 
1.7.11.7

Re: [PATCH] gcc/c/c-decl.c: Let NEWDECL dereference shared data to fix segment fault issue.

[Joseph S. Myers]

On Sun, 29 Jun 2014, Chen Gang wrote:

> NEWDECL dereferences shared data of OLDDECL, or when free NEWDECL, also
> have effect with OLDDECL. At present, only fix the related reference for
> current issue. If find another related issue, can follow this fix.

I'm afraid I can't make any sense of this.

We need a carefully written analysis of the issue you are trying to fix 
that explains what is going wrong and why, in terms of the underlying 
design of the code, the proposed change is logically correct to fix the 
issue.

That is, explain how NEWDECL gets used after merge_decls returns, why your 
proposed changes to NEWDECL are correct for the subsequent use of NEWDECL, 
why the previous contents of NEWDECL would be incorrect for the subsequent 
uses of NEWDECL, and why it is correct for the subsequent uses to make 
whatever use of NEWDECL is causing problems.  Where does the segfault 
occur anyway?

>   root@gchen:/upstream/linux# cat elevator.i
>   extern int __attribute__ ((__section__(".init.text"))) elv_register(void)
>   {
>return 0;
>   }
>   extern typeof(elv_register) elv_register;

Patch submissions should add a test to the testsuite, when it's something 
small like this.

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

Re: [fortran,patch] Binding label can be any initialisation expression

[FX]

> Works as advertized and even fixes pr38838.
> Thanks for the patch.

Thanks for the review, committed to trunk as rev. 212123

FX

[patch libstdc++] Add xmethods for std::vector and std::unique_ptr

[Siva Chandra]

GDB now supports xmethods in its Python API:
https://sourceware.org/gdb/current/onlinedocs/gdb/Xmethods-In-Python.html

This feature will be available in GDB starting version 7.8 (which has
not yet been released, but has been branched). The attached patch adds
xmethods to the classes std::vector and std::unique_ptr. One can of
course add xmethods to many other classes, but I am viewing this as
the first patch in that series (though not a series yet) to get the
basic infrastructure for adding more xmethods in place.

ChangeLog

libstdc++-v3/

2014-06-29  Siva Chandra Reddy  

* python/hook.in: Register libstdcxx xmethods.
* python/libstdcxx/v6/xmethods.py: New file.
* testsuite/lib/gdb-test.exp (gdb_version_check_xmethods): New
function.
(gdb-test): New optional argument LOAD_XMETHODS.  Load xmethods
python script if LOAD_XMETHODS is true.
* testsuite/libstdc++-xmethods/unique_ptr.cc: New file.
* testsuite/libstdc++-xmethods/vector.cc: New file.
* testsuite/libstdc++-xmethods/xmethods.exp: New file.
diff --git a/libstdc++-v3/python/hook.in b/libstdc++-v3/python/hook.in
index 3620523..34368b5 100644
--- a/libstdc++-v3/python/hook.in
+++ b/libstdc++-v3/python/hook.in
@@ -58,3 +58,7 @@ if gdb.current_objfile () is not None:
 # Load the pretty-printers.
 from libstdcxx.v6.printers import register_libstdcxx_printers
 register_libstdcxx_printers (gdb.current_objfile ())
+
+# Load the xmethods.
+from libstdcxx.v6.xmethods import register_libstdcxx_xmethods
+register_libstdcxx_xmethods (gdb.current_objfile ())
diff --git a/libstdc++-v3/python/libstdcxx/v6/xmethods.py 
b/libstdc++-v3/python/libstdcxx/v6/xmethods.py
new file mode 100644
index 000..1b4b721
--- /dev/null
+++ b/libstdc++-v3/python/libstdcxx/v6/xmethods.py
@@ -0,0 +1,113 @@
+# Xmethods for libstc++.
+
+# Copyright (C) 2014 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+import gdb
+import gdb.xmethod
+import re
+
+matcher_name_prefix = 'libstdc++::'
+
+# Xmethods for std::vector
+
+class VectorSizeWorker(gdb.xmethod.XMethodWorker):
+def __init__(self):
+self.name = 'size'
+self.enabled = True
+
+def get_arg_types(self):
+return None
+
+def __call__(self, obj):
+return obj['_M_impl']['_M_finish'] - obj['_M_impl']['_M_start']
+
+class VectorSubscriptWorker(gdb.xmethod.XMethodWorker):
+def __init__(self):
+self.name = 'operator[]'
+self.enabled = True
+
+def get_arg_types(self):
+return gdb.lookup_type('std::size_t')
+
+def __call__(self, obj, subscript):
+return obj['_M_impl']['_M_start'][subscript]
+
+class VectorMethodsMatcher(gdb.xmethod.XMethodMatcher):
+def __init__(self):
+gdb.xmethod.XMethodMatcher.__init__(self,
+matcher_name_prefix + 'vector')
+self._subscript_worker = VectorSubscriptWorker()
+self._size_worker = VectorSizeWorker()
+self.methods = [self._subscript_worker, self._size_worker]
+
+def match(self, class_type, method_name):
+if not re.match('^std::vector<.*>$', class_type.tag):
+return None
+if method_name == 'operator[]' and self._subscript_worker.enabled:
+return self._subscript_worker
+elif method_name == 'size' and self._size_worker.enabled:
+return self._size_worker
+
+# Xmethods for std::unique_ptr
+
+class UniquePtrGetWorker(gdb.xmethod.XMethodWorker):
+def __init__(self):
+self.name = 'get'
+self.enabled = True
+
+def get_arg_types(self):
+return None
+
+def __call__(self, obj):
+_m_t = obj['_M_t']
+# The object to be returned is the 0-th element in the tuple _m_t.
+# The following retrieves the 0-th element of this tuple.
+_m_t_base = _m_t[_m_t.type.fields()[0]] # std::tuple has a single base
+# class and no data members.
+for f in _m_t_base.type.fields():
+# The object is embedded in the _Head_base<> base class of
+# _m_t_base.
+if f.is_base_class and f.name.find('std::_Head_base<') == 0:
+_head_base = _m_t_base[f]
+return _head_base['_M_head_impl']
+
+class UniquePtrDerefWorker(UniquePtrGetWorker):
+def __init__(self)

Re: [Committed] Fix lto.c compiling

[Andi Kleen]

Andrew Pinski  writes:

> I committed this as obvious.  The changelog says it all.

I think the problem is that LTO bootstraps frequently error out with
-Werror. That incentives LTO users to bootstrap with --disable-werror.

[e.g. currently the graphite libraries don't build this way]

The main problem seems to be -Wmaybe-undefined + -Werror + LTO. 
Perhaps there should be a way to make this one warning not error.

-Andi

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

Re: [wwwdocs,Patch] Update Fortran part in gcc-4.9/changes.html

[Gerald Pfeifer]

On Tue, 25 Jun 2013, Tobias Burnus wrote:
Comments are welcome. Otherwise, I intent to commit it soon. (Well, 
comments are also welcome after committal ;-)


Since you are offering that ;-), I find the the wording "(but inexact)" 
in


 When STOP or ERROR STOP are used to 
 terminate the execution and any exception (but inexact) is signaling


a bit confusing.  Any chance you can reword this somehow?


I also committed a number of editorial changes (grammar, shorter
sentences,...) per the patch below.

Gerald

 
Index: changes.html

===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.72
diff -u -r1.72 changes.html
--- changes.html28 Jun 2014 12:37:43 -  1.72
+++ changes.html29 Jun 2014 17:13:36 -
@@ -374,22 +374,22 @@
has been incremented; additionally, module files are now compressed.
Fortran MODULEs compiled by earlier GCC versions have
to be recompiled, when they are USEd by files compiled
-with GCC 4.9, because GCC 4.9 is not able to read .mod
+with GCC 4.9.  GCC 4.9 is not able to read .mod
files of earlier GCC versions; attempting to do so gives an error
message. Note: The ABI of the produced assembler data itself has not
-changed: object files and libraries are fully compatible to older
-versions. (Except for the next items.)
+changed: object files and libraries are fully compatible with older
+versions (except as stated below).
  ABI changes:
  
-Note that the The https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gfortran/Argument-passing-conventions.html";
  >argument passing ABI has changed for scalar dummy
  arguments of type INTEGER, REAL,
  COMPLEX and LOGICAL, which have
  both the VALUE and the OPTIONAL
- attribute.
-Due to the support of finalization, the virtual table associated
-  with polymorphic variables has changed. Therefore, code containing
+ attributes.
+To support finalization the virtual table associated
+  with polymorphic variables has changed.  Code containing
  CLASS should be recompiled, including all files which
  define derived types involved in the type definition used by
  polymorphic variables. (Note: Due to the incremented module version,
@@ -438,8 +438,8 @@
  of the argument.
https://gcc.gnu.org/wiki/Fortran2003Status";>Fortran 2003:

-  Finalization is now supported. Note that finalization is currently
-only done for a subset of the situations in which it should occur.
+  Finalization is now supported.  It is currently only done for a
+subset of those situations in which it should occur.
  Experimental support for scalar character components with
deferred length (i.e. allocatable string length) in derived types has
been added. (Deferred-length character variables are supported since
@@ -447,13 +447,13 @@

https://gcc.gnu.org/wiki/Fortran2008Status";>Fortran 2008:

-  When STOP or ERROR STOP is used to 
terminate
+  When STOP or ERROR STOP are used to 
terminate
the execution and any exception (but inexact) is signaling, a warning is
printed to ERROR_UNIT, indicating which exceptions are
signaling. The https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gfortran/Debugging-Options.html";
>-ffpe-summary= command-line option can be used to fine-tune
-for which exception the warning should be shown.
+for which exceptions the warning should be shown.
  Rounding on input (READ) is now handled on systems where
strtod honours the rounding mode. (For output, rounding is
supported since GCC 4.5.) Note that for input, the

Re: [Patch] Patch set for regex instantiation

[Jonathan Wakely]

On 11/01/14 19:48 -0500, Tim Shen wrote:

Here're 4 patches that finally led the _Compiler's instantiation and
some other optimization for compiling time.

1) Create class _ScannerBase to make _Scanner pithier. Move const
static members to src/c++11/regex.cc.


I think it might be time to revisit this change and put the data
members of _ScannerBase into the .so, as we're creating and
initializing 136 bytes of duplicated constants every time we construct
a std::regex.

Alternatively, we could just make them local statics instead of member
data and still remove the duplciation (see attached).


commit 82f3e9fa7d16a677bb9ebc6bc3da12c1209c2df5
Author: Jonathan Wakely 
Date:   Sun Jun 29 17:58:59 2014 +0100

	* include/bits/regex_scanner.h (_ScannerBase): Replace member data
	with static member functions.
	* include/bits/regex_scanner.tcc (_ScannerBase): Likewise.

diff --git a/libstdc++-v3/include/bits/regex_scanner.h b/libstdc++-v3/include/bits/regex_scanner.h
index 6627db9..fdc1210 100644
--- a/libstdc++-v3/include/bits/regex_scanner.h
+++ b/libstdc++-v3/include/bits/regex_scanner.h
@@ -1,4 +1,4 @@
-// class template regex -*- C++ -*-
+// Regex implementation -*- C++ -*-
 
 // Copyright (C) 2013-2014 Free Software Foundation, Inc.
 //
@@ -92,13 +92,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 : _M_state(_S_state_normal),
 _M_flags(__flags),
 _M_escape_tbl(_M_is_ecma()
-		  ? _M_ecma_escape_tbl
-		  : _M_awk_escape_tbl),
+		  ? _S_ecma_escape_tbl()
+		  : _S_awk_escape_tbl()),
 _M_spec_char(_M_is_ecma()
-		 ? _M_ecma_spec_char
+		 ? _S_ecma_spec_char()
 		 : _M_is_basic()
-		 ? _M_basic_spec_char
-		 : _M_extended_spec_char),
+		 ? _S_basic_spec_char()
+		 : _S_extended_spec_char()),
 _M_at_bracket_start(false)
 { }
 
@@ -138,46 +138,60 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { return _M_flags & regex_constants::awk; }
 
   protected:
-const std::pair _M_token_tbl[9] =
-  {
-	{'^', _S_token_line_begin},
-	{'$', _S_token_line_end},
-	{'.', _S_token_anychar},
-	{'*', _S_token_closure0},
-	{'+', _S_token_closure1},
-	{'?', _S_token_opt},
-	{'|', _S_token_or},
-	{'\n', _S_token_or}, // grep and egrep
-	{'\0', _S_token_or},
-  };
-const std::pair _M_ecma_escape_tbl[8] =
-  {
-	{'0', '\0'},
-	{'b', '\b'},
-	{'f', '\f'},
-	{'n', '\n'},
-	{'r', '\r'},
-	{'t', '\t'},
-	{'v', '\v'},
-	{'\0', '\0'},
-  };
-const std::pair _M_awk_escape_tbl[11] =
-  {
-	{'"', '"'},
-	{'/', '/'},
-	{'\\', '\\'},
-	{'a', '\a'},
-	{'b', '\b'},
-	{'f', '\f'},
-	{'n', '\n'},
-	{'r', '\r'},
-	{'t', '\t'},
-	{'v', '\v'},
-	{'\0', '\0'},
-  };
-const char* _M_ecma_spec_char = "^$\\.*+?()[]{}|";
-const char* _M_basic_spec_char = ".[\\*^$";
-const char* _M_extended_spec_char = ".[\\()*+?{|^$";
+static const std::pair* _S_token_tbl()
+{
+  static const std::pair __token_tbl[9] =
+	{
+	  {'^', _S_token_line_begin},
+	  {'$', _S_token_line_end},
+	  {'.', _S_token_anychar},
+	  {'*', _S_token_closure0},
+	  {'+', _S_token_closure1},
+	  {'?', _S_token_opt},
+	  {'|', _S_token_or},
+	  {'\n', _S_token_or}, // grep and egrep
+	  {'\0', _S_token_or},
+	};
+  return __token_tbl;
+}
+
+static const std::pair* _S_ecma_escape_tbl()
+{
+  static const std::pair __ecma_escape_tbl[8] =
+	{
+	  {'0', '\0'},
+	  {'b', '\b'},
+	  {'f', '\f'},
+	  {'n', '\n'},
+	  {'r', '\r'},
+	  {'t', '\t'},
+	  {'v', '\v'},
+	  {'\0', '\0'},
+	};
+  return __ecma_escape_tbl;
+}
+static const std::pair* _S_awk_escape_tbl()
+{
+  static const std::pair __awk_escape_tbl[11] =
+	{
+	  {'"', '"'},
+	  {'/', '/'},
+	  {'\\', '\\'},
+	  {'a', '\a'},
+	  {'b', '\b'},
+	  {'f', '\f'},
+	  {'n', '\n'},
+	  {'r', '\r'},
+	  {'t', '\t'},
+	  {'v', '\v'},
+	  {'\0', '\0'},
+	};
+  return __awk_escape_tbl;
+}
+
+static const char* _S_ecma_spec_char() { return "^$\\.*+?()[]{}|"; }
+static const char* _S_basic_spec_char() { return ".[\\*^$"; }
+static const char* _S_extended_spec_char() { return ".[\\()*+?{|^$"; }
 
 _StateT   _M_state;
 _FlagT_M_flags;
diff --git a/libstdc++-v3/include/bits/regex_scanner.tcc b/libstdc++-v3/include/bits/regex_scanner.tcc
index 818e47b..ed88f71 100644
--- a/libstdc++-v3/include/bits/regex_scanner.tcc
+++ b/libstdc++-v3/include/bits/regex_scanner.tcc
@@ -170,7 +170,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 		&& __c != '}')
 	   || (_M_is_grep() && __c == '\n'))
 	{
-	  auto __it = _M_token_tbl;
+	  auto __it = _S_token_tbl();
 	  auto __narrowc = _M_ctype.narrow(__c, '\0');
 	  for (; __it->first != '\0'; ++__it)
 	if (__it->first == __narrowc)

Re: [GSoC] Addition of ISL AST generation to Graphite

[Gerald Pfeifer]

I'm pretty it's the following that causes bootstrap to fail for me:

  2014-06-29  Roman Gareev  

* Makefile.in:
Add the compilation of graphite-isl-ast-to-gimple.o.
* common.opt:
Add new switch fgraphite-code-generator=[isl|cloog].
* flag-types.h:
Add new enum fgraphite_generator.
* graphite-isl-ast-to-gimple.c: New.
* graphite-isl-ast-to-gimple.h: New.
* graphite.c (graphite_transform_loops):
Add choice of Graphite code generator,
which depends on flag_graphite_code_gen.

testsuite/gcc.dg/graphite/isl-codegen-loop-dumping.c:
New testcase that checks that the dump is generated.

As follows:

  /scratch2/tmp/gerald/gcc-HEAD/gcc/graphite-isl-ast-to-gimple.c:23:10: 
  fatal error: 'isl/set.h' file not found
  #include 
   ^

I do not have ISL installed on that machine and I don't want to use 
graphite on that machine.


PR 61650 - [4.10] Bootstrap failure due to dependency on ISL.

Gerald

Re: [GSoC] Addition of ISL AST generation to Graphite

[Tobias Grosser]

On 29/06/2014 19:31, Gerald Pfeifer wrote:

I'm pretty it's the following that causes bootstrap to fail for me:

   2014-06-29  Roman Gareev  

 * Makefile.in:
 Add the compilation of graphite-isl-ast-to-gimple.o.
 * common.opt:
 Add new switch fgraphite-code-generator=[isl|cloog].
 * flag-types.h:
 Add new enum fgraphite_generator.
 * graphite-isl-ast-to-gimple.c: New.
 * graphite-isl-ast-to-gimple.h: New.
 * graphite.c (graphite_transform_loops):
 Add choice of Graphite code generator,
 which depends on flag_graphite_code_gen.

 testsuite/gcc.dg/graphite/isl-codegen-loop-dumping.c:
 New testcase that checks that the dump is generated.

As follows:

   /scratch2/tmp/gerald/gcc-HEAD/gcc/graphite-isl-ast-to-gimple.c:23:10:
   fatal error: 'isl/set.h' file not found
   #include 
^

I do not have ISL installed on that machine and I don't want to use
graphite on that machine.


PR 61650 - [4.10] Bootstrap failure due to dependency on ISL.


Hi Gerald,

sorry for the breakage. This seems to be caused by forgotten include 
guards. I attached a patch (not bootstrapped yet), that should fix the

issue. I will start a gcc (non-graphite) bootstrap to see if it works
and will commit it immediately after.

Please report back if it fixes the bootstrap for you.

Cheers,
Tobias



>From 2910e41368c3895a7a023133a1fcb87772b838a8 Mon Sep 17 00:00:00 2001
From: Tobias Grosser 
Date: Sun, 29 Jun 2014 19:34:30 +0200
Subject: [PATCH] Fix gcc bootstrap

	gcc/
* graphite-isl-ast-to-gimple.c: Add cloog include guards.
---
 gcc/graphite-isl-ast-to-gimple.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 6437474..8ba7b75 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-isl-ast-to-gimple.c
@@ -20,10 +20,12 @@ along with GCC; see the file COPYING3.  If not see
 
 #include "config.h"
 
+#ifdef HAVE_cloog
 #include 
 #include 
 #include 
 #include 
+#endif
 
 #include "system.h"
 #include "coretypes.h"
@@ -41,6 +43,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-data-ref.h"
 #include "sese.h"
 
+#ifdef HAVE_cloog
 #include "graphite-poly.h"
 #include "graphite-isl-ast-to-gimple.h"
 
@@ -131,3 +134,4 @@ graphite_regenerate_ast_isl (scop_p scop)
   timevar_pop (TV_GRAPHITE_CODE_GEN);
   return !graphite_regenerate_error;
 }
+#endif
-- 
1.8.3.2

[committed-PATCH] Add missing HAVE_cloog guards

[Tobias Grosser]

I just committed the attached patch to fix the gcc bootstrap problem 
reported by Gerald.


At the moment my bootstrap already passed the point where it previously 
failed, but did not yet complete. I committed it is very likely to be 
both correct and to unbreak the build. I will report back after my 
bootstrap succeeded.


Tobias
>From 75af30d234e53414c664c907dfd003b907574fe3 Mon Sep 17 00:00:00 2001
From: grosser 
Date: Sun, 29 Jun 2014 17:51:01 +
Subject: [PATCH] Add missing HAVE_cloog guards

* graphite-isl-ast-to-gimple.c: Add missing guards.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@212125 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog| 4 
 gcc/graphite-isl-ast-to-gimple.c | 4 
 2 files changed, 8 insertions(+)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 7c34af8..22b99b5 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2014-06-29  Tobias Grosser 
+
+	* graphite-isl-ast-to-gimple.c: Add missing guards.
+
 2014-06-29  Roman Gareev  
 
 	* Makefile.in:
diff --git a/gcc/graphite-isl-ast-to-gimple.c b/gcc/graphite-isl-ast-to-gimple.c
index 6437474..8ba7b75 100644
--- a/gcc/graphite-isl-ast-to-gimple.c
+++ b/gcc/graphite-isl-ast-to-gimple.c
@@ -20,10 +20,12 @@ along with GCC; see the file COPYING3.  If not see
 
 #include "config.h"
 
+#ifdef HAVE_cloog
 #include 
 #include 
 #include 
 #include 
+#endif
 
 #include "system.h"
 #include "coretypes.h"
@@ -41,6 +43,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-data-ref.h"
 #include "sese.h"
 
+#ifdef HAVE_cloog
 #include "graphite-poly.h"
 #include "graphite-isl-ast-to-gimple.h"
 
@@ -131,3 +134,4 @@ graphite_regenerate_ast_isl (scop_p scop)
   timevar_pop (TV_GRAPHITE_CODE_GEN);
   return !graphite_regenerate_error;
 }
+#endif
-- 
1.8.3.2

Re: [PATCH, alpha]: Wrap {un,}aligned_store sequence with memory blockages.

[Uros Bizjak]

On Fri, Jun 27, 2014 at 10:04 PM, Richard Henderson  wrote:
> On 06/27/2014 10:04 AM, Uros Bizjak wrote:
>> This happened due to the way stores to QImode and HImode locations are
>> implemented on non-BWX targets. The sequence reads full word, does its
>> magic to the part and stores the full word with changed part back to
>> the memory. However - the scheduler mixed two sequences, violating the
>> atomicity of RMW sequence.
>
> Except that addresses with AND in them (ldq_u, stq_u) are already supposed to
> be memory barriers.  So you shouldn't need to add such to them again.
>
> I think something else has gone wrong somewhere.

There is am early shortcut for MEM_READOLNY_P in true_dependence_1.

In this case,

(insn 15 13 18 2 (set (reg/f:DI 78 [ b ])
(mem/u/f/c:DI (reg/f:DI 79) [2 b+0 S8 A64])) rmw.c:7 226 {*movdi}
 (expr_list:REG_DEAD (reg/f:DI 79)
(nil)))

is free to be scheduled before

(insn 13 12 15 2 (set (mem:DI (and:DI (plus:DI (reg/f:DI 72 [ a ])
(const_int 1 [0x1]))
(const_int -8 [0xfff8])) [0  S8 A64])
(reg:DI 77)) rmw.c:6 226 {*movdi}
 (expr_list:REG_DEAD (reg:DI 77)
(expr_list:REG_DEAD (reg/f:DI 72 [ a ])
(nil

Attached RFC patch also fixes the testcase, trivially preventing
scheduling of (insn 13) before (insn 15).

Uros.
Index: alias.c
===
--- alias.c (revision 212063)
+++ alias.c (working copy)
@@ -2468,10 +2468,19 @@
   || MEM_ALIAS_SET (mem) == ALIAS_SET_MEMORY_BARRIER)
 return 1;
 
+  if (! mem_addr)
+{
+  mem_addr = XEXP (mem, 0);
+  if (mem_mode == VOIDmode)
+   mem_mode = GET_MODE (mem);
+}
+
   /* Read-only memory is by definition never modified, and therefore can't
  conflict with anything.  We don't expect to find read-only set on MEM,
  but stupid user tricks can produce them, so don't die.  */
   if (MEM_READONLY_P (x))
+if (GET_CODE (mem_addr) == AND)
+  return 1;
 return 0;
 
   /* If we have MEMs referring to different address spaces (which can
@@ -2480,13 +2489,6 @@
   if (MEM_ADDR_SPACE (mem) != MEM_ADDR_SPACE (x))
 return 1;
 
-  if (! mem_addr)
-{
-  mem_addr = XEXP (mem, 0);
-  if (mem_mode == VOIDmode)
-   mem_mode = GET_MODE (mem);
-}
-
   if (! x_addr)
 {
   x_addr = XEXP (x, 0);

Re: [Patch] Patch set for regex instantiation

[Tim Shen]

On Sun, Jun 29, 2014 at 10:18 AM, Jonathan Wakely  wrote:
> Alternatively, we could just make them local statics instead of member
> data and still remove the duplciation (see attached).

This is a good idea. Can we use constexpr for the functions/static variables?


-- 
Regards,
Tim Shen

[wwwdocs] testing/: Remove reference to obsolete autobuilder; use https

[Gerald Pfeifer]

Amazing what collateral damage^Wroom for improvement I'm running
into as part of the http->https conversion.

Applied.

Gerald

Index: testing/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/testing/index.html,v
retrieving revision 1.36
diff -u -r1.36 index.html
--- testing/index.html  28 Jun 2014 11:59:44 -  1.36
+++ testing/index.html  29 Jun 2014 18:49:19 -
@@ -53,9 +53,7 @@
   If your system is beefy enough, do regular builds and test runs with
   RTL consistency checks enabled.  This slows the compiler down by an
   order of magnitude but has found plenty of bugs in the past.
-  Set up an autobuilder (see
-  http://gcc.gnu.org/regtest/";>
-  gcc-regression) to nag people in e-mail when they submit
+  Set up an autobuilder to nag people in e-mail when they submit
   patches that break builds.  Ideally we would have one of these
   for at least each of the primary evaluation platforms listed in
   the current release criteria, but the more the merrier.
Index: testing/testing-boost.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/testing/testing-boost.html,v
retrieving revision 1.5
diff -u -r1.5 testing-boost.html
--- testing/testing-boost.html  17 Apr 2004 22:32:31 -  1.5
+++ testing/testing-boost.html  29 Jun 2014 18:49:19 -
@@ -71,7 +71,7 @@
 GCC 3.1
 g++ -c -w -ftemplate-depth-30 -I%include %source
 g++ -o boosttmp.exe -w -ftemplate-depth-30 -I%include %source -lrt
-GNU
GCC
3.1
+GNU
GCC
3.1
 
 
 To build the package with specific optimizations, add them to the

[PATCH v2, rtl]: Teach _.barriers and _.eh_range passes to not split a call and its corresponding CALL_ARG_LOCATION note.

[Uros Bizjak]

On Fri, Jun 27, 2014 at 9:11 PM, Richard Henderson  wrote:
> On 06/26/2014 02:15 PM, Uros Bizjak wrote:
>> * except.c (emit_note_eh_region_end): New helper function.
>> (convert_to_eh_region_ranges): Use emit_note_eh_region_end to
>> emit EH_REGION_END note.
>
> This bit looks good.
>
>
>>rtx insn, next, prev;
>> -  for (insn = get_insns (); insn; insn = next)
>> +  for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
>>  {
>> -  next = NEXT_INSN (insn);
>>if (BARRIER_P (insn))
>>   {
>> prev = prev_nonnote_insn (insn);
>> if (!prev)
>>   continue;
>> +
>> +   /* Make sure we do not split a call and its corresponding
>> +  CALL_ARG_LOCATION note.  */
>> +   next = NEXT_INSN (prev);
>> +   if (next == NULL)
>> + continue;
>> +   if (NOTE_P (next)
>> +   && NOTE_KIND (next) == NOTE_INSN_CALL_ARG_LOCATION)
>> + prev = next;
>> +
>
> This bit looks more complicated than it needs to be.
> It would also be helpful for legibility to move the
> declarations from the top to the first uses.
>
> The next == NULL test can never be true, since we've
> already searched backward from insn.

Thanks for the review!

I believe that attached v2 patch addresses all your review comments.

Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Uros.
Index: except.c
===
--- except.c(revision 212063)
+++ except.c(working copy)
@@ -2466,6 +2466,20 @@ add_call_site (rtx landing_pad, int action, int se
   return call_site_base + crtl->eh.call_site_record_v[section]->length () - 1;
 }
 
+static rtx
+emit_note_eh_region_end (rtx insn)
+{
+  rtx next = NEXT_INSN (insn);
+
+  /* Make sure we do not split a call and its corresponding
+ CALL_ARG_LOCATION note.  */
+  if (next && NOTE_P (next)
+  && NOTE_KIND (next) == NOTE_INSN_CALL_ARG_LOCATION)
+insn = next;
+
+  return emit_note_after (NOTE_INSN_EH_REGION_END, insn);
+}
+
 /* Turn REG_EH_REGION notes back into NOTE_INSN_EH_REGION notes.
The new note numbers will not refer to region numbers, but
instead to call site entries.  */
@@ -2544,8 +2558,8 @@ convert_to_eh_region_ranges (void)
note = emit_note_before (NOTE_INSN_EH_REGION_BEG,
 first_no_action_insn_before_switch);
NOTE_EH_HANDLER (note) = call_site;
-   note = emit_note_after (NOTE_INSN_EH_REGION_END,
-   last_no_action_insn_before_switch);
+   note
+ = emit_note_eh_region_end (last_no_action_insn_before_switch);
NOTE_EH_HANDLER (note) = call_site;
gcc_assert (last_action != -3
|| (last_action_insn
@@ -2569,8 +2583,7 @@ convert_to_eh_region_ranges (void)
first_no_action_insn = NULL_RTX;
  }
 
-   note = emit_note_after (NOTE_INSN_EH_REGION_END,
-   last_action_insn);
+   note = emit_note_eh_region_end (last_action_insn);
NOTE_EH_HANDLER (note) = call_site;
  }
 
@@ -2617,7 +2630,7 @@ convert_to_eh_region_ranges (void)
 
   if (last_action >= -1 && ! first_no_action_insn)
 {
-  note = emit_note_after (NOTE_INSN_EH_REGION_END, last_action_insn);
+  note = emit_note_eh_region_end (last_action_insn);
   NOTE_EH_HANDLER (note) = call_site;
 }
 
Index: jump.c
===
--- jump.c  (revision 212063)
+++ jump.c  (working copy)
@@ -121,15 +121,26 @@ rebuild_jump_labels_chain (rtx chain)
 static unsigned int
 cleanup_barriers (void)
 {
-  rtx insn, next, prev;
-  for (insn = get_insns (); insn; insn = next)
+  rtx insn;
+  for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
 {
-  next = NEXT_INSN (insn);
   if (BARRIER_P (insn))
{
- prev = prev_nonnote_insn (insn);
+ rtx prev = prev_nonnote_insn (insn);
  if (!prev)
continue;
+
+ if (CALL_P (prev))
+   {
+ /* Make sure we do not split a call and its corresponding
+CALL_ARG_LOCATION note.  */
+ rtx next = NEXT_INSN (prev);
+
+ if (NOTE_P (next)
+ && NOTE_KIND (next) == NOTE_INSN_CALL_ARG_LOCATION)
+   prev = next;
+   }
+
  if (BARRIER_P (prev))
delete_insn (insn);
  else if (prev != PREV_INSN (insn))

Re: Optimize type streaming

[Jan Hubicka]

> In addition of pr61644 and pr61646, this commit breaks a lot of
> fortran tests with -flto -O0.
Hello,
the problem here is that we have POINTER_TYPE that points to array of variable
length (not sure why it happens only with -O0). The ICE is introduced by the
fact that we stream the type inside of function body then and thus it never
goes through the lto.c's type handling.

This patch fixes the ICE by moving the fixup somewhat earlier (perhaps it is
good idea in general). I do not believe resulting IL is correct: we do not
compute canonical type of the pointer nor we link correctly the variants.

Richard, we probably ought to try to make all of the canonical type fixup
happen also for function local types which would involve moving it all from
lto.c into generic code? :((

I am testing the patch.  I think it is better to have fixup here, so OK if
it passes?

Honza

Index: lto-streamer-in.c
===
--- lto-streamer-in.c   (revision 212098)
+++ lto-streamer-in.c   (working copy)
@@ -1182,6 +1182,58 @@ lto_read_tree (struct lto_input_block *i
 }
 
 
+/* Copy fields that are not streamed but copied from other nodes.  */
+static void
+lto_copy_fields_not_streamed (tree t)
+{
+  if (TYPE_P (t) && TYPE_MAIN_VARIANT (t) != t)
+{
+  tree mv = TYPE_MAIN_VARIANT (t);
+
+  if (COMPLETE_TYPE_P (t))
+   {
+ TYPE_SIZE (t) = TYPE_SIZE (mv);
+ TYPE_SIZE_UNIT (t) = TYPE_SIZE_UNIT (mv);
+   }
+  TYPE_ATTRIBUTES (t) = TYPE_ATTRIBUTES (mv);
+
+  if (CODE_CONTAINS_STRUCT (TREE_CODE (t), TS_TYPE_NON_COMMON))
+   {
+ if (TREE_CODE (t) == ENUMERAL_TYPE && COMPLETE_TYPE_P (t))
+   TYPE_VALUES (t) = TYPE_VALUES (mv);
+ else if (TREE_CODE (t) == ARRAY_TYPE)
+   TYPE_DOMAIN (t) = TYPE_DOMAIN (mv);
+
+  if (RECORD_OR_UNION_TYPE_P (t) && COMPLETE_TYPE_P (t))
+   TYPE_VFIELD (t) = TYPE_VFIELD (mv);
+ else if ((TREE_CODE (t) == ENUMERAL_TYPE && COMPLETE_TYPE_P (t))
+  || TREE_CODE (t) == INTEGER_TYPE
+  || TREE_CODE (t) == BOOLEAN_TYPE
+  || TREE_CODE (t) == REAL_TYPE
+  || TREE_CODE (t) == FIXED_POINT_TYPE)
+   TYPE_MIN_VALUE (t) = TYPE_MIN_VALUE (mv);
+
+ if (TREE_CODE (t) == METHOD_TYPE)
+   TYPE_METHOD_BASETYPE (t) = TYPE_METHOD_BASETYPE (mv);
+ else if (RECORD_OR_UNION_TYPE_P (t) && COMPLETE_TYPE_P (t))
+   TYPE_METHODS (t) = TYPE_METHODS (mv);
+ else if (TREE_CODE (t) == OFFSET_TYPE)
+   TYPE_OFFSET_BASETYPE (t) = TYPE_OFFSET_BASETYPE (mv);
+ else if (TREE_CODE (t) == ARRAY_TYPE)
+   TYPE_ARRAY_MAX_SIZE (t) = TYPE_ARRAY_MAX_SIZE (mv);
+ else if ((TREE_CODE (t) == ENUMERAL_TYPE && COMPLETE_TYPE_P (t))
+  || TREE_CODE (t) == INTEGER_TYPE
+  || TREE_CODE (t) == BOOLEAN_TYPE
+  || TREE_CODE (t) == REAL_TYPE
+  || TREE_CODE (t) == FIXED_POINT_TYPE)
+   TYPE_MAX_VALUE (t) = TYPE_MAX_VALUE (mv);
+
+ if (RECORD_OR_UNION_TYPE_P (t) && COMPLETE_TYPE_P (t))
+   TYPE_BINFO (t) = TYPE_BINFO (mv);
+   }
+}
+}
+
 /* Populate the reader cache with trees materialized from the SCC
following in the IB, DATA_IN stream.  */
 
@@ -1194,6 +1246,7 @@ lto_input_scc (struct lto_input_block *i
   unsigned size = streamer_read_uhwi (ib);
   hashval_t scc_hash = streamer_read_uhwi (ib);
   unsigned scc_entry_len = 1;
+  unsigned from = data_in->reader_cache->nodes.length ();
 
   if (size == 1)
 {
@@ -1233,6 +1286,12 @@ lto_input_scc (struct lto_input_block *i
}
 }
 
+  /* Copy fileds we do not stream before unification so we can compare them
+ without being worried if they are already initialized.  */
+  for (unsigned i = 0; i < size; ++i)
+lto_copy_fields_not_streamed
+   (streamer_tree_cache_get_tree (data_in->reader_cache, from + i));
+
   *len = size;
   *entry_len = scc_entry_len;
   return scc_hash;
Index: lto/lto.c
===
--- lto/lto.c   (revision 212114)
+++ lto/lto.c   (working copy)
@@ -1050,58 +1050,6 @@ lto_register_function_decl_in_symtab (st
 decl, get_resolution (data_in, ix));
 }
 
-/* Copy fields that are not streamed but copied from other nodes.  */
-static void
-lto_copy_fields_not_streamed (tree t)
-{
-  if (TYPE_P (t) && TYPE_MAIN_VARIANT (t) != t)
-{
-  tree mv = TYPE_MAIN_VARIANT (t);
-
-  if (COMPLETE_TYPE_P (t))
-   {
- TYPE_SIZE (t) = TYPE_SIZE (mv);
- TYPE_SIZE_UNIT (t) = TYPE_SIZE_UNIT (mv);
-   }
-  TYPE_ATTRIBUTES (t) = TYPE_ATTRIBUTES (mv);
-
-  if (CODE_CONTAINS_STRUCT (TREE_CODE (t), TS_TYPE_NON_COMMON))
-   {
- if (TREE_CODE (t) == ENUMERAL_TYPE && COMPLETE_TYPE_P (t))
-   TYPE_VALUES (t) = TYPE_VALUES (mv);
- else if (TREE_CODE (t) == ARRAY_TY

Re: [PATCH] gcc/c/c-decl.c: Let NEWDECL dereference shared data to fix segment fault issue.

[Jan Hubicka]

> On Sun, 29 Jun 2014, Chen Gang wrote:
> 
> > NEWDECL dereferences shared data of OLDDECL, or when free NEWDECL, also
> > have effect with OLDDECL. At present, only fix the related reference for
> > current issue. If find another related issue, can follow this fix.
> 
> I'm afraid I can't make any sense of this.
> 
> We need a carefully written analysis of the issue you are trying to fix 
> that explains what is going wrong and why, in terms of the underlying 
> design of the code, the proposed change is logically correct to fix the 
> issue.
> 
> That is, explain how NEWDECL gets used after merge_decls returns, why your 
> proposed changes to NEWDECL are correct for the subsequent use of NEWDECL, 
> why the previous contents of NEWDECL would be incorrect for the subsequent 
> uses of NEWDECL, and why it is correct for the subsequent uses to make 
> whatever use of NEWDECL is causing problems.  Where does the segfault 
> occur anyway?

Actually this problem was introduced by me (and I made patch for it once already
but apparently it did not reach the ML). THe problem is that we now create 
symbols
to hold information about decl that is no longer represented in trees - 
sections,
comdats etc.

Now in duplicate_decl we have two symbol nodes for the duplicated declarations
and remove one of them at the end.  cgraph_remove_node calls
cgraph_release_function_body that assumes that we never have two functions with
same DECL_STRUCT_FUNCTION.

So Cheng is right we need to clear DECL_STRUCT_FUNCTION or we end up ggc_freeing
it that later ICEs in push_cfun.  We do not need to clear the other fields.

The patch bellow just copy identical hunk of code from cp/decl.c
> 
> >   root@gchen:/upstream/linux# cat elevator.i
> >   extern int __attribute__ ((__section__(".init.text"))) elv_register(void)
> >   {
> >return 0;
> >   }
> >   extern typeof(elv_register) elv_register;
> 
> Patch submissions should add a test to the testsuite, when it's something 
> small like this.

Added.

thanks for working on this!  I am bootstrapping/regtesting the attacked patch 
on x86_64-linux
OK?

Honza

Chen Gang 
Jan Hubicka  

* c-decl.c (duplicate_decls): CLear DECL_STRUCT_FUNCTION before 
releasing
symbol.

* gcc.c-torture/compile/section.c: New testcase
Index: testsuite/gcc.c-torture/compile/section.c
===
--- testsuite/gcc.c-torture/compile/section.c   (revision 0)
+++ testsuite/gcc.c-torture/compile/section.c   (revision 0)
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+
+/* { dg-require-effective-target named_sections } */
+extern int __attribute__ ((__section__(".init.text"))) elv_register(void)
+{
+ return 0;
+}
+extern typeof(elv_register) elv_register;
Index: c/c-decl.c
===
--- c/c-decl.c  (revision 212098)
+++ c/c-decl.c  (working copy)
@@ -2575,7 +2575,14 @@ duplicate_decls (tree newdecl, tree oldd
 
   merge_decls (newdecl, olddecl, newtype, oldtype);
 
-  /* The NEWDECL will no longer be needed.  */
+  /* The NEWDECL will no longer be needed.
+
+ Before releasing the node, be sore to remove function from symbol
+ table that might have been inserted there to record comdat group.
+ Be sure to however do not free DECL_STRUCT_FUNCTION becuase this
+ structure is shared in between newdecl and oldecl.  */
+  if (TREE_CODE (newdecl) == FUNCTION_DECL)
+DECL_STRUCT_FUNCTION (newdecl) = NULL;
   if (TREE_CODE (newdecl) == FUNCTION_DECL
   || TREE_CODE (newdecl) == VAR_DECL)
 {

[wwwdocs,Java] Make links in faq.html and java/faq.html relative

[Gerald Pfeifer]

Ever since

  2007-10-01  Gerald Pfeifer  

* gcc_release: Do not include copies of faq.html in releases,
and remove all the explicit support code to pull in web pages.

there was no reason faq.html (formerly included as FAQ) needed absolute
links unless wrt. services only available on gcc.gnu.org.  This adjusts
both faq.html and java/faq.html accordingly.

As a nice side effect, this avoids http vs https changes.

Applied.

Gerald

Index: faq.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/faq.html,v
retrieving revision 1.219
diff -u -r1.219 faq.html
--- faq.html28 Jun 2014 11:59:42 -  1.219
+++ faq.html29 Jun 2014 19:38:24 -
@@ -8,9 +8,6 @@
 
 GCC Frequently Asked Questions
 
-The latest version of this document is always available at 
-http://gcc.gnu.org/faq.html";>http://gcc.gnu.org/faq.html.
-
 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,
@@ -21,7 +18,7 @@
 Other GCC-related FAQs: 
https://gcc.gnu.org/onlinedocs/libstdc++/faq.html";>
  libstdc++-v3, and 
-   http://gcc.gnu.org/java/faq.html";>GCJ.
+   GCJ.
 
 
 Questions
@@ -105,7 +102,7 @@
 These are included in the sources for a release in INSTALL/specific.html,
 and the https://gcc.gnu.org/install/specific.html";>latest version
 is always available at the GCC web site.
-Reports of http://gcc.gnu.org/buildstat.html";>successful builds
+Reports of successful builds
 for several versions of GCC are also available at the web site.
 
 



2014-06-29  Gerald Pfeifer  

* faq.html: Remove two absolute links/references.

Index: java/faq.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/java/faq.html,v
retrieving revision 1.73
diff -u -r1.73 faq.html
--- java/faq.html   28 Jun 2014 17:12:51 -  1.73
+++ java/faq.html   29 Jun 2014 19:38:26 -
@@ -6,7 +6,7 @@
 
 
   The GCJ FAQ
-  The latest version of this document is always available at http://gcc.gnu.org/java/faq.html.
+
   
 General Questions 
   
@@ -422,7 +422,8 @@
   used for CNI with the -fno-rtti option.
   This constraint does not apply in version 3.0 and later.
   
-  The primary source of documentation for CNI is at http://gcc.gnu.org/java/papers/cni/t1.html
+  The primary source of documentation for CNI is 
+  this paper.
 
   
 

Re: [Patch] Patch set for regex instantiation

[Daniel Krügler]

2014-06-29 20:47 GMT+02:00 Tim Shen :
> On Sun, Jun 29, 2014 at 10:18 AM, Jonathan Wakely  wrote:
>> Alternatively, we could just make them local statics instead of member
>> data and still remove the duplciation (see attached).
>
> This is a good idea. Can we use constexpr for the functions/static variables?

Not so for local statics within constexpr functions, but you could
have constexpr static data members, yes.

- Daniel

Re: [GSoC] Addition of ISL AST generation to Graphite

[Gerald Pfeifer]

On Sun, 29 Jun 2014, Tobias Grosser wrote:
sorry for the breakage. This seems to be caused by forgotten include 
guards. I attached a patch (not bootstrapped yet), that should fix the 
issue. I will start a gcc (non-graphite) bootstrap to see if it works 
and will commit it immediately after.


Please report back if it fixes the bootstrap for you.


Thanks for the quick response, Tobias.  I confirm that it fixes
bootstrap on the system that showed the breakage originally.

Gerald

Re: [committed-PATCH] Add missing HAVE_cloog guards

[Gerald Pfeifer]

On Sun, 29 Jun 2014, Tobias Grosser wrote:
I just committed the attached patch to fix the gcc bootstrap problem 
reported by Gerald.


Thanks!

I closed PR bootstrap/61650 and added that reference to your ChangeLog
entry.

Gerald

Re: [PATCH] gcc/c/c-decl.c: Let NEWDECL dereference shared data to fix segment fault issue.

[Marek Polacek]

On Sun, Jun 29, 2014 at 10:00:34PM +0200, Jan Hubicka wrote:
> > On Sun, 29 Jun 2014, Chen Gang wrote:
> > 
> > > NEWDECL dereferences shared data of OLDDECL, or when free NEWDECL, also
> > > have effect with OLDDECL. At present, only fix the related reference for
> > > current issue. If find another related issue, can follow this fix.
> > 
> > I'm afraid I can't make any sense of this.
> > 
> > We need a carefully written analysis of the issue you are trying to fix 
> > that explains what is going wrong and why, in terms of the underlying 
> > design of the code, the proposed change is logically correct to fix the 
> > issue.
> > 
> > That is, explain how NEWDECL gets used after merge_decls returns, why your 
> > proposed changes to NEWDECL are correct for the subsequent use of NEWDECL, 
> > why the previous contents of NEWDECL would be incorrect for the subsequent 
> > uses of NEWDECL, and why it is correct for the subsequent uses to make 
> > whatever use of NEWDECL is causing problems.  Where does the segfault 
> > occur anyway?
> 
> Actually this problem was introduced by me (and I made patch for it once 
> already
> but apparently it did not reach the ML). THe problem is that we now create 
> symbols
> to hold information about decl that is no longer represented in trees - 
> sections,
> comdats etc.
> 
> Now in duplicate_decl we have two symbol nodes for the duplicated declarations
> and remove one of them at the end.  cgraph_remove_node calls
> cgraph_release_function_body that assumes that we never have two functions 
> with
> same DECL_STRUCT_FUNCTION.
> 
> So Cheng is right we need to clear DECL_STRUCT_FUNCTION or we end up 
> ggc_freeing
> it that later ICEs in push_cfun.  We do not need to clear the other fields.
> 
> The patch bellow just copy identical hunk of code from cp/decl.c
> > 
> > >   root@gchen:/upstream/linux# cat elevator.i
> > >   extern int __attribute__ ((__section__(".init.text"))) 
> > > elv_register(void)
> > >   {
> > >return 0;
> > >   }
> > >   extern typeof(elv_register) elv_register;
> > 
> > Patch submissions should add a test to the testsuite, when it's something 
> > small like this.
> 
> Added.
> 
> thanks for working on this!  I am bootstrapping/regtesting the attacked patch 
> on x86_64-linux
> OK?

Just some typos:

>   Chen Gang 

Two spaces after the name.

>   Jan Hubicka  
> 
>   * c-decl.c (duplicate_decls): CLear DECL_STRUCT_FUNCTION before 
> releasing
>   symbol.

s/CLear/Clear/

> Index: c/c-decl.c
> ===
> --- c/c-decl.c(revision 212098)
> +++ c/c-decl.c(working copy)
> @@ -2575,7 +2575,14 @@ duplicate_decls (tree newdecl, tree oldd
>  
>merge_decls (newdecl, olddecl, newtype, oldtype);
>  
> -  /* The NEWDECL will no longer be needed.  */
> +  /* The NEWDECL will no longer be needed.
> +
> + Before releasing the node, be sore to remove function from symbol

s/sore/sure/

> + table that might have been inserted there to record comdat group.
> + Be sure to however do not free DECL_STRUCT_FUNCTION becuase this

s/becuase/because/

> + structure is shared in between newdecl and oldecl.  */

s/newdecl/NEWDECL/;s/oldecl/OLDDECL/

Marek

Re: [DOC Patch] Attribute 'naked'

[Gerald Pfeifer]

On Thu, 26 Jun 2014, Gerald Pfeifer wrote:
>> 2014-06-17  David Wohlferd 
>> 
>> * doc/extend.texi (Function Attributes): Update 'naked' attribute
>> doc.
> This patch makes sense to me and I've seen feedback on an earlier
> iteration that lead to this now.  So, I am planning to commit this
> unless anyone objects in the next day or two.

Done.  The patch is in after another round of (bootstrap) testing
on i386-unknown-freebsd10.0.

Thanks for the contribution and patience, David!

Gerald

Re: [PATCH] gcc/c/c-decl.c: Let NEWDECL dereference shared data to fix segment fault issue.

[Joseph S. Myers]

On Sun, 29 Jun 2014, Jan Hubicka wrote:

> So Cheng is right we need to clear DECL_STRUCT_FUNCTION or we end up 
> ggc_freeing it that later ICEs in push_cfun.  We do not need to clear 
> the other fields.

Thanks for the explanation.  This patch is OK with the typo fixes Marek 
has noted.

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

Re: [PATCH 1/7] Add missing documentation of four IPA-CP params

[Gerald Pfeifer]

On Tue, 10 Jun 2014, Gerald Pfeifer wrote:
> On Wed, 21 May 2014, Martin Jambor wrote:
>> +@item ipa-cp-loop-hint-bonus
>> +When IPA-CP determines that a cloning candidate would make the number
>> +of iterations of a loop known, it adds a bonus of
>^
>> +@option{ipa-cp-loop-hint-bonus} bonus to the profitability score of
>> +the candidate.  ^
> 
> That's a bit much bonus in there. :-)
> 
>> +@item ipa-cp-array-index-hint-bonus
>> +When IPA-CP determines that a cloning candidate would make the index of
>> +an array access known, it adds a bonus of
>> +@option{ipa-cp-array-index-hint-bonus} bonus to the profitability
>> +score of the candidate.
> 
> In here, too.

Hmm, I expected you'd fix this?

Apparently not, so I just applied the following.

2014-06-30  Gerald Pfeifer  

* doc/invoke.texi (Optimize Options): Fix descriptions of
ipa-cp-loop-hint-bonus and ipa-cp-array-index-hint-bonus.

Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 212127)
+++ doc/invoke.texi (working copy)
@@ -10163,13 +10163,13 @@
 @item ipa-cp-loop-hint-bonus
 When IPA-CP determines that a cloning candidate would make the number
 of iterations of a loop known, it adds a bonus of
-@option{ipa-cp-loop-hint-bonus} bonus to the profitability score of
+@option{ipa-cp-loop-hint-bonus} to the profitability score of
 the candidate.
 
 @item ipa-cp-array-index-hint-bonus
 When IPA-CP determines that a cloning candidate would make the index of
 an array access known, it adds a bonus of
-@option{ipa-cp-array-index-hint-bonus} bonus to the profitability
+@option{ipa-cp-array-index-hint-bonus} to the profitability
 score of the candidate.
 
 @item ipa-max-aa-steps

SRA: don't drop clobbers

[Marc Glisse]

Hello,

with this patch on top of
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02315.html
we finally warn for the testcase of PR 60517.

The new function is copied from init_subtree_with_zero right above. I 
guess it might be possible to merge them into a single function, if 
desired. I don't understand the debug stuff, but hopefully by keeping the 
functions similar enough it shouldn't be too broken.


When we see a clobber during scalarization, instead of dropping it, we add 
a clobber to the new variable, which the previous patch turns into an 
SSA_NAME with a default def. Then either we reach uninit and warn, or the 
variable appears in a PHI and CCP optimizes.


Bootstrap+testsuite (all,obj-c++,ada,go) on x86_64-linux-gnu.


2014-07-01  Marc Glisse  

PR c++/60517
PR tree-optimization/60770
gcc/
* tree-sra.c (clobber_subtree): New function.
(sra_modify_constructor_assign): Call it.
gcc/testsuite/
* g++.dg/tree-ssa/pr60517.C: New file.

--
Marc GlisseIndex: gcc/tree-sra.c
===
--- gcc/tree-sra.c  (revision 212126)
+++ gcc/tree-sra.c  (working copy)
@@ -2727,20 +2727,58 @@ init_subtree_with_zero (struct access *a
   if (insert_after)
gsi_insert_after (gsi, ds, GSI_NEW_STMT);
   else
gsi_insert_before (gsi, ds, GSI_SAME_STMT);
 }
 
   for (child = access->first_child; child; child = child->next_sibling)
 init_subtree_with_zero (child, gsi, insert_after, loc);
 }
 
+static void
+clobber_subtree (struct access *access, gimple_stmt_iterator *gsi,
+   bool insert_after, location_t loc)
+
+{
+  struct access *child;
+
+  if (access->grp_to_be_replaced)
+{
+  tree rep = get_access_replacement (access);
+  tree clobber = build_constructor (access->type, NULL);
+  TREE_THIS_VOLATILE (clobber) = 1;
+  gimple stmt = gimple_build_assign (rep, clobber);
+
+  if (insert_after)
+   gsi_insert_after (gsi, stmt, GSI_NEW_STMT);
+  else
+   gsi_insert_before (gsi, stmt, GSI_SAME_STMT);
+  update_stmt (stmt);
+  gimple_set_location (stmt, loc);
+}
+  else if (access->grp_to_be_debug_replaced)
+{
+  tree rep = get_access_replacement (access);
+  tree clobber = build_constructor (access->type, NULL);
+  TREE_THIS_VOLATILE (clobber) = 1;
+  gimple ds = gimple_build_debug_bind (rep, clobber, gsi_stmt (*gsi));
+
+  if (insert_after)
+   gsi_insert_after (gsi, ds, GSI_NEW_STMT);
+  else
+   gsi_insert_before (gsi, ds, GSI_SAME_STMT);
+}
+
+  for (child = access->first_child; child; child = child->next_sibling)
+clobber_subtree (child, gsi, insert_after, loc);
+}
+
 /* Search for an access representative for the given expression EXPR and
return it or NULL if it cannot be found.  */
 
 static struct access *
 get_access_for_expr (tree expr)
 {
   HOST_WIDE_INT offset, size, max_size;
   tree base;
 
   /* FIXME: This should not be necessary but Ada produces V_C_Es with a type of
@@ -3039,43 +3077,41 @@ enum assignment_mod_result { SRA_AM_NONE
 SRA_AM_REMOVED };  /* stmt eliminated */
 
 /* Modify assignments with a CONSTRUCTOR on their RHS.  STMT contains a pointer
to the assignment and GSI is the statement iterator pointing at it.  Returns
the same values as sra_modify_assign.  */
 
 static enum assignment_mod_result
 sra_modify_constructor_assign (gimple *stmt, gimple_stmt_iterator *gsi)
 {
   tree lhs = gimple_assign_lhs (*stmt);
-  struct access *acc;
-  location_t loc;
-
-  acc = get_access_for_expr (lhs);
+  struct access *acc = get_access_for_expr (lhs);
   if (!acc)
 return SRA_AM_NONE;
+  location_t loc = gimple_location (*stmt);
 
   if (gimple_clobber_p (*stmt))
 {
-  /* Remove clobbers of fully scalarized variables, otherwise
-do nothing.  */
+  /* Clobber the replacement variable.  */
+  clobber_subtree (acc, gsi, !acc->grp_covered, loc);
+  /* Remove clobbers of fully scalarized variables, they are dead.  */
   if (acc->grp_covered)
{
  unlink_stmt_vdef (*stmt);
  gsi_remove (gsi, true);
  release_defs (*stmt);
  return SRA_AM_REMOVED;
}
   else
-   return SRA_AM_NONE;
+   return SRA_AM_MODIFIED;
 }
 
-  loc = gimple_location (*stmt);
   if (vec_safe_length (CONSTRUCTOR_ELTS (gimple_assign_rhs1 (*stmt))) > 0)
 {
   /* I have never seen this code path trigger but if it can happen the
 following should handle it gracefully.  */
   if (access_has_children_p (acc))
generate_subtree_copies (acc->first_child, lhs, acc->offset, 0, 0, gsi,
 true, true, loc);
   return SRA_AM_MODIFIED;
 }
 
Index: gcc/testsuite/g++.dg/tree-ssa/pr60517.C
===
--- gcc/testsuite/g++.dg/tree-ssa/pr60517.C (revision 0)
+++ gcc/testsu

Re: [PATCH] gcc/c/c-decl.c: Let NEWDECL dereference shared data to fix segment fault issue.

[Chen Gang]

On 06/30/2014 05:23 AM, Joseph S. Myers wrote:
> On Sun, 29 Jun 2014, Jan Hubicka wrote:
> 
>> So Cheng is right we need to clear DECL_STRUCT_FUNCTION or we end up 
>> ggc_freeing it that later ICEs in push_cfun.  We do not need to clear 
>> the other fields.
> 
> Thanks for the explanation.  This patch is OK with the typo fixes Marek 
> has noted.
> 

Thank you very much for all of your work!

And I shall continue to find and try to solve other gcc issues, hope I
can provide a patch per month.


Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

[PATCH, rs6000, testsuite] Skip gfortran.dg/round_4.f90 for PowerPC Linux

[Bill Schmidt]

Hi,

The test in gfortran.dg/round_4.f90, introduced in GCC 4.9, checks for
correct behavior of different rounding modes.  However, for
quad-precision floating-point, it requires that the number
0.100481 be exactly represented.  Since
the PowerPC long double implementation (double-double) only guarantees
31 bits of precision, the test fails for the real(qp) portions of the
test.  Thus this patch marks the test invalid for PowerPC Linux for now.
(We may want to also do this for other subtargets; let me know if so.)

At such time as IEEE 128-bit floating-point is supported by the PowerPC
port, we should revisit this.

Is this ok for trunk and 4.9?

Thanks,
Bill


2014-06-29  Bill Schmidt  

* gfortran.dg/round_4.f90: Skip for powerpc*-*-linux* since the
test requires greater precision than the current PowerPC long
double implementation supports.


Index: gcc/testsuite/gfortran.dg/round_4.f90
===
--- gcc/testsuite/gfortran.dg/round_4.f90   (revision 212074)
+++ gcc/testsuite/gfortran.dg/round_4.f90   (working copy)
@@ -1,6 +1,7 @@
 ! { dg-do run }
 ! { dg-add-options ieee }
 ! { dg-skip-if "PR libfortran/58015" { hppa*-*-hpux* } }
+! { dg-skip-if "IBM long double 31 bits of precision, test requires 38" { 
powerpc*-*-linux* } }
 !
 ! PR fortran/35862
 !

RE: [PATCH] Fix PR61306: improve handling of sign and cast in bswap

[Thomas Preud'homme]

> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Friday, June 27, 2014 4:49 PM
> 
> FIne with me now.

Commited.

Best regards,

Thomas

[Committed] [PATCH, loop2_invariant, 1/2] Check only one register class

[Zhenqiang Chen]

On 26 June 2014 05:30, Jeff Law  wrote:
> On 06/11/14 04:05, Zhenqiang Chen wrote:
>>
>> On 10 June 2014 19:06, Steven Bosscher  wrote:
>>>
>>> On Tue, Jun 10, 2014 at 11:22 AM, Zhenqiang Chen wrote:

 Hi,

 For loop2-invariant pass, when flag_ira_loop_pressure is enabled,
 function gain_for_invariant checks the pressures of all register
 classes. This does not make sense since one invariant might impact
 only one register class.

 The patch enhances functions get_inv_cost and gain_for_invariant to
 check only the register pressure of the invariant if possible.
>>>
>>>
>>> This patch may work for targets with more-or-less orthogonal reg
>>> classes, but not if there is a lot of overlap between reg classes.
>>
>>
>> Yes. I need check the overlap between reg classes.
>>
>> Patch is updated to check all overlap reg classes by
>> reg_classes_intersect_p:
>
> So you need a new ChangeLog, of course :-)
>
>
>
>>
>> diff --git a/gcc/loop-invariant.c b/gcc/loop-invariant.c
>> index c76a2a0..6e43b49 100644
>> --- a/gcc/loop-invariant.c
>> +++ b/gcc/loop-invariant.c
>> @@ -1092,16 +1092,22 @@ get_pressure_class_and_nregs (rtx insn, int
>> *nregs)
>>   }
>>
>>   /* Calculates cost and number of registers needed for moving invariant
>> INV
>> -   out of the loop and stores them to *COST and *REGS_NEEDED.  */
>> +   out of the loop and stores them to *COST and *REGS_NEEDED.  *CL will
>> be
>> +   the REG_CLASS of INV.  Return
>> + 0: if INV is invalid.
>> + 1: if INV and its depends_on have same reg_class
>> +   > 1: if INV and its depends_on have different reg_classes.  */
>
> Nit/bikeshedding.  I tend to prefer < 0, 0, > 0 (or -1, 0, 1) for
> tri-states.  It's not a big deal though.

Thanks! Update the tri-state values to ( -1, 0, 1).

>
>>check_p = i < ira_pressure_classes_num;
>> +
>> + if ((dep_ret > 1) || ((dep_ret == 1) && (*cl != dep_cl)))
>> +   {
>> + *cl = ALL_REGS;
>> + ret ++;
>
> Whitespace nit -- no space in this statement.  use "ret++;"
>
> You should add a testcase if at all possible.  Perhaps two, one which runs
> on an ARM variant and one for x86_64.  The former because that's obviously
> what Linaro cares about, the latter for wider testing.
>
>
> Definitely add a ChangeLog entry, fix the whitespace nit & add testcase.  OK
> with those fixes.   Your choice on the tri-state values.

Updated with a testcase for X86-64 and committed @212135.

ChangeLog:
2014-06-30  Zhenqiang Chen  

* loop-invariant.c (get_inv_cost): Handle register class.
(gain_for_invariant): Check the register pressure of the inv
and its overlapped register class, other than all.

testsuite/ChangeLog:
2014-06-30  Zhenqiang Chen  

* ira-loop-pressure.c: New test.
diff --git a/gcc/loop-invariant.c b/gcc/loop-invariant.c
index 25e63e4..ef5c59b 100644
--- a/gcc/loop-invariant.c
+++ b/gcc/loop-invariant.c
@@ -1090,16 +1090,22 @@ get_pressure_class_and_nregs (rtx insn, int *nregs)
 }

 /* Calculates cost and number of registers needed for moving invariant INV
-   out of the loop and stores them to *COST and *REGS_NEEDED.  */
+   out of the loop and stores them to *COST and *REGS_NEEDED.  *CL will be
+   the REG_CLASS of INV.  Return
+ -1: if INV is invalid.
+  0: if INV and its depends_on have same reg_class
+  1: if INV and its depends_on have different reg_classes.  */

-static void
-get_inv_cost (struct invariant *inv, int *comp_cost, unsigned *regs_needed)
+static int
+get_inv_cost (struct invariant *inv, int *comp_cost, unsigned *regs_needed,
+ enum reg_class *cl)
 {
   int i, acomp_cost;
   unsigned aregs_needed[N_REG_CLASSES];
   unsigned depno;
   struct invariant *dep;
   bitmap_iterator bi;
+  int ret = 1;

   /* Find the representative of the class of the equivalent invariants.  */
   inv = invariants[inv->eqto];
@@ -1115,7 +1121,7 @@ get_inv_cost (struct invariant *inv, int
*comp_cost, unsigned *regs_needed)

   if (inv->move
   || inv->stamp == actual_stamp)
-return;
+return -1;
   inv->stamp = actual_stamp;

   if (! flag_ira_loop_pressure)
@@ -1127,6 +1133,8 @@ get_inv_cost (struct invariant *inv, int
*comp_cost, unsigned *regs_needed)

   pressure_class = get_pressure_class_and_nregs (inv->insn, &nregs);
   regs_needed[pressure_class] += nregs;
+  *cl = pressure_class;
+  ret = 0;
 }

   if (!inv->cheap_address
@@ -1167,6 +1175,8 @@ get_inv_cost (struct invariant *inv, int
*comp_cost, unsigned *regs_needed)
   EXECUTE_IF_SET_IN_BITMAP (inv->depends_on, 0, depno, bi)
 {
   bool check_p;
+  enum reg_class dep_cl = ALL_REGS;
+  int dep_ret;

   dep = invariants[depno];

@@ -1174,7 +1184,7 @@ get_inv_cost (struct invariant *inv, int
*comp_cost, unsigned *regs_needed)
   if (dep->move)
continue;

-  get_inv_cost (dep, &acomp_cost, aregs_needed);
+  dep_ret = get_inv_cost (dep, &acomp_cost, aregs_needed, 

Re: [PATCH] Pass correct memory attributes for build constant

[Kito Cheng]

>>test.c:
>>extern bar(unsigned char p[3][2]);
>>void foo(int i)
>>{
>> unsigned char data[3][2] = {{1,1}, {1,0}, {1,1}};
>>
>> bar(data);
>>}
> First, note, I'm not an ARM expert.  However, the first question I
> have is are we sure the initializer is always going to be suitably
> aligned?   What guarantees this initializer is going to have 32 bit

It's a ARRAY_TYPE for the data and ARM require 32-bit align for that.
(Aligned by DATA_ALIGNMENT as Jan say.)

> I think that needs to be settled first, then we need to verify that
> the trees are correctly carrying that alignment requirement around
> and that the code uses it appropriately (and I have my doubts
> because EXP is a CONSTRUCTOR element and those seem to be largely
> ignored in the code we're looking to change).

The key problem is `exp` don't have right alignment info, but `decl` have,
 we can observe this in the code:

varasm.c
3166   /* Construct the VAR_DECL associated with the constant.  */
3167   decl = build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifier (label),
3168  TREE_TYPE (exp));
3169   DECL_ARTIFICIAL (decl) = 1;
3170   DECL_IGNORED_P (decl) = 1;
3171   TREE_READONLY (decl) = 1;
3172   TREE_STATIC (decl) = 1;
3173   TREE_ADDRESSABLE (decl) = 1;
...
3181   if (TREE_CODE (exp) == STRING_CST)
3182 {
3183 #ifdef CONSTANT_ALIGNMENT
3184   DECL_ALIGN (decl) = CONSTANT_ALIGNMENT (exp, DECL_ALIGN (decl));
3185 #endif
3186 }
3187   else
3188 align_variable (decl, 0);

`decl` get alignment info here but `exp` doesn't.

...
3203   rtl = gen_const_mem (TYPE_MODE (TREE_TYPE (exp)), symbol);
3204   set_mem_attributes (rtl, exp, 1);
but here, we use `exp` to set memory attribute for MEM rtl.

> I would also strongly recommend turning your testcase into something
> we can add to the testsuite.
>
> If you look in gcc/testsuite/gcc.target/arm you'll see several
> examples.  I think you just want to compile this down to assembly
> code with the optimizer enabled, then verify there is no call to
> memcpy in the resulting output.  20030909-1.c would seem to be a
> reasonable example of a test that does something similar.

Hmmm, it's not target dependent problem, but this problem only can
observe by some target since not every target use MEM_ALIGN info for code gen,
the most common case is movmem pattern, they use alignment info to
decide expand or not.

So I am not sure is does it reasonable to make a testcase for target?

[tree-optimization/61607] Look through SSA_NAME_VALUE chains

[Jeff Law]

SSA_NAME_VALUE is, in effect, a chain of values.  ie, it's possible for 
SSA_NAME_VALUE of any given SSA_NAME to refer to another SSA_NAME.  In 
many cases it is advantageous to look deeper into those chains, 
particularly when simplifying conditionals for jump threading.


The problem with simply following the chains, is they can have loops. 
This can occur when we're threading across a loop backedge.


I did some fairly simple experiments which showed that chains of 0, or 1 
element are by far the most common.  chains of 2 elements are rare, but 
do occur in practice (such as pr61607).  Chains of > 2 elements 
consistently have loops.


So this patch just looks up to two elements deep in the chain and avoids 
the complication of explicitly looking for loops.  This allows us to 
pick up the obvious equivalency in pr61607 and gets the jumps outside 
the loop fully threaded.


Bootstrapped and regression tested on x86_64-unknown-linux-gnu. 
Installed on the trunk.






commit 3e2754da946eb64d7a1d30548c9b6119cda3a014
Author: Jeff Law 
Date:   Sun Jun 29 23:35:50 2014 -0600

tree-optimization/61607
* tree-ssa-threadedge.c (simplify_control_stmt_condition): Look
deeper into the SSA_NAME_VALUE chain.

tree-optimization/61607
* gcc.dg/tree-ssa/pr61607.c: New test.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 4cc167a..6dfe1d3 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2014-06-30  Jeff Law  
+
+   tree-optimization/61607
+   * tree-ssa-threadedge.c (simplify_control_stmt_condition): Look
+   deeper into the SSA_NAME_VALUE chain.
+
 2014-06-30  Zhenqiang Chen  
 
* loop-invariant.c (get_inv_cost): Handle register class.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 5a9d73a..1df9d4e 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2014-06-30  Jeff Law  
+
+   tree-optimization/61607
+   * gcc.dg/tree-ssa/pr61607.c: New test.
+
 2014-06-30  Zhenqiang Chen  
 
* ira-loop-pressure.c: New test.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr61607.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr61607.c
new file mode 100644
index 000..ec00f51
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr61607.c
@@ -0,0 +1,29 @@
+/* { dg-do compile } */
+/* { dg-options "-Os -fno-tree-fre -fdump-tree-dom1" } */
+
+void foo(int *);
+void f2(int dst[3], int R)
+{
+  int i, inter[2];
+  _Bool inter0p = 0;
+  _Bool inter1p = 0;
+  for (i = 1; i < R; i++)
+{
+  inter0p = 1;
+  inter1p = 1;
+}
+  if (inter0p)
+inter[0] = 1;
+  if (inter1p)
+inter[1] = 1;
+  foo(inter);
+}
+
+
+/* There should be precisely two conditionals.  One for the loop condition
+   and one for the test after the loop.  Previously we failed to eliminate
+   the second conditional after the loop.  */
+/* { dg-final { scan-tree-dump-times "if" 2 "dom1"} } */
+ 
+/* { dg-final { cleanup-tree-dump "dom1" } } */
+
diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index a76a7ce..9807b42 100644
--- a/gcc/tree-ssa-threadedge.c
+++ b/gcc/tree-ssa-threadedge.c
@@ -542,16 +542,26 @@ simplify_control_stmt_condition (edge e,
   /* Get the current value of both operands.  */
   if (TREE_CODE (op0) == SSA_NAME)
{
-  tree tmp = SSA_NAME_VALUE (op0);
- if (tmp)
-   op0 = tmp;
+ for (int i = 0; i < 2; i++)
+   {
+ if (TREE_CODE (op0) == SSA_NAME
+ && SSA_NAME_VALUE (op0))
+   op0 = SSA_NAME_VALUE (op0);
+ else
+   break;
+   }
}
 
   if (TREE_CODE (op1) == SSA_NAME)
{
- tree tmp = SSA_NAME_VALUE (op1);
- if (tmp)
-   op1 = tmp;
+ for (int i = 0; i < 2; i++)
+   {
+ if (TREE_CODE (op1) == SSA_NAME
+ && SSA_NAME_VALUE (op1))
+   op1 = SSA_NAME_VALUE (op1);
+ else
+   break;
+   }
}
 
   if (handle_dominating_asserts)
@@ -625,10 +635,17 @@ simplify_control_stmt_condition (edge e,
 It is possible to get loops in the SSA_NAME_VALUE chains
 (consider threading the backedge of a loop where we have
 a loop invariant SSA_NAME used in the condition.  */
-  if (cached_lhs
- && TREE_CODE (cached_lhs) == SSA_NAME
- && SSA_NAME_VALUE (cached_lhs))
-   cached_lhs = SSA_NAME_VALUE (cached_lhs);
+  if (cached_lhs)
+   {
+ for (int i = 0; i < 2; i++)
+   {
+ if (TREE_CODE (cached_lhs) == SSA_NAME
+ && SSA_NAME_VALUE (cached_lhs))
+   cached_lhs = SSA_NAME_VALUE (cached_lhs);
+ else
+   break;
+   }
+   }
 
   /* If we're dominated by a suitable ASSERT_EXPR, then
 update CACHED_LHS appropriately.  */