[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[oleg.smolsky at gmail dot com]

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

--- Comment #11 from Oleg Smolsky  2011-08-26 
00:48:02 UTC ---
Also, I have just built the same suite with GCC version 4.7 that came from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20110820/gcc-4.7-20110820.tar.bz2 and
the performance degradation remains:

gcc41:
0 "int8_t constant add"   1.35 sec   1185.19 M 1.00

gcc47:
0 "int8_t constant add"   2.37 sec   675.11 M 1.00

Note, these are original unmodified tests, not my digested derivatives

[Bug fortran/36313] [F2003] {MIN,MAX}{LOC,VAL} should accept character arguments

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  2011-08-26 
00:06:48 UTC ---
Created attachment 25108
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25108
patch doing maxloc0* at least.

Still missing: A lot, like minloc*, maxloc1*, etc.

Also: Don't forget the inlined versions, that should be fun too.

[Bug target/50193] New: ARM: ICE on a | (b << negative-constant)

[michael.hope at linaro dot org]

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

 Bug #: 50193
   Summary: ARM: ICE on a | (b << negative-constant)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.h...@linaro.org


trunk r178025, 4.6.1, and 4.5.3 all ICE with unsatisfied constraints on the
following code:

int foo(int a, int b)
{
return a | (b << -3);
}

shift.c: In function 'foo':
shift.c:3:5: warning: left shift count is negative [enabled by default]
shift.c:4:1: error: insn does not satisfy its constraints:
(insn 14 9 17 2 (set (reg/i:SI 0 r0)
(ior:SI (ashift:SI (reg:SI 1 r1 [ b ])
(const_int -3 [0xfffd]))
(reg:SI 0 r0 [ a ]))) shift.c:4 259 {*arith_shiftsi}
 (expr_list:REG_DEAD (reg:SI 1 r1 [ b ])
(nil)))
shift.c:4:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2030

This happens with -mcpu=cortex-a9 -mthumb.  With -marm, GCC recognises that the
shift is unusual, loads it into a register, then uses this in the
register-shifted-register form of ORR.  This form isn't available in Thumb-2.

The problem was originally seen in libtheora:lib/mathops.c when built with -O3
-funroll-loops when a shift by negative 8 is generated.

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[oleg.smolsky at gmail dot com]

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

--- Comment #10 from Oleg Smolsky  2011-08-25 
22:08:49 UTC ---
BTW, the uint16_t test also got slower for the same very reason. Here is the
inner-most loop generated by g++4.6:

text:00400DA0 loc_400DA0:
.text:00400DA0 add eax, 0Ah
.text:00400DA3 add ax, [rdx]
.text:00400DA6 add rdx, 2
.text:00400DAA cmp rdx, 5092E0h
.text:00400DB1 jnz short loc_400DA0

[Bug tree-optimization/50183] ICE in verify_ssa for 416.gamess when optimizing using profile data

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from William J. Schmidt  2011-08-25 
21:02:02 UTC ---
Here's the backtrace from the failure.

(gdb) bt
#0  internal_error (gmsgid=0x10e73c80 "verify_ssa failed") at
/home/wschmidt/gcc/gcc-4_6-branch/gcc/diagnostic.c:838
#1  0x1071b964 in verify_ssa (check_modified_stmt=) at /home/wschmidt/gcc/gcc-4_6-branch/gcc/tree-ssa.c:1119
#2  0x106b44e4 in verify_loop_closed_ssa (verify_ssa_p=) at /home/wschmidt/gcc/gcc-4_6-branch/gcc/tree-ssa-loop-manip.c:456
#3  0x10a56adc in rewrite_commutative_reductions_out_of_ssa
(scop=0x116311a0) at
/home/wschmidt/gcc/gcc-4_6-branch/gcc/graphite-sese-to-poly.c:3218
#4  build_poly_scop (scop=0x116311a0) at
/home/wschmidt/gcc/gcc-4_6-branch/gcc/graphite-sese-to-poly.c:3281
#5  0x10a39110 in graphite_transform_loops () at
/home/wschmidt/gcc/gcc-4_6-branch/gcc/graphite.c:272
#6  0x106bf3d8 in graphite_transforms () at
/home/wschmidt/gcc/gcc-4_6-branch/gcc/tree-ssa-loop.c:256
#7  0x104dddf8 in execute_one_pass (pass=0x11132640) at
/home/wschmidt/gcc/gcc-4_6-branch/gcc/passes.c:1556

[Bug libfortran/50192] New: Wrong character comparision with wide strings

[tkoenig at gcc dot gnu.org]

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

 Bug #: 50192
   Summary: Wrong character comparision with wide strings
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org
CC: jvdeli...@gcc.gnu.org


ig25@linux-fd1f:~/Krempel/4> cat compare.f90
program main
  character(kind=4,len=2) :: c1, c2
  c1 = 4_' '
  c2 = 4_' '
  c1(1:1) = transfer(257, mold=c1)
  c2(1:1) = transfer(64, mold=c2)
  if (c1 < c2) print *,"strange..."
end program main
ig25@linux-fd1f:~/Krempel/4> gfortran compare.f90
ig25@linux-fd1f:~/Krempel/4> ./a.out
 strange...

The problem is in compare_string.  We use

int
compare_string (gfc_charlen_type len1, const CHARTYPE *s1,
gfc_charlen_type len2, const CHARTYPE *s2)
{
  const UCHARTYPE *s;
  gfc_charlen_type len;
  int res;

  res = memcmp (s1, s2, ((len1 < len2) ? len1 : len2) * sizeof (CHARTYPE));

which works on big-endian, but not on little-endian, where the memcmp is used
to compare (bytewise) 0x01 0x01 0x00 0x00 vs. 0x40 0x00 0x00 0x00.

[Bug tree-optimization/50188] Optimizer doesn't take into account, that longjmp could lead to loops, which causes illegal code transformations.

[michael.v.zolotukhin at gmail dot com]

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

--- Comment #4 from Michael Zolotukhin  
2011-08-25 20:21:10 UTC ---
If I understand standard correctly, in this case behavior isn't undefined. Am I
right?
If so, then if behavior of optimized code (loop is infinite) is correct,
behavior of not optimized code isn't.

[Bug c++/48582] Template non-type arguments doesn't accept null pointer constant value

[gintensubaru at gmail dot com]

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

--- Comment #1 from Takaya Saito  2011-08-25 
20:09:49 UTC ---
Current C++0x draft 14.3.2/5 says 0 is not a valid template-argument
for a non-type template-parameter of pointer type.

So, `f<0>();' is ill-formed, as current gcc rejects it.

But 14.3.2/5 says both `(void*)0' and `nullptr' are valid,
so the other codes should be accepted.

[Bug fortran/50050] [4.6/4.7 Regression] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2

[mikael at gcc dot gnu.org]

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

--- Comment #11 from Mikael Morin  2011-08-25 
19:10:11 UTC ---
Author: mikael
Date: Thu Aug 25 19:10:06 2011
New Revision: 178086

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178086
Log:
2011-08-25  Mikael Morin  

PR fortran/50050
* expr.c (gfc_free_shape): Do nothing if shape is NULL.
(free_expr0): Remove redundant NULL shape check.
* resolve.c (check_host_association): Ditto.
* trans-expr.c (gfc_trans_subarray_assign): Assert that shape is
non-NULL.
* trans-io.c (transfer_array_component): Ditto.

2011-08-25  Mikael Morin  

PR fortran/50050
* gfortran.dg/pointer_comp_init_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/pointer_comp_init_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/49864] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2439

[rth at gcc dot gnu.org]

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

--- Comment #10 from Richard Henderson  2011-08-25 
18:57:53 UTC ---
Author: rth
Date: Thu Aug 25 18:57:48 2011
New Revision: 178084

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178084
Log:
PR 50132
PR 49864
* cfgcleanup.c (old_insns_match_p): Don't allow cross-jump for
non-constant stack adjutment.
* expr.c (find_args_size_adjust): Break out from ...
(fixup_args_size_notes): ... here.
* rtl.h (find_args_size_adjust): Declare.

Added:
trunk/gcc/testsuite/gcc.dg/pr50132.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgcleanup.c
trunk/gcc/expr.c
trunk/gcc/rtl.h

[Bug debug/50132] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2234 with -fno-asynchronous-unwind-tables and long double

[rth at gcc dot gnu.org]

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

--- Comment #3 from Richard Henderson  2011-08-25 
18:57:53 UTC ---
Author: rth
Date: Thu Aug 25 18:57:48 2011
New Revision: 178084

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178084
Log:
PR 50132
PR 49864
* cfgcleanup.c (old_insns_match_p): Don't allow cross-jump for
non-constant stack adjutment.
* expr.c (find_args_size_adjust): Break out from ...
(fixup_args_size_notes): ... here.
* rtl.h (find_args_size_adjust): Declare.

Added:
trunk/gcc/testsuite/gcc.dg/pr50132.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgcleanup.c
trunk/gcc/expr.c
trunk/gcc/rtl.h

[Bug c++/50157] [C++0x] Non-silent SFINAE in new expression with explicit conversion

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution||FIXED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.2

--- Comment #3 from Jason Merrill  2011-08-25 
18:53:01 UTC ---
Fixed for 4.6.2.

[Bug testsuite/50185] [4.7 Regression] Bad AVX2 tests

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-25
 AssignedTo|unassigned at gcc dot   |kirill.yukhin at intel dot
   |gnu.org |com
Summary|[4.7 Regression] FAIL:  |[4.7 Regression] Bad AVX2
   |gcc.target/i386/avx2-vmovms |tests
   |kb-2.c scan-assembler   |
   |vmovmskb on |
   |x86_64-apple-darwin10   |
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-08-25 18:46:28 
UTC ---
Many AVX2 tests have things like:

[hjl@gnu-6 i386]$ head -10 avx2-vmovmskb-2.c
/* { dg-do compile } */
/* { dg-options "-mavx2 -O2" } */
/* { dg-final { scan-assembler "vmovmskb" } } */

It scans vmovmskb, which is also the part of filename:

[hjl@gnu-6 gcc]$ head avx2-vmovmskb-2.s
.file"avx2-vmovmskb-2.c"
.text
.p2align 4,,15
.typedo_test, @function

Even if there is no vmovmskb instruction at all, the scan
still passes.  We should add -dp:

/* { dg-options "-mavx2 -O2 -dp" } */

and scan the proper pattern name.

Also avx2-vmovmskb-2.c should be avx2-vpmovmskb-2.c.

[Bug tree-optimization/50188] Optimizer doesn't take into account, that longjmp could lead to loops, which causes illegal code transformations.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #3 from Andrew Pinski  2011-08-25 
18:43:54 UTC ---
POSIX says this is correct behavior:
http://pubs.opengroup.org/onlinepubs/7908799/xsh/longjmp.html

[Bug tree-optimization/50188] Optimizer doesn't take into account, that longjmp could lead to loops, which causes illegal code transformations.

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2011-08-25 
18:33:44 UTC ---
IIRC the variables need to be marked as volatile if you want them to be correct
over setjmp/longjmp.

[Bug c++/50189] [4.5 Regression] Wrong code error in -O2 compile, target independent

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
  Known to work||4.6.1
   Target Milestone|--- |4.5.5
Summary|Wrong code error in -O2 |[4.5 Regression] Wrong code
   |compile, target independent |error in -O2 compile,
   ||target independent

[Bug middle-end/50083] [4.7 regression] All 32-bit fortran tests fail on 32-bit Solaris

[ubizjak at gmail dot com]

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

--- Comment #8 from Uros Bizjak  2011-08-25 18:30:54 
UTC ---
Too many trees to see the forest case ;)

