[Bug tree-optimization/52073] [4.7 Regression] ICE: vector VEC(vec_void_p,base) index domain error, in vinfo_for_stmt at tree-vectorizer.h:620

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-02-02 
08:09:43 UTC ---
Author: jakub
Date: Thu Feb  2 08:09:37 2012
New Revision: 183829

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183829
Log:
PR tree-optimization/52073
* tree-vect-stmts.c (vect_mark_relevant): When checking uses of
a pattern stmt for pattern uses, ignore uses outside of the loop.

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

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr52073.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug regression/47037] 465.tonto Segmentation Fault in memset with -fcaller-saves (default at -O2 or higher)

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski  2012-02-02 
08:12:54 UTC ---
Does this work now?

[Bug fortran/52093] [4.6/4.7 Regression] Extra parenthesis with Size and Shape functions argument cause internal compiler error: Segmentation fault

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
Summary|Extra parenthesis with Size |[4.6/4.7 Regression] Extra
   |and Shape functions |parenthesis with Size and
   |argument cause internal |Shape functions argument
   |compiler error: |cause internal compiler
   |Segmentation fault  |error: Segmentation fault
 Ever Confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  2012-02-02 
08:16:42 UTC ---
Revision 162456 (2010-07-23) is OK,
revision 164728 (2010-09-29) gives the ICE.

