[Bug rtl-optimization/45728] [4.4 Regression] ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1 when comparing union members

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-09-23 07:41 ---
Subject: Bug 45728

Author: jakub
Date: Thu Sep 23 07:41:30 2010
New Revision: 164549

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164549
Log:
PR rtl-optimization/45728
* expr.c (expand_expr_real_1): If op0 isn't REG or MEM, try
gen_lowpart_common first and if that fails, force_reg first
before calling gen_lowpart.

* gcc.c-torture/compile/pr45728.c: New test.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr45728.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/expr.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/45728] [4.4 Regression] ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1 when comparing union members

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-09-23 07:57 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug java/44095] [4.5/4.6 Regression] massive java failures due to -findirect-dispatch breakage on sparc64-linux

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-09-22 08:07 ---
That semantics can't cope well with -fcompare-debug though, where cc1 etc. is
invoked multiple times.  If you remove some options forever, they wouldn't
appear on the next cc1 etc. invocation line and thus that would behave
differently.  I wonder if e.g. not using %(invoke_as) but instead duplicating
its text in java/jvspec.c with additional %findirect-dispatch right after as
and before %(asm_options) wouldn't do the trick.
Or we need a different % letter that would have the previous behavior, though
am not sure if it could ever work with gcj -fcompare-debug -fmain=myclass
myclass.java


-- 


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

[Bug rtl-optimization/45739] static evaluation of SSE intrinsics (pxor)

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-09-22 08:57 ---
Subject: Bug 45739

Author: jakub
Date: Wed Sep 22 08:57:38 2010
New Revision: 164516

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164516
Log:
PR rtl-optimization/45739
* gcc.target/i386/pr45739.c: Tighten up scan-assembler-not
regexps.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr45739.c


-- 


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

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-09-22 15:59 ---
The reason why the return stmt, at least after lowering, doesn't have a
location, is because after lowering there is just one return instead of
possibly multiple returns from before lowering.  So the location_t of the
individual returns is preserved on the gimple assignments to the RESULT_DECL.

What I just find strange is why is the return stmt involved in the SRA
optimization (except as unrelated stmt following the deleted stmt).  There was
an assignment to RESULT_DECL before that, it had the intended locus of the
return from the source, and I'd say that the replacements are connected to that
statements if the RESULT_DECL can't be scalarized.


-- 


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

[Bug middle-end/45234] [4.4/4.5/4.6 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca

[jakub at gcc dot gnu dot org]

--- Comment #22 from jakub at gcc dot gnu dot org  2010-09-22 17:24 ---
The 4.5/4.4 backports of this patch break:
/* { dg-do compile } */
/* { dg-options -march=i586 { target ilp32 } } */

struct S { union { double b[4]; } a[18]; } s, a[5];
void foo (struct S);
struct S bar (struct S, struct S *, struct S);

void
foo (struct S arg)
{
}

void
baz (void)
{
  foo (bar (s, a[1], a[2]));
}

(distilled from struct-layout-1.exp tests, many of them fail).  Please either
fix soon, or revert the patch.  I'd like to roll 4.4.5 RC1 soon, but with this
kind of regression it is not possible.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Priority|P2  |P1
 Resolution|FIXED   |


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

[Bug target/45739] static evaluation of SSE intrinsics (pxor)

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-09-21 10:25:16 |2010-09-21 11:27:37
   date||


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

[Bug rtl-optimization/45739] static evaluation of SSE intrinsics (pxor)

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-09-21 12:23 ---
Created an attachment (id=21856)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21856action=view)
gcc46-pr45739.patch

Fix.  For further optimizations (like vector A | ~0, A | ~A, A ^ ~0, A  ~0), I
guess we'd need something like CONST_ALL_ONES_RTX (mode) and sharing that in
const_tiny_rtx.


-- 


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

[Bug rtl-optimization/45678] [4.4/4.5 Regression] crash on vector code with -m32 -msse

[jakub at gcc dot gnu dot org]

--- Comment #29 from jakub at gcc dot gnu dot org  2010-09-21 14:19 ---
Subject: Bug 45678

Author: jakub
Date: Tue Sep 21 14:18:34 2010
New Revision: 164480

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164480
Log:
PR middle-end/45678
* expr.c (expand_expr_real_1) case VIEW_CONVERT_EXPR: If
op0 isn't sufficiently aligned and there is movmisalignM
insn for mode, use it to load op0 into a temporary register.

Backport from mainline
2010-09-20  Jakub Jelinek  ja...@redhat.com

PR middle-end/45678
* cfgexpand.c (expand_one_stack_var_at): Limit alignment to
crtl-max_used_stack_slot_alignment.

Backport from mainline
2010-09-17  Richard Guenther  rguent...@suse.de
H.J. Lu  hongjiu...@intel.com

PR middle-end/45678
* gcc.dg/torture/pr45678-1.c: New.
* gcc.dg/torture/pr45678-2.c: Likewise.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr45678-1.c
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr45678-2.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/cfgexpand.c
branches/gcc-4_5-branch/gcc/expr.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/45678] [4.4/4.5 Regression] crash on vector code with -m32 -msse

[jakub at gcc dot gnu dot org]

--- Comment #30 from jakub at gcc dot gnu dot org  2010-09-21 16:30 ---
Subject: Bug 45678

Author: jakub
Date: Tue Sep 21 16:30:21 2010
New Revision: 164486

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164486
Log:
PR middle-end/45678
* expr.c (expand_expr_real_1) case VIEW_CONVERT_EXPR: If
op0 isn't sufficiently aligned and there is movmisalignM
insn for mode, use it to load op0 into a temporary register.

Backport from mainline
2010-09-20  Jakub Jelinek  ja...@redhat.com

PR middle-end/45678
* cfgexpand.c (expand_one_stack_var_at): Limit alignment to
crtl-max_used_stack_slot_alignment.

Backport from mainline
2010-09-17  Richard Guenther  rguent...@suse.de
H.J. Lu  hongjiu...@intel.com

PR middle-end/45678
* gcc.dg/torture/pr45678-1.c: New.
* gcc.dg/torture/pr45678-2.c: Likewise.

Added:
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr45678-1.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr45678-2.c
Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/cfgexpand.c
branches/gcc-4_4-branch/gcc/expr.c
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/45678] [4.4/4.5 Regression] crash on vector code with -m32 -msse