We also have to protect conversion of round, rint and nearbyint with
TARGET_C99.

Obvious patch (also includes non-harmful typo in existing code):

--cut here--
Index: convert.c
===
--- convert.c(revision 178071)
+++ convert.c(working copy)
@@ -469,6 +469,9 @@ convert_to_integer (tree type, tree expr)
   break;

 CASE_FLT_FN (BUILT_IN_ROUND):
+  /* Only convert in ISO C99 mode.  */
+  if (!TARGET_C99_FUNCTIONS)
+break;
   if (outprec < TYPE_PRECISION (integer_type_node)
   || (outprec == TYPE_PRECISION (integer_type_node)
   && !TYPE_UNSIGNED (type)))
@@ -487,11 +490,14 @@ convert_to_integer (tree type, tree expr)
 break;
   /* ... Fall through ...  */
 CASE_FLT_FN (BUILT_IN_RINT):
+  /* Only convert in ISO C99 mode.  */
+  if (!TARGET_C99_FUNCTIONS)
+break;
   if (outprec < TYPE_PRECISION (integer_type_node)
   || (outprec == TYPE_PRECISION (integer_type_node)
   && !TYPE_UNSIGNED (type)))
 fn = mathfn_built_in (s_intype, BUILT_IN_IRINT);
-  else if (outprec < TYPE_PRECISION (long_integer_type_node)
+  else if (outprec == TYPE_PRECISION (long_integer_type_node)
&& !TYPE_UNSIGNED (type))
 fn = mathfn_built_in (s_intype, BUILT_IN_LRINT);
   else if (outprec == TYPE_PRECISION (long_long_integer_type_node)
--cut here--

[Bug rtl-optimization/50191] New: Strange debug insn produced for TOC compiling 416.gamess with profile-generate

[wschmidt at gcc dot gnu.org]

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

 Bug #: 50191
   Summary: Strange debug insn produced for TOC compiling
416.gamess with profile-generate
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wschm...@gcc.gnu.org
CC: berg...@gcc.gnu.org, meiss...@gcc.gnu.org,
pthau...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


Created attachment 25107
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25107
Failing source code

I opened a bug against binutils
(http://sourceware.org/bugzilla/show_bug.cgi?id=13131) for the linkage error
described there.  However, Alan Modra determined the linker was confused by a
strange debug_insn reference into the TOC, produced by gcc:

(debug_insn 8390 8396 8395 5 (var_location:DI D#142 (mem/u/c:DI (lo_sum:DI
(reg/f:DI 2011)
(const:DI (unspec:DI [
(symbol_ref/u:DI ("*.LC7") [flags 0x2])
] UNSPEC_TOCREL))) [23 S8 A8])) -1
 (nil))

The debug_insn appears to be modified during combine; prior to that it contains
the more innocuous:

(debug_insn 8390 8396 8395 5 (var_location:DI D#142 (reg/f:DI 1243 [ ivtmp.961
])) -1
 (nil))