[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #19 from Andrew Pinski  2012-02-02 
08:16:23 UTC ---
libiberty has been removed as a target library.
And zlib as a target library is only built when building with java and java
support needs a full C library anyways.

So this is not really a bug and closing as such.

[Bug middle-end/51231] [4.5/4.6/4.7 Regression] g++ remove placement new with -O1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|regression  |middle-end
   Target Milestone|--- |4.5.4
Summary|g++ remove placement new|[4.5/4.6/4.7 Regression]
   |with -O1|g++ remove placement new
   ||with -O1

[Bug rtl-optimization/31830] Input parameter trashed with optimization -O when using a union and bit field

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  2012-02-02 
08:25:41 UTC ---
Since 4.1.x and 4.2.x are no longer maintained and it was fixed in 4.3.0, I am
closing it as fixed.

[Bug fortran/52093] [4.6/4.7 Regression] Extra parenthesis with Size and Shape functions argument cause internal compiler error: Segmentation fault

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org
   Target Milestone|--- |4.6.3

--- Comment #2 from Tobias Burnus  2012-02-02 
08:28:27 UTC ---
For me (on 4.7), SHAPE and LBOUND work, only SIZE and UBOUND cause an ICE.

The segfault happens for SIZE and UBOUND at:

 Invalid read of size 4
at 0x5383E0: gfc_simplify_size (simplify.c:5553)

(When patching, remember that UBOUND((X)) and UBOUND(X) are different, it the
lower bound of X is not 1.)


Untested patch:

--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -5543,2 +5543,3 @@ gfc_simplify_size (gfc_expr *array, gfc_expr *dim,
gfc_expr *kind)
  case INTRINSIC_UMINUS:
+ case INTRINSIC_PARENTHESES:
replacement = array->value.op.op1;

[Bug tree-optimization/52091] [4.7 Regression] ICE: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2012-02-02 
08:29:41 UTC ---
Looking at it.

[Bug rtl-optimization/52092] [4.7 Regression] ICE: internal consistency failure

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  2012-02-02 
08:31:42 UTC ---
Looking at this too.

[Bug rtl-optimization/32605] Missing byte swap optimizations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
 Ever Confirmed|0   |1

--- Comment #3 from Andrew Pinski  2012-02-02 
08:32:00 UTC ---
Confirmed.

[Bug rtl-optimization/47992] ICE: SIGSEGV in ira_reuse_stack_slot (ira-color.c:2887) with -fweb

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-02-02 
08:33:32 UTC ---
This works for me on the trunk.

[Bug tree-optimization/52073] [4.7 Regression] ICE: vector VEC(vec_void_p,base) index domain error, in vinfo_for_stmt at tree-vectorizer.h:620

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2012-02-02 
08:33:01 UTC ---
Fixed.

[Bug target/52079] ICE in aggregate_value_p while building libgo on arm-linux-gnueabihf

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2012-02-02 
08:34:00 UTC ---
Fixed then.

[Bug rtl-optimization/48188] ICE: SIGSEGV in remove_unnecessary_regions (ira-build.c:1855) with --param ira-max-loops-num=0 on basic code

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-02-02 
08:34:57 UTC ---
This works for me on the trunk.  maybe fixed by:
2012-01-19  Vladimir Makarov  

PR rtl-optimization/40761

[Bug libfortran/52087] program does not follow logical rules

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #5 from Tobias Burnus  2012-02-02 
08:34:15 UTC ---
(In reply to comment #0)
>   if ( (nt_save.eqv..true.) .or. (nt_save.eqv..false.) ) then

Side remark: It often is clearer and avoids precedence issues if one writes
instead:
   if (nt_save .or. .not. nt_save) then

The .eqv. and .neqv. operators are then only used when comparing two logical
variables with each other.

[Bug target/52079] ICE in aggregate_value_p while building libgo on arm-linux-gnueabihf

[doko at gcc dot gnu.org]

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

--- Comment #6 from Matthias Klose  2012-02-02 
08:30:34 UTC ---
builds with this patch; testsuite still running

[Bug tree-optimization/47258] [4.5/4.6/4.7 Regression] Extra instruction generated in 4.5.2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.4.0
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-11/msg01865.htm
   ||l
   Keywords||missed-optimization
  Component|rtl-optimization|tree-optimization
 Resolution||FIXED
Summary|Extra instruction generated |[4.5/4.6/4.7 Regression]
   |in 4.5.2|Extra instruction generated
   ||in 4.5.2
   Target Milestone|--- |4.7.0
  Known to fail||4.5.2, 4.6.0, 4.7.0

--- Comment #8 from Andrew Pinski  2012-02-02 
08:38:55 UTC ---
Fixed for 4.7.0 by:

r181476 | wschmidt | 2011-11-18 06:15:38 -0800 (Fri, 18 Nov 2011) | 6 lines

2011-11-18  Bill Schmidt  

* tree-outof-ssa.c (insert_back_edge_copies):  Add call to
mark_dfs_back_edges.

[Bug target/36927] Altivec #pragma's can be implemented now

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2012-02-02 
08:40:00 UTC ---
Confirmed.

[Bug rtl-optimization/47379] fwprop1 generates bad codes for x86-64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  2012-02-02 
08:49:21 UTC ---
Can you try after:
2011-12-19  Richard Sandiford  

PR rtl-optimization/42839
* fwprop.c (forward_propagate_subreg): Skip the SIGN/ZERO_EXTEND
optimization if the source register is already extended.

[Bug rtl-optimization/46943] Unnecessary ZERO_EXTEND

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
 Ever Confirmed|0   |1

--- Comment #2 from Andrew Pinski  2012-02-02 
08:51:50 UTC ---
Confirmed.

[Bug boehm-gc/48514] [4.6] boehm gc incorrectly compile using __declspec(dllexport) on i686-w64-mingw32 target

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
 CC||ktietz at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug rtl-optimization/49800] [4.7 Regression] segfault with -fsched-pressure -fdump-rtl-sched1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|segfault with   |[4.7 Regression] segfault
   |-fsched-pressure|with -fsched-pressure
   |-fdump-rtl-sched1   |-fdump-rtl-sched1

--- Comment #1 from Andrew Pinski  2012-02-02 
08:53:43 UTC ---
Does this still fail?

[Bug middle-end/51994] [4.6/4.7 Regression] git-1.7.8.3 miscompiled due to negative bitpos from get_inner_reference

[rguenther at suse dot de]

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

--- Comment #34 from rguenther at suse dot de  
2012-02-02 08:56:04 UTC ---
On Wed, 1 Feb 2012, ebotcazou at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
> 
> --- Comment #32 from Eric Botcazou  2012-02-01 
> 16:34:30 UTC ---
> > The base object can be an indirect reference, so yes, there doesn't have
> > to be an overall positive offset (well, yes, to the _real_ object,
> > but we don't see that).
> 
> If this is an indirect reference, there is no base object by definition.  So
> I'm not sure we should care in get_inner_reference and, in any case, I'm not
> sure what to do.  Probably avoid sending MEM_REF to get_inner_reference in 
> this
> case,
> after all it's clearly not a handled_component_p-like thing.

Well, you can have component refs wrapped around a MEM_REF (or formerly
an INDIRECT_REF).  The only difference now is that the MEM_REF may
have a (negative) constant offset embedded.  Now, only if the MEM_REF
is based on an ADDR_EXPR (and thus a real object) we factor in its
(possibly negative) offset to bitpos.  So, hum - now I don't see
as easily that we can get a negative bitpos from a not
undefined input ... (maybe except for the Ada fat pointer case).

So your patch is probably ok (can you try verifying we don't get
(too much) codegen differences on a bootstrap?)

Richard.

[Bug rtl-optimization/49800] [4.7 Regression] segfault with -fsched-pressure -fdump-rtl-sched1

[krebbel at gcc dot gnu.org]

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

--- Comment #2 from Andreas Krebbel  2012-02-02 
08:58:57 UTC ---
(In reply to comment #1)
> Does this still fail?

Still fails with r183790.

[Bug tree-optimization/52091] [4.7 Regression] ICE: verify_gimple failed

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-02-02 
09:00:36 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178728

[Bug target/52086] [4.7 Regression] ICE caused by wrong peephole2 for QImode mem += reg followed by test

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2012-02-02 
09:05:03 UTC ---
Author: jakub
Date: Thu Feb  2 09:04:57 2012
New Revision: 183830

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183830
Log:
PR target/52086
* config/i386/i386.md (*addqi_2 peephole with SImode addition): Check
that operands[2] is either immediate, or q_regs_operand.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr52086.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug target/52086] [4.7 Regression] ICE caused by wrong peephole2 for QImode mem += reg followed by test

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Jakub Jelinek  2012-02-02 
09:15:55 UTC ---
Fixed.

[Bug fortran/52093] [4.6/4.7 Regression] Extra parenthesis with Size and Shape functions argument cause internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug rtl-optimization/52092] [4.7 Regression] ICE: internal consistency failure

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-02-02 
09:20:03 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183296

[Bug c++/52094] New: g++ yields different behaviour for postfix increment and decrement operators with fundamental types vs. classes

[dicomj23 at gmail dot com]

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

 Bug #: 52094
   Summary: g++ yields different behaviour for postfix increment
and decrement operators with fundamental types vs.
classes
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dicom...@gmail.com

[Bug c++/52094] internal compiler error: Segmentation fault (program cc1plus)

[dicomj23 at gmail dot com]

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

Dico  changed:

   What|Removed |Added

Summary|g++ yields different|internal compiler error:
   |behaviour for postfix   |Segmentation fault (program
   |increment and decrement |cc1plus)
   |operators with fundamental  |
   |types vs. classes   |

--- Comment #1 from Dico  2012-02-02 10:04:30 UTC ---
user:$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6.1/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=i686-linux-gnu
--host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 
user:$ 



user$ gcc main.cpp & cat main.cpp
[1] 31057
namespace N { struct A { struct Inner; }; struct Inner {}; }
namespace NN { struct AA : N::A {}; struct AA::Inner : N::Inner {}; }

int main() { return 0; }
user$ gcc: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/52094] ICE on definition of nested class in wrong namespace scope with wrong nested-name-qualifier

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
Summary|internal compiler error:|ICE on definition of nested
   |Segmentation fault (program |class in wrong namespace
   |cc1plus)|scope with wrong
   ||nested-name-qualifier
 Ever Confirmed|0   |1
  Known to fail||4.4.3, 4.5.2, 4.6.2, 4.7.0

--- Comment #2 from Jonathan Wakely  2012-02-02 
10:23:24 UTC ---
Reduced:

namespace N { struct A { struct Inner; }; }
namespace NN { struct AA : N::A {}; struct AA::Inner {}; }

[Bug c++/52094] ICE on definition of nested class in wrong namespace scope with wrong nested-name-qualifier

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2012-02-02 
10:25:54 UTC ---
If the nested class is declared in an enclosing namespace scope (as required)
but still with the nested-name-qualifier of the derived type, G++ accepts it:

namespace N { struct A { struct Inner; }; }
namespace NN { struct AA : N::A {}; }
struct NN::AA::Inner {}; 