[jakub at gcc dot gnu dot org]

--- Comment #31 from jakub at gcc dot gnu dot org  2010-09-21 16:42 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/45739] static evaluation of SSE intrinsics (pxor)

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-09-21 23:33 ---
Subject: Bug 45739

Author: jakub
Date: Tue Sep 21 23:33:01 2010
New Revision: 164501

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164501
Log:
PR rtl-optimization/45739
* simplify-rtx.c (simplify_binary_operation_1): Optimize even
vector mode | CONST0_RTX (mode) and ^ CONST0_RTX (mode).

* gcc.target/i386/pr45739.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr45739.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/45739] static evaluation of SSE intrinsics (pxor)

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-22 00:06 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/45728] ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1 when comparing union members

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-09-20 07:29 ---
Created an attachment (id=21843)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21843action=view)
gcc46-pr45728.patch

Fix.  Alternatively we could just change the == SUBREG condition to force_reg
first to !REG_P  !MEM_P.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug rtl-optimization/45695] [4.5/4.6 Regression] -O1 wrong-code by cmove

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-09-20 13:24 ---
Subject: Bug 45695

Author: jakub
Date: Mon Sep 20 13:24:23 2010
New Revision: 164431

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164431
Log:
PR rtl-optimization/45695
* combine.c (try_combine): When splitting a two set pattern,
make sure the pattern which will be put into i2 doesn't use REGs
or MEMs set by insns in between i2 and i3.

* gcc.c-torture/execute/pr45695.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr45695.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/45124] No DW_AT_accessibility for public DIEs in DW_TAG_class_type

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-09-20 16:48 ---
Subject: Bug 45124

Author: jakub
Date: Mon Sep 20 16:48:29 2010
New Revision: 164442

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164442
Log:
PR debug/45124
* dwarf2out.c (add_accessibility_attribute): Assume
DW_ACCESS_private as the default for dwarf_version  2
and DW_TAG_class_type parent.
(gen_inheritance_die): Assume DW_ACCESS_public as the default
for dwarf_version  2 and parent other than DW_TAG_class_type.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c


-- 


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

[Bug debug/45124] No DW_AT_accessibility for public DIEs in DW_TAG_class_type

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-20 16:51 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/45678] [4.4/4.5 Regression] crash on vector code with -m32 -msse

[jakub at gcc dot gnu dot org]

--- Comment #28 from jakub at gcc dot gnu dot org  2010-09-20 20:37 ---
Subject: Bug 45678

Author: jakub
Date: Mon Sep 20 20:37:10 2010
New Revision: 164454

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164454
Log:
PR middle-end/45678
* cfgexpand.c (expand_one_stack_var_at): Use
crtl-max_used_stack_slot_alignment as max_align, instead
of maximum of that and PREFERRED_STACK_BOUNDARY.
Don't call update_stack_alignment.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgexpand.c


-- 


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

[Bug rtl-optimization/45728] ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1 when comparing union members

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-20 20:41 ---
Subject: Bug 45728

Author: jakub
Date: Mon Sep 20 20:41:08 2010
New Revision: 164456

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164456
Log:
PR rtl-optimization/45728
* expr.c (expand_expr_real_1): If op0 isn't REG or MEM, try
gen_lowpart_common first and if that fails, force_reg first
before calling gen_lowpart.

* gcc.c-torture/compile/pr45728.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr45728.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/45695] [4.5/4.6 Regression] -O1 wrong-code by cmove

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-20 22:37 ---
Subject: Bug 45695

Author: jakub
Date: Mon Sep 20 22:37:32 2010
New Revision: 164467

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164467
Log:
PR rtl-optimization/45695
* combine.c (try_combine): Don't try to swap the two patterns, if the
chosen order is not possible, just give up.  For HAVE_cc0 targets,
check if XVECEXP (newpat, 0, 0) doesn't use REGs or MEMs set by insns
in between i2 and i3.

* gcc.c-torture/execute/pr45695.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/execute/pr45695.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/combine.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/45728] ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1 when comparing union members

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-09-20 22:38 ---
Subject: Bug 45728

Author: jakub
Date: Mon Sep 20 22:38:42 2010
New Revision: 164468

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164468
Log:
PR rtl-optimization/45728
* expr.c (expand_expr_real_1): If op0 isn't REG or MEM, try
gen_lowpart_common first and if that fails, force_reg first
before calling gen_lowpart.

* gcc.c-torture/compile/pr45728.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr45728.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/expr.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/45695] [4.5/4.6 Regression] -O1 wrong-code by cmove

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-09-20 22:39 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug rtl-optimization/45728] ICE: in gen_lowpart_general, at rtlhooks.c:59 at -O1 when comparing union members

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-09-20 22:40 ---
Fixed on the trunk and in 4.5 so far.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.4.5 4.5.2 4.6.0   |4.4.5 4.5.1
  Known to work||4.5.2 4.6.0


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

[Bug middle-end/33380] Internal compiler error: in gen_lowpart_general, at rtlhooks.c:62

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-09-19 18:50 ---
Can't reproduce with either current trunk nor 4.4.4.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug preprocessor/45696] Continuation character gets lost or not taken into account

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-17 07:09 ---
You can use gcc -E -P, then it doesn't print # lineno file
lines and puts the label and fn on the same line (as, without the line notes
locations aren't preserved anyway).
As Andrew wrote, gcc -E is a C/C++ preprocessor, and the semantics of
label:
 fn (args)
is the same as
label: fn (args)
and the former maintains better the location info.


-- 


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

[Bug bootstrap/45700] New: [4.5/4.6 Regression] --enable-checking=fold bootstrap failures

[jakub at gcc dot gnu dot org]

On the trunk (and supposedly on 4.5 too) fold checking bootstrap fails e.g.
while building dyncast.cc in libsupc++ (and some ada compilations too).
I've debugged the dyncast.cc failure, the problem is that
fold_build3_loc on loc, COND_EXPR, type, EQ_EXPR, 1, 0 modifies the EQ_EXPR by
changing its locus.  This is because /* Convert A ? 1 : 0 to simply A.  */
folding calls pedantic_non_lvalue_loc, and that one if !pedantic_lvalues
modifies the passed expr's locus.
I'd say most of the protected_set_expr_location calls in fold-const.c are
suspicios.  Either it is in places where fold-const first calls build[1-5]
followed by protected_set_expr_location, IMHO in these cases we should just
apply Tobias' build[1-5]_loc patch and use those routines instead, and the rest
either should be dropped altogether (fold_convert_loc also ignores locus
if the type is already right, etc.), or, if the locus is really essentialy,
should do nothing if the locus is equal and if not, do a copy_node and set the
locus on the copy and return it.


-- 
   Summary: [4.5/4.6 Regression] --enable-checking=fold bootstrap
failures
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug rtl-optimization/45695] [4.5/4.6 Regression] -O1 wrong-code by cmove

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-09-17 12:05 ---
Created an attachment (id=21817)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21817action=view)
gcc46-pr45695.patch