This occurs when compiling chgpen.fppized.f (attached) with the following
minimal set of options:

> /home/wschmidt/gcc/install/gcc-mainline-base/libexec/gcc/powerpc64-linux/4.7.0/f951
>  chgpen.fppized.f -g -O3 -fprofile-generate -ffast-math -funroll-loops -o 
> chgpen.fppized.s

[Bug c++/50157] [C++0x] Non-silent SFINAE in new expression with explicit conversion

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-08-25 
18:22:36 UTC ---
Author: jason
Date: Thu Aug 25 18:22:33 2011
New Revision: 178080

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178080
Log:
PR c++/50157
* call.c (convert_like_real): Exit early if bad and !tf_error.

Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/sfinae27.C
Modified:
branches/gcc-4_6-branch/gcc/cp/ChangeLog
branches/gcc-4_6-branch/gcc/cp/call.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug c++/50157] [C++0x] Non-silent SFINAE in new expression with explicit conversion

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-08-25 
18:22:49 UTC ---
Author: jason
Date: Thu Aug 25 18:22:46 2011
New Revision: 178081

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178081
Log:
PR c++/50157
* call.c (convert_like_real): Exit early if bad and !tf_error.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae27.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/50190] New: linkpk bench of polyhedron fails during validation with gcc trunk when it is compiled with -Ofast on amd64.