Clang++ and Comeau both reject this.

[Bug c++/52094] ICE on definition of nested class in wrong namespace scope with wrong nested-name-qualifier

[dicomj23 at gmail dot com]

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

--- Comment #4 from Dico  2012-02-02 10:34:41 UTC ---
I agree, but they don't perform a segmentation fault

[Bug c++/52088] [4.7 Regression] ICE in "delete" with template convertion operator

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords|lto |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2012-02-02 
10:35:12 UTC ---
Confirmed.

[Bug c++/52094] ICE on definition of nested class in wrong namespace scope with wrong nested-name-qualifier

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-02-02 
10:43:33 UTC ---
Why do you think I confirmed the bug and changed its status to NEW?

[Bug tree-optimization/52081] Missed tail merging with pure calls

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org 2012-02-02 10:46:42 UTC ---
submitted patch: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00078.html

[Bug c++/17729] [4.4/4.5/4.6/4.7 Regression] Duplicate __attribute__((deprecated)) warning

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

  Attachment #26539|0   |1
is obsolete||

--- Comment #25 from Iain Sandoe  2012-02-02 10:51:32 
UTC ---
Created attachment 26550
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26550
fix that covers pr50308 as well.

The problem I perceive is that we have a set of tests for deprecation sprinkled
over the code.  This means that each time we uncover a new pathway - e.g.
pr50308 there is (potentially) some amendment required.

What I can't see (because I don't know the c++ FE well enough) is whether there
is a single place that a [possibly more sophisticated] test could be made.

For example, since the deprecation state of items does not alter the outcome of
parsing, but only the presence of warning/error, perhaps when one logically
reaches the ";" that would be a place to check the preceding statement for
deprecated items?

Anyway, the attached patch deals with the fact that we can't check a function
ID for deprecation because it might be later overloaded - but also, that we
can't delegate all of the checking to the call processing - because function
ids might be used without a call.

[Bug boehm-gc/48514] [4.6] boehm gc incorrectly compile using __declspec(dllexport) on i686-w64-mingw32 target

[ktietz at gcc dot gnu.org]

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

--- Comment #2 from Kai Tietz  2012-02-02 10:51:56 
UTC ---
well, the underlying issue is here the wrong assumption of the meaning of _DLL
macro for Windows targets.  This macro gets defined, if shared (means DLL)
version of msvcrt.dll is used and has nothing to do with the fact, if a DLL is
build, or not.

I will prepare a patch for it

[Bug c++/50308] __attribute__((deprecated)) incorrectly generates warning in ADL lookup

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe  2012-02-02 10:54:44 
UTC ---
Created attachment 26551
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26551
test-case

see PR17729 for an updated patch that also passes for this PR.

Attached, version of the example problem set up as a test-case for the
test-suite.

[Bug c++/50308] __attribute__((deprecated)) incorrectly generates warning in ADL lookup

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  2012-02-02 10:59:40 
UTC ---
Comment on attachment 26551
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26551
test-case

>  // The original reported fault...
>  A (x); // { dg-bogus ".A. is deprecated .declared at .*pr50308-1.C:4." "" }

duh, wrong version attached should be:

  A (x); // { dg-bogus ".void A.int.. is deprecated .declared
at.*pr50308-1.C:4." "" }