Untested fix.


-- 


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

[Bug fortran/45505] [4.6 Regression] gfortran.dg/pr25923.f90

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-09-17 12:46 ---
You now set the location, but I believe the wrong one.
esra changes are:
 foo (struct S * arg)
 {
+  int SR.1;
+  int s$a;
   struct S s;
   struct S D.2694;
   int D.2690;
@@ -72,10 +37,12 @@ foo (struct S * arg)
   goto bb 5;

 bb 4:
-  [pr25923.c : 13:7] s = [pr25923.c : 13] *arg_2(D);
+  [pr25923.c : 13:7] s$a_9 = [pr25923.c : 13] MEM[(struct S *)arg_2(D)];

 bb 5:
-  [pr25923.c : 14:3] D.2694 = s;
+  # s$a_8 = PHI s$a_7(D)(3), [pr25923.c : 13:7] s$a_9(4)
+  [pr25923.c : 14:3] SR.1_10 = s$a_8;
+  MEM[(struct S *)D.2694] = SR.1_10;
   return D.2694;

 }

The added MEM = SR.1_10 uses location_t of the stmt after it, as
sra_modify_expr
emits statements before gsi.  I'm arguing that in this case the MEM[(struct S
*)D.2694] = SR.1_10; stmt is not related to return D.2694, but to D.2694 = s
that has been removed and thus I believe it should inherit its locus as well.


-- 


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

[Bug lto/45702] [4.6 Regression] New LTO test failures

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-09-17 13:57 ---
With -r -nostdlib when -lm is mentioned on the command line, it is looking for
libm.a.  Guess you have it installed on one box and not on the other one.
That said, the tests really shouldn't have -lm on their link line.


-- 


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

[Bug lto/45702] [4.6 Regression] New LTO test failures

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-09-17 14:04 ---
Dejagnu adds it always for dg-do link/run, and there doesn't seem to be a way
to bypass that.


-- 


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

[Bug middle-end/45705] New: [4.3/4.4/4.5/4.6 Regression] Useless store not optimized away

[jakub at gcc dot gnu dot org]

int x;

void
foo (void)
{
  if (x == 0)
x = 0;
}

was optimized into empty routine with gcc 3.4 and 4.0, but isn't any longer in
4.1+.  In 4.0 apparently the store went away in *.optimized, and with
-fno-tree-ter in ce1+combine removed it.  This occurs quite a lot in
http://embed.cs.utah.edu/embarrassing/


-- 
   Summary: [4.3/4.4/4.5/4.6 Regression] Useless store not optimized
away
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug c/45687] possible wrong code bug

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-09-16 08:13 ---
Broken by
http://gcc.gnu.org/viewcvs?root=gccview=revrev=164135


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-16 08:13:07
   date||


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

[Bug c/45687] possible wrong code bug

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-09-16 08:27 ---
Seems ipa_modify_call_arguments creates incorrect MEM_REF here.
base is correctly ADDR_EXPR of a, with int * type for the ADDR_EXPR, but
offset has int ** type instead of int *.  At RTL level this results in alias
set 3 being used for the memory read (int *) instead of 2 (int).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org


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