[venkataramanan.kumar.gnu at gmail dot com]

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

 Bug #: 50190
   Summary: linkpk bench of polyhedron fails during validation
with gcc trunk when it is compiled with -Ofast on
amd64.
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: venkataramanan.kumar@gmail.com


Polyhedron benchmark linpk fails during validation when compiled with -Ofast
flag.

(Snip)
> Value= 25.114499300 Target= 23.1 Tolerance= 2.00
FAIL 
> Value=0.27880142600E-10 Target=0.27858826400E-10 Tolerance=0.100E-09
> Value=0.22204460500E-15 Target=0.22204460500E-15 Tolerance=0.100E-14
> Value= 1.00 Target= 1.00 Tolerance=0.100E-07
> Value= 1.00 Target= 1.00 Tolerance=0.100E-07
linpk FAILED1 fails and4 passes
(Snip)

exact version of GCC: gcctrunk 1780539
system type: amd64
options given when GCC was configured/built: --disable-bootstrap --without-ppl
--without-cloog --enable-languages=c,c++,fortran 
complete command line that triggers the bug: -Ofast


This issue does not occur when -fprotect-parens is specified with -Ofast.
Current trunk has -fno-protect-parens in -Ofast. So this seems to be a
precision issue as GCC may reorder floating point computations. But I have
reported this to bring it to the notice of community.

[Bug c++/50189] Wrong code error in -O2 compile, target independent

[pkoning at gcc dot gnu.org]

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

Paul Koning  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #2 from Paul Koning  2011-08-25 
17:20:41 UTC ---
I forgot to mention: the test program was run on Linux-i686, but the problem
was originally discovered and also exists on a mips64-netbsdelf targeted gcc
4.5.1.

[Bug c++/50189] Wrong code error in -O2 compile, target independent

[pkoning at gcc dot gnu.org]

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