[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data

[gcc-bugs at tesarici dot cz]

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

Petr Tesarik  changed:

   What|Removed |Added

 CC||gcc-bugs at tesarici dot cz

--- Comment #9 from Petr Tesarik  2012-02-02 
11:00:50 UTC ---
OK, my minimal test case removed the "volatile" keyword by mistake.

The real code in BTRFS has the volatile for the lock value which precedes the
bitfield, so the corresponding structure would be:

struct x {
long a;
volatile unsigned int lock;   /* <- note the "volatile" here */
unsigned int full : 1;
};

Now, GCC should honour that the value of "lock" can change any time, so it must
not assume that writing back the same value a few cycles later is safe.

[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Guenther  2012-02-02 
11:08:56 UTC ---
(In reply to comment #9)
> OK, my minimal test case removed the "volatile" keyword by mistake.
> 
> The real code in BTRFS has the volatile for the lock value which precedes the
> bitfield, so the corresponding structure would be:
> 
> struct x {
> long a;
> volatile unsigned int lock;   /* <- note the "volatile" here */
> unsigned int full : 1;
> };
> 
> Now, GCC should honour that the value of "lock" can change any time, so it 
> must
> not assume that writing back the same value a few cycles later is safe.

volatiles on single structure members is of course under- (or even
un-)specified.  Consider

struct x {
  int i : 1;
  volatile int j : 1;
};

Where we clearly cannot access i without modifying j (but it's still
valid C).  So I don't think that a volatile member inside a non-volatile
struct guarantees anything.

Now, with

struct x {
long a;
volatile unsigned int lock;
unsigned int full : 1;
};

void
wrong(volatile struct x *ptr)
{
  ptr->full = 1;
}

IA64 uses

.mmi
ld8.acq r14 = [r32]
;;
nop 0
dep r14 = r15, r14, 32, 1
;;
.mib
st8.rel [r32] = r14

which seems to be an attempt to work around this issue (albeit a
possibly very slow one).

[Bug target/50077] FAIL: gcc.target/i386/pr49866.c (test for excess errors) on x86_64-apple-darwin10

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin10   |x86_64-apple-darwin10,
   ||i?86-apple-darwin9
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
   Host|x86_64-apple-darwin10   |
 Ever Confirmed|0   |1
  Build|x86_64-apple-darwin10   |

--- Comment #2 from Iain Sandoe  2012-02-02 11:40:03 
UTC ---
Fails at m64 on i686-darwin9 too.

the code below is obviously incorrect for m64 x86 Darwin;  so, we just don't
handle the large model.

movabsq $_GLOBAL_OFFSET_TABLE_-L7, %r11
pushq   %r15
LCFI0:
movq%rcx, %r15
movabsq $_baz@PLTOFF, %rax
pushq   %r14
LCFI1:
movabsq $_fn2@PLTOFF, %r14
pushq   %r13
LCFI2:
movabsq $_fn@PLTOFF, %r13
pushq   %r12

--

clang seems to support -mcmodel=large - at least at 3.1 - so any necessary
ld64/dyld support is available.

This is not likely to get fixed in the short term (certainly not in stage 4) -
so we'll have to decide between XFAIL/tolerate the noise in the error logs.

[Bug lto/51765] Testsuite ICEs with -flto

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-02-02 
11:46:10 UTC ---
+FAIL: g++.dg/cpp0x/variadic-init.C (internal compiler error)
-FAIL: g++.dg/tm/pr45940-3.C -std=gnu++98 (internal compiler error)
-FAIL: g++.dg/tm/pr45940-3.C -std=gnu++11 (internal compiler error)
-FAIL: g++.dg/tm/pr45940-4.C -std=gnu++98 (internal compiler error)
-FAIL: g++.dg/tm/pr45940-4.C -std=gnu++11 (internal compiler error)
-FAIL: gcc.dg/O16384.c (internal compiler error)
-FAIL: gcc.dg/pr37106-1.c (internal compiler error)
-FAIL: gcc.dg/pr43562.c (internal compiler error)
-FAIL: gcc.dg/pr43564.c (internal compiler error)
-FAIL: gcc.target/i386/funcspec-9.c (internal compiler error)
-FAIL: gcc.target/i386/opt-1.c (internal compiler error)
-FAIL: gcc.target/i386/opt-2.c (internal compiler error)

So, TM and C ICEs are gone, one new C++ ICE appears:

lto1: internal compiler error: in lto_output_varpool_node, at
lto-cgraph.c:595^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See  for instructions.^M

The fortran ICEs prevail.

[Bug tree-optimization/52091] [4.7 Regression] ICE: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  2012-02-02 
12:06:27 UTC ---
Executable testcase:

/* PR tree-optimization/52091 */

int b, c, d, f;
unsigned h;
extern void abort (void);

int
main ()
{
  d = -1;
  h = 65;
  asm volatile ("" : : : "memory");
  for (f = 0; f < 4; f++)
{
  h &= (unsigned short) d;
  for (b = 0; b <= 1; b++)
{
  c = 0;
  d &= 1;
}
}
  asm volatile ("" : : : "memory");
  if (b != 2 || c != 0 || d != 1 || f != 4 || h != 1)
abort ();
  return 0;
}

Following patch fixes the ICE:
--- gcc/tree-vect-stmts.c.jj2012-02-01 10:33:58.0 +0100
+++ gcc/tree-vect-stmts.c2012-02-02 11:50:42.623948066 +0100
@@ -1294,7 +1294,11 @@ vect_get_vec_def_for_operand (tree op, g

 /* Get the def before the loop  */
 op = PHI_ARG_DEF_FROM_EDGE (def_stmt, loop_preheader_edge (loop));
-return get_initial_def_for_reduction (stmt, op, scalar_def);
+vec_oprnd = get_initial_def_for_reduction (stmt, op, scalar_def);
+if (!is_gimple_val (vec_oprnd))
+  vec_oprnd = vect_init_vector (stmt, vec_oprnd,
+TREE_TYPE (vec_oprnd), NULL);
+return vec_oprnd;
  }

 /* Case 5: operand is defined by loop-header phi - induction.  */
but just turns ice-on-valid-code into wrong-code, h is 65 when vectorizing.

Ira, could you please look at this?  Thanks.

OT, it is strange that we are creating a reduction for a loop which loops
exactly as many times as there are units in the vector, that doesn't seem to be
profitable.

My other attempt to fix the ICE was:
--- gcc/tree-vect-loop.c.jj2011-12-16 08:37:45.0 +0100
+++ gcc/tree-vect-loop.c2012-02-02 11:57:25.354607843 +0100
@@ -3370,7 +3370,10 @@ get_initial_def_for_reduction (gimple st
 if (TREE_CONSTANT (init_val))
   init_def = build_vector (vectype, t);
 else
-  init_def = build_constructor_from_list (vectype, t);
+  {
+init_def = build_constructor_from_list (vectype, t);
+init_def = vect_init_vector (stmt, init_def, vectype, NULL);
+  }

 break;
but that ICEs on the testcase, because the other caller of
get_initial_def_for_reduction is calling vect_init_vector immediately after it,
with a different stmt than was passed to get_initial_def_for_reduction, and
this resulted in definition not dominating the use.  Wonder if that isn't
another bug.

[Bug target/52080] Stores to bitfields introduce a store-data-race on adjacent data

[gcc-bugs at tesarici dot cz]

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

--- Comment #11 from Petr Tesarik  2012-02-02 
12:39:25 UTC ---
(In reply to comment #10)
> IA64 uses
> 
> .mmi
> ld8.acq r14 = [r32]
> ;;
> nop 0
> dep r14 = r15, r14, 32, 1
> ;;
> .mib
> st8.rel [r32] = r14
> 
> which seems to be an attempt to work around this issue (albeit a
> possibly very slow one).

Are you referring to the ".acq" and ".rel" forms? That doesn't change the
situation at all. All it does is ensure correct memory ordering with respect to
external visibility, but it does nothing to avoid the race condition.

[Bug rtl-optimization/52092] [4.7 Regression] ICE: internal consistency failure

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-02-02 
13:14:37 UTC ---
Created attachment 26552
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26552
gcc47-pr52092.patch

Untested fix.

[Bug tree-optimization/52091] [4.7 Regression] ICE: verify_gimple failed

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 CC||irar at il dot ibm.com

--- Comment #5 from Ira Rosen  2012-02-02 13:22:53 UTC 
---
(In reply to comment #4)

I think that the problem here is that 
D.2030_19 = prephitmp.17_21 & 65535
is falsely initialized as reduction, while it isn't a reduction. The mistake
occurs because its def_stmt, 
prephitmp.17_21 = PHI  ,
is a phi node marked as double reduction:

:
  # f.6_36 = PHI 
  # prephitmp.17_21 = PHI  - double reduction phi
   ...
  D.2030_19 = prephitmp.17_21 & 65535; - not a reduction stmt
   ...
:
  # b.4_41 = PHI 
   ...
  d.3_9 = d_lsm.23_31 & 1;
   ...

:
  # d.3_44 = PHI- double reduction stmt

I think we should fail to vectorize D.2030_19 = prephitmp.17_21 & 65535, or any
other non-phi/not vect_double_reduction_def stmt with a double reduction phi as
a def_stmt.

We can either check this in every vectorizable_* for every operand, like this:
Index: tree-vect-stmts.c
===
--- tree-vect-stmts.c   (revision 183125)
+++ tree-vect-stmts.c   (working copy)
@@ -3326,7 +3326,8 @@ vectorizable_operation (gimple stmt, gimple_stmt_i

   op0 = gimple_assign_rhs1 (stmt);
   if (!vect_is_simple_use_1 (op0, loop_vinfo, bb_vinfo,
-&def_stmt, &def, &dt[0], &vectype))
+&def_stmt, &def, &dt[0], &vectype)
+  || dt[0] == vect_double_reduction_def)
 {
   if (vect_print_dump_info (REPORT_DETAILS))
 fprintf (vect_dump, "use not simple.");


or pass stmt or stmt_info to vect_is_simple_use and check it there.


> OT, it is strange that we are creating a reduction for a loop which loops
> exactly as many times as there are units in the vector, that doesn't seem to 
> be
> profitable.
> 

Right, but doesn't cost model catch this?

[Bug middle-end/51998] compiler hangs on self-recursive alias attribute

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka  2012-02-02 
13:29:34 UTC ---
Author: hubicka
Date: Thu Feb  2 13:29:31 2012
New Revision: 183836

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

PR middle-end/51998
* cgraphunit.c (cgraph_analyze_function): Break cyclic aliases.
* varpool.c (varpool_analyze_pending_decls): Likewise.

* testsuite/gcc.dg/alias-12.c: New testcase.
* testsuite/gcc.dg/alias-13.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/alias-12.c
trunk/gcc/testsuite/gcc.dg/alias-13.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varpool.c

[Bug middle-end/51998] compiler hangs on self-recursive alias attribute

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Jan Hubicka  2012-02-02 
13:32:20 UTC ---
Updated the error message (thanks, Jakub) and comitted.

[Bug c++/21386] Inconsistent diagnostics for taking address of rvalue

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  2012-02-02 
13:33:59 UTC ---
4.6 gives:

x.cc: In function 'int main()':
x.cc:6:19: error: lvalue required as unary '&' operand
x.cc:7:17: error: taking address of temporary [-fpermissive]

[Bug c/19541] need another option to support what -I- did just besides -iquote

[achurch+gcc at achurch dot org]

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

--- Comment #22 from Andrew Church  2012-02-02 
13:38:49 UTC ---
Created attachment 26553
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26553
Remove deprecation warning for -I- (gcc-4.6.2)

Patch against gcc-4.6.2 to remove the deprecation warning for -I- since there's
no complete replacement for it yet.  This will probably ruffle some feathers;
sorry about that.

FWIW, it's my intention to keep this patch updated (at
http://achurch.org/patch-pile/#gcc) until either it's officially undeprecated
or a replacement for the "ignore source directory" functionality of -I- is
available.

[Bug tree-optimization/52091] [4.7 Regression] ICE: verify_gimple failed

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-02-02 
13:41:01 UTC ---
(In reply to comment #5)
> I think we should fail to vectorize D.2030_19 = prephitmp.17_21 & 65535, or 
> any
> other non-phi/not vect_double_reduction_def stmt with a double reduction phi 
> as
> a def_stmt.
> 
> We can either check this in every vectorizable_* for every operand, like this:
> Index: tree-vect-stmts.c
> ===
> --- tree-vect-stmts.c   (revision 183125)
> +++ tree-vect-stmts.c   (working copy)
> @@ -3326,7 +3326,8 @@ vectorizable_operation (gimple stmt, gimple_stmt_i
> 
>op0 = gimple_assign_rhs1 (stmt);
>if (!vect_is_simple_use_1 (op0, loop_vinfo, bb_vinfo,
> -&def_stmt, &def, &dt[0], &vectype))
> +&def_stmt, &def, &dt[0], &vectype)
> +  || dt[0] == vect_double_reduction_def)
>  {
>if (vect_print_dump_info (REPORT_DETAILS))
>  fprintf (vect_dump, "use not simple.");
> 
> 
> or pass stmt or stmt_info to vect_is_simple_use and check it there.

Are you going to write a patch for this?  Not sure how exactly would you like
it to look up.

> > OT, it is strange that we are creating a reduction for a loop which loops
> > exactly as many times as there are units in the vector, that doesn't seem 
> > to be
> > profitable.
> > 
> 
> Right, but doesn't cost model catch this?

For simple testcases it does apparently.

[Bug c++/52088] [4.7 Regression] ICE in "delete" with template convertion operator

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2012-02-02 
13:53:52 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183221 aka
PR51827 fix.

[Bug target/50499] segmentation fault in gcc.dg/compat/struct-by-value-1 c_compat_x_tst.o-c_compat_y_tst.o with ppc -m64

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Peter Bergner  2012-02-02 
15:07:34 UTC ---
This is a duplicate of PR36043.

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

[Bug middle-end/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #18 from Peter Bergner  2012-02-02 
15:07:34 UTC ---
*** Bug 50499 has been marked as a duplicate of this bug. ***

[Bug target/50499] segmentation fault in gcc.dg/compat/struct-by-value-1 c_compat_x_tst.o-c_compat_y_tst.o with ppc -m64

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #4 from Peter Bergner  2012-02-02 
15:08:50 UTC ---
Closing as duplicate.

[Bug tree-optimization/52091] [4.7 Regression] ICE: verify_gimple failed

[irar at il dot ibm.com]

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

--- Comment #7 from Ira Rosen  2012-02-02 15:16:18 UTC 
---
(In reply to comment #6)
> (In reply to comment #5)
> > I think we should fail to vectorize D.2030_19 = prephitmp.17_21 & 65535, or 
> > any
> > other non-phi/not vect_double_reduction_def stmt with a double reduction 
> > phi as
> > a def_stmt.
> > 
> > We can either check this in every vectorizable_* for every operand, like 
> > this:
> > Index: tree-vect-stmts.c
> > ===
> > --- tree-vect-stmts.c   (revision 183125)
> > +++ tree-vect-stmts.c   (working copy)
> > @@ -3326,7 +3326,8 @@ vectorizable_operation (gimple stmt, gimple_stmt_i
> > 
> >op0 = gimple_assign_rhs1 (stmt);
> >if (!vect_is_simple_use_1 (op0, loop_vinfo, bb_vinfo,
> > -&def_stmt, &def, &dt[0], &vectype))
> > +&def_stmt, &def, &dt[0], &vectype)
> > +  || dt[0] == vect_double_reduction_def)
> >  {
> >if (vect_print_dump_info (REPORT_DETAILS))
> >  fprintf (vect_dump, "use not simple.");
> > 
> > 
> > or pass stmt or stmt_info to vect_is_simple_use and check it there.
> 
> Are you going to write a patch for this?  Not sure how exactly would you like
> it to look up.
> 

We need to check that if def_stmt is vect_double_reduction_def, the stmt itself
needs to be vect_double_reduction_def. We know def_type (dt in the above patch)
of def_stmt from vect_is_simple_use. We call it from all the vectorizable_*
functions. We don't pass the stmt itself to vect_is_simple_use, therefore, we
should either do that and perform the check in vect_is_simple_use, or check
this in all the vectorizable_* (except perhaps vectorizable_reduction). I
prefer to pass stmt or stmt_info to vect_is_simple_use.

I can do this on Sunday. You are welcome to do this yourself. Whatever you
prefer.

[Bug middle-end/48071] [4.6/4.7 Regression] Blank line after 'all warnings being treated as errors'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2012-02-02 
15:18:59 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158168

[Bug middle-end/48071] [4.6/4.7 Regression] Blank line after 'all warnings being treated as errors'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  2012-02-02 
15:20:15 UTC ---
Created attachment 26554
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26554
gcc47-pr48071.patch

Untested fix.

[Bug middle-end/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #19 from Peter Bergner  2012-02-02 
15:46:09 UTC ---
>From PR50499, we have this similar test case that fails on powerpc64-linux:

struct S50 { char i[9]; };
extern void bar (struct S50);
void
foo (struct S50 *p)
{
  bar (*p);
}

Gives (using -m64 -O1):

...
ld 3,0(3)
ld 4,8(9)
bl bar

[Bug target/50077] FAIL: gcc.target/i386/pr49866.c (test for excess errors) on x86_64-apple-darwin10

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2012-02-02 
16:06:05 UTC ---
> clang seems to support -mcmodel=large - at least at 3.1 - so any necessary
> ld64/dyld support is available.

The test compiles (using -c) with

Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn)

> This is not likely to get fixed in the short term (certainly not in stage 4) -
> so we'll have to decide between XFAIL/tolerate the noise in the error logs.

When XFAILed, this kind of bug disappears from the radar scopes and tends to
rot forever (see pr10901) until it resurfaces in a nasty way. I'ld prefer to
change the summary to something such as "large model is broken on
*86*-apple-darwin*" to point to the real problem.

[Bug tree-optimization/52095] New: [4.7 regression] ICE compiling gcc.dg/sms-7.c: SEGV in fprintf

[ro at gcc dot gnu.org]

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

 Bug #: 52095
   Summary: [4.7 regression] ICE compiling gcc.dg/sms-7.c: SEGV in
fprintf
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
  Host: i386-pc-solaris2.10
Target: i386-pc-solaris2.10
 Build: i386-pc-solaris2.10


Since 20111213, gcc.dg/sms-7.c FAILs on Solaris 10/x86, both 32 and 64-bit:

FAIL: gcc.dg/sms-7.c (internal compiler error)
FAIL: gcc.dg/sms-7.c (test for excess errors)
WARNING: gcc.dg/sms-7.c compilation failed to produce executable

Running cc1

$ cc1 -fpreprocessed sms-7.i -quiet -mtune=generic -march=pentium4 -O3
-fmodulo-sched -fstrict-aliasing -fdump-rtl-sms -fmodulo-sched-allow-regmoves
--param sms-min-sc=1 -o sms-7.s

gives:

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/sms-7.c: In function 'main':
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/sms-7.c:45:1: internal
compiler error: Segmentation Fault

With gdb, I find:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xfee063dc in strlen () from /lib/libc.so.1
(gdb) where
#0  0xfee063dc in strlen () from /lib/libc.so.1
#1  0xfee6169a in _ndoprnt () from /lib/libc.so.1
#2  0xfee64229 in fprintf () from /lib/libc.so.1
#3  0x088689b0 in sms_schedule ()
at /vol/gcc/src/hg/trunk/local/gcc/modulo-sched.c:1414
#4  rest_of_handle_sms ()
at /vol/gcc/src/hg/trunk/local/gcc/modulo-sched.c:3338
#5  0x083bb744 in execute_one_pass (pass=pass@entry=0x8d82be0)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2081
#6  0x083bba9d in execute_pass_list (pass=0x8d82be0)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2136
#7  0x083bbab0 in execute_pass_list (pass=0x8d7f0a0)
at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2137
#8  0x08497e86 in tree_rest_of_compilation (fndecl=0xfeaaa780)
at /vol/gcc/src/hg/trunk/local/gcc/tree-optimize.c:422
#9  0x0822ff07 in cgraph_expand_function (node=0xfea0e47c)
at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1819
#10 0x08231795 in cgraph_expand_all_functions ()
at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1886
#11 cgraph_optimize () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2200
#12 0x08231cbf in cgraph_finalize_compilation_unit ()
at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1328
#13 0x0816dc1c in c_write_global_declarations ()
at /vol/gcc/src/hg/trunk/local/gcc/c-decl.c:10030
#14 0x0845241b in compile_file ()
at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:573
#15 do_compile () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1938
#16 toplev_main (argc=15, argv=0x80474c0)
at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:2014
#17 0x08af940b in main (argc=15, argv=0x80474c0)
at /vol/gcc/src/hg/trunk/local/gcc/main.c:36

It turns out that sms_schedule calls fprintf with a NULL ptr since
insn_file(insn) is NULL at this point.

This is a regression from 4.6.

  Rainer

[Bug driver/52096] New: -dumpmachine does not respect -m32

[matze at braunis dot de]

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

 Bug #: 52096
   Summary: -dumpmachine does not respect -m32
Classification: Unclassified
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ma...@braunis.de


On a x86_64-linux-gnu machine calling
  gcc -m32 -dumpmachine
gives
 x86_64-linux-gnu
while I would have expected something like
 i686-linux-gnu

Docu says "print the compilers target machine" in the presence of "-m32" I'm
not sure that the right answer would be. The most usefull answer for me would
be i686-linux-gnu, as I am using gcc -dumpmachine in my makefiles and users
passing in CFLAGS="-m32" break the build.

[Bug driver/52096] -dumpmachine does not respect -m32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Andrew Pinski  2012-02-02 
16:30:16 UTC ---
No, dumpmachine should dump the target which gcc was built.  It should not be
made multilib aware.

If you want to make sure you are compiling for 32bit, then check the
preprocessed predefines instead.

[Bug driver/52096] -dumpmachine does not respect -m32

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-02-02 
16:30:59 UTC ---
Also the dumpmachine does not work for things like x32 where just the ABI
changes.

[Bug middle-end/27238] mips64: wrong code for gcc.c-torture/execute/20050713-1.c with -O2 or -Os

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  2012-02-02 
17:24:50 UTC ---
Fixed in at least 4.3.3 and above.

[Bug middle-end/46119] -fsplit-stack -fstack-protector-all - code crashes when passing large struct via stack

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-02-02 
17:26:40 UTC ---
This works for me on the trunk

[Bug middle-end/45410] constant not optimized / propagated

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
 Ever Confirmed|0   |1

--- Comment #6 from Andrew Pinski  2012-02-02 
17:28:36 UTC ---
Confirmed.

[Bug middle-end/45364] Compiling wine's directx.c with -O1 -g takes a very long time

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
   Host|i686-pc-linux-gnu   |
 Ever Confirmed|0   |1
  Build|i686-pc-linux-gnu   |
   Severity|enhancement |minor

--- Comment #7 from Andrew Pinski  2012-02-02 
17:35:42 UTC ---
With checking still enabled we get:
-O1 -g:
 var-tracking dataflow   :   7.73 (57%) usr   0.05 (12%) sys   7.78 (56%) wall 
 0 kB ( 0%) ggc
-O2 -g:
 var-tracking dataflow   :  15.23 (45%) usr   0.07 (13%) sys  15.33 (45%) wall 
 0 kB ( 0%) ggc

-O2:
 CPROP   :   4.35 (27%) usr   0.02 ( 4%) sys   4.36 (27%) wall 
  2486 kB ( 3%) ggc


on the trunk.
I have not checked without checking enabled.

So confirmed but it has improved a lot already.

[Bug driver/45356] ICE: in main, at gcc.c:7175 with -fcompare-debug -save-temps and unusable PCH file

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
  Component|middle-end  |driver
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2012-02-02 
17:38:46 UTC ---
Confirmed.

[Bug middle-end/31279] Uninitialized warning for call-by-reference arguments with known intent(in)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2012-02-02 
17:49:32 UTC ---
Confirmed.

[Bug middle-end/38264] tree_forwarder_block_p says no to first basic block

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
 Ever Confirmed|0   |1

--- Comment #3 from Andrew Pinski  2012-02-02 
17:58:52 UTC ---
Confirmed.
The code looks slightly different now as find_edge has been inlined and merged
with checking for eh edges.

[Bug middle-end/38537] -fstrict-aliasing and -Wstrict-aliasing do not work

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
 Ever Confirmed|0   |1

--- Comment #4 from Andrew Pinski  2012-02-02 
18:04:08 UTC ---
Hmm, on the trunk we don't get any warnings for -W -Wall -O2 or -O2
-Wstrict-aliasing=3.
Confirmed then.

[Bug rtl-optimization/47379] fwprop1 generates bad codes for x86-64

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  2012-02-02 18:11:24 
UTC ---
(In reply to comment #4)
> Can you try after:
> 2011-12-19  Richard Sandiford  
> 
> PR rtl-optimization/42839
> * fwprop.c (forward_propagate_subreg): Skip the SIGN/ZERO_EXTEND
> optimization if the source register is already extended.

GCC 4.7.0 20120131 still does it.

[Bug middle-end/34285] buffer overflow incorrectly detected

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #9 from Andrew Pinski  2012-02-02 
18:26:36 UTC ---
The warning has "fixed" by the patch which changed PR 50460.

[Bug rtl-optimization/49800] [4.7 Regression] segfault with -fsched-pressure -fdump-rtl-sched1

[vmakarov at redhat dot com]

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

--- Comment #3 from Vladimir Makarov  2012-02-02 
18:33:34 UTC ---
I am working on it.

[Bug middle-end/35696] Segmentation fault

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  2012-02-02 
18:37:07 UTC ---
The testcase in comment #1 works for me with 4.3 and 4.4

[Bug java/48512] [4.6] gcj spec files references incorrectly crtmt.o on i686-w64-mingw32 target

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
 CC||ktietz at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Kai Tietz  2012-02-02 18:37:41 
UTC ---
Confirmed.

Following patch should solve this

Index: gcc/libjava/configure.ac
===
--- gcc.orig/libjava/configure.ac
+++ gcc/libjava/configure.ac
@@ -1150,8 +1150,13 @@ case "$THREADS" in
 # FIXME: In Java we are able to detect thread death at the end of
 # Thread.run() so we should be able to clean up the exception handling
 # contexts ourselves.
-THREADSTARTFILESPEC='crtmt%O%s'
-;;
+case "$host" in
+*-w64-mingw*)
+  ;;
+*)
+  THREADSTARTFILESPEC='crtmt%O%s'
+  ;;
+esac

  none)
 THREADH=no-threads.h

[Bug middle-end/36294] gcc exited and told me to report a bug (details follow)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
 Ever Confirmed|0   |1

--- Comment #7 from Andrew Pinski  2012-02-02 
18:45:03 UTC ---
I have not tested with a release checking enabled compiler but with checking
enabled it takes about a minute to compile at -O2 and takes around 210Megs.

So confirmed.

[Bug middle-end/38518] Excessive compile time with -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-02-02
 Ever Confirmed|0   |1
  Known to fail||4.7.0

--- Comment #4 from Andrew Pinski  2012-02-02 
19:06:47 UTC ---
-ftime-report will report where the extra time is happening.

Anyways confirmed.
 loop unswitching: 308.19 (70%) usr   0.05 ( 4%) sys 308.17 (70%) wall 
   105 kB ( 0%) ggc

[Bug fortran/51522] ICE in gfortran 4.6.2, x86_64

[jb at gcc dot gnu.org]

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

--- Comment #5 from Janne Blomqvist  2012-02-02 19:08:19 
UTC ---
Sorry, I'm unable to reproduce the ICE with today's trunk. I tried to testcase
in comment #4 with and without the fixes from #3 as well as the original
testcase.

[Bug ada/26326] Incorrect installation of libgnarl-4.1.sl and libgnat-4.1.sl

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

   Last reconfirmed||2012-02-02

--- Comment #1 from John David Anglin  2012-02-02 
19:43:36 UTC ---
Still present in 4.6.

[Bug rtl-optimization/49800] [4.7 Regression] segfault with -fsched-pressure -fdump-rtl-sched1

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  2012-02-02 
19:45:09 UTC ---
Author: vmakarov
Date: Thu Feb  2 19:45:04 2012
New Revision: 183843

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183843
Log:
2012-02-02  Vladimir Makarov  

PR rtl-optimization/49800
* haifa-sched.c (sched_init): Call regstat_init_n_sets_and_refs.
(sched_finish): Call regstat_free_n_sets_and_refs.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c

[Bug java/50045] [4.7 regression] ICE in gcc/java/lang.c:427 with -fdump-tree-all

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2012-02-02 
19:45:56 UTC ---
Created attachment 26555
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26555
small testcase (p.class)

[Bug java/50045] [4.7 regression] ICE in gcc/java/lang.c:427 with -fdump-tree-all

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|i686-pc-mingw32 |
 Status|UNCONFIRMED |NEW
  Known to work||4.6.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2012-02-02
 CC||pinskia at gcc dot gnu.org
   Host|i686-pc-cygwin  |
 Ever Confirmed|0   |1
  Known to fail||4.7.0
  Build|i686-pc-cygwin  |

--- Comment #3 from Andrew Pinski  2012-02-02 
19:45:23 UTC ---
Confirmed.  I just ran into this myself.

[Bug middle-end/39885] Missed fre optimization

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #8 from Andrew Pinski  2012-02-02 
19:50:15 UTC ---
Fixed on the trunk.  There is only one load from length left in each of the
functions.

[Bug libstdc++/52068] libc++98.a and libc++11.a are installed

[bkoz at gcc dot gnu.org]

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

--- Comment #1 from Benjamin Kosnik  2012-02-02 
19:59:04 UTC ---
Author: bkoz
Date: Thu Feb  2 19:58:59 2012
New Revision: 183846

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183846
Log:
2012-02-02  Benjamin Kosnik  

PR libstdc++/52068
* src/c++11/Makefile.am (toolexeclib_LTLIBRARIES,
libc__11_la_SOURCES): Remove.
* src/c++11/Makefile.in: Regenerate.
* src/c++98/Makefile.am (toolexeclib_LTLIBRARIES,
libc__98_la_SOURCES): Remove.
* src/c++98/Makefile.in: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++11/Makefile.am
trunk/libstdc++-v3/src/c++11/Makefile.in
trunk/libstdc++-v3/src/c++98/Makefile.am
trunk/libstdc++-v3/src/c++98/Makefile.in

[Bug middle-end/52097] New: ICE: in get_bit_range, at expr.c:4535 with -O -flto -fexceptions -fnon-call-exceptions --param allow-store-data-races=0

[zsojka at seznam dot cz]

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

 Bug #: 52097
   Summary: ICE: in get_bit_range, at expr.c:4535 with -O -flto
-fexceptions -fnon-call-exceptions --param
allow-store-data-races=0
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 26556
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26556
reduced testcase (from gcc.c-torture/execute/20031201-1.c)

Compiler output:
$ gcc -O -flto -fexceptions -fnon-call-exceptions --param
allow-store-data-races=0 testcase.c 
In file included from testcase.c:5:0,
 from :0:
testcase.c: In function 'main':
testcase.c:10:9: internal compiler error: in get_bit_range, at expr.c:4535
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: /mnt/svn/gcc-trunk/binary-latest/bin/gcc returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

Tested revisions:
r183741 - crash

[Bug rtl-optimization/49800] [4.7 Regression] segfault with -fsched-pressure -fdump-rtl-sched1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  2012-02-02 
20:03:08 UTC ---
Fixed.

[Bug libstdc++/52068] libc++98.a and libc++11.a are installed

[bkoz at gcc dot gnu.org]

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

Benjamin Kosnik  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-02-02
 CC||bkoz at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |bkoz at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #2 from Benjamin Kosnik  2012-02-02 
20:03:35 UTC ---
Mine. Fixed.

[Bug libgcj/46082] libgcj fails to build in current 4.5 branch

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  2012-02-02 
20:05:22 UTC ---
What configure flags did you use?
How did you invoke make?
Also what is in your env?

[Bug libgcj/44567] FreeBSD 6.x compile error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  2012-02-02 
20:05:57 UTC ---
Does this still happen?

[Bug libgcj/46999] Problem compiling gcc 4.5.2

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #1 from Andrew Pinski  2012-02-02 
20:04:23 UTC ---
This works for me and others so closing as works for me.

[Bug libgcj/39161] gcc 4.4.0 20090210 - The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug libgcj/39161] gcc 4.4.0 20090210 - The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #9 from Andrew Pinski  2012-02-02 
20:08:07 UTC ---
No feedback about comment #6 and comment #8 for over 7 months so closing.

[Bug libgcj/43258] In-tree build may fail in libjava/classpath/tools

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug libgcj/38414] gcc 4.3-20081204 build broken on OS X 10.4 ppc

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #3 from Andrew Pinski  2012-02-02 
20:10:40 UTC ---
(In reply to comment #2)
> Can you suggest some way of testing that hypothesis?  Or some way of figuring
> out why that build broke when the previous one did not break?  What changed?

Well rm is failing.  That does not make any sense really. Anyways this works
for many other people so closing as worksforme.

[Bug libstdc++/51967] FAIL: libstdc++-prettyprinters/48362.cc

[bkoz at gcc dot gnu.org]

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

Benjamin Kosnik  changed:

   What|Removed |Added

 CC||bkoz at gcc dot gnu.org

--- Comment #4 from Benjamin Kosnik  2012-02-02 
20:17:02 UTC ---


> > do the printers ever work, outside the testsuite?
> 
> No.

Well then, then need to be disabled. 

dg-require-prettyprinters

Should be developed and all the failing pretty printing tests should use it.