[Bug c/45687] possible wrong code bug

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-09-16 08:55 ---
--- ipa-prop.c.jj 2010-09-14 15:24:45.0 +0200
+++ ipa-prop.c 2010-09-16 10:47:14.0 +0200
@@ -2185,7 +2185,8 @@ ipa_modify_call_arguments (struct cgraph

   if (TREE_CODE (base) == ADDR_EXPR
DECL_P (TREE_OPERAND (base, 0)))
-off = build_int_cst (reference_alias_ptr_type (base),
+off = build_int_cst (reference_alias_ptr_type (TREE_OPERAND (base,
+ 0)),
  adj-offset / BITS_PER_UNIT);
   else if (TREE_CODE (base) != ADDR_EXPR
 POINTER_TYPE_P (TREE_TYPE (base)))

seems to fix this, but even the else { } block a few lines below looks very
questionable.  In particular, the
  if (TREE_CODE (base) == ADDR_EXPR)
base = TREE_OPERAND (base, 0);  
without remembering anywhere whether it was ADDR_EXPR or not and so what level
of indirection we need.


-- 


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

[Bug bootstrap/45686] Building rev. 164285 fails with --enable-checking=all

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
  Component|other   |bootstrap
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-16 09:17:24
   date||


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

[Bug bootstrap/45686] Building rev. 164285 fails with --enable-checking=all

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-09-16 09:35 ---
Subject: Bug 45686

Author: jakub
Date: Thu Sep 16 09:35:02 2010
New Revision: 164330

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164330
Log:
PR bootstrap/45686
* fold-const.c (fold_checksum_tree): Change slot from const void **
to void **, use CONST_CAST_TREE to store into *slot.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c


-- 


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

[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-09-16 10:40 ---
Re: #c4, shouldn't there be srcvar = NULL_TREE; somewhere for the
STRICT_ALIGNMENT non-aligned case?


-- 


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

[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-09-16 11:57 ---
For the ix86/x86_64 alignment issue, I believe the problem here is that
  max_align = MAX (crtl-max_used_stack_slot_alignment,
   PREFERRED_STACK_BOUNDARY);
is fine for !SUPPORTS_STACK_ALIGNMENT targets, but for ix86/x86_64 if
max_used_stack_slot_alignment is really small, we might end up with deciding to
use a smaller alignment.
Perhaps for SUPPORTS_STACK_ALIGNMENT we should use here instead
max_align = MAX (crtl-max_used_stack_slot_alignment,
 INCOMING_STACK_BOUNDARY);
and if the align we compute is bigger than crtl-max_used_stack_slot_alignment
ensure we will keep using that alignment (e.g. by bumping also
crtl-stack_align_needed/estimated).  If INCOMING_STACK_BOUNDARY is 128 bits
aligned, I think using 128 bit alignment shouldn't cost us anything extra.
The problem with using INCOMING_STACK_BOUNDARY is that it is on ix86/x86-64
computed only too late (in expand_stack_alignment by
targetm.calls.update_stack_boundary (); ).  The comment above it says it is
computed again, but I can't actually find another call.


-- 


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

[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse

[jakub at gcc dot gnu dot org]

--- Comment #14 from jakub at gcc dot gnu dot org  2010-09-16 13:54 ---
The reason why cfgexpand does increase the alignment is that it believes that
the base slot will be at least PREFERRED_STACK_BOUNDARY bytes aligned, which is
true on all targets but i?86/x86-64, which apparently sometimes chooses even
smaller alignment for the stack base.  So, we can either use there
MAX (..., STACK_BOUNDARY); for STACK_ALIGNMENT_SUPPORTED instead, which might
penalize some code though, or use INCOMING_STACK_BOUNDARY there (after making
sure we compute it before) and bump needed alignment to whatever we pick there
up.  During expansion expanders of course make use of the DECL_ALIGN info
cfgexpand provides, after all that's why we do that. 


-- 


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

[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse

[jakub at gcc dot gnu dot org]

--- Comment #17 from jakub at gcc dot gnu dot org  2010-09-16 14:08 ---
That's true.  But many expanders can make use of DECL_ALIGN information, e.g.
to choose faster code.  If cfgexpand keeps doing what it does now, namely
bumping DECL_ALIGN of variables up to PREFERRED_STACK_BOUNDARY even when in the
end the stack block doesn't end up being aligned that way, then it lies to the
expander
and that will hit us again and again.  On x86-64/i686, I don't think we want to
prevent memcpy folding as your patch does, at least not for CPUs where movu* is
fast.


-- 


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

[Bug c/45691] Floating point comparison failure

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-16 17:13 ---
i?86 is a FLT_EVAL_METHOD 2 target, so for strict C compliance all floating
operations and constants are supposed to be evaluated in the precision
of long double.  The assignment of the constant to a double var or explicit
cast to double cause rounding to happen, so your testcase is evaluated as:
  int main()
  {
  double z = 3.14159265358979323846L;
  puts((long double) z == 3.14159265358979323846L ? == : !=);
  return 0;
  }
and of course (double) 3.14159265358979323846L != 3.14159265358979323846L.
You can use -fexcess-precision=fast (the default unless -std=c99/-std=c89
is requested) for the old behavior, or you can add explicit cast,
z == (double) M_PI, or (as usually a good idea) avoid floating point
equality/non-equality comparisons, instead check whether difference is
smaller than some epsilon. 


-- 


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

[Bug c/45695] -O1 wrong-code by cmove

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-09-16 21:57 ---
Caused by my http://gcc.gnu.org/viewcvs?root=gccview=revrev=163555
change, so will look into it tomorrow.
http://gcc.gnu.org/bugzilla/attachment.cgi?id=21560action=view
doesn't break it, only the version that tries harder and tries it the other way
around.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-16 21:57:25
   date||


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

[Bug preprocessor/45362] [4.6 Regression] Dangling reference about saved cpp_macro for push/pop macro

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2010-09-16 22:28 ---
Can you try compiling it with
--param ggc-min-expand=0 --param ggc-min-heapsize=0
?  Perhaps you'll trigger it then more reliably...


-- 


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

[Bug libffi/45677] Bad stack allocation for ffi function calls on x86-64

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-09-15 19:21 ---
Yes, x86-64 requires 16 byte stack alignment, but alloca should ensure that.

Can you come up with a small testcase which was misbehaving before?  It would
be great to add it to the libffi testsuite.


-- 


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

[Bug c++/45635] [4.6 regression] Failed to bootstrap on Linux/ia64

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-09-15 06:56 ---
Thanks.  Though, both #c5 and #c6 patches are C++ FE patches and thus I can't
see how they could ever be related to a C testcase.


-- 


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

[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-09-15 08:37 ---
You're right, it doesn't call compute_spt_expr on all the actual arguments's
-expr.  If/when it will use a generic walker, that will be fixed
automatically, but I'll fix it in the meantime as well.


-- 


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

[Bug rtl-optimization/45678] gcc-4.4: crash on vector code with -m32 -msse

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-09-15 14:10 ---
No longer crashes in 4.5/4.6 since r147980, aka SRA rewrite.  The only
difference in *.optimized is though that before r147980 we have:
  m3.3_3 = VIEW_CONVERT_EXPRv4sf(m2);
  m3.5_4 = m3.3_3 * { 5.0e+0, 1.5e+1, 2.5e+1, 3.5e+1 };
  m4$0_5 = VIEW_CONVERT_EXPRfloat[4](m3.5_4)[0];
  if (m4$0_5 != 2.0e+1)
and after it:
  m3.3_7 = VIEW_CONVERT_EXPRv4sf(m2);
  m3.5_8 = m3.3_7 * { 5.0e+0, 1.5e+1, 2.5e+1, 3.5e+1 };
  m4 = VIEW_CONVERT_EXPRfloat[4](m3.5_8);
  m4$0_22 = m4[0];
  if (m4$0_22 != 2.0e+1)
where m2 (and in the second case m4 as well) are float [4] arrays, m3 is v4sf
and m4$0 is float.  This doesn't look like a fix for the case that the
VCEv4sf(m2) load during expansion assumes m2 is 128-bits aligned when it is
not.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-15 14:10:59
   date||


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

[Bug rtl-optimization/45678] [4.4 Regression] crash on vector code with -m32 -msse

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|gcc-4.4: crash on vector|[4.4 Regression] crash on
   |code with -m32 -msse|vector code with -m32 -msse
   Target Milestone|--- |4.4.5


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

[Bug rtl-optimization/45678] [4.4/4.5/4.6 Regression] crash on vector code with -m32 -msse

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-09-15 14:23 ---
Actually
typedef float V __attribute__ ((vector_size (16)));
V g;

int
main ()
{
  float d[4] = { 4, 3, 2, 1 };
  V e;
  __builtin_memcpy (e, d, sizeof (d));
  V f = { 5, 15, 25, 35 };
  e = e * f;
  g = e;
  return 0;
}

segfaults even with 4.5/4.6 at -O2 -m32 -msse2.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.4 Regression] crash on   |[4.4/4.5/4.6 Regression]
   |vector code with -m32 -msse |crash on vector code with -
   ||m32 -msse


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

[Bug c++/45635] [4.6 regression] Failed to bootstrap on Linux/ia64

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-09-15 15:40 ---
Subject: Bug 45635

Author: jakub
Date: Wed Sep 15 15:39:57 2010
New Revision: 164311

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164311
Log:
PR c++/45635
* class.c (build_vtbl_initializer): Use fn instead of init's operand
as first argument to FDESC_EXPR.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c


-- 


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

[Bug tree-optimization/45633] [4.6 regression] internal compiler error: verify_stmts failed

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-09-15 15:43 ---
Subject: Bug 45633

Author: jakub
Date: Wed Sep 15 15:42:41 2010
New Revision: 164312

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164312
Log:
PR tree-optimization/45633
* tree-cfg.c (verify_gimple_assign_binary): Allow
MINUS_EXPR with lhs and rhs1 pointer vector and
rhs2 sizetype vector.
* expr.c (expand_expr_real_2) case PLUS_EXPR: For pointer
or vector pointer use TER to optimize pointer subtraction.

* gcc.dg/vect/pr45633.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr45633.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c


-- 


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

[Bug c++/45635] [4.6 regression] Failed to bootstrap on Linux/ia64

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2010-09-15 15:54 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/45633] [4.6 regression] internal compiler error: verify_stmts failed

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-09-15 16:06 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libffi/45677] Bad stack allocation for ffi function calls on x86-64

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-15 17:07 ---
That patch looks wrong.  The padding for alignment must be done before the
arguments, not after them.
Say if bytes is 24 at the start of one iteration, cif-arg_types[i]-alignment
is 32 and cif-arg_types[i]-size is 40, currently it would correctly
first pad bytes to 32 and then increase it 72, while with your patch
it will be 64.
What we need is to make sure  8 byte arguments have the whole word assigned
for them.  As alignment is always set to at least 8, it is enough to add this
final padding just at the end, so I think the right fix is:
--- libffi/src/x86/ffi64.c 2010-08-11 21:08:14.0 +0200
+++ libffi/src/x86/ffi64.c 2010-09-15 19:05:16.573717651 +0200
@@ -390,7 +390,7 @@ ffi_prep_cif_machdep (ffi_cif *cif)
   if (ssecount)
 flags |= 1  11;
   cif-flags = flags;
-  cif-bytes = bytes;
+  cif-bytes = ALIGN (bytes, 8);

   return FFI_OK;
 }


-- 


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

[Bug libffi/45677] Bad stack allocation for ffi function calls on x86-64

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-09-15 17:51 ---
No, the 8 in the final ALIGN is because that's the stack word size, everything
smaller than that is passed as low bits of the whole 64-bit word.


-- 


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

[Bug debug/45660] [4.5/4.6 Regression] ICE in dwarf2out_finish

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-09-14 09:48 ---
Subject: Bug 45660

Author: jakub
Date: Tue Sep 14 09:48:04 2010
New Revision: 164271

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164271
Log:
PR debug/45660
* dwarf2out.c (gen_decl_die): Call gen_type_die for origin before
gen_type_die for function/method return type.

* g++.dg/debug/pr45660.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/debug/pr45660.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/45660] [4.5/4.6 Regression] ICE in dwarf2out_finish

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-09-14 09:49 ---
Subject: Bug 45660

Author: jakub
Date: Tue Sep 14 09:49:13 2010
New Revision: 164272

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164272
Log:
PR debug/45660
* dwarf2out.c (gen_decl_die): Call gen_type_die for origin before
gen_type_die for function/method return type.

* g++.dg/debug/pr45660.C: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/g++.dg/debug/pr45660.C
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/dwarf2out.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/45660] [4.5/4.6 Regression] ICE in dwarf2out_finish

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-14 09:51 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/45661] sincos opportunity missed

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-09-14 09:59 ---
Not sure how far loop fusion is currently in graphite...


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spop at gcc dot gnu dot org


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