--- Comment #1 from Paul Koning  2011-08-25 
17:19:23 UTC ---
Created attachment 25106
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25106
gcc -v output (configure options etc.

[Bug c++/50189] New: Wrong code error in -O2 compile, target independent

[pkoning at gcc dot gnu.org]

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

 Bug #: 50189
   Summary: Wrong code error in -O2 compile, target independent
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pkon...@gcc.gnu.org


Created attachment 25105
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25105
Test program

The attached test program compiles to wrong code with GCC 4.5.3 (and 4.5.1)
when compiled -O2.  GCC 4.6.1 gets it right.

I did some digging and determined that the problem shows up in the
-fdump-tree-all output in the .068t.vrp1 dump file; the preceding file
(.067.mergephi2) is correct.  In the generated code that corresponds to the
check_pos method, the second compare "if (m_timestamp != a_timestamp)" is
transformed into "if (3 == a_timestamp)".  If m_timestamp were of time
position_t (an enum of range 0..3) that would be correct, but m_timestamp is an
unsigned int so it can, and in our application does, have values larger than 3.

[Bug tree-optimization/50188] Optimizer doesn't take into account, that longjmp could lead to loops, which causes illegal code transformations.

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-25
 Ever Confirmed|0   |1
  Build|4.7.0 20110801, 4.5.1   |
   |20100924 (Red Hat 4.5.1-4)  |

--- Comment #1 from H.J. Lu  2011-08-25 17:00:07 
UTC ---
It also fails with GCC 4.1.2.

[Bug middle-end/50083] [4.7 regression] All 32-bit fortran tests fail on 32-bit Solaris

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #7 from Uros Bizjak  2011-08-25 16:48:38 
UTC ---
Thanks, confirmed.

Looking into it.

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[oleg.smolsky at gmail dot com]

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

--- Comment #9 from Oleg Smolsky  2011-08-25 
16:26:05 UTC ---
AFAIK it's a production processor, a couple of years old. From x86info:

Family: 6 Model: 15 Stepping: 4 Type: 0 Brand: 0
CPU Model: Core 2 Duo E6600 Original OEM
Feature flags:
 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflsh
ds acpi mmx fxsr sse sse2 ss ht tm pbe sse3 monitor ds-cpl vmx tm2 ssse3 cx16
xT
PR
Extended feature flags:
 SYSCALL xd em64t lahf_lm
Cache info
 L1 Instruction cache: 32KB, 8-way associative. 64 byte line size.
 L1 Data cache: 32KB, 8-way associative. 64 byte line size.
 L3 unified cache: 4MB, 16-way associative. 64 byte line size.
TLB info
 Instruction TLB: 4x 4MB page entries, or 8x 2MB pages entries, 4-way assoc..
 Instruction TLB: 4K pages, 4-way associative, 128 entries.
 Data TLB: 4MB pages, 4-way associative, 32 entries
 L0 Data TLB: 4MB pages, 4-way set associative, 16 entries
 L0 Data TLB: 4MB pages, 4-way set associative, 16 entries
 Data TLB: 4K pages, 4-way associative, 256 entries.
 Data TLB: 4MB pages, 4-way associative, 32 entries
 64 byte prefetching.
 L0 Data TLB: 4MB pages, 4-way set associative, 16 entries
 L0 Data TLB: 4MB pages, 4-way set associative, 16 entries
 Data TLB: 4K pages, 4-way associative, 256 entries.
The physical package supports 4 logical processors

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[xinliangli at gmail dot com]

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

--- Comment #8 from davidxl  2011-08-25 16:17:10 
UTC ---
gcc46 and gcc47 difference can be reproduced using -O2 -m64.

David

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  2011-08-25 15:58:08 
UTC ---
(In reply to comment #6)
>
> The processor is Intel quad core something:
> 
> processor: 0
> vendor_id: GenuineIntel
> cpu family: 6
> model: 15
> model name: Genuine Intel(R) CPU  @ 2.40GHz
> stepping: 4

Are you using engineering example? It doesn't look
like a production processor.

[Bug tree-optimization/50188] New: Optimizer doesn't take into account, that longjmp could lead to loops, which causes illegal code transformations.

[michael.v.zolotukhin at gmail dot com]

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

 Bug #: 50188
   Summary: Optimizer doesn't take into account, that longjmp
could lead to loops, which causes illegal code
transformations.
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.v.zolotuk...@gmail.com


Created attachment 25104
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25104
Bug reproducer.

Setjmp/longjmp could form loops, like following:
  int i = 0;
  (void) setjmp (env);
  i++;
  if (i < 10)
longjmp (env, 0);

Optimizer removes check 'if(i<10)' and 'i++' (seemingly, as a dead code). In
this example after such transformations the loop becomes infinite.

[Bug tree-optimization/46009] ?: vectorized, very similar if is not

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  2011-08-25 15:37:02 
UTC ---
Fixed.

[Bug middle-end/50083] [4.7 regression] All 32-bit fortran tests fail on 32-bit Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-08-25 15:29:38 UTC ---
I can now also reproduce the failure on x86_64-unknown-linux-gnu:

cc1 -quiet -O2 -m32 iround.i -muclibc

With the default (-mglibc), it doesn't occur.

Rainer

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[oleg.smolsky at gmail dot com]

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

--- Comment #6 from Oleg Smolsky  2011-08-25 
15:25:49 UTC ---
Oh, the settings and things were discussed the mail thread... Here is the
digest:

I have compiled and run a set of C++ benchmarks on a CentOS4/64 box using the
following compilers:
 a) g++4.1 that is available for this distro (GCC version 4.1.2 20071124 (Red
Hat 4.1.2-42)
 b) g++4.6 that I built (stock version 4.6.1)

I built the compiler with all the default options (it just has a distinct
installation path):
 ../gcc-%{version}/configure --prefix=/work/tools/gcc46
--enable-languages=c,c++ --with-system-zlib --with-mpfr=/work/tools/mpfr24
--with-gmp=/work/tools/gmp --with-mpc=/work/tools/mpc
LD_LIBRARY_PATH=/work/tools/mpfr/lib24:/work/tools/gmp/lib:/work/tools/mpc/lib

Tests were compiled with -O2 and -O3, I later added -march=native to 4.6
builds.

The processor is Intel quad core something:

processor: 0
vendor_id: GenuineIntel
cpu family: 6
model: 15
model name: Genuine Intel(R) CPU  @ 2.40GHz
stepping: 4
cpu MHz: 2393.943
cache size: 4096 KB
physical id: 0
siblings: 4
core id: 0
cpu cores: 4
fpu: yes
fpu_exception: yes
cpuid level: 10
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm pni monitor
ds_cpl tm2 cx16 xtpr lahf_lm
bogomips: 4793.09
clflush size: 64
cache_alignment: 64
address sizes: 36 bits physical, 48 bits virtual
power management:

[Bug rtl-optimization/48575] RTL vector patterns are limited to 26 elements

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #2 from H.J. Lu  2011-08-25 15:20:10 
UTC ---
Fixed.

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[oleg.smolsky at gmail dot com]

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

--- Comment #5 from Oleg Smolsky  2011-08-25 
15:19:57 UTC ---
Created attachment 25103
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25103
The same test preprocessed with g++ 4.1

[Bug c/50186] junk at end of line: `1

[santoshkumar.a at gmail dot com]

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

--- Comment #9 from SK  2011-08-25 15:01:26 
UTC ---
Just for checking i changed the instruction in .s file from "mfcr 27,1" to
"mfcr 27" and used the assembler to generate the binary there was no error
reported. Now i am confused whether it is fault with assembler if with
compiler. Please suggest where to look into.

[Bug fortran/45859] [Coarray, F2008, IR] Rejects valid actuals to coarray dummies

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-08-25 
14:28:03 UTC ---
(In reply to comment #0)
> is supposed to be valid according the following IR. A modified program which
> uses
>call sub (x(10:))
> is unambiguously valid. However, both programs are rejected by:

With current gfortran 4.7, the "x(10:)" program is accepted and the other one
is rejected for "x(10)" with "must be simply contiguous" (which is true). Thus,
the result is OK and only depends on what J3/WG5 regard as correct.

TODO: Wait for the result of the IR.

[Bug target/50164] [IRA, 4.7 Regression] Performance degradation due to increased memory instructions count

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  2011-08-25 13:58:28 
UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > Yesterday I sent a patch
> > http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01954.html which most probably
> > solved the problem.
> > 
> > Now I have code size 419 (gcc 4.6) vs 411 (gcc as of Aug 24) bytes for the
> > test.
> 
> I tried it but unfortunately it did not solve the regression. We still have xk
> on the stack and x1.5 more memory accesses in GCC 4.7 assembly for mentioned
> code part. GCC 4.6 produces bigger but faster code.
> 

Can you find which checkin caused this?

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  2011-08-25 13:56:52 
UTC ---
(In reply to comment #2)
> For gcc with 
> Target: x86_64-unknown-linux-gnu
> Configured with: ../configure --disable-bootstrap --enable-languages=c,c++
> --prefix=/export/users/izamyati/gcc_4_6_2_prefix/
> Thread model: posix
> gcc version 4.6.2 20110825 (prerelease) (GCC)
> 
> everything is fine, no that spill-fill generated

Can we find which checkin caused this?

[Bug go/50166] ICE in go1: SEGV on Solaris 10/x86

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  2011-08-25 13:40:57 UTC ---
I've just checked that it still occurs with current mainline.  I'm
running a reghunt to identify the culprit.

Rainer

[Bug tree-optimization/50183] ICE in verify_ssa for 416.gamess when optimizing using profile data

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from William J. Schmidt  2011-08-25 
13:39:54 UTC ---
Thanks.  -floop-interchange is required to cause the problem, and
graphite_transforms was in the stack at the time of the verify failure.  I
believe there was an explicit call to verify_ssa in there somewhere rather than
a TODO.  I took a priority interrupt at that point and haven't had time yet to
dig deeper.

[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char->int conversion

[izamyatin at gmail dot com]

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

--- Comment #2 from Igor Zamyatin  2011-08-25 
13:17:36 UTC ---
For gcc with 
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --disable-bootstrap --enable-languages=c,c++
--prefix=/export/users/izamyati/gcc_4_6_2_prefix/
Thread model: posix
gcc version 4.6.2 20110825 (prerelease) (GCC)

everything is fine, no that spill-fill generated

[Bug inline-asm/50187] New: Interrupt handler attribute for x86/x86_64

[christian.gnu at juner dot de]

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

 Bug #: 50187
   Summary: Interrupt handler attribute for x86/x86_64
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: inline-asm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: christian@juner.de


I think it would be nice to have a function attribute that tells gcc to omit
the function prologue/epilogue, to be able to write tings such as interrupt
handlers. See the description of different compiler implementations here:
.

[Bug c/50186] junk at end of line: `1

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  2011-08-25 
12:10:26 UTC ---
And 476 CPU according to rs6000-cpus.def should support that:
RS6000_CPU ("476", PROCESSOR_PPC476,
POWERPC_BASE_MASK | MASK_SOFT_FLOAT | MASK_PPC_GFXOPT | MASK_MFCRF
| MASK_POPCNTB | MASK_FPRND | MASK_CMPB | MASK_MULHW | MASK_DLMZB)
so the bug is probably on your assembler side.

[Bug c/50186] junk at end of line: `1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  2011-08-25 
12:06:46 UTC ---
MFCRF is ISA 2.01 BTW.

[Bug c/50186] junk at end of line: `1

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-08-25 
12:05:46 UTC ---
That seems like your gcc is assuming -mmfcrf for your CPU, yet your assembler
can't assemble it (or is assembling for a CPU which doesn't have the mfcrf
insn).

