[Bug middle-end/53082] local malloc/free optimization

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #2 from Marc Glisse  2012-04-23 
07:11:14 UTC ---
(In reply to comment #1)
> Dup of an older bug 19831.

The second part (coalescing mallocs and/or replacing them with alloca) doesn't
look like a dup of 19831.

[Bug c/53083] New: gcc bug in moving from the SSE registers back onto the heap.

[da_fox at mad dot scientist.com]

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

 Bug #: 53083
   Summary: gcc bug in moving from the SSE registers back onto the
heap.
Classification: Unclassified
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da_...@mad.scientist.com


After investigation of a suspected graphics-driver bug, it was found that the
issue lay with gcc. Please see
https://bugs.freedesktop.org/show_bug.cgi?id=47559 .

The problem as I understand is that gcc-4.6.0 miscompiles miarc.c from the
xorg-server package if -ftree-vectorize is enabled. This flag is enabled with
-O3.

The following minimal set of CFLAGS worked:
"-g -O2"

Adding the -ftree-vectorize separately, "-g -O2 -ftree-vectorize", caused the
program to misbehave at runtime.

I am running gentoo, the default CFLAGS for my system are:
CFLAGS="-march=native -O3 -pipe -fomit-frame-pointer -fweb -ffast-math
-mtune=native -mfpmath=sse"
I don't know if these match exactly with what is passed by portage for
compiling GCC.

Software versions (gentoo package versions):
sys-devel/gcc-4.6.0 
x11-base/xorg-server-1.11.2-r2

My hardware is a Dell XPS 15 (L502x) laptop with a 'Intel(R) Core(TM) i7-2630QM
CPU @ 2.00GHz'

I additional information is required please let me know.

[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.

[ubizjak at gmail dot com]

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

--- Comment #1 from Uros Bizjak  2012-04-23 07:55:29 
UTC ---
(In reply to comment #0)

> I additional information is required please let me know.

Please provide all necessary information, as outlined in [1].

[1] http://gcc.gnu.org/bugs/#report

[Bug middle-end/53081] memcpy/memset loop recognition

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  2012-04-23 
08:18:42 UTC ---
Note that -ftree-loop-distribution for some weird reason only handles clearing,
but not initialization by arbitrary constants that are convertible to memset
(i.e. all bytes have the same constant stored, such as 0x0a0a0a0a etc.).

[Bug fortran/53077] suggestion to add the .f extension to the list of file extensions that trigger enabling of the preprocessor

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||burnus at gcc dot gnu.org

--- Comment #4 from Tobias Burnus  2012-04-23 
08:27:05 UTC ---
> Hmm... apparently the PGI compiler uses the same rule for enabling
> preprocessor with .f and .F extensions.

I think most compilers follow that pattern, which can be overridden by "-cpp"
and "-no-cpp", respectively.


> Then, if there's some important reason behind it (?)

Well, the C preprocessor is not part of the Fortran standard, thus, a compiler
can expect that no C preprocessing has to be done. (Though, most compilers do
support CPP preprocessing; there are some caveats with regards to newer CPP
features: The preprocessor has then to be aware of Fortran. Thus, many
compilers do not support the CPP of newer C standards.)

Side note: The Fortran 95 standard actually defines in Part 3 "Conditional
Compilation" (ISO/IEC 1539-3:1998), however, this Fortran-specific way was
never widely used and it is not implemented in any compiler (to my knowledge).
However, there exists a preprocessor "coco" (written in Fortran).


> perhaps at least the warning message could be improved by indicating that the
> preprocessor is off.

I concur.


Untested patch.

Remark: At some point, gfortran needs to follow GCC with regards to
-f(no-)diagnostics-show-caret. I now keep the "::" with -cpp but
the caret diagnostic without.

--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -1792,4 +1792,9 @@ preprocessor_line (gfc_char_t *c)
  bad_cpp_line:
-  gfc_warning_now ("%s:%d: Illegal preprocessor directive",
-  current_file->filename, current_file->line);
+  if (gfc_cpp_enabled ())
+gfc_warning_now ("%s:%d: Illegal preprocessor directive",
+current_file->filename, current_file->line);
+  else
+gfc_warning_now ("Ignoring preprocessor directive at %C. Used -cpp to ",
+"enable the C preprocessor");
+
   current_file->line++;(In reply to comment #2)

[Bug libstdc++/53080] tuple interface to std::array doesn't check bounds

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-23
Summary|std::array - std::get() and |tuple interface to
   |std::tuple_element is   |std::array doesn't check
   |nothing bounds check|bounds
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-04-23 
08:35:41 UTC ---
Testcase:

#include 
int main()
{
  typedef std::tuple_element<1, std::array> type;
  std::array a;
  std::get<1>(a);
}

[Bug middle-end/53032] [4.8 Regression] 447.dealII in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-04-23 
09:15:26 UTC ---
It might be a duplicate of PR53050.

[Bug middle-end/53047] [4.8 Regression] 482.sphinx3 in SPEC CPU 2006 miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-23
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2012-04-23 
09:16:35 UTC ---
I am pretty sure that it is sphinx3s fault.  Investigating.

[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Component|middle-end  |testsuite

--- Comment #4 from Richard Guenther  2012-04-23 
09:17:10 UTC ---
I belive those are likely out-of-bound accesses in the testcases.

[Bug middle-end/53073] [4.8 Regression] 464.h264ref in SPEC CPU 2006 miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

--- Comment #1 from Richard Guenther  2012-04-23 
09:20:37 UTC ---
Well, I'm sure it is h264refs fault.

[Bug c++/53078] [C++11] Wrong diagnostic "no return statement in function returning non-void" on lambdas

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #3 from Paolo Carlini  2012-04-23 
09:30:18 UTC ---
Ok (4_7-branch is also fine)

[Bug target/52451] gcc w/i387 float generates fucom rather than fcom for floating point comparsons

[bugdal at aerifal dot cx]

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

--- Comment #3 from Rich Felker  2012-04-23 09:37:45 
UTC ---
Compiling with the -mno-ieee-fp option fixes this bug. It seems like the
behavior of this option is reversed from the documentation; -mno-ieee-fp gives
IEEE conformant comparisons (raising exception on unordered) and -mieee-fp
gives non-conformant comparisons (silent on unordered)...

[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||chris at bubblescope dot
   ||net

--- Comment #5 from Paolo Carlini  2012-04-23 
09:37:08 UTC ---
Chris, can you have a look to the mem_check tests?

[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures

[chris at bubblescope dot net]

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

--- Comment #6 from Chris Jefferson  2012-04-23 
09:44:11 UTC ---
Yes, will check.

[Bug other/53065] ICE replace_reg_with_saved_mem, at caller-save.c:1125

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  2012-04-23 
09:56:24 UTC ---
Also confirmed with 4.8.0 from 2012-04-16 under i686-pc-linux-gnu.

[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures

[chris at bubblescope dot net]

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

--- Comment #7 from Chris Jefferson  2012-04-23 
09:57:12 UTC ---
While I haven't yet got a recent copy of gcc trunk compiled, it does indeed
look like an out-of-bounds error, but just a 'testsuite' problem.

At the top of both mem_check tests as a 'const int A[]' array with 29 elements,
which we read 30 elements of. If doesn't matter what the extra element is, we
just want an array of any 30 integers, which is why this hasn't caused problems
before.

[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2012-04-23 
09:58:38 UTC ---
Created attachment 27219
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27219
gcc48-pr52999.patch

This patch avoids the ICE when diagnosing the section conflict, but not sure
what to do to actually compile the testcase without errors.  What ld.so does is
not exactly kosher from GCC POV (it wants to put non-constant, writable
variables into a section that GCC assumes is for constant variables that need
relocations).

[Bug c/53060] Typo in build_binary_op for scalar-vector ops

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-23
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #3 from Richard Guenther  2012-04-23 
10:00:52 UTC ---
Mine.

[Bug c/53084] New: GCC cannot handle array initialization of string constant with point arithmetic properly

[ray_linn at hotmail dot com]

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

 Bug #: 53084
   Summary: GCC cannot handle array initialization of string
constant with point arithmetic properly
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ray_l...@hotmail.com


Consider the following code:

#include 
int main() {
static const char *const aa[] = {"foo"+1};
printf("aa[0] = %s\n",aa[0]);
return 0;
}

 works fine on GCC 4.5.2 and 4.6.1
C:\work>gcc --version
gcc (tdm-1) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


C:\work>gcc a.c -oa.exe

C:\work>a
aa[0] = oo


C:\work>gcc --version
gcc (tdm-1) 4.6.1
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


C:\work>gcc a.c -oa.exe

C:\work>a
aa[0] = oo

On GCC 4.7.0, it fails with segmentation fault.

C:\work>gcc --version
gcc (GCC) 4.7.0
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


C:\work>gcc a.c -oa.exe

C:\work>a

(error dialog)


Please go there to find the original bug threads: 
http://bugs.ruby-lang.org/issues/6333

[Bug tree-optimization/52891] [4.8 Regression] ICE in adjust_bool_pattern

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-04-23 
10:13:46 UTC ---
Author: jakub
Date: Mon Apr 23 10:13:39 2012
New Revision: 186694

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186694
Log:
PR tree-optimizations/52891
* tree-vect-patterns.c (adjust_bool_pattern): Use
build_nonstandard_type even if rhs1 has unsigned INTEGER_TYPE,
but with non-standard precision.

* gcc.c-torture/compile/pr52891-1.c: New test.
* gcc.c-torture/compile/pr52891-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr52891-1.c
trunk/gcc/testsuite/gcc.c-torture/compile/pr52891-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-patterns.c

[Bug tree-optimization/52891] [4.8 Regression] ICE in adjust_bool_pattern

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-04-23 
10:17:08 UTC ---
Author: jakub
Date: Mon Apr 23 10:16:57 2012
New Revision: 186695

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186695
Log:
PR tree-optimizations/52891
* tree-vect-patterns.c (adjust_bool_pattern): Use
build_nonstandard_type even if rhs1 has unsigned INTEGER_TYPE,
but with non-standard precision.

* gcc.c-torture/compile/pr52891-1.c: New test.
* gcc.c-torture/compile/pr52891-2.c: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/compile/pr52891-1.c
branches/gcc-4_7-branch/gcc/testsuite/gcc.c-torture/compile/pr52891-2.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-vect-patterns.c

[Bug c/53060] Typo in build_binary_op for scalar-vector ops

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2012-04-23 
10:20:13 UTC ---
Author: rguenth
Date: Mon Apr 23 10:20:05 2012
New Revision: 186696

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186696
Log:
2012-04-23  Richard Guenther  

PR c/53060
* c-typeck.c (build_binary_op): Fix typo.

* gcc.dg/pr53060.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr53060.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2012-04-23
 Ever Confirmed|0   |1
Summary|GCC cannot handle array |[4.7/4.8 Regression] GCC
   |initialization of string|cannot handle array
   |constant with point |initialization of string
   |arithmetic properly |constant with point
   ||arithmetic properly
   Target Milestone|--- |4.7.1
   Severity|critical|normal

--- Comment #1 from Richard Guenther  2012-04-23 
10:22:34 UTC ---
Confirmed.

[Bug c/53060] Typo in build_binary_op for scalar-vector ops

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-04-23 
10:24:25 UTC ---
Author: rguenth
Date: Mon Apr 23 10:24:14 2012
New Revision: 186698

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186698
Log:
2012-04-23  Richard Guenther  

PR c/53060
* c-typeck.c (build_binary_op): Fix typo.

* gcc.dg/pr53060.c: New testcase.

Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr53060.c
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/c-typeck.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-04-23
 Ever Confirmed|0   |1

[Bug c/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[ktietz at gcc dot gnu.org]

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

--- Comment #2 from Kai Tietz  2012-04-23 10:25:05 
UTC ---
I can confirm it with trunk version for -O0, too.

Issue is that there seems to be a wrong-code generation bug for O0 and
read-only section data.

...
movqaa.2567(%rip), %rax
movq%rax, %rdx
leaq.LC0(%rip), %rcx
callprintf
...

...
.data
.align 8
aa.2567:
.section .rdata,"dr"
.LC1:
.ascii "foo\0"
.quad   .LC1+1
...

The aa.2567 label is emitted in data, but its definition in .rdata

[Bug tree-optimization/53081] memcpy/memset loop recognition

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-23
 CC||rguenth at gcc dot gnu.org
  Component|middle-end  |tree-optimization
Version|unknown |4.8.0
 Ever Confirmed|0   |1

--- Comment #8 from Richard Guenther  2012-04-23 
10:26:45 UTC ---
clearing recognition is enabled by default at -O2+ with
-ftree-loop-distribute-patterns.  I agree more general memset handling would be
nice, as well as
memcpy and memmove recognition.

[Bug c/53079] Unwanted optimization occurs on function with the same name as a math.h function without including math.h nor linking with libm

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Richard Guenther  2012-04-23 
10:27:13 UTC ---
Indeed.

[Bug regression/53076] [4.8 Regression]: gcc.dg/torture/builtin-explog-1.c, gcc.dg/torture/builtin-power-1.c at -O0

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug tree-optimization/53070] ICE: in execute_cse_reciprocals, at tree-ssa-math-opts.c:513 with -O -ffast-math -ftree-loop-if-convert -fno-tree-loop-im

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-23
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-04-23 
10:32:41 UTC ---
Confirmed.

#1  0x00cd5750 in execute_cse_reciprocals ()
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-math-opts.c:513
513 gcc_assert (!bb->aux);

likely somebody (if-conversion) leaves bb->aux initialized.

Mine.

[Bug target/53071] Wrong instruction replacement when compiling for xop

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-23
 Depends on||52908, 52910
 Ever Confirmed|0   |1

[Bug tree-optimization/53058] [4.8 Regression] Another ice in remove_range_assertions

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Target Milestone|--- |4.8.0
Summary|Another ice in  |[4.8 Regression] Another
   |remove_range_assertions |ice in
   ||remove_range_assertions

[Bug middle-end/53032] [4.8 Regression] 447.dealII in SPEC CPU 2006 failed to build

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Richard Guenther  2012-04-23 
10:37:27 UTC ---
Failed and worked again in our testers.  Dup.

*** This bug has been marked as a duplicate of bug 53050 ***

[Bug c/53060] Typo in build_binary_op for scalar-vector ops

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Richard Guenther  2012-04-23 
10:36:28 UTC ---
Fixed.  Thanks for spotting.

[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #8 from Paolo Carlini  2012-04-23 
10:36:28 UTC ---
Oops, thanks a lot Chris!! I'll do the change.

[Bug c++/53050] ssa_forward_propagate_and_combine: segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from Richard Guenther  2012-04-23 
10:37:28 UTC ---
*** Bug 53032 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/53058] [4.8 Regression] Another ice in remove_range_assertions

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-04-23 
10:39:16 UTC ---
Will look at this.

[Bug libstdc++/53080] tuple interface to std::array doesn't check bounds

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.8.0

--- Comment #2 from Paolo Carlini  2012-04-23 
10:50:33 UTC ---
Ok.

[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures

[chris at bubblescope dot net]

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

--- Comment #9 from Chris Jefferson  2012-04-23 
10:54:57 UTC ---
Looking at the output of -fdump-tree-all, it looks like the compiler optimises
the loop which accesses an array out of bounds to:

while(true);

Is this expected behaviour? That seems like terrible output for every
situation...

[Bug fortran/53077] suggestion to add the .f extension to the list of file extensions that trigger enabling of the preprocessor

[slayoo at staszic dot waw.pl]

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

--- Comment #5 from Sylwester Arabas  2012-04-23 
11:13:21 UTC ---
Thanks for quick replies.

> Why can't you just pass the -cpp option to gfortran
> if you want to enable the preprocessor?

Of course you can, but first you need to know that the
"Illegal preprocessor directive" warning actually means 
that the preprocessor is off :)

> Untested patch.

I guess "Used -cpp to" should read "Use -cpp to".

Thanks,
Sylwester

[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures

[paolo at gcc dot gnu.org]

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

--- Comment #10 from paolo at gcc dot gnu.org  
2012-04-23 11:17:34 UTC ---
Author: paolo
Date: Mon Apr 23 11:17:28 2012
New Revision: 186701

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186701
Log:
2012-04-23  Chris Jefferson  

PR testsuite/53046
* testsuite/25_algorithms/stable_partition/mem_check.cc: Fix size
of array A.
* testsuite/25_algorithms/stable_sort/mem_check.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/25_algorithms/stable_partition/mem_check.cc
trunk/libstdc++-v3/testsuite/25_algorithms/stable_sort/mem_check.cc

[Bug middle-end/53047] [4.8 Regression] 482.sphinx3 in SPEC CPU 2006 miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #3 from Richard Guenther  2012-04-23 
11:18:33 UTC ---
Works for me with -Ofast -funroll-loops -fpeel-loops -march=native with
rev.186697
on a Core i7 X980.

What flags do you use?

[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Paolo Carlini  2012-04-23 
11:20:26 UTC ---
Done.

(Chris, if you are interested in discussing optimizer issues, please move the
discussion to the mailing list!)

[Bug middle-end/53073] [4.8 Regression] 464.h264ref in SPEC CPU 2006 miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Richard Guenther  2012-04-23 
11:29:58 UTC ---
1016int
1017SATD (int* diff, int use_hadamard)
1018{
1019  int k, satd = 0, m[16], dd, d[16];
...
1092/*= sum up =*/
1093for (dd=d[k=0]; k<16; dd=d[++k])
1094{
1095  satd += (dd < 0 ? -dd : dd);
1096}

accesses d[16].

[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Guenther  2012-04-23 
11:42:28 UTC ---
(In reply to comment #9)
> Looking at the output of -fdump-tree-all, it looks like the compiler optimises
> the loop which accesses an array out of bounds to:
> 
> while(true);
> 
> Is this expected behaviour? That seems like terrible output for every
> situation...

It's similar to other cases where undefined behavior leads to the GIGO
principle.  Other cases being a simple integer overflow inside a loop
(not even necessarily the loop induction variable itself).

[Bug middle-end/53073] [4.8 Regression] 464.h264ref in SPEC CPU 2006 miscompiled

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-04-23 
11:44:11 UTC ---
Fixed by doing

/*= sum up =*/
for (k=0; k < 16; k++)
{
  dd = d[k];
  satd += (dd < 0 ? -dd : dd);
}

instead.

[Bug fortran/53015] free_pi_tree(): Unresolved fixup is back

[brainschrat at gmx dot de]

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

--- Comment #5 from brainschrat at gmx dot de 2012-04-23 11:48:20 UTC ---
Yes, -I and -J are totally unneccessary together. I made use of -I long before
I started putting the modules in other directories, and together they produce
this mess, but not reliably.

I have six modules (the problem is matlib.f90, the most complex one) and about
seven test cases that use them. Six of seven test cases build fine, and the
seventh can be reduced to an empty subroutine with a couple of use statements,
which are identical to the ones from a working case. The problem occurs on "use
matlib"

I tried to use the Fortran-aware delta to reduce the case, but I get some
confusing errors. The error disappears if I put the f90 files for the modules
in the same directory as the source file for the test case, even if I move the
modules with -J. My testscript for delta returns 0 if I call it, but it returns
1 if called by delta:

cat deltascript.sh
#! /bin/sh
make -C /home/staff/paul/noo DEBUG=1 lib
mpif90 -I/home/staff/paul/noo/include -c $1 2>&1| grep -q fixup
if ! test $? = 0; then
exit 1
fi
exit 0

The first call is to make sure the library (made up of the object files related
to the six modules) is there. This returns 0 if I call it myself with
./deltascript.sh gugv_ass_test.f90, but using

 ~/skripte/delta -test=deltascript.sh -suffix=.f90 -cp_minimal=bla.f90
../../../src/matlib.f90

gives 

[0,2108] 000.f90make: Entering directory `/home/staff/paul/noo'
make: Nothing to be done for `lib'.
make: Leaving directory `/home/staff/paul/noo'


 FAIL: The initial input does not pass the test.

So appearently I am doing something wrong or the whole problem is also related
to the directory from which make (or gfortran?) is called, as delta copies the
files to tmp**/arena. I am sort of stuck at this issue, but maybe I am not
using delta correctly?

[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.

[da_fox at mad dot scientist.com]

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

--- Comment #2 from Da Fox  2012-04-23 
12:26:53 UTC ---
Created attachment 27220
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27220
.i version of miarc.c

I think this is the information that was missing:

The file in question compiled with CFLAGS="-O3 -pipe -fomit-frame-pointer -fweb
-ffast-math -mtune=native -mfpmath=sse" (attached)

gcc build options:
>>> Compiling source in /var/tmp/portage/sys-devel/gcc-4.6.0/work/gcc-4.6.0 ...
 * CFLAGS="-march=native -pipe -mtune=native -O2"
 * CXXFLAGS="-march=native -pipe -mtune=native -O2"
 * Configuring gcc ...
 * configuring for GCC_LANG: c,c++,fortran

 * PREFIX:/usr
 * BINPATH:/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0
 * LIBPATH:/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0
 * DATAPATH:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0
 * STDCXX_INCDIR:/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include/g++-v4

 * Configuring GCC with: 
 * --prefix=/usr 
 * --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0 
 * --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include 
 * --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0 
 * --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/man 
 * --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/info 
 *
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include/g++-v4 
 * --host=x86_64-pc-linux-gnu 
 * --build=x86_64-pc-linux-gnu 
 * --disable-altivec 
 * --disable-fixed-point 
 * --with-ppl 
 * --with-cloog 
 * --disable-ppl-version-check 
 * --with-cloog-include=/usr/include/cloog-ppl 
 * --enable-lto 
 * --enable-nls 
 * --without-included-gettext 
 * --with-system-zlib 
 * --disable-werror 
 * --enable-secureplt 
 * --disable-multilib 
 * --disable-libmudflap 
 * --disable-libssp 
 * --enable-libgomp 
 * --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/python 
 * --enable-checking=release 
 * --disable-libgcj 
 * --enable-languages=c,c++,fortran 
 * --enable-shared 
 * --enable-threads=posix 
 * --enable-__cxa_atexit 
 * --enable-clocale=gnu 
 * --enable-targets=all 
 * --with-bugurl=http://bugs.gentoo.org/ 
 * --with-pkgversion=Gentoo 4.6.0 p1.2, pie-0.4.5

Compiler does not seem to output anything relevant (no errors, compilation is
successful).

[Bug libstdc++/53080] tuple interface to std::array doesn't check bounds

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Paolo Carlini  2012-04-23 
12:27:44 UTC ---
Done.

[Bug libstdc++/53080] tuple interface to std::array doesn't check bounds

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  
2012-04-23 12:26:57 UTC ---
Author: paolo
Date: Mon Apr 23 12:26:43 2012
New Revision: 186702

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186702
Log:
2012-04-23  Paolo Carlini  

PR libstdc++/53080
* include/std/array (tuple_element, get): static_assert I < N.
* testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc:
New.
* testsuite/23_containers/array/tuple_interface/get_neg.cc: Likewise.
* testsuite/23_containers/array/tuple_interface/tuple_element.cc: Fix.

Added:
trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/get_neg.cc
   
trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element_neg.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/array
   
trunk/libstdc++-v3/testsuite/23_containers/array/tuple_interface/tuple_element.cc

[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.

[da_fox at mad dot scientist.com]

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

--- Comment #3 from Da Fox  2012-04-23 
12:28:06 UTC ---
gcc -v output:

Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.6.0/work/gcc-4.6.0/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --disable-werror
--enable-secureplt --disable-multilib --disable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.6.0 p1.2, pie-0.4.5'
Thread model: posix
gcc version 4.6.0 (Gentoo 4.6.0 p1.2, pie-0.4.5)

[Bug libstdc++/53080] tuple interface to std::array doesn't check bounds

[faithandbrave at gmail dot com]

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

--- Comment #5 from Akira Takahashi  2012-04-23 
12:32:13 UTC ---
(In reply to comment #4)
> Done.

Great thanks!

[Bug c++/52008] [C++0x] ICE when adding partial specialization for variadic-templated structure

[ethouris at gmail dot com]

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

--- Comment #10 from Michal Malecki  2012-04-23 
12:38:47 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > 2. The code is rejected the following way: the template specialization
> > definition is itself rejected because due to not covered explicitly all
> > explicit parameters (that is, all but parameter pack) this is not considered
> > template specialization.
> 
> Right, because the partial specialization doesn't specialize the Type1
> parameter, it is not more specialized than the primary template.

It's not the problem that it's "not more specialized" (because it is, as long
as we state it's correct), but rather that it's not correctly defined partial
specialization.

I have tried to find some confirmation in the C++ standard; I think the
14.5.5/4 should make things clear:

(...)
Specifically, the order of the template arguments is the sequence in which they
appear in the template parameter list.
(...)

There are no specific statements for template specializations in case of
variadic parameters. It's important because there are two theoretical
possibilities:

1. First there happens the parameter pack expansion, and then the potential
specialization is verified against the primary template. This way the
specialization can only be rejected if the resulting parameter list does not
match the primary template.

2. First the potential specialization is verified against the primary template,
and then the parameter pack is expanded. In this case the mentioned code is
invalid because the second definition cannot be considered partial
specialization of the tuple_sliced class.

By literally adhering to this rule in the standard, the #2 solution should be
taken. It would be also hard to apply #1 for templates that are also variadic
(to expand the parameter pack, it must be instantiated, and after
instantiation, specializations can no longer be considered).

So, this code should be rejected already at the place of definition of the
specialization, with the explanation, that the arguments passed to the
specialization must exactly match arguments defined in the primary template
(even if it's a parameter pack).

The only thing I have doubts of is whether this is then correct:

template  class X;
template  class X;

According to the cited rule in the standard, it's not - the only allowed would
be  or .

> You should rewrite your code the way I did, and then do something to address
> the ambiguity; possibly a third partial specialization.

It's not a problem to rewrite the above code so that it works as expected:

template
struct TypeIf { typedef TypeIfNot type; };

template
struct TypeIf { typedef TypeIfSo type; };

template 
struct tuple_sliced
{
typedef typename
TypeIf,
tuple_sliced
>::type type;
};

Important thing is that the initial code, even though incorrect, should result
in correct rejection and error report.

[Bug lto/48246] ICE in lto_wpa_write_files

[bergner at gcc dot gnu.org]

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

--- Comment #14 from Peter Bergner  2012-04-23 
12:44:51 UTC ---
Author: bergner
Date: Mon Apr 23 12:44:46 2012
New Revision: 186703

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186703
Log:
Backport from mainline
2011-06-11  Jan Hubicka  

PR lto/48246
* lto.c (lto_1_to_1_map): Don't create empty partitions.
(lto_balanced_map): Likewise.

Modified:
branches/gcc-4_6-branch/gcc/lto/ChangeLog
branches/gcc-4_6-branch/gcc/lto/lto.c

[Bug fortran/53015] free_pi_tree(): Unresolved fixup is back

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus  2012-04-23 
12:46:20 UTC ---
(In reply to comment #5)
> My testscript for delta returns 0 if I call it, but it returns
> 1 if called by delta

Delta generates a new directory, copies the file there and runs then the
script. You probably miss some .mod files. You could add a
  cp /full/path/{a,b,c}.mod .
at the beginning of the delta script for those .mod files you need.

[Bug tree-optimization/53070] ICE: in execute_cse_reciprocals, at tree-ssa-math-opts.c:513 with -O -ffast-math -ftree-loop-if-convert -fno-tree-loop-im

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-04-23 
12:47:09 UTC ---
Author: rguenth
Date: Mon Apr 23 12:47:02 2012
New Revision: 186704

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186704
Log:
2012-04-23  Richard Guenther  

PR tree-optimization/53070
* tree-if-conv.c (combine_blocks): Free predicates in all blocks.
(main_tree_if_conversion): Verify we succeeded in that.

* gcc.dg/torture/pr53070.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr53070.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug c/53085] New: write to volatile struct member is missing on Cortex-M3

[unixoid2003 at mail dot ru]

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

 Bug #: 53085
   Summary: write to volatile struct member is missing on
Cortex-M3
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: unixoid2...@mail.ru


Created attachment 27221
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27221
test code

[Bug c/53085] write to volatile struct member is missing on Cortex-M3

[unixoid2003 at mail dot ru]

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

--- Comment #1 from brag  2012-04-23 12:58:17 UTC 
---
struct aa{
volatile unsigned short a;
unsigned short b;
volatile unsigned short c;
unsigned short d;
};

#define AAmem ((struct aa *) 256)

static inline unsigned int tx(unsigned int v){
while(AAmem->a&1);
AAmem->c=v;
while(AAmem->a&2);
v=AAmem->c;
return v;
}

void f(){
tx(0xff);
tx(0xff);
}

Compiled by:
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -O2 -fomit-frame-pointer
-ffreestanding -fno-common -Wall -Wextra -x c -c test.cpp
OR
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -O2 -fomit-frame-pointer
-ffreestanding -fno-common -Wall -Wextra -x c++ -c test.cpp

The code generated is wrong. There should be two writes to AAmem->c bute there
is one write (strhr3, [r2, #4])

arm-none-eabi-objdump -d test.o :
test.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:f44f 7180 mov.wr1, #256; 0x100
   4:880b  ldrhr3, [r1, #0]
   6:f44f 7280 mov.wr2, #256; 0x100
   a:07d8  lslsr0, r3, #31
   c:d4fa  bmi.n4 
   e:23ff  movsr3, #255; 0xff
  10:8093  strhr3, [r2, #4]
  12:4611  movr1, r2
  14:880b  ldrhr3, [r1, #0]
  16:f44f 7280 mov.wr2, #256; 0x100
  1a:f003 0302 and.wr3, r3, #2
  1e:b29b  uxthr3, r3
  20:2b00  cmpr3, #0
  22:d1f7  bne.n14 
  24:8893  ldrhr3, [r2, #4]
  26:8813  ldrhr3, [r2, #0]
  28:07db  lslsr3, r3, #31
  2a:d4fc  bmi.n26 
  2c:f44f 7280 mov.wr2, #256; 0x100
  30:8813  ldrhr3, [r2, #0]
  32:f003 0302 and.wr3, r3, #2
  36:b29b  uxthr3, r3
  38:2b00  cmpr3, #0
  3a:d1f9  bne.n30 
  3c:f44f 7380 mov.wr3, #256; 0x100
  40:889b  ldrhr3, [r3, #4]
  42:4770  bxlr

[Bug fortran/41587] [OOP] ICE with ALLOCATABLE CLASS components

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  2012-04-23 
12:59:24 UTC ---
(In reply to comment #7)
> As of yesterday, the testcase in comment #1 compiles and runs
> successfully.  We now just need the error message for the original problem.


Untested patch:

--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1626,5 +1626,8 @@ build_struct (const char *name, gfc_charlen *cl, gfc_expr

-  if (c->attr.pointer)
+  if (c->attr.pointer
+  || (c->ts.type == BT_CLASS && CLASS_DATA (c)
+  && CLASS_DATA (c)->attr.class_pointer))
 {
-  if (c->as->type != AS_DEFERRED)
+  if ((c->ts.type == BT_CLASS && CLASS_DATA (c)->as->type != AS_DEFERRED)
+ || (c->ts.type != BT_CLASS &&  c->as->type != AS_DEFERRED))
{
@@ -1635,5 +1638,8 @@ build_struct (const char *name, gfc_charlen *cl, gfc_expr 
 }
-  else if (c->attr.allocatable)
+  else if (c->attr.allocatable
+  || (c->ts.type == BT_CLASS && CLASS_DATA (c)
+  && CLASS_DATA (c)->attr.allocatable))
 {
-  if (c->as->type != AS_DEFERRED)
+  if ((c->ts.type == BT_CLASS && CLASS_DATA (c)->as->type != AS_DEFERRED)
+ || (c->ts.type != BT_CLASS &&  c->as->type != AS_DEFERRED))
{

[Bug c/53085] write to volatile struct member is missing on Cortex-M3

[unixoid2003 at mail dot ru]

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

--- Comment #2 from brag  2012-04-23 13:19:03 UTC 
---
The simpler example:

struct aa{
volatile unsigned short a;
};

struct aa AAmem;

void f(){
AAmem.a=0xff;
AAmem.a=0xff;
}

 <_Z1fv>:
   0:f240 0300 movwr3, #0
   4:f2c0 0300 movtr3, #0
   8:22ff  movsr2, #255; 0xff
   a:801a  strhr2, [r3, #0]  ; <<--- one write here
   c:4770  bxlr
   e:bf00  nop

There is one write but should be two.

Reads seems to work good:
struct aa{
volatile unsigned short a;
};

#define AAmem ((struct aa *) 256)

void f(){
int t;
t=AAmem->a;
t=AAmem->a;
}

 <_Z1fv>:
   0:f44f 7380 mov.wr3, #256; 0x100
   4:881a  ldrhr2, [r3, #0]  ;<<---| two reads here
   6:881b  ldrhr3, [r3, #0]  ;<<---|
   8:4770  bxlr
   a:bf00  nop


Simple volatile variable seems to work OK:
#define s (*((volatile unsigned short*)128))

void f(){
s=0xff;
s=0xff;
}

 <_Z1fv>:
   0:2380  movsr3, #128; 0x80
   2:22ff  movsr2, #255; 0xff
   4:801a  strhr2, [r3, #0]   ;<<---| two writes here
   6:801a  strhr2, [r3, #0]   ;<<---|
   8:4770  bxlr
   a:bf00  nop

[Bug c/53085] writes to volatile struct members is missing

[unixoid2003 at mail dot ru]

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

brag  changed:

   What|Removed |Added

   Severity|critical|normal

[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net 2012-04-23 13:47:31 UTC ---
On 4/23/2012 5:58 AM, jakub at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52999
>
> --- Comment #1 from Jakub Jelinek  2012-04-23 
> 09:58:38 UTC ---
> Created attachment 27219
>-->  http://gcc.gnu.org/bugzilla/attachment.cgi?id=27219
> gcc48-pr52999.patch
>
> This patch avoids the ICE when diagnosing the section conflict, but not sure
> what to do to actually compile the testcase without errors.  What ld.so does 
> is
> not exactly kosher from GCC POV (it wants to put non-constant, writable
> variables into a section that GCC assumes is for constant variables that need
> relocations).
I asked a glibc maintainer whether it would be possible to work around 
the issue.

I know from debugging  that there is at least one varable in the code 
that's placed in .data.rel.ro
and assigned to.  So, the const qualifier can't be used for it.  As 
things stand, glibc doesn't build
with GCC 4.6 and later.

One fix might be to provide an option to set the SECTION_OVERRIDE flag.  
Another might
be to issue a warning rather than an error on section conflicts.

Dave

[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2012-04-23 
13:56:44 UTC ---
Or for PA define __attribute_relro__ to nothing, or assume that users putting
decls into .data.rel.ro or .data.rel.ro.local sections know what they are doing
and just force SECTION_WRITE | SECTION_RELRO always for those.

[Bug middle-end/53086] New: [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[hjl.tools at gmail dot com]

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

 Bug #: 53086
   Summary: [4.8 Regression] 416.gamess in SPEC CPU 2006
miscompiled
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: areg.melikadam...@gmail.com, rgue...@gcc.gnu.org
Depends on: 53073


+++ This bug was initially created as a clone of Bug #53073 +++

On Linux/x86-64, revision 186600 compiles 416.gamess in SPEC CPU 2006
into infinite loop.  Revision 186566 is OK.

[Bug regression/53076] [4.8 Regression]: gcc.dg/torture/builtin-explog-1.c, gcc.dg/torture/builtin-power-1.c at -O0

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from William J. Schmidt  2012-04-23 
14:06:17 UTC ---
Author: wschmidt
Date: Mon Apr 23 14:06:11 2012
New Revision: 186709

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186709
Log:
gcc-testsuite:

2012-04-23  Bill Schmidt  

PR regression/53076
* gcc.dg/torture/builtin-explog-1.c: Skip if -O0.
* gcc.dg/torture/builtin-power-1.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/builtin-explog-1.c
trunk/gcc/testsuite/gcc.dg/torture/builtin-power-1.c

[Bug regression/53076] [4.8 Regression]: gcc.dg/torture/builtin-explog-1.c, gcc.dg/torture/builtin-power-1.c at -O0

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from William J. Schmidt  2012-04-23 
14:11:32 UTC ---
Fixed per discussion on gcc-patches for PR44214.

[Bug tree-optimization/53058] [4.8 Regression] Another ice in remove_range_assertions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-23
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #4 from Jakub Jelinek  2012-04-23 
14:16:47 UTC ---
Created attachment 27222
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27222
gcc48-pr53058.patch

Untested fix.

[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[dave.anglin at bell dot net]

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

--- Comment #4 from dave.anglin at bell dot net 2012-04-23 14:50:18 UTC ---
On 4/23/2012 9:56 AM, jakub at gcc dot gnu.org wrote:
> Or for PA define __attribute_relro__ to nothing, or assume that users putting
> decls into .data.rel.ro or .data.rel.ro.local sections know what they are 
> doing
> and just force SECTION_WRITE | SECTION_RELRO always for those.
hppa-linux uses the default section flags.  Is there a reason why this 
is PA specific?  I sense
there must be as this would have come up before.  It's -fPIC that 
triggers the error.

[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.

[ubizjak at gmail dot com]

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

--- Comment #4 from Uros Bizjak  2012-04-23 14:50:54 
UTC ---
Unfortunately, this is a runtime failure, so we will also need a runtime
testcase (probably minimized) that fails when compiled with options that expose
the bug.

In comment #8 of the linked bugreport, you have testing failures, so this is a
good starting point to locate the problem.

[Bug middle-end/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID
   Target Milestone|--- |4.8.0

--- Comment #1 from Richard Guenther  2012-04-23 
15:05:49 UTC ---
  DO 210 I=1,NAT
 PM = X(I-1+IGAC)
 QM = ZAN(I) - PM
 PL = X(I-1+ILAC)
 QL = ZAN(I) - PL
 IF(DBG) WRITE(IW,9160) I,ANAM(I),BNAM(I),PM,PL
 IF(LAST .AND. MASWRK) WRITE(IW,9180)
 *  I,ANAM(I),BNAM(I),PM,QM,PL,QL
 IF(LAST .AND. MASWRK) WRITE(IP,9200)
 *  ANAM(I),BNAM(I),PM,QM,PL,QL
  210 CONTINUE

This loop does not make progress for me.  I don't see the out-of-bound
access immediately.

But if you build 416.gamess with -O -fbounds-check you immediately get

  Running 416.gamess ref base amd64-m64-gcc42-nn default
/abuild/rguenther/spec2k6/bin/specinvoke -d
/abuild/rguenther/spec2k6/benchspec/CPU2006/416.gamess/run/run_base_ref_amd64-m64-gcc42-nn.0001
-e speccmds.err -o speccmds.stdout -f speccmds.cmd -C

416.gamess: copy #0 non-zero return code (rc=2, signal=0)



Contents of h2ocu2+.gradient.err

At line 768 of file inputb.fppized.f
Fortran runtime error: Index '2' of dimension 1 of array 'x' above upper bound
of 1

which is not within the offending accesses. Manually just compiling
prppop.F with -fbounds-check reveals

  Running 416.gamess ref base amd64-m64-gcc42-nn default
/abuild/rguenther/spec2k6/bin/specinvoke -d
/abuild/rguenther/spec2k6/benchspec/CPU2006/416.gamess/run/run_base_ref_amd64-m64-gcc42-nn.0003
-e speccmds.err -o speccmds.stdout -f speccmds.cmd -C

416.gamess: copy #0 non-zero return code (rc=2, signal=0)



Contents of h2ocu2+.gradient.err

At line 928 of file prppop.fppized.f
Fortran runtime error: Index '2' of dimension 1 of array 'x' above upper bound
of 1

thus, similar.

[Bug tree-optimization/53070] ICE: in execute_cse_reciprocals, at tree-ssa-math-opts.c:513 with -O -ffast-math -ftree-loop-if-convert -fno-tree-loop-im

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #3 from Richard Guenther  2012-04-23 
15:06:15 UTC ---
Fixed.

[Bug middle-end/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2012-04-23 
15:08:45 UTC ---
In most units we have

  COMMON /FMCOM / X(1)

but in unport.F

  PARAMETER (MEMSIZ=   80 000 000)
  COMMON /FMCOM / X(MEMSIZ)

that can't work (?)

[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Component|middle-end  |fortran

--- Comment #3 from Richard Guenther  2012-04-23 
15:12:59 UTC ---
If it is valid to have such "trailing array" in a COMMON then we need to fix
array sizes for them (that's possible).

Is this valid fortran?  If so this is a Frontend bug as well - -fbounds-check
triggers after all.

[Bug c/53085] writes to volatile struct members is missing

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  2012-04-23 
15:18:52 UTC ---
See discussion of volatile members in non-volatile structs in bug 45472

[Bug target/52717] thunk referenced in discarded section when building samba with -flto

[matt at use dot net]

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

--- Comment #13 from Matt Hargett  2012-04-23 15:19:47 UTC 
---
*** Bug 52704 has been marked as a duplicate of this bug. ***

[Bug middle-end/52704] thunk referenced in discarded section when combining -flto -ftree-vectorize -fipa-cp-clone on Debian/SPARC

[matt at use dot net]

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

Matt Hargett  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Matt Hargett  2012-04-23 15:19:47 UTC 
---
Went away when the fix for 52717 was applied.

*** This bug has been marked as a duplicate of bug 52717 ***

[Bug target/52610] mpfr fails to compile when specifying CFLAGS="-O3 -mcpu=leon"

[matt at use dot net]

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

Matt Hargett  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #7 from Matt Hargett  2012-04-23 15:21:19 UTC 
---
Verified again with 4.7 trunk.

[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures

[paolo at gcc dot gnu.org]

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

--- Comment #13 from paolo at gcc dot gnu.org  
2012-04-23 15:24:49 UTC ---
Author: paolo
Date: Mon Apr 23 15:24:44 2012
New Revision: 186713

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186713
Log:
2012-04-23  Chris Jefferson  

PR testsuite/53046
* testsuite/25_algorithms/stable_partition/mem_check.cc: Fix size
of array A.
* testsuite/25_algorithms/stable_sort/mem_check.cc: Likewise.

Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/25_algorithms/stable_partition/mem_check.cc
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/25_algorithms/stable_sort/mem_check.cc

[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|4.8.0   |4.7.1

[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.

[ubizjak at gmail dot com]

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

--- Comment #5 from Uros Bizjak  2012-04-23 15:29:03 
UTC ---
BTW: Can you test if this problem is still present in a newer version of the
compiler (i.e. 4.6.3 or 4.7.0)?

[Bug c++/52851] auto&& fails to deduce type in function template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME
   Target Milestone|--- |4.7.1

--- Comment #4 from Paolo Carlini  2012-04-23 
15:42:16 UTC ---
Indeed, already fixed mainline and 4_7-branch.

[Bug c++/53057] [c++0x] ICE on construction off of initializer list with overloads for constructor

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.7.1, 4.8.0
 Resolution||WORKSFORME

--- Comment #2 from Paolo Carlini  2012-04-23 
15:46:03 UTC ---
Indeed, already fixed mainline and 4_7-branch.

[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org 2012-04-23 16:09:46 UTC ---
(In reply to comment #3)
> If it is valid to have such "trailing array" in a COMMON then we need to fix
> array sizes for them (that's possible).
> 
> Is this valid fortran?  If so this is a Frontend bug as well - -fbounds-check
> triggers after all.

>From F2003 standard one finds on page 99:

   The form variable-name (explicit-shape-spec-list) declares variable-name
   to have the DIMENSION attribute and specifies the array properties that
   apply.

My interpretation is that

  COMMON /FMCOM / X(1)

declares X to have 1 element while

  PARAMETER (MEMSIZ=   80 000 000)
  COMMON /FMCOM / X(MEMSIZ)

has 8000 elements.  The above appears to be a common
F77 idiom for "dynamic" memory management where the 
programmer is abusing the storage association of element
x(1).

[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-04-23 
16:16:54 UTC ---
The PA specific thing there is that PA puts rtx constant pool into .data.rel.ro
section, something that doesn't happen on i?86/x86_64/ppc/ppc64 etc. to my
knowledge.  Which is why there is no section->named.decl (thus the diagnostics
ICE), as well as that in the absence of user variables without section
attribute that should go into .data.rel.ro (like const int *foo = &bar; where
bar isn't hidden) the compiler puts anything into .data.rel.ro section.  rtld.c
carefully doesn't have such variables, and uses .data.rel.ro section attribute
on variables that are writable and written before relocation processing, but
never after.

[Bug fortran/53086] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2012-04-23
 Resolution|INVALID |
 Ever Confirmed|0   |1

--- Comment #5 from H.J. Lu  2012-04-23 16:28:33 
UTC ---
(In reply to comment #4)
> 
> From F2003 standard one finds on page 99:
> 
>The form variable-name (explicit-shape-spec-list) declares variable-name
>to have the DIMENSION attribute and specifies the array properties that
>apply.
> 
> My interpretation is that
> 
>   COMMON /FMCOM / X(1)
> 
> declares X to have 1 element while
> 
>   PARAMETER (MEMSIZ=   80 000 000)
>   COMMON /FMCOM / X(MEMSIZ)
> 
> has 8000 elements.  The above appears to be a common
> F77 idiom for "dynamic" memory management where the 
> programmer is abusing the storage association of element
> x(1).

I was told that it was allowed in F77.

[Bug middle-end/53047] [4.8 Regression] 482.sphinx3 in SPEC CPU 2006 miscompiled

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #4 from H.J. Lu  2012-04-23 16:29:58 
UTC ---
Fixed as of revision 186710.

[Bug target/53087] New: Poor code for conversion from _Bool to int

[steven at gcc dot gnu.org]

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

 Bug #: 53087
   Summary: Poor code for conversion from _Bool to int
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ste...@gcc.gnu.org


Consider this test case:

#define ONEUL (1UL)

int
foo (long unsigned int a)
{
  _Bool b;
  long unsigned int cst, csui;

  if (a > 27) goto return_zero;
/*cst = 217579583UL;*/
  cst = (ONEUL <<  0) | (ONEUL <<  1) | (ONEUL <<  2) |
(ONEUL <<  3) | (ONEUL <<  4) | (ONEUL <<  5) |
(ONEUL << 19) | (ONEUL << 20) | (ONEUL << 21) |
(ONEUL << 22) | (ONEUL << 23) | (ONEUL << 26) |
(ONEUL << 27);
  csui = (ONEUL << a);
  b = ((csui & cst) != 0);
  if (b)
return 1;
  else
return 0;

return_zero:
   return 0;
}


On powerpc64, with GCC trunk r186580, the code generated for this example is:

foo:
.quad   .L.foo,.TOC.@tocbase,0
.previous
.type   foo, @function
.L.foo:
cmpldi 7,3,27
bgt 7,.L3
li 10,1
lis 9,0xcf8
sld 3,10,3
ori 9,9,63
and. 10,3,9
mfcr 9
rlwinm 9,9,3,1
xori 3,9,1
blr
.p2align 4,,15
.L3:
.L2:
li 3,0
blr



The poor code results from PHI-OPT which converts away the if() statement. The
.149t.optimized dump looks like this:

;; Function foo (foo, funcdef_no=0, decl_uid=1996, cgraph_uid=0)

foo (long unsigned int a)
{
  _Bool D.2013;
  long unsigned int csui;
  int D.2008;
  long unsigned int D.2005;
  int D.2004;

:
  if (a_2(D) > 27)
goto  (return_zero);
  else
goto ;

:
  D.2004_3 = (int) a_2(D);
  csui_4 = 1 << D.2004_3;
  D.2005_5 = csui_4 & 217579583;
  D.2013_7 = D.2005_5 != 0;
  D.2008_8 = (int) D.2013_7;

  # D.2008_1 = PHI 
return_zero:
  return D.2008_1;

}


The last statement in  and the PHI are expanded as follows (compiled with
-fno-tree-ter to make it easier to see as what RTL each statement expanded to):

;; D.2013_7 = D.2005_5 != 0;

(insn 15 14 16 (set (reg:CC 134)
(compare:CC (reg:DI 123 [ D.2005 ])
(const_int 0 [0]))) t.c:16 -1
 (nil))

(insn 16 15 17 (set (reg:DI 135)
(eq:DI (reg:CC 134)
(const_int 0 [0]))) t.c:16 -1
 (nil))

(insn 17 16 18 (set (reg:SI 133)
(subreg:SI (reg:DI 135) 4)) t.c:16 -1
 (nil))

(insn 18 17 19 (set (reg:QI 132)
(subreg:QI (reg:SI 133) 3)) t.c:16 -1
 (nil))

(insn 19 18 20 (set (reg:SI 136)
(xor:SI (subreg:SI (reg:QI 132) 0)
(const_int 1 [0x1]))) t.c:16 -1
 (nil))

(insn 20 19 0 (set (reg:DI 124 [ D.2013+-7 ])
(zero_extend:DI (subreg:QI (reg:SI 136) 3))) t.c:16 -1
 (nil))

;; D.2008_8 = (int) D.2013_7;

(insn 21 20 0 (set (reg:DI 120 [ D.2008+-4 ])
(sign_extend:DI (subreg/s/u:SI (reg:DI 124 [ D.2013+-7 ]) 4))) t.c:17
-1
 (nil))



This is a target problem, because i686, x86_64, mips, and arm all generate much
better code for this example, for example:

MIPS:
foo:
.frame  $sp,0,$31   # vars= 0, regs= 0/0, args= 0, gp= 0
.mask   0x,0
.fmask  0x,0
.setnoreorder
.setnomacro
sltu$2,$4,28
beq $2,$0,$L3
nop

li  $2,1# 0x1
sll $4,$2,$4
li  $2,217579520# 0xcf8
addiu   $2,$2,63
and $2,$4,$2
j   $31
sltu$2,$0,$2

$L3:
$L2 = .
j   $31
move$2,$0



ARM:
foo:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmp r0, #27
bhi .L3
mov r3, #1
mov r0, r3, asl r0
ldr r3, .L5
and r3, r0, r3
addsr0, r3, #0
movne   r0, #1
bx  lr
.L3:
.L2:
mov r0, #0
bx  lr
.L6:
.align  2
.L5:
.word   217579583

[Bug lto/48246] ICE in lto_wpa_write_files

[bergner at gcc dot gnu.org]

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

--- Comment #15 from Peter Bergner  2012-04-23 
16:40:10 UTC ---
Author: bergner
Date: Mon Apr 23 16:39:59 2012
New Revision: 186714

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186714
Log:
Merge up to 186704 (pick up PR lto/48246).
* REVISION: Update subversion id.

Modified:
branches/ibm/gcc-4_6-branch/   (props changed)
branches/ibm/gcc-4_6-branch/gcc/ChangeLog
branches/ibm/gcc-4_6-branch/gcc/ChangeLog.ibm
branches/ibm/gcc-4_6-branch/gcc/DATESTAMP
branches/ibm/gcc-4_6-branch/gcc/REVISION
branches/ibm/gcc-4_6-branch/gcc/config/alpha/linux-unwind.h
branches/ibm/gcc-4_6-branch/gcc/config/bfin/linux-unwind.h
branches/ibm/gcc-4_6-branch/gcc/config/i386/linux-unwind.h
branches/ibm/gcc-4_6-branch/gcc/config/ia64/linux-unwind.h
branches/ibm/gcc-4_6-branch/gcc/config/mips/linux-unwind.h
branches/ibm/gcc-4_6-branch/gcc/config/pa/linux-unwind.h
branches/ibm/gcc-4_6-branch/gcc/config/sh/linux-unwind.h
branches/ibm/gcc-4_6-branch/gcc/config/xtensa/linux-unwind.h
branches/ibm/gcc-4_6-branch/gcc/lto/ChangeLog
branches/ibm/gcc-4_6-branch/gcc/lto/lto.c

Propchange: branches/ibm/gcc-4_6-branch/
('svn:mergeinfo' modified)

Propchange: branches/ibm/gcc-4_6-branch/
('svnmerge-integrated' modified)

[Bug target/53087] Poor code for conversion from _Bool to int

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||powerpc-unknown-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-23
 Ever Confirmed|0   |1
  Known to fail||4.8.0

--- Comment #1 from Steven Bosscher  2012-04-23 
16:40:30 UTC ---
This code generation problem is important because the GIMPLE switch lowering
transformations (as ported from stmt.c) introduce this kind of code a lot (e.g.
for the gimple.[ch] predicates).

[Bug c/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2012-04-23 
16:47:32 UTC ---
Can't reproduce on x86_64-linux, please fill in Target.

[Bug middle-end/53088] New: [4.8 Regression] gcc.target/i386/pr39082-1.c

[hjl.tools at gmail dot com]

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

 Bug #: 53088
   Summary: [4.8 Regression] gcc.target/i386/pr39082-1.c
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: hubi...@gcc.gnu.org


On Linux/x86-64, revision 186687:

http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00639.html

gave

FAIL: gcc.target/i386/pr39082-1.c  (test for warnings, line 33)

./xgcc -B./ -S ../../src-trunk/gcc/testsuite/gcc.target/i386/pr39082-1.c -O2
../../src-trunk/gcc/testsuite/gcc.target/i386/pr39082-1.c: In function ‘foo1’:
../../src-trunk/gcc/testsuite/gcc.target/i386/pr39082-1.c:16:1: note: the ABI
of passing union with long double has changed in GCC 4.4
 foo1 (union un u)
 ^

Revision 186685 gave

gcc -S -O2 gcc/gcc/testsuite/gcc.target/i386/pr39082-1.c
gcc/gcc/testsuite/gcc.target/i386/pr39082-1.c: In function ‘foo3’:
gcc/gcc/testsuite/gcc.target/i386/pr39082-1.c:33:12: note: the ABI of passing
union with long double has changed in GCC 4.4
   union un u = bar2 (x); /* { dg-message "note: the ABI of passing union with
long double has changed in GCC 4.4" } */
^

[Bug middle-end/53089] New: [4.8 Regression] gcc.target/i386/pr39082-1.c

[hjl.tools at gmail dot com]

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

 Bug #: 53089
   Summary: [4.8 Regression] gcc.target/i386/pr39082-1.c
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: hubi...@gcc.gnu.org
Depends on: 53088


+++ This bug was initially created as a clone of Bug #53088 +++

On Linux/x86, revision 186687:

http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00639.html

caused:

FAIL: gfortran.dg/coarray/atomic_1.f90 -fcoarray=lib  -O2  -lcaf_single
execution test
FAIL: gfortran.dg/coarray/registering_1.f90 -fcoarray=lib  -O2  -lcaf_single
execution test

[Bug middle-end/52999] [4.7/4.8 Regression] ICE, segmentation fault in c_tree_printer

[dave.anglin at bell dot net]

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

--- Comment #6 from dave.anglin at bell dot net 2012-04-23 17:04:13 UTC ---
On 4/23/2012 12:16 PM, jakub at gcc dot gnu.org wrote:
> The PA specific thing there is that PA puts rtx constant pool into 
> .data.rel.ro
> section, something that doesn't happen on i?86/x86_64/ppc/ppc64 etc. to my
> knowledge.
This occurs in default_elf_select_section.  For example,

  case SECCAT_DATA_REL:
   sname = ".data.rel";
   break;
 case SECCAT_DATA_REL_LOCAL:
   sname = ".data.rel.local";
   break;
 case SECCAT_DATA_REL_RO:
   sname = ".data.rel.ro";

The category comes from here:

   else if (! TREE_READONLY (decl)
|| TREE_SIDE_EFFECTS (decl)
|| ! TREE_CONSTANT (DECL_INITIAL (decl)))
 {
   /* Here the reloc_rw_mask is not testing whether the section 
should
  be read-only or not, but whether the dynamic link will have to
  do something.  If so, we wish to segregate the data in 
order to
  minimize cache misses inside the dynamic linker.  */
   if (reloc & targetm.asm_out.reloc_rw_mask ())
 ret = reloc == 1 ? SECCAT_DATA_REL_LOCAL : SECCAT_DATA_REL;
   else
 ret = SECCAT_DATA;
 }

With PIC code, we get SECCAT_DATA_REL for the variable that caused
the diagnostic ICE.  It lacked a "const" qualifier.

[Bug lto/52605] LTO -g ICE when looking up context of VMTs of classes defined within functions

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
  Known to fail||4.7.0, 4.8.0

--- Comment #1 from Martin Jambor  2012-04-23 
17:04:23 UTC ---
This is still the only problem that prevents me from LTO building
Firefox with -g.  Moreover, I have just verified the problem is also
present also in 4.7 (and it's also the only one).  I really think we
should fix this for 4.7.1.

My patch proposed on the mailing list still applies (to both trunk and
the branch).

[Bug target/53087] Poor code for conversion from _Bool to int

[steven at gcc dot gnu.org]

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

--- Comment #2 from Steven Bosscher  2012-04-23 
17:13:28 UTC ---
Expected code:

foo:
.quad   .L.foo,.TOC.@tocbase,0
.previous
.type   foo, @function
.L.foo:
lwz 9,0(3)
cmplwi 7,9,27
bgt 7,.L4
li 8,1
lis 10,0xcf8
sld 9,8,9
ori 10,10,63
and. 8,9,10
li 3,1
bnelr 0
.L4:
li 3,0
blr

[Bug c/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Target|*-*-mingw*  |x86_64-*-* i686-*-*

--- Comment #4 from Kai Tietz  2012-04-23 17:19:27 
UTC ---
(In reply to comment #3)
> Can't reproduce on x86_64-linux, please fill in Target.

Hmm, I can.  For x86_64-unknown-linux-gnu using -O0 as optimization option, I
see for this test

aa.2162:
.LC1:
 .string "foo"
 .quad .LC1+1

which is wrong, too.

[Bug middle-end/53090] New: suboptimal ivopt

[xinliangli at gmail dot com]

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

 Bug #: 53090
   Summary: suboptimal ivopt
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xinlian...@gmail.com


Compiling the attached benchmark code with trunk gcc, the code generated for
the hot memory swap loop (line 60) is very inefficient : both icc and llvm use
two ivs and generate a tight loop with 9 instructions, but gcc decides to use 3
ivs, and the loop exit testing code is wierd and inefficient -- it ends up
produce a loop with 11 instructions.

#define XCH(x,y){ Aint t_mp; t_mp=(x); (x)=(y); (y)=t_mp; }

for( i=1, j=k-1 ; iThis Inner Loop Header: Depth=3
movl(%rbx,%rdi,4), %ebp
movl(%rbx,%rsi,4), %eax
movl%eax, (%rbx,%rdi,4)
movl%ebp, (%rbx,%rsi,4)
decq%rsi
incq%rdi
cmpl%edx, %edi
leal-1(%rdx), %edx
jl.LBB0_11


The gcc version:

.L18:
movl(%rdx), %edi
addl$1, %ecx
movl(%rsi), %eax
movl%eax, (%rdx)
addq$4, %rdx
movl%edi, (%rsi)
movl%r8d, %edi
subq$4, %rsi
subl%ecx, %edi
cmpl%edi, %ecx
jl.L18


However gcc is doing the right thing when applied on the extracted test case:

#define XCH(x,y) { int t_mp; t_mp=(x); (x)=(y); (y)=t_mp; }

void foo (int *perm, int k)
{
 int i,j;
 for( i=1, j=k-1 ; i

[Bug middle-end/53090] suboptimal ivopt

[xinliangli at gmail dot com]

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

--- Comment #1 from davidxl  2012-04-23 17:37:40 
UTC ---
Created attachment 27223
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27223
benchmark source

[Bug tree-optimization/52979] [4.7/4.8 Regression] likely wrong code bug w/packed bitfields

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2012-04-23 
17:38:43 UTC ---
Doesn't reproduce with r186687 and above (supposedly just went latent with this
testcase).

[Bug c/53084] [4.7/4.8 Regression] GCC cannot handle array initialization of string constant with point arithmetic properly

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-04-23 
17:45:55 UTC ---
I don't see that on the trunk:
.section.rodata
.LC1:
.string"foo"
.align 8
.typeaa.1706, @object
.sizeaa.1706, 8
aa.1706:
.quad.LC1+1
Ah, but looking at current 4.7, I can reproduce that.  Will look at it.