[Bug middle-end/45567] [4.5/4.6 Regression] __builtin_popcountl ICEs with -ftree-ter

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-09-14 10:11 ---
Subject: Bug 45567

Author: jakub
Date: Tue Sep 14 10:11:11 2010
New Revision: 164274

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164274
Log:
PR middle-end/45567
* builtins.c (expand_builtin_interclass_mathfn, expand_builtin_cexpi,
expand_builtin_powi): Remove subtarget argument, pass NULL_RTX instead.
(expand_builtin): Adjust caller.
(expand_builtin_unop): Only use subtarget if it has the right mode.

* gcc.dg/pr45567.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr45567.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/45567] [4.5/4.6 Regression] __builtin_popcountl ICEs with -ftree-ter

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-09-14 10:12 ---
Subject: Bug 45567

Author: jakub
Date: Tue Sep 14 10:12:21 2010
New Revision: 164275

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164275
Log:
PR middle-end/45567
* builtins.c (expand_builtin_interclass_mathfn, expand_builtin_cexpi,
expand_builtin_powi): Remove subtarget argument, pass NULL_RTX instead.
(expand_builtin): Adjust caller.
(expand_builtin_unop): Only use subtarget if it has the right mode.

* gcc.dg/pr45567.c: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr45567.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/builtins.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/45567] [4.5/4.6 Regression] __builtin_popcountl ICEs with -ftree-ter

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-09-14 10:14 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/45663] [4.6 regression] New test failures

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-09-14 11:26 ---
Created an attachment (id=21789)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21789action=view)
gcc46-pr45663.patch

A sign extension insn for the first bar call is scheduled before the a.j++
insns
with the debug_insn for a$j.  While at the call itself the vars already have
expected values, at the first insn on the same line as the first bar call (the
sign extension) a.j is still 13, not 14.

I think we could fix this up by adjusting the testcase (with current trunk it
gives no failures on both x86_64-linux and i686-linux), though haven't tested
other targets.


-- 


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

[Bug c++/45635] [4.6 regression] Failed to bootstrap on Linux/ia64

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-14 14:00 ---
Created an attachment (id=21791)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21791action=view)
gcc46-pr45635.patch

Fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


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