[Bug c/50186] junk at end of line: `1

[santoshkumar.a at gmail dot com]

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

--- Comment #5 from SK  2011-08-25 12:02:09 
UTC ---
at line 665 in do_mounts_rd.s "mfcr 27,1" is a wrong instruction generated. As
per Power ISA™ Version 2.05 mfcr take only one argument i.e "mfcr RT". Let me
know if i have to change any components used.

[Bug c/50186] junk at end of line: `1

[santoshkumar.a at gmail dot com]

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

--- Comment #4 from SK  2011-08-25 11:59:11 
UTC ---
Created attachment 25102
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25102
cross compile script

cross compile script

[Bug c/50186] junk at end of line: `1

[santoshkumar.a at gmail dot com]

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

--- Comment #2 from SK  2011-08-25 11:53:17 
UTC ---
Created attachment 25100
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25100
intermidate file

intermidate file do_mounts_rd.i

[Bug c/50186] junk at end of line: `1

[santoshkumar.a at gmail dot com]

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

--- Comment #3 from SK  2011-08-25 11:53:59 
UTC ---
Created attachment 25101
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25101
do_mounts_rd.s

assembly file

[Bug c/50154] attribute printf and scanf should imply attribute nonnull

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution||INVALID

--- Comment #3 from Jakub Jelinek  2011-08-25 
11:13:59 UTC ---
Yeah, I agree with that.

[Bug c++/50184] Segmentation fault. Copy Constructor.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-08-25 
10:48:59 UTC ---
-fno-elide-constructors prevents the segfault

something goes wrong copying the return value of func() into the CData base
class of B

