[Bug debug/66301] internal compiler error when using -fopt-info

[singhai at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66301

Sharad Singhai  changed:

   What|Removed |Added

 CC||singhai at gcc dot gnu.org

--- Comment #5 from Sharad Singhai  ---
Sorry, I didn't get time to look at this. Yes, this is the right fix in the
interim as old and new style of dumping cannot be mixed.

Another fix would require converting this and other passes to the new style.

[Bug testsuite/66497] FAIL: g++.dg/abi/aarch64_guard1.C

[singhai at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66497

Sharad Singhai  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Sharad Singhai  ---
Already fixed at r224313.

[Bug testsuite/66497] New: FAIL: g++.dg/abi/aarch64_guard1.C

[singhai at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66497

Bug ID: 66497
   Summary: FAIL: g++.dg/abi/aarch64_guard1.C
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: singhai at gcc dot gnu.org
  Target Milestone: ---

This is a bug which requires testcase update after r224118.

The failure is like this:

FAIL: g++.dg/abi/aarch64_guard1.C  -std=gnu++11  scan-tree-dump original
"_ZGVZ3foovE1x & 1"


The passing testcase at r224117 had the following
aarch64_guard1.C.003t.original: (r224117)
  if ((_ZGVZ3foovE1x & 1) == 0)


but at r224118 an atomic acquiring load (type 2) is done instead (as below)
which causes the pattern match to fail.

aarch64_guard1.C.003t.original: (r224118)
  if (<>)

[Bug target/66200] GCC for ARM / AArch64 doesn't define TARGET_RELAXED_ORDERING

[singhai at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66200

--- Comment #4 from Sharad Singhai  ---
Author: singhai
Date: Tue Jun  9 06:45:43 2015
New Revision: 224265

URL: https://gcc.gnu.org/viewcvs?rev=224265&root=gcc&view=rev
Log:
Backport r224118 from trunk for Google ref b/20542176 and b/20766120.

Remove TARGET_RELAXED_ORDERING and optimize for weak memory models.


This patch removes the special casing for targets with relaxed
memory ordering and handles guard accesses with equivalent
atomic load acquire operations. In this process we change the
algorithm to load the guard variable with an atomic load that
has ACQUIRE semantics.

This then means that on targets which have weak memory models, the
fast path is inlined and can directly use a load-acquire instruction
where available (and yay! one more hook gone).

2015-06-04  Ramana Radhakrishnan  

PR c++/66192
PR target/66200
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGET_RELAXED_ORDERING): Delete.
* target.def (TARGET_RELAXED_ORDERING): Likewise.
* config/alpha/alpha.c (TARGET_RELAXED_ORDERING): Likewise.
* config/ia64/ia64.c (TARGET_RELAXED_ORDERING): Likewise.
* config/rs6000/rs6000.c (TARGET_RELAXED_ORDERING): Likewise.
* config/sparc/linux.h (SPARC_RELAXED_ORDERING): Likewise.
* config/sparc/linux64.h (SPARC_RELAXED_ORDERING): Likewise.
* config/sparc/sparc.c (TARGET_RELAXED_ORDERING): Likewise.
* config/sparc/sparc.h (SPARC_RELAXED_ORDERING): Likewise.
* system.h (TARGET_RELAXED_ORDERING): Poison.

2015-06-04  Ramana Radhakrishnan  

PR c++/66192
PR target/66200
* cp-tree.h (get_guard_cond): Adjust declaration
* decl.c (expand_static_init): Use atomic load acquire
and adjust call to get_guard_cond.
* decl2.c (build_atomic_load_byte): New function.
(get_guard_cond): Handle thread_safety.
(one_static_initialization_or_destruction): Adjust call to
get_guard_cond.

Modified:
branches/google/gcc-4_9/gcc/config/alpha/alpha.c
branches/google/gcc-4_9/gcc/config/ia64/ia64.c
branches/google/gcc-4_9/gcc/config/rs6000/rs6000.c
branches/google/gcc-4_9/gcc/config/sparc/linux.h
branches/google/gcc-4_9/gcc/config/sparc/linux64.h
branches/google/gcc-4_9/gcc/config/sparc/sparc.c
branches/google/gcc-4_9/gcc/config/sparc/sparc.h
branches/google/gcc-4_9/gcc/cp/cp-tree.h
branches/google/gcc-4_9/gcc/cp/decl.c
branches/google/gcc-4_9/gcc/cp/decl2.c
branches/google/gcc-4_9/gcc/doc/tm.texi
branches/google/gcc-4_9/gcc/doc/tm.texi.in
branches/google/gcc-4_9/gcc/system.h
branches/google/gcc-4_9/gcc/target.def

[Bug c++/66192] C++ static initializer unnecessary __cxa_guard_acquire for TARGET_RELAXED_ORDERING

[singhai at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66192

--- Comment #3 from Sharad Singhai  ---
Author: singhai
Date: Tue Jun  9 06:45:43 2015
New Revision: 224265

URL: https://gcc.gnu.org/viewcvs?rev=224265&root=gcc&view=rev
Log:
Backport r224118 from trunk for Google ref b/20542176 and b/20766120.

Remove TARGET_RELAXED_ORDERING and optimize for weak memory models.


This patch removes the special casing for targets with relaxed
memory ordering and handles guard accesses with equivalent
atomic load acquire operations. In this process we change the
algorithm to load the guard variable with an atomic load that
has ACQUIRE semantics.

This then means that on targets which have weak memory models, the
fast path is inlined and can directly use a load-acquire instruction
where available (and yay! one more hook gone).

2015-06-04  Ramana Radhakrishnan  

PR c++/66192
PR target/66200
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (TARGET_RELAXED_ORDERING): Delete.
* target.def (TARGET_RELAXED_ORDERING): Likewise.
* config/alpha/alpha.c (TARGET_RELAXED_ORDERING): Likewise.
* config/ia64/ia64.c (TARGET_RELAXED_ORDERING): Likewise.
* config/rs6000/rs6000.c (TARGET_RELAXED_ORDERING): Likewise.
* config/sparc/linux.h (SPARC_RELAXED_ORDERING): Likewise.
* config/sparc/linux64.h (SPARC_RELAXED_ORDERING): Likewise.
* config/sparc/sparc.c (TARGET_RELAXED_ORDERING): Likewise.
* config/sparc/sparc.h (SPARC_RELAXED_ORDERING): Likewise.
* system.h (TARGET_RELAXED_ORDERING): Poison.

2015-06-04  Ramana Radhakrishnan  

PR c++/66192
PR target/66200
* cp-tree.h (get_guard_cond): Adjust declaration
* decl.c (expand_static_init): Use atomic load acquire
and adjust call to get_guard_cond.
* decl2.c (build_atomic_load_byte): New function.
(get_guard_cond): Handle thread_safety.
(one_static_initialization_or_destruction): Adjust call to
get_guard_cond.

Modified:
branches/google/gcc-4_9/gcc/config/alpha/alpha.c
branches/google/gcc-4_9/gcc/config/ia64/ia64.c
branches/google/gcc-4_9/gcc/config/rs6000/rs6000.c
branches/google/gcc-4_9/gcc/config/sparc/linux.h
branches/google/gcc-4_9/gcc/config/sparc/linux64.h
branches/google/gcc-4_9/gcc/config/sparc/sparc.c
branches/google/gcc-4_9/gcc/config/sparc/sparc.h
branches/google/gcc-4_9/gcc/cp/cp-tree.h
branches/google/gcc-4_9/gcc/cp/decl.c
branches/google/gcc-4_9/gcc/cp/decl2.c
branches/google/gcc-4_9/gcc/doc/tm.texi
branches/google/gcc-4_9/gcc/doc/tm.texi.in
branches/google/gcc-4_9/gcc/system.h
branches/google/gcc-4_9/gcc/target.def

[Bug middle-end/58134] [4.8/4.9 Regression] -ftree-vectorizer-verbose= shows vectorized loops only for N== 1 and N >2 but not for N==2

[singhai at gcc dot gnu.org]

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

Sharad Singhai  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Sharad Singhai  ---
I have removed this deprecated option in r204244, hence marking it fixed.

[Bug middle-end/58134] [4.8/4.9 Regression] -ftree-vectorizer-verbose= shows vectorized loops only for N== 1 and N >2 but not for N==2

[singhai at gcc dot gnu.org]

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

--- Comment #6 from Sharad Singhai  ---
Author: singhai
Date: Thu Oct 31 01:01:40 2013
New Revision: 204244

URL: http://gcc.gnu.org/viewcvs?rev=204244&root=gcc&view=rev
Log:
2013-10-30  Sharad Singhai  

PR middle-end/58134
* opts.c (common_handle_option): Remove deprecated option
-ftree-vectorizer-verbose.
* doc/invoke.texi (Debugging Options): Ditto.
* opts-global.c (handle_common_deferred_options): Ditto.
(dump_remap_tree_vectorizer_verbose): Delete.
* common.opt: Set -ftree-vectorizer-verbose as an ignored option.

ada/ChangeLog
* gnat_ugn.texi: Remove option description for PR middle-end/58134.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gnat_ugn.texi
trunk/gcc/common.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/opts-global.c
trunk/gcc/opts.c

[Bug middle-end/58134] [4.8/4.9 Regression] -ftree-vectorizer-verbose= shows vectorized loops only for N== 1 and N >2 but not for N==2

[singhai at gcc dot gnu.org]

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

--- Comment #4 from Sharad Singhai  ---
I think perhaps it would be better if I remove this deprecated option
-ftree-vectorizer-verbose= completely. It is confusing in its current form and
the equivalent functionality is already available via -fopt-info-xxx option.

Any opinions?

Thanks,
Sharad

[Bug middle-end/58134] [4.8/4.9 Regression] -ftree-vectorizer-verbose= shows vectroiyed loops only for N== 1 and N >2 but not for N==2

[singhai at gcc dot gnu.org]

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

--- Comment #3 from Sharad Singhai  ---
I think this is the intended behavior. While working on the new dump
infrastructure, I modified the behavior of -ftree-vectorizer-verbose.

Thus right now
-ftree-vectorizer-verbose=1 : dump info about optimized loops
...=2 : dump info about missed loops
...>2 : dump info about optimized _and_ missed loops

Thus at 3 and greater, you are again seeing info available at 1. But really,
only 1 and 2 are meaningful. Anything higher is a combination of these two
kinds of information. This was a way to preserve compatibility with old
scripts, while deprecating this flag. I didn't see any tests relying on the old
behavior.

Here is the current documentation about this flag in gcc.info:

`-ftree-vectorizer-verbose=N'
 This option is deprecated and is implemented in terms of
 `-fopt-info'. Please use `-fopt-info-KIND' form instead, where
 KIND is one of the valid opt-info options. It prints additional
 optimization information.  For N=0 no diagnostic information is
 reported.  If N=1 the vectorizer reports each loop that got
 vectorized, and the total number of loops that got vectorized.  If
 N=2 the vectorizer reports locations which could not be vectorized
 and the reasons for those. For any higher verbosity levels all the
 analysis and transformation information from the vectorizer is
 reported.

[Bug c++/57850] Option -fdump-translation-unit not working

[singhai at gcc dot gnu.org]

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

--- Comment #7 from Sharad Singhai  ---
I looked at it and this issue seems related to handling of PCH files. The
following patch introduced it

http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/cp/decl2.c?r1=194363&r2=194362&pathrev=194363

When only a header file is being compiled then cp_write_global_declarations ()
returns immediately without doing any extra work. Thus dump code (and
everything else) is skipped.

I don't know what should be the right course of action here. If it is only the
dump functionality that needs to be restored, I can perhaps work around with
some restructuring. However, there is a lot of other processing which should be
skipped in case of PCH. Suggestions?

Thanks,
Sharad

[Bug tree-optimization/55995] vect increase_alignment notes missing from dump file

[singhai at gcc dot gnu.org]

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



Sharad Singhai  changed:



   What|Removed |Added



 Status|ASSIGNED|RESOLVED

 Resolution||FIXED



--- Comment #5 from Sharad Singhai  2013-01-19 
01:24:43 UTC ---

Should be fixed in r195303.

[Bug tree-optimization/55995] vect increase_alignment notes missing from dump file

[singhai at gcc dot gnu.org]

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



--- Comment #4 from Sharad Singhai  2013-01-18 
18:26:17 UTC ---

Author: singhai

Date: Fri Jan 18 18:26:04 2013

New Revision: 195303



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195303

Log:

2013-01-18  Sharad Singhai  



PR tree-optimization/55995

* dumpfile.c (dump_loc): Print location only if available.

* tree-vectorizer.c (increase_alignment): Intialize vect_location.



testsuite/ChangeLog

PR tree-optimization/55995

* gcc.dg/vect/vect.exp: Use "details" flags for dump info.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/dumpfile.c

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.dg/vect/vect.exp

trunk/gcc/tree-vectorizer.c

[Bug tree-optimization/55995] vect increase_alignment notes missing from dump file

[singhai at gcc dot gnu.org]

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



Sharad Singhai  changed:



   What|Removed |Added



 Status|WAITING |ASSIGNED

 AssignedTo|unassigned at gcc dot   |singhai at gcc dot gnu.org

   |gnu.org |



--- Comment #3 from Sharad Singhai  2013-01-16 
17:03:26 UTC ---

Hmm, it looks like it is trying to output a source location where none exists.

This is clearly a bug. I would look at it.



Thanks,

Sharad

[Bug other/55164] [4.8 Regression] -fdump-*-all not working

[singhai at gcc dot gnu.org]

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



Sharad Singhai  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #3 from Sharad Singhai  2012-11-01 
18:05:53 UTC ---

This should be fixed now at r193064.

[Bug other/55164] [4.8 Regression] -fdump-*-all not working

[singhai at gcc dot gnu.org]

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



--- Comment #2 from Sharad Singhai  2012-11-01 
17:55:46 UTC ---

Author: singhai

Date: Thu Nov  1 17:55:23 2012

New Revision: 193064



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193064

Log:

2012-11-01  Sharad Singhai  



PR other/55164

* dumpfile.h (struct dump_file_info): Fix order of flags.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/dumpfile.h

[Bug testsuite/54772] vectorization broken in gfortran on x86_64-*-freebsd

[singhai at gcc dot gnu.org]

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



Sharad Singhai  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||FIXED

 AssignedTo|unassigned at gcc dot   |singhai at gcc dot gnu.org

   |gnu.org |



--- Comment #4 from Sharad Singhai  2012-10-02 
17:25:46 UTC ---

Should be fixed with r191991.

[Bug testsuite/54772] vectorization broken in gfortran on x86_64-*-freebsd

[singhai at gcc dot gnu.org]

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



--- Comment #3 from Sharad Singhai  2012-10-02 
17:19:14 UTC ---

Author: singhai

Date: Tue Oct  2 17:19:09 2012

New Revision: 191991



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191991

Log:

2012-10-02  Sharad Singhai  



PR testsuite/54772

* tree-vect-stmts.c (vectorizable_operation): Add missing return.



testsuite/ChangeLog

2012-10-02  Sharad Singhai  



PR testsuite/54772

* gfortran.dg/vect/vect.exp: Change verbose vectorizor dump options

to fix test failures caused by r191883.

* gcc.dg/tree-ssa/gen-vect-11.c: Likewise.

* gcc.dg/tree-ssa/gen-vect-2.c: Likewise.

* gcc.dg/tree-ssa/gen-vect-32.c: Likewise.

* gcc.dg/tree-ssa/gen-vect-25.c: Likewise.

* gcc.dg/tree-ssa/gen-vect-11a.c: Likewise.

* gcc.dg/tree-ssa/gen-vect-26.c: Likewise.

* gcc.dg/tree-ssa/gen-vect-11b.c: Likewise.

* gcc.dg/tree-ssa/gen-vect-11c.c: Likewise.

* gcc.dg/tree-ssa/gen-vect-28.c: Likewise.



Modified:

trunk/gcc/ChangeLog

trunk/gcc/testsuite/ChangeLog

trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11a.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11b.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11c.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c

trunk/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-32.c

trunk/gcc/testsuite/gfortran.dg/vect/vect.exp

trunk/gcc/tree-vect-stmts.c

[Bug gcov-profile/45890] Coverage may be weakened by r164986

[singhai at gcc dot gnu.org]

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

--- Comment #2 from Sharad Singhai  2011-10-01 
19:42:48 UTC ---
I don't know if it is related. But the coverage is imprecise in case of
attached source file foo.c. Build it with O2, as 

gcc --coverage -O2 foo.c
./a.out
gcov -b foo.c

Now the coverage data for the 'if' condition in 'sum' looks like this:
(in attached file foo.c.gcov)

   8:8:if (v[i]) total += 1;
branch  0 never executed
branch  1 never executed
branch  2 taken 75% (fallthrough)
branch  3 taken 25%

Thus a simple two-way conditional looks like a four-way branch. It is due to
early inlining of 'sum' into 'main where a couple of bb's get eliminated/merged
so  that the branch coverage incorrectly gets attributed to the conditional.
Similarly the coverage data for the for-loop in 'sum' looks like this

   9:7:  for (i = 0; i < N; ++i) {
branch  0 never executed
branch  1 never executed
branch  2 taken 89%
branch  3 taken 11% (fallthrough)

After disabling early inlining, the coverage data looks saner. (Attached in
foo.c.gcov.no-early-inlining.)

gcc --coverage -O2 -fno-early-inlining foo.c
./a.out
gcov -b foo.c

Adding the following patch mitigates the issue.

2011-09-30   Sharad Singhai  

   * gcc.c (cc1_options): Added -fno-early-inlining for coverage.

Index: gcc.c
===
--- gcc.c   (revision 179402)
+++ gcc.c   (working copy)
@@ -776,7 +776,7 @@
 %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}}\
 %{fsyntax-only:-o %j} %{-param*}\
 %{fmudflap|fmudflapth:-fno-builtin -fno-merge-constants}\
- %{coverage:-fprofile-arcs -ftest-coverage}";
+ %{coverage:-fprofile-arcs -ftest-coverage -fno-early-inlining}";

 /* If an assembler wrapper is used to invoke post-assembly tools
   like MAO, --save-temps need to be passed to save the output of

[Bug gcov-profile/45890] Coverage may be weakened by r164986

[singhai at gcc dot gnu.org]

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

--- Comment #1 from Sharad Singhai  2011-10-01 
19:39:32 UTC ---
Created attachment 25392
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25392
tar of source and coverage files