[Bug c++/45635] [4.6 regression] Failed to bootstrap on Linux/ia64

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-09-14 14:47 ---
Created an attachment (id=21792)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21792action=view)
gcc46-pr45635.patch

Alternatively, we can avoid computing the address of fn altogether on
TARGET_VTABLE_USES_DESCRIPTORS targets.


-- 


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

[Bug tree-optimization/45633] [4.6 regression] internal compiler error: verify_stmts failed

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-09-14 15:24 ---
Simplified testcase that ICEs the same way on x86_64-linux (-O3) and i686-linux
(-O3 -msse2):

int s[4];
unsigned char *t[4];

void
foo (void)
{
  int i;
  for (i = 0; i  4; i++)
{
  s[i] = -s[i];
  t[i] -= s[i];
}
}


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i686-pc-cygwin  |
   GCC host triplet|i686-pc-cygwin  |
 GCC target triplet|i686-pc-cygwin  |
   Last reconfirmed|-00-00 00:00:00 |2010-09-14 15:24:04
   date||


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

[Bug tree-optimization/45633] [4.6 regression] internal compiler error: verify_stmts failed

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-09-14 16:18 ---
Created an attachment (id=21794)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21794action=view)
gcc46-pr45633-1.patch

The s[i] = -s[i]; line is also unnecessary in the testcase.

One possible patch attached, allows also MINUS_EXPR with vector pointer on
lhs/rhs1 and vector sizetype on rhs2.


-- 


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

[Bug tree-optimization/45633] [4.6 regression] internal compiler error: verify_stmts failed

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-09-14 16:20 ---
Created an attachment (id=21795)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21795action=view)
gcc46-pr45633-2.patch

Another fix, this one keeps disallowing such MINUS_EXPR.  Unfortunately the
generated code is worse, apparently no RTL pass is able to do that
tmp1 = -b
r = a + tmp1
into
r = a - b
transformation for vector modes.


-- 


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

[Bug c/45669] strcpy_chk false positive

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-09-14 17:09 ---
This is intentional, considering this as a flexible array member is already way
too over what should be allowed.
Either use a true flexible array member, or use memcpy instead (which isn't
limited to field boundaries, only to object boundaries).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug tree-optimization/45633] [4.6 regression] internal compiler error: verify_stmts failed

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-09-14 17:15 ---
I've looked at the combiner with the second patch, but I'm afraid this isn't
fixable in the combiner easily.  While combiner is able for i3
(set (reg:V2DI res) (plus:V2DI (reg:V2DI temp) (mem:V2DI (symbol_ref:P t
, i2
(set (reg:V2DI temp) (minus:V2DI zero) (mem:V2DI (reg:V2DI a)))
and i1
(set (reg:V2DI zero) (const_vector:V2DI [0 0]))
to figure this is
(set (reg:V2DI res) (minus:V2DI (mem:V2DI (symbol_ref:P t)) (reg:V2DI a))
(plus repeating i1, as its result is not dead), this pattern doesn't match
as minus obviously isn't commutative and combiner doesn't try to make 3 insns
out of 3.  So I'd prefer if we could either apply the first patch, or try TER
on the PLUS_EXPR to see if the second operand isn't negation and expand it as
MINUS_EXPR, even when MINUS_EXPR isn't allowed on such arguments in GIMPLE.


-- 


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

[Bug tree-optimization/45633] [4.6 regression] internal compiler error: verify_stmts failed

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2010-09-14 18:43 ---
Created an attachment (id=21796)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21796action=view)
gcc46-pr45633-3.patch

Patch that uses TER to expand PLUS_EXPR/POINTER_PLUS_EXPR as MINUS_EXPR if it
is really pointer subtraction.


-- 


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

[Bug c++/45635] [4.6 regression] Failed to bootstrap on Linux/ia64

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-09-14 19:25 ---
Could you please also try the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635#c5 patch?  Thanks.


-- 


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

[Bug middle-end/45567] [4.5/4.6 Regression] __builtin_popcountl ICEs with -ftree-ter

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-13 09:17 ---
Created an attachment (id=21783)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21783action=view)
gcc46-pr45567.patch

Untested fix.


-- 


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

[Bug fortran/36841] Eliminate gfortran_sum_r8 call for calculation involving multidimensional array multiplication followed by a sum along first dimension

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2010-09-13 10:18 ---
I believe just gfc_conv_intrinsic_arith needs to be adjusted so that it also
handles se-ss case, at least for optimize  !optimize_size.  Currently it
just handles the case where those intrinsics return a scalar.


-- 


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

[Bug fortran/45654] New: -fwhole-file doesn't warn about INTERFACE vs. definition mismatches

[jakub at gcc dot gnu dot org]

Sorry if this is a dup.
Is there any reason why with -fwhole-file we don't warn about:
subroutine foo(ptr, ptr2, f)
  integer, pointer :: ptr(:), ptr2(:)
  logical :: f
  if (f) then
allocate (ptr(6))
  else
nullify(ptr)
  end if
end subroutine
subroutine bar()
  real, pointer :: ptr(:), ptr2(:)
  real, target :: a(6)
  interface
subroutine foo(ptr, ptr2, f)
  real, pointer :: ptr(:), ptr2(:)
  logical :: f
end subroutine
  end interface
  ptr2 = a
  call foo(ptr, ptr2, .true.)
  ptr = a + 6
end subroutine

?


-- 
   Summary: -fwhole-file doesn't warn about INTERFACE vs. definition
mismatches
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2010-09-13 15:36 ---
Created an attachment (id=21785)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21785action=view)
gcc46-pr45596.patch

Updated patch.  This one should handle the case where pointer assigment just
points into some other var's array section and similar (ie. when there is a
possible overlap with some other var, but not necessarily the same
rank/start/bounds) and has some limited interprocedural points-to handling.
tonto.f90 isn't still handled, because for the pointer ALLOCATE it compares the
pointer symbol on which the ALLOCATE is called, and with create_ doing the
ALLOCATE on self that's the same symbol in both cases (although GFC_PT_CALL in
both cases is through different variables).


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #21735|0   |1
is obsolete||


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

[Bug debug/45660] New: [4.5/4.6 Regression] ICE in dwarf2out_finish

[jakub at gcc dot gnu dot org]

// { dg-do compile }
// { dg-options -g -fno-inline }

void
test ()
{
  struct S
  {
typedef void (**T) (void);
static T i (void) { return 0; }
  };
  S s;
  if (s.i ())
*s.i () = 0;
}