[Bug c/50186] junk at end of line: `1

[santoshkumar.a at gmail dot com]

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

--- Comment #1 from SK  2011-08-25 10:33:22 
UTC ---
Created attachment 25099
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25099
build errors

build errors

[Bug c/50179] [4.6/4.7 Regression] wrong "set but not used" warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.2
Summary|wrong "set but not used"|[4.6/4.7 Regression] wrong
   |warning |"set but not used" warning

[Bug c/50179] wrong "set but not used" warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-08-25
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-08-25 
10:25:17 UTC ---
Created attachment 25098
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25098
gcc47-pr50179.patch

Untested fix.

[Bug c/50186] New: junk at end of line: `1

[santoshkumar.a at gmail dot com]

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

 Bug #: 50186
   Summary: junk at end of line: `1
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: santoshkuma...@gmail.com


All,
  I have built a Toolchain for powerpc 476 in little endian mode.

With below:

binutils-2.21
gcc-4.6.1
glibc-2.13
linux-2.6.39

While comiling linux kernel 2.6.39 with 
"make ARCH=powerpc CROSS_COMPILE=powerpc-476-linux-gnu-"
I see the below error.

  CHK include/linux/version.h
  CHK include/generated/utsrelease.h
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  SKIPPED include/generated/compile.h
  CC  init/do_mounts_rd.o
{standard input}: Assembler messages:
{standard input}:665: Error: junk at end of line: `1'

If any one has faced this issue please let me know what needs to be done.

Thanks

[Bug c++/50184] Segmentation fault. Copy Constructor.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-25
 Ever Confirmed|0   |1
  Known to fail||4.1.2, 4.4.3, 4.5.2, 4.6.1,
   ||4.7.0

--- Comment #2 from Jonathan Wakely  2011-08-25 
10:12:21 UTC ---
(that code is actually invalid and g++ should reject it because CData::CItem is
private in B's constructor, but there's a g++ bug that doesn't do access
checking for template arguments, and fixing that doesn't prevent the segfault)

reduced:

#include 
#include 
using namespace std;

struct CData
{
struct CItem
{
string m_str1;
};

map  m_map;

std::string m_strDFName;
int m_nDFMsgTimeout;
};

CData func()
{
CData data;
data.m_map["Test"].m_str1 = "Data";
return data;
}

class B : public CData
{
public:
B()
: CData(func())
{
std::string s;
map::iterator it = m_map.begin();
for (; it != m_map.end(); it++) // loops past the end
{
s += it->second.m_str1 + it->first;;
}
}
};

int main()
{
B b1;
return 0;
}

[Bug testsuite/50185] New: [4.7 Regression] FAIL: gcc.target/i386/avx2-vmovmskb-2.c scan-assembler vmovmskb on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

 Bug #: 50185
   Summary: [4.7 Regression] FAIL:
gcc.target/i386/avx2-vmovmskb-2.c scan-assembler
vmovmskb on x86_64-apple-darwin10
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: h...@gcc.gnu.org, kirill.yuk...@intel.com
  Host: x86_64-apple-darwin10
Target: x86_64-apple-darwin10
 Build: x86_64-apple-darwin10


In the tests introduced in revision 178006, scan-assembler vmovmskb fails for
gcc.target/i386/avx2-vmovmskb-2.c on x86_64-apple-darwin10. The assembly is

.text
.align 4,0x90
_do_test:
LFB1005:
pushq%rbp
LCFI0:
xorl%eax, %eax
movl$1, %esi
LCFI1:
movq%rsp, %rbp
LCFI2:
andq$-32, %rsp
subq$32, %rsp
vmovdqaLC0(%rip), %ymm0
vmovdqa%ymm0, (%rsp)
jmpL3
.align 4,0x90
L2:
addq$1, %rax
cmpq$32, %rax
jeL7
L3:
cmpb$0, (%rsp,%rax)
movl%eax, %ecx
jnsL2
movl%esi, %edi
addq$1, %rax
sall%cl, %edi
orl%edi, %edx
cmpq$32, %rax
jneL3
L7:
vmovdqaLC1(%rip), %ymm0
vpmovmskb%ymm0, %eax
cmpl%edx, %eax
jneL8
leave
LCFI3:
vzeroupper
ret
L8:
LCFI4:
vzeroupper
call_abort
...

So there is no vmovmskb, but three vmovdqa. Any idea why?

[Bug target/50164] [IRA, 4.7 Regression] Performance degradation due to increased memory instructions count

[enkovich.gnu at gmail dot com]

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

--- Comment #2 from Ilya Enkovich  2011-08-25 
09:31:29 UTC ---
(In reply to comment #1)
> Yesterday I sent a patch
> http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01954.html which most probably
> solved the problem.
> 
> Now I have code size 419 (gcc 4.6) vs 411 (gcc as of Aug 24) bytes for the
> test.

I tried it but unfortunately it did not solve the regression. We still have xk
on the stack and x1.5 more memory accesses in GCC 4.7 assembly for mentioned
code part. GCC 4.6 produces bigger but faster code.

Problem somehow appears only when -march=atom is used. There is no degradation
if generic arch is used. I compared GCC 4.7 dumps for "-O2 -m32" and "-O2 -m32
-march=atom" and found that RTLs are same before IRA and differ after IRA. 

How does -march=atom affects register allocation?

[Bug fortran/50174] [4.7 Regression] ICE on derived type allocation

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #4 from Tobias Burnus  2011-08-25 
09:15:44 UTC ---
I marked it as duplicated of PR 50050 comment 7 as the error seems to be
identically.

If the patch at http://gcc.gnu.org/ml/fortran/2011-08/msg00199.html does not
fix the issue - or if the final commit does not fix the issue, feel free to
reopen this PR.

Sorry for the breakage.

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

[Bug fortran/50050] [4.6/4.7 Regression] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||pmason at ricardo dot com

--- Comment #10 from Tobias Burnus  2011-08-25 
09:15:44 UTC ---
*** Bug 50174 has been marked as a duplicate of this bug. ***

[Bug c++/50184] Segmentation fault. Copy Constructor.

[EugeneSm at yandex dot ru]

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

--- Comment #1 from Eugene  2011-08-25 09:01:52 UTC 
---
gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC)

 Build of configuration Debug for project Test 

make all 
Building file: ../src/Test.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/Test.d"
-MT"src/Test.d" -o"src/Test.o" "../src/Test.cpp"
Finished building: ../src/Test.cpp

Building target: Test
Invoking: GCC C++ Linker
g++  -o"Test"  ./src/Test.o   
Finished building target: Test

[Bug c++/50184] New: Segmentation fault. Copy Constructor.

[EugeneSm at yandex dot ru]

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

 Bug #: 50184
   Summary: Segmentation fault. Copy Constructor.
Classification: Unclassified
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eugen...@yandex.ru


#include 
#include 
using namespace std;

class CData
{
class CItem
{
public:
string m_str1;
};

public:
map  m_map;

int m_nWaitTime2ReadSS;
int m_eQueueOrderType;

//- Data ---
boolm_bDFRead;
std::string m_strDFName;
int m_nDFLoopCount;
int m_nDFLoopTimeout;
int m_nDFMsgTimeout;
};

class A
{
public:
CData func()
{
CData data;
data.m_map["Test"].m_str1 = "Data";
return data;
}
};

class B : public CData
{
public:
template 
B(T& a)
: CData(a.func())
{
map::iterator it = m_map.begin();
for (; it != m_map.end(); it++)//In this place m_map.end() returns
wrong value as result I get segmentation fault.
//I noticed that copy constructor when I added one into CData is never called.
{
cout << (*it).first<< " "<<(*it).second.m_str1<<"\n";
}
cout << "GOOD"<<"\n";
}
};

int main()
{
A a;
B b1(a);
return 0;
}

Result of this code is Segmentation fault.

[Bug target/50182] Performance degradation from gcc 4.1 (x86_64)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2011-08-25 
08:55:42 UTC ---
The bugreport is incomplete, I don't see anywhere where you'd state what g++
options were meassured, what CPU was it on, is it -m32 or -m64, etc.
For me, on i7-2600 CPU 4.6.0 (both Fedora 4.6.0-10 and 20110727 4.6 branch
snapshot) is actually much faster than current trunk with -O3 -m64:
4.6.* gives roughly
 0 "int8_t constant add"   0.84 sec   1904.76 M 1.00
while trunk
 0 "int8_t constant add"   1.26 sec   1269.84 M 1.00
4.4.* gives also
 0 "int8_t constant add"   1.26 sec   1269.84 M 1.00
4.3.* gives
 0 "int8_t constant add"   1.26 sec   1269.84 M 1.00
4.2.* gives
 0 "int8_t constant add"   0.84 sec   1904.76 M 1.00
and 4.1.* doesn't compile, because the source has been preprocessed and STL is
dependent on the compiler version.

[Bug middle-end/45262] [4.2/4.3 Regression] Optimization results in wrong result on expression x>>31||(-x)>>31

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||
 Resolution||FIXED

--- Comment #8 from Richard Guenther  2011-08-25 
08:32:56 UTC ---
.

[Bug fortran/50163] [4.3/4.4/4.5/4.6/4.7 Regression] ICE: initialization expression

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2011-08-25 
08:29:36 UTC ---
Author: burnus
Date: Thu Aug 25 08:29:29 2011
New Revision: 178054

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178054
Log:
2011-08-25  Tobias Burnus  

PR fortran/50163
* check_init_expr (check_init_expr): Return when an error
occured.

2011-08-25  Tobias Burnus  

PR fortran/50163
* gfortran.dg/initialization_28.f90: New.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/initialization_28.f90
Modified:
branches/gcc-4_6-branch/gcc/fortran/ChangeLog
branches/gcc-4_6-branch/gcc/fortran/expr.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/50178] [4.6 regression] ICE with gfortran -O3, not with gfortran -02

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
   Target Milestone|--- |4.6.2

[Bug tree-optimization/50183] ICE in verify_ssa for 416.gamess when optimizing using profile data

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org

--- Comment #2 from Richard Guenther  2011-08-25 
07:19:09 UTC ---
Does it reproduce without -floop-interchange?

I bet it's graphite producing invalid SSA, but it doesn't verify it.  Apply

Index: gcc/tree-ssa-loop.c
===
--- gcc/tree-ssa-loop.c (revision 177782)
+++ gcc/tree-ssa-loop.c (working copy)
@@ -308,7 +308,8 @@ struct gimple_opt_pass pass_graphite_tra
   0,   /* properties_provided */
   0,   /* properties_destroyed */
   0,   /* todo_flags_start */
-  TODO_dump_func   /* todo_flags_finish */
+  TODO_dump_func
+  | TODO_verify_ssa | TODO_verify_stmts /* todo_flags_finish */
  }
 };