ICEs with
rh632847.C:15:1: internal compiler error: in dwarf2out_finish, at
dwarf2out.c:22387
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

This has been introduced in r145440.


-- 
   Summary: [4.5/4.6 Regression] ICE in dwarf2out_finish
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug debug/45660] [4.5/4.6 Regression] ICE in dwarf2out_finish

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-09-13 18:28 ---
Created an attachment (id=21786)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21786action=view)
gcc46-pr45660.patch

Untested fix.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED


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

[Bug fortran/36841] Eliminate gfortran_sum_r8 call for calculation involving multidimensional array multiplication followed by a sum along first dimension

[jakub at gcc dot gnu dot org]

--- Comment #8 from jakub at gcc dot gnu dot org  2010-09-13 18:50 ---
So, are you goint to take care of this?


-- 


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

[Bug fortran/42831] Unnecessary array temporary produced

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-09-13 19:04 ---
Perhaps a testcase should be added (either with -Warray-temporaries or scanning
dumps) to make sure we don't regress here?


-- 


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

[Bug rtl-optimization/45617] optimize bit shift+compare at RTL level

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-09-13 21:00 ---
Subject: Bug 45617

Author: jakub
Date: Mon Sep 13 21:00:03 2010
New Revision: 164257

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164257
Log:
PR rtl-optimization/45617
* combine.c (simplify_comparison): Optimize (X  N) {,=,,=} C
even if low N bits of X aren't known to be zero.

* gcc.target/i386/pr45617.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr45617.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/45617] optimize bit shift+compare at RTL level

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-09-13 21:10 ---
Committed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug middle-end/45567] [4.5/4.6 Regression] __builtin_popcountl ICEs with -ftree-ter

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2010-09-10 21:24:05 |2010-09-11 20:21:14
   date||


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

[Bug web/43011] Upgrade gcc.gnu.org/bugzilla to Bugzilla 3.6

[jakub at gcc dot gnu dot org]

--- Comment #45 from jakub at gcc dot gnu dot org  2010-09-10 10:46 ---
The Log In line in elinks looks quite weird.  There is
a text field Bugzilla_login, then Bugzilla_password (both expected), but then
there is another text field prefilled with password:
input id=Bugzilla_login_top
   class=bz_login
   name=Bugzilla_login
   onfocus=mini_login_on_focus('_top')

input class=bz_password
   id=Bugzilla_password_top
   name=Bugzilla_password
   type=password

input class=bz_password bz_default_hidden bz_mini_login_help type=text
   id=Bugzilla_password_dummy_top value=password
   onfocus=mini_login_on_focus('_top')

Took me a while to figure out one shouldn't input password in there...


-- 


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

[Bug bootstrap/45630] [4.6 Regression] Revision 164050 breaks bootstrap on powerpc-apple-darwin9

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-09-10 10:52 ---
Subject: Bug 45630

Author: jakub
Date: Fri Sep 10 10:52:16 2010
New Revision: 164163

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164163
Log:
PR bootstrap/45630
* dwarf2out.c (get_ref_die_offset_label): Use %ld instead of
HOST_WIDE_INT_PRINT_DEC to print ref-die_offset.
(implicit_ptr_descriptor): Return NULL if dwarf_strict.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c


-- 


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

[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-09-10 14:40 ---
For the interprocedural analysis I believe static points-to is the only
reasonable thing to do, anything else would have too big complexity (both space
and time).  Within one function, sure, you have the code, but not in a form
which makes it very easy to do such analysis (e.g. SSA form is much more
suitable for that), and you need to understand many different constructs (IF,
loops, GOTO, CYCLE, BREAK, OpenMP constructs, ...) and handle propagating the
information through the callgraph (which isn't built).  I think reimplementing
many middle-end passes on the Front-end trees is not the right way to go, and I
hope the static points-to analysis should catch most of the interesting cases
in real-world code.


-- 


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

[Bug fortran/45636] Failed to fold simple Fortran string

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-09-10 15:47 ---
For arbitrary lengths (both of the constant string and of the padding) the
memmove (which will be optimized to memcpy as the source is read-only) + memset
is the best thing to do, replacing say
memmove (x, 900 bytes long string, 900);
memset (x + 900, ' ', 100);
would be very .rodata size unfriendly.
So, the question is, do we want to optimize this for very small sizes of both
(what sizes?  Should we call can_store_by_pieces to determine that from the
FE?)
in the FE by transforming that say
memmove (x, ABCDE, 5);
memset (x + 5, ' ', 3);
into
memcpy (x, ABCDE   , 8);
or should we do this generically in the middle-end, where we'd do this
transformation for such cases even for other languages?


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code


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

[Bug c++/45588] unused-but-set-variable false trigger building gold

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-09 06:51 ---
Subject: Bug 45588

Author: jakub
Date: Thu Sep  9 06:50:56 2010
New Revision: 164051

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164051
Log:
PR c++/45588
* pt.c (tsubst) case INTEGER_TYPE: Call mark_rvalue_use
before calling fold_decl_constant_value.

* g++.dg/warn/Wunused-var-15.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wunused-var-15.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/45588] unused-but-set-variable false trigger building gold

[jakub at gcc dot gnu dot org]

--- Comment #5 from jakub at gcc dot gnu dot org  2010-09-09 07:16 ---
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/45603] cc1plus crashes in build_addr_func

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-09-09 07:45 ---
That's because the compiler's expectation is that if you define
__cxa_guard_acquire, you also define __cxa_guard_release and __cxa_guard_abort.
And, they should be declared throw() as well.


-- 


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

[Bug c++/45603] cc1plus crashes in build_addr_func

[jakub at gcc dot gnu dot org]

--- Comment #11 from jakub at gcc dot gnu dot org  2010-09-09 10:28 ---
templatetypename T
struct Singleton
{
  static T* get()
  {
static T instance;
return instance;
  }
  ~Singleton() {}
};

struct Foo : SingletonFoo
{
};

#ifdef __ARM_EABI__
typedef int __guard;
#else
typedef int __guard __attribute__((mode(DI)));
#endif
extern C int __cxa_guard_acquire(__guard *)
{
}
extern C void __cxa_guard_release(__guard *) throw()
{
}
extern C void __cxa_guard_abort(__guard *) throw()
{
}

void foo()
{
  Foo::get();
}

compiles just fine.


-- 


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

[Bug libstdc++/45574] cin.getline() is extremely slow

[jakub at gcc dot gnu dot org]

--- Comment #16 from jakub at gcc dot gnu dot org  2010-09-09 10:33 ---
The *_unlocked versions are faster a lot actually, at least for the one
character ops, because no locking is performed and the calls are inlined.
But the question is whether libstdc++ can use them, unless there is some
restriction that would disallow several threads from using the same FILE *
(including using STL APIs in one thread and C stdio APIs in another thread).


-- 


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

[Bug c++/45609] [4.3/4.4/4.5/4.6 Regression] 'is used uninitialized' becomes 'may be used uninitialized' on unrelated code changes (namespace addition)

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-09-09 11:56 ---
I don't see any problem.  All of current trunk, 4.5 and 4.4 print it as
b.B::t.T::MBUUITF
rather than
b$t$MBUUITF
and the other difference in the warning message is not caused by unrelated code
changes, but actually very much related.
With -UBAD_NAMESPACE ::f() function is defined in the current TU and thus the
compiler knows it doesn't throw and that D::D() doesn't throw either, with
-DBAD_NAMESPACE ::f() is only declared and so the compiler doesn't know it it
throws or doesn't, and similarly for D::D().  The is used uninitialized warning
is emitted only in basic blocks that are always executed (with -UBAD_NAMESPACE
if A::A() is called, it will always pass the uninitialized var to C::g(int);
with -DBAD_NAMESPACE if ::f() throws then that wouldn't happen.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug libstdc++/45574] cin.getline() is extremely slow

[jakub at gcc dot gnu dot org]

--- Comment #21 from jakub at gcc dot gnu dot org  2010-09-09 15:07 ---
#if  __GNUC__ = 3
# define _IO_BE(expr, res) __builtin_expect ((expr), res)
#else
# define _IO_BE(expr, res) (expr)
#endif

#define _IO_getc_unlocked(_fp) \
   (_IO_BE ((_fp)-_IO_read_ptr = (_fp)-_IO_read_end, 0) \
? __uflow (_fp) : *(unsigned char *) (_fp)-_IO_read_ptr++)
...
__STDIO_INLINE int
getc_unlocked (FILE *__fp)
{
  return _IO_getc_unlocked (__fp);
}

i.e. if getc_unlocked is called directly, it should be very fast, unless the
underlying stream is unbuffered.  This is direct access to the buffer, just STL
getline couldn't use memchr.

Anyway, not sure which STL getline we are talking about here, because e.g.
src/istream.cc getline seems to access the stdio buffer directly:
  streamsize __size = std::min(streamsize(__sb-egptr()
  - __sb-gptr()),
   streamsize(__n - _M_gcount
  - 1));
  if (__size  1)
{
  const char_type* __p = traits_type::find(__sb-gptr(),
   __size,
   __delim);


-- 


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

[Bug c/45620] GCC library allows the use of a negative value for 'NAN'

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2010-09-09 20:45 ---
The C99 standard says the sign should be printed even for NaN, see
7.19.6.1/8:
... A double argument representing an infinity is converted in one of the
styles [-]inf or [-]infinity — which style is implementation-defined. A
double argument representing a NaN is converted in one of the styles
[-]nan or [-]nan(n-char-sequence) — which style, and the meaning of
any n-char-sequence, is implementation-defined. The F conversion specifier
produces INF, INFINITY, or NAN instead of inf, infinity, or nan,
respectively. ...


-- 


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

[Bug fortran/45596] New: Implement simple static points-to analysis in Fortran FE

[jakub at gcc dot gnu dot org]

This is a RFC, the intent of this is to improve tonto speed and hopefully other
Fortran testcases.
I'll attach a WIP patch.
What it currently does is from frontend-passes.c walks down procedure body and
tries to determine all possible POINTER assignments (currently for POINTER vars
only, no POINTER components), computing points_to list for each suitable
POINTER var.  NULL points_to means points to not computed, or could point to
anything.
Otherwise it can contain other symbols, the fact that ALLOCATE has been used on
some pointer, that it is nullified, that it inherits its value from caller for
dummy vars or that a callee might set the var.

Currently the patch doesn't implement interprocedural analysis (we give up
immediately on GFC_PT_CALL).  Eventually, for GFC_PT_CALL we should be able to
look up if we have points_to for the corresponding dummy argument and somehow
try to remap the stuff from its points_to to current function.
GFC_PT_DUMMY obviously can map to whatever we pass to that argument,
GFC_PT_NULL is null as well, similarly GFC_PT_ALLOCATE, for other pointers just
recurse and
remap what they point to, for stuff like module vars I'm afraid the FE syms
might not be shared, or for COMMONs etc.

Another thing which still needs solving is distinction between full pointer
assignments and partial ones (ptr = x vs. ptr = y(:, 1) ), as for the latter
ones we should simply give up if we find out symbols might be same, instead of
trying to do some dependency resolution.

For tonto there is another problem, create_ and destroy method subroutines are
defined in a different file, so in order to optimize that we'd probably need to
save the computed points_to info into *.mod file and read it from that again.


-- 
   Summary: Implement simple static points-to analysis in Fortran FE
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-09-08 12:01 ---
Created an attachment (id=21735)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21735action=view)
gcc46-pr45596.patch

WIP patch.


-- 


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

[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-09-08 12:05 ---
Created an attachment (id=21736)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21736action=view)
uu.f90

One testcase I've been playing with.  The patch allows optimizing away
temporaries on 3 of the 4 p? = a + ? assignments, only for p3 it assumes it
might point to a (well, in this case a is never assigned to any pointer, but
that is not tracked).


-- 


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

[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-09-08 12:08 ---
Created an attachment (id=21737)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21737action=view)
tonto2.f90

Modified testcase from tonto (well, in particular from richi's testcase in one
of the tonto PRs), where the allocate is done directly in the current function
instead of another subroutine.  Here the most important temporary can be
optimized out.
With (working) GFC_PT_CALL handling even the case where create_ is a module
function defined in the current file could work, and with saving/restoring
points_to stuff in theory even the original tonto could be optimized.

Anyway, before I continue working on this, I'd appreciate comments on issues
you see in the current code already.


-- 


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

[Bug fortran/45595] segfault on omp collapse

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-08 12:18:18
   date||


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