[Bug tree-optimization/49959] ABS pattern is not recognized

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-01-21 
08:03:40 UTC ---
If we had a pass which was able to convert:
:
  iftmp.0_6 = (long unsigned int) D.1708_4;
  goto ;

:
  D.1712_8 = -D.1708_4;
  iftmp.0_9 = (long unsigned int) D.1712_8;

:
  # iftmp.0_1 = PHI 

Into:

:
  goto ;

:
  D.1712_8 = -D.1708_4;

:
  # t_N = PHI
  iftmp.0_1 = (long unsigned int)t_n;

And then PHIOPT would recognize it.  So this is really the code commoning.

[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug middle-end/50971] Only one loop detected when there should be two

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  2012-01-21 
08:16:05 UTC ---
I have a patch which fixes this.

[Bug c++/51415] [4.5/4.6/4.7 Regression] Broken diagnostic: 'vec_init_expr' not supported by dump_expr

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-21
Summary|Broken diagnostic:  |[4.5/4.6/4.7 Regression]
   |'vec_init_expr' not |Broken diagnostic:
   |supported by dump_expr  |'vec_init_expr' not
   ||supported by dump_expr
 Ever Confirmed|0   |1

--- Comment #2 from Andrew Pinski  2012-01-21 
08:20:55 UTC ---
Confirmed.  This is a regression as the non -std=c++11 case regressed.

[Bug c++/51421] [c++0x] ICE with invalid use of auto

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  2012-01-21 
08:21:51 UTC ---
Confirmed.

[Bug c++/51422] [c++0x] ICE with invalid lambda expression

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  2012-01-21 
08:22:49 UTC ---
Confirmed.

[Bug middle-end/51928] New: ICE: SIGSEGV in lookup_fnfields_idx_nolazy (search.c:1384) with -fgnu-tm on invalid code

[zsojka at seznam dot cz]

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

 Bug #: 51928
   Summary: ICE: SIGSEGV in lookup_fnfields_idx_nolazy
(search.c:1384) with -fgnu-tm on invalid code
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  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 26400
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26400
preprocessed source (testsuite/g++.dg/parse/crash54.C)

Compiler output:
$ gcc -fgnu-tm crash54.ii
==30972== Invalid read of size 1
==30972==at 0x6E45BD: lookup_fnfields_idx_nolazy(tree_node*, tree_node*)
(search.c:1384)
==30972==by 0x6E833F: look_for_overrides_here(tree_node*, tree_node*)
(search.c:2026)
==30972==by 0x634E10: look_for_tm_attr_overrides(tree_node*, tree_node*)
(class.c:4335)
==30972==by 0x65149B: finish_struct_1(tree_node*) (class.c:4355)
==30972==by 0x6533EC: finish_struct(tree_node*, tree_node*) (class.c:6215)
==30972==by 0x67F0FE: cp_parser_type_specifier(cp_parser*, int,
cp_decl_specifier_seq*, bool, int*, bool*) (parser.c:17977)
==30972==by 0x6930CF: cp_parser_decl_specifier_seq(cp_parser*, int,
cp_decl_specifier_seq*, int*) (parser.c:10701)
==30972==by 0x695A56: cp_parser_simple_declaration(cp_parser*, bool,
tree_node**) (parser.c:10351)
==30972==by 0x69C187: cp_parser_block_declaration(cp_parser*, bool)
(parser.c:10300)
==30972==by 0x6A13EB: cp_parser_declaration(cp_parser*) (parser.c:10196)
==30972==by 0x69FFF7: cp_parser_declaration_seq_opt(cp_parser*)
(parser.c:10082)
==30972==by 0x6A1962: c_parse_file() (parser.c:3791)
==30972==by 0x79F814: c_common_parse_file() (c-opts.c:1117)
==30972==by 0xB8104F: toplev_main(int, char**) (toplev.c:557)
==30972==by 0x66E009C: (below main) (in /lib64/libc-2.13.so)
==30972==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==30972== 
/mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/parse/crash54.C:10:8: internal compiler
error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r183351 - crash

[Bug tree-optimization/35629] [4.4/4.5/4.6/4.7 Regression] gcc.dg/tree-ssa/loop-25.c scan-tree-dump-times profile fails

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  2012-01-21 
09:37:37 UTC ---
I have a fix which I am testing.

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #8 from Iain Sandoe  2012-01-21 10:04:58 
UTC ---
(In reply to comment #7)

Thanks for the debugging Patrick.

> Tracing a bit more, I see that simple_object_mach_o_match() ends with this:
> *errmsg = "Mach-O file found but no segment name specified";
> Indeed, lto-wrapper always gives NULL for the segment name.
> sobj = simple_object_start_read (fd, file_offset, NULL, &errmsg, &err);
> 
> So, since there is no documentation/specification of the
> simple_object_start_read function I cannot say if it is a gcc/lto bug or a
> libiberty bug.

include/simple_object.h:

/* Create an simple_object_read given DESCRIPTOR, an open file
   descriptor, and OFFSET, an offset within the file.  The offset is
   for use with archives, and should be 0 for an ordinary object file.
   The descriptor must remain open until done with the returned
   simple_object_read.  SEGMENT_NAME is used on Mach-O and is required
   on that platform: it means to only look at sections within the
   segment with that name.  It is ignored for other object file
   formats.  On error, this function returns NULL, and sets *ERRMSG to
   an error string and sets *ERR to an errno value or 0 if there is no
   relevant errno.  */

extern simple_object_read *
simple_object_start_read (int descriptor, off_t offset,
  const char *segment_name, const char **errmsg,
  int *err);

> Finally, there is a problem with lto-wrapper.c
>   if (!simple_object_find_section (sobj, LTO_SECTION_NAME_PREFIX "."
> "opts",
>&offset, &length, &errmsg, &err))
> In MacOSX, I don't know the section name for opts (I have __wrapper_index,
> __wrapper_sects, and __wrapper_names) but if I add the segment name 
> "__GNU_LTO"
> , the section name is ".gnu.lto_.opts" (not existing in my files).

the sections are there (inside the wrapper - if you objdump or hexdump -C the
objects you'll see them) and if I apply this hack the link works (the objects
are correctly formed as of now):

Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c   (revision 183359)
+++ gcc/lto-wrapper.c   (working copy)
@@ -479,7 +479,7 @@ run_gcc (unsigned argc, char *argv[])
   fd = open (argv[i], O_RDONLY);
   if (fd == -1)
continue;
-  sobj = simple_object_start_read (fd, file_offset, NULL, &errmsg, &err);
+  sobj = simple_object_start_read (fd, file_offset, "__GNU_LTO", &errmsg,
&err);
   if (!sobj)
{
  close (fd);


... so this is a build/config issue - or, alternatively, the segment name can
be specified as above since it is ignored for non-mach-o platforms.

thanks
Iain

[Bug lto/51916] FAIL: gcc.dg/lto/trans-mem-3 c_lto_trans-mem-3_0.o-c_lto_trans-mem-3_1.o link, -flto (internal compiler error)

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  2012-01-21 10:34:59 
UTC ---
(In reply to comment #8)
> (In reply to comment #7)


> ... so this is a build/config issue - or, alternatively, the segment name can
> be specified as above since it is ignored for non-mach-o platforms.

note:
gcc/lto/lto-object.c 
hardwires this without any ill effect on other platforms.  So, since the test
and the section are lto-specific, I'd suspect that this is the right solution
rather than some tricky config machinery.

[Bug middle-end/51929] New: ICE: verify_cgraph_node failed with -O2 -fno-guess-branch-probability -fipa-cp-clone --param ipa-cp-eval-threshold=0 --param max-inline-insns-single=1

[zsojka at seznam dot cz]

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

 Bug #: 51929
   Summary: ICE: verify_cgraph_node failed with -O2
-fno-guess-branch-probability -fipa-cp-clone --param
ipa-cp-eval-threshold=0 --param
max-inline-insns-single=1
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 26401
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26401
reduced testcase

Compiler output:
$ g++ -O2 -fno-guess-branch-probability -fipa-cp-clone --param
ipa-cp-eval-threshold=0 --param max-inline-insns-single=1 testcase.C
testcase.C:35:19: error: edge points to wrong declaration:
 >
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x7f2b78da4f18
arg-types >>
static autoinline decl_5 QI file testcase.C line 8 col 3 align 16 context
 initial 
abstract_origin 
result 
used ignored VOID file testcase.C line 11 col 3
align 8 context  abstract_origin >
full-name "basic_string<  >::~basic_string() [with
 = void]"
pending-inline-info 0x7f2b78d85a50 template-info 0x7f2b78d7e9c0
struct-function 0x7f2b78da3b40>
 Instead of: >
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x7f2b78d892a0 method
basetype 
arg-types 
chain >>
pointer_to_this >
addressable used public static external autoinline decl_5 QI defer-output
file testcase.C line 8 col 3 align 16 context  initial  abstract_origin 
arguments 
readonly unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x7f2b78d891f8>
readonly used unsigned DI file testcase.C line 8 col 18 size
 unit size 
align 64 context 
abstract_origin  arg-type >
result 
ignored VOID file testcase.C line 11 col 3
align 8 context >
full-name "basic_string<  >::~basic_string() [with
 = void]"
pending-inline-info 0x7f2b78d85b40 template-info 0x7f2b78d7e9c0
struct-function 0x7f2b78c11960>
basic_stringbuf::basic_stringbuf()/9 @0x7f2b78d8f240 (asm:
_ZN15basic_stringbufC2Ev.constprop.3) (inline copy in (static initializers for
testcase.C)/16) availability:local analyzed reachable body local finalized
  called by: stringstream::stringstream()/3 (1.00 per call) (inlined) (can
throw external) 
  calls: void basic_stringbuf::_M_stringbuf_init()/20 (1.00 per call) (can
throw external) basic_string<  >::~basic_string() [with
 = void]/12 (1.00 per call) (can throw external) 
  References:  var:stringstream ss_01 (addr) var:stringstream ss_01 (addr)
fn:/19 (addr)
  Refering this function: 
testcase.C:35:19: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  0x761e4790 in exit () from /lib64/libc.so.6
#1  0x01350802 in diagnostic_action_after_output (context=0x1b01ea0,
diagnostic=Unhandled dwarf expression opcode 0xfa
) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:243
#2  0x0135096e in diagnostic_report_diagnostic (context=0x1b01ea0,
diagnostic=0x7fffd3b0) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:552
#3  0x01351620 in internal_error (gmsgid=) at
/mnt/svn/gcc-trunk/gcc/diagnostic.c:845
#4  0x0084027c in verify_cgraph_node (node=0x75c16240) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:795
#5  0x00840ad8 in verify_cgraph () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:810
#6  verify_cgraph () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:802
#7  0x0084299e in cgraph_materialize_all_clones () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:2607
#8  0x00842b08 in cgraph_optimize () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:2181
#9  0x0084374a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1327
#10 0x0066199b in cp_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/cp/decl2.c:4051
#11 0x00b8109c in compile_file () at
/mnt/svn/gcc-trunk/gcc/toplev.c:573
#12 do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1938
#13 toplev_main (argc=20, argv=0x7fffd778) at
/mnt/svn/gcc-trunk/gcc/toplev.c:2014
#14 0x761cc09d in __libc_start_main () from /lib64/libc.so.6
#15 0x00585bb1 in _start ()

Tested revisions:
r183351 - crash
4.6 - invalid parameter 'ipa-cp-eval-threshold'

[Bug c++/51930] New: Explicitly instantiated template gets hidden visibility

[s...@s-e-f-i.de]

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

 Bug #: 51930
   Summary: Explicitly instantiated template gets hidden
visibility
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@s-e-f-i.de


gcc-4.7 produces a symbol with hidden visibility for testfunc, while
gcc-4.6 produces a symbol with default visibility.

struct foo
{
};

template<
typename T
>
__attribute__ ((visibility("default")))
void testfunc();

template<
typename T
>
void testfunc()
{
}

template
__attribute__ ((visibility("default")))
void testfunc();


I compiled this with 
g++-4.7 -fvisibility=hidden -shared test.cpp


If I replace

struct foo {};

with 

struct __attribute__ ((visibility("default"))) foo {};

then testfunc gets default visibility even with gcc-4.7.

Is this intentional?

[Bug target/51931] New: No support for MIPS16 long branches

[rsandifo at gcc dot gnu.org]

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

 Bug #: 51931
   Summary: No support for MIPS16 long branches
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rsand...@gcc.gnu.org


The MIPS port doesn't detect when MIPS16 branches are out of range,
and it doesn't provide the same kind of "branch around jump" fallback
as it does for non-MIPS16 code.

This has always been a problem, and shows up as a long-standing failure
in gcc.c-torture/compile/20001226-1.c and g++.dg/opt/longbranch1.C.
I've thought about various fixes, such as saving a MIPS16 register
to $1 before using it as a scratch, then restoring it in the branch
delay slot.  But there are various ugly cases.

The bug only triggers for very large functions and at least these days
there's a workaround: add __attribute__((nomips16)).

[Bug c++/25973] [4.4/4.5/4.6/4.7 Regression] Wrong warning: control reaches end of non-void function

[vries at gcc dot gnu.org]

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

--- Comment #13 from vries at gcc dot gnu.org 2012-01-21 11:34:08 UTC ---
Created attachment 26402
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26402
patch to fix problem in comment 4

(In reply to comment #12)
> Tom, are you handling this?

I submitted a more elaborate version of the patch in comment 11 at
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg00649.html.

Richard Guenther suggested a different way to handle this, and this patch is an
attempt at that.

I tested an earlier version of this patch without any problems, I just need to
retest and submit.

[Bug fortran/50981] [4.4/4.5/4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument

[dominiq at lps dot ens.fr]

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

--- Comment #26 from Dominique d'Humieres  
2012-01-21 11:41:15 UTC ---
Running the regression test suite gives:

FAIL: gfortran.dg/coarray_poly_1.f90  -O  (internal compiler error)
FAIL: gfortran.dg/coarray_poly_1.f90  -O   (test for errors, line 11)
FAIL: gfortran.dg/coarray_poly_1.f90  -O  (test for excess errors)
FAIL: gfortran.dg/extends_type_of_1.f03  -O0  execution test
FAIL: gfortran.dg/extends_type_of_1.f03  -O1  execution test
FAIL: gfortran.dg/extends_type_of_1.f03  -O2  execution test
FAIL: gfortran.dg/extends_type_of_1.f03  -O3 -fomit-frame-pointer  execution
test
FAIL: gfortran.dg/extends_type_of_1.f03  -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/extends_type_of_1.f03  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/extends_type_of_1.f03  -O3 -g  execution test
FAIL: gfortran.dg/extends_type_of_1.f03  -Os  execution test

The failure for gfortran.dg/coarray_poly_1.f90 is

[macbook] f90/bug% gfc
/opt/gcc/work/gcc/testsuite/gfortran.dg/coarray_poly_1.f90 -fcoarray=single
-O/opt/gcc/work/gcc/testsuite/gfortran.dg/coarray_poly_1.f90:9.25:

  class(t) :: A(:)[4,2:*] ! { dg-error "is not ALLOCATABLE, SAVE nor a dummy ar
 1
Error: Variable 'a' at (1) is a coarray and is not ALLOCATABLE, SAVE nor a
dummy argument
f951: internal compiler error: Segmentation fault

Note that gfortran.dg/extends_type_of_3.f90 does not appear because it is not
run (dg-do compile). However it runs without the patch and gives a segmentation
fault with it.

[Bug c++/25973] [4.4/4.5/4.6/4.7 Regression] Wrong warning: control reaches end of non-void function

[paolo.carlini at oracle dot com]

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

--- Comment #14 from Paolo Carlini  2012-01-21 
11:57:42 UTC ---
Great, thanks. I would recommend trying to do that before Stage 3 ends.

[Bug target/51882] ICE: in extract_insn, at recog.c:2109 (unrecognizable insn) when building Mesa on ARM

[ramana at gcc dot gnu.org]

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

--- Comment #1 from Ramana Radhakrishnan  2012-01-21 
12:29:02 UTC ---
Created attachment 26403
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26403
reduced testcase

Reduced testcase. 

Configured with : 


--target=arm-linux-gnueabi --with-cpu=cortex-a9 --with-fpu=neon
--with-float=softfp -

Command line options. : 

 ./xgcc -B`pwd` -S -O2  -fPIC   -mapcs -O2  -Wall-ffast-math
-mtune=cortex-a9 besttry.c 

Ramana

[Bug target/51882] ICE: in extract_insn, at recog.c:2109 (unrecognizable insn) when building Mesa on ARM

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-21
 CC||ramana at gcc dot gnu.org
 Ever Confirmed|0   |1

[Bug rtl-optimization/51924] [4.7 Regression] wrong code with -O -free -fno-rename-registers -ftree-vectorize -funroll-loops

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-21
 CC||enkovich.gnu at gmail dot
   ||com, ubizjak at gmail dot
   ||com
 Ever Confirmed|0   |1

--- Comment #2 from Uros Bizjak  2012-01-21 12:59:49 
UTC ---
Confirmed, CCed author of REE pass.

[Bug libstdc++/51932] New: Cannot use std::errno with

[nospam.kotarou.dono at gmail dot com]

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

 Bug #: 51932
   Summary: Cannot use std::errno with 
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nospam.kotarou.d...@gmail.com


Attempting to use `std::errno' while including  does not work and
results in an error.

Examples:
$ cat | g++ -xc++ - -o -
#include 
int main()
{ return std::errno; }
^D: In function ‘int main()’:
:3:15: error: expected unqualified-id before ‘(’ token

$ cat | i686-w64-mingw32-g++ -xc++ - -o -
#include 
int main()
{ return std::errno; }
^D: In function ‘int main()’:
:3:15: error: expected unqualified-id before ‘(’ token

$ cat | x86_64-w64-mingw32-g++ -xc++ - -o -
#include 
int main()
{ return std::errno; }
^D: In function ‘int main()’:
:3:15: error: expected unqualified-id before ‘(’ token

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/kotarou3/usr/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../mingw/gcc-src/configure
--prefix=/home/kotarou3/work/gcc-build/../gcc
--with-gmp=/home/kotarou3/work/gcc-build/../mingw/gmp
--with-mpfr=/home/kotarou3/work/gcc-build/../mingw/mpfr
--with-mpc=/home/kotarou3/work/gcc-build/../mingw/mpc --enable-languages=c,c++
--disable-win32-registry --enable-checking=release --enable-shared
Thread model: posix
gcc version 4.7.0 20111231 (experimental) (GCC)

i686-w64-mingw32 -v:
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/i686-w64-mingw32/4.7.0/lto-wrapper
Target: i686-w64-mingw32
Configured with: ../gcc-src/configure --target=i686-w64-mingw32
--prefix=/home/kotarou3/work/mingw/MinGW
--with-gmp=/home/kotarou3/work/mingw/gmp
--with-mpfr=/home/kotarou3/work/mingw/mpfr
--with-mpc=/home/kotarou3/work/mingw/mpc --enable-languages=c,c++
--disable-win32-registry --enable-checking=release --disable-shared
--disable-multilib
Thread model: win32
gcc version 4.7.0 20111231 (experimental) (GCC)

x86_64-w64-mingw32 -v:
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../gcc-src/configure --target=x86_64-w64-mingw32
--prefix=/home/kotarou3/work/mingw/MinGW
--with-gmp=/home/kotarou3/work/mingw/gmp
--with-mpfr=/home/kotarou3/work/mingw/mpfr
--with-mpc=/home/kotarou3/work/mingw/mpc --enable-languages=c,c++
--disable-win32-registry --enable-checking=release --disable-shared
--disable-multilib
Thread model: win32
gcc version 4.7.0 20111231 (experimental) (GCC)

[Bug c++/51930] Explicitly instantiated template gets hidden visibility

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  2012-01-21 
14:04:39 UTC ---
(In reply to comment #0)
> Is this intentional?

I think so, see PR 35688

[Bug libstdc++/51932] Cannot use std::errno with

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-01-21 
14:06:51 UTC ---
errno is required to be a macro, you can't use std::NULL either

[Bug libstdc++/51932] Cannot use std::errno with

[nospam.kotarou.dono at gmail dot com]

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

--- Comment #2 from nospam.kotarou.dono at gmail dot com 2012-01-21 14:10:15 
UTC ---
So then std::errno shouldn't compile, according to the standard? Because,
googling "std::errno" shows me some people attempting to use std::errno.

[Bug libstdc++/51932] Cannot use std::errno with

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Jonathan Wakely  2012-01-21 
14:23:20 UTC ---
There are lots of things you can find by searching the web, that doesn't make
them a good idea ;)

I'm not sure if it's required to fail, but it's certainly not required to
compile either, and I don't see how it would be possible to make it work when
errno is defined as a macro that usually expands to something like
(*__thread_errno())

It is rejected by Solaris Studio CC and by the Comeau and LLVM online demos
too.

[Bug rtl-optimization/51924] [4.7 regression] wrong code with -O -free -fno-rename-registers -ftree-vectorize -funroll-loops

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||ebotcazou at gcc dot
   ||gnu.org
 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot
   |gnu.org |gnu.org
Summary|[4.7 Regression] wrong code |[4.7 regression] wrong code
   |with -O -free   |with -O -free
   |-fno-rename-registers   |-fno-rename-registers
   |-ftree-vectorize|-ftree-vectorize
   |-funroll-loops  |-funroll-loops

--- Comment #3 from Eric Botcazou  2012-01-21 
14:31:06 UTC ---
Investigating.

[Bug rtl-optimization/51933] New: [4.7 Regression] Wrong-code due to -free

[jakub at gcc dot gnu.org]

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

 Bug #: 51933
   Summary: [4.7 Regression] Wrong-code due to -free
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org


static signed char v1;
static unsigned char v2[256], v3[256];

__attribute__((noclone, noinline)) void
foo (void)
{
  asm volatile ("" : : "r" (&v1), "r" (v2), "r" (v3) : "memory");
}

__attribute__((noclone, noinline)) int
bar (const int x, const unsigned short *y, char *z)
{
  int i;
  unsigned short u;
  if (!v1)
foo ();
  for (i = 0; i < x; i++)
{
  u = y[i];
  z[i] = u < 0x0100 ? v2[u] : v3[u & 0xff];
}
  z[x] = '\0';
  return x;
}

int
main (void)
{
  char buf[18];
  unsigned short s[18];
  unsigned char c[18] = "abcdefghijklmnopq";
  int i;
  for (i = 0; i < 256; i++)
{
  v2[i] = i;
  v3[i] = i + 1;
}
  for (i = 0; i < 18; i++)
s[i] = c[i];
  s[5] |= 0x600;
  s[6] |= 0x500;
  s[11] |= 0x2000;
  s[15] |= 0x500;
  foo ();
  if (bar (17, s, buf) != 17
  || __builtin_memcmp (buf, "abcdeghhijkmmnoqq", 18) != 0)
__builtin_abort ();
  return 0;
}

is miscompiled on x86_64 at -O2, works with -O2 -fno-ree.
Introduced with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182574

[Bug rtl-optimization/51933] [4.7 Regression] Wrong-code due to -free

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
  Known to work||4.6.3
   Target Milestone|--- |4.7.0
  Known to fail||4.7.0

[Bug libstdc++/51932] Cannot use std::errno with

[nospam.kotarou.dono at gmail dot com]

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

nospam.kotarou.dono at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |

--- Comment #4 from nospam.kotarou.dono at gmail dot com 2012-01-21 14:42:28 
UTC ---
Very well then. Just making sure :)

[Bug libstdc++/51932] Cannot use std::errno with

[nospam.kotarou.dono at gmail dot com]

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

nospam.kotarou.dono at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #5 from nospam.kotarou.dono at gmail dot com 2012-01-21 14:43:00 
UTC ---
Oops, accidental changed status :(

[Bug ada/46192] [4.5/4.6/4.7 regression] wrong code for renaming of volatile packed array with address clause

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  2012-01-21 
14:58:39 UTC ---
Author: ebotcazou
Date: Sat Jan 21 14:58:33 2012
New Revision: 183365

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183365
Log:
PR ada/46192
* gcc-interface/decl.c (gnat_to_gnu_entity) : In the case of a
renaming, preserve the volatileness through the indirection, if any.

Added:
trunk/gcc/testsuite/gnat.dg/renaming5.adb
trunk/gcc/testsuite/gnat.dg/renaming5.ads
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug ada/46192] [4.5/4.6/4.7 regression] wrong code for renaming of volatile packed array with address clause

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  2012-01-21 
15:01:56 UTC ---
Author: ebotcazou
Date: Sat Jan 21 15:01:48 2012
New Revision: 183366

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183366
Log:
PR ada/46192
* gcc-interface/decl.c (gnat_to_gnu_entity) : In the case of a
renaming, preserve the volatileness through the indirection, if any.

Added:
branches/gcc-4_6-branch/gcc/testsuite/gnat.dg/renaming5.adb
  - copied unchanged from r183365,
trunk/gcc/testsuite/gnat.dg/renaming5.adb
branches/gcc-4_6-branch/gcc/testsuite/gnat.dg/renaming5.ads
  - copied unchanged from r183365,
trunk/gcc/testsuite/gnat.dg/renaming5.ads
Modified:
branches/gcc-4_6-branch/gcc/ada/ChangeLog
branches/gcc-4_6-branch/gcc/ada/gcc-interface/decl.c
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug ada/46192] [4.5/4.6/4.7 regression] wrong code for renaming of volatile packed array with address clause

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou  2012-01-21 
15:04:31 UTC ---
Author: ebotcazou
Date: Sat Jan 21 15:04:25 2012
New Revision: 183367

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183367
Log:
PR ada/46192
* gcc-interface/decl.c (gnat_to_gnu_entity) : In the case of a
renaming, preserve the volatileness through the indirection, if any.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gnat.dg/renaming5.adb
  - copied unchanged from r183365,
trunk/gcc/testsuite/gnat.dg/renaming5.adb
branches/gcc-4_5-branch/gcc/testsuite/gnat.dg/renaming5.ads
  - copied unchanged from r183366,
trunk/gcc/testsuite/gnat.dg/renaming5.ads
Modified:
branches/gcc-4_5-branch/gcc/ada/ChangeLog
branches/gcc-4_5-branch/gcc/ada/gcc-interface/decl.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug ada/46192] [4.5/4.6/4.7 regression] wrong code for renaming of volatile packed array with address clause

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|ebotcazou at gcc dot|
   |gnu.org |
 Resolution||FIXED

--- Comment #10 from Eric Botcazou  2012-01-21 
15:06:58 UTC ---
In the next 4.5.x and above releases.

[Bug fortran/51913] [4.6/4.7 Regression][OOP] bug when submitting a class pointer to a subroutine

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-01-21 
15:12:39 UTC ---
Author: burnus
Date: Sat Jan 21 15:12:31 2012
New Revision: 183368

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183368
Log:
2012-01-21  Tobias Burnus  

PR fortran/51913
* interface.c (compare_parameter): Fix CLASS comparison.

2012-01-21  Tobias Burnus  

PR fortran/51913
* gfortran.dg/class_47.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/class_47.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/51933] [4.7 Regression] Wrong-code due to -free

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  2012-01-21 
15:24:26 UTC ---
Consider following 3 routines:

unsigned long
foo (unsigned short *s, int i)
{
  unsigned short x = s[i];
  if (x < 0x211)
return (unsigned char) x;
  asm volatile ("");
  return 6;
}
unsigned long
bar (unsigned short *s, int i)
{
  unsigned short x = s[i];
  if (x < 0x211)
return (unsigned char) x;
  asm volatile ("");
  return x;
}
unsigned long
baz (unsigned short *s, int i)
{
  unsigned short x = s[i];
  if (x < 0x211)
return x;
  asm volatile ("");
  return (unsigned char) x;
}

In foo ree doesn't optimize away the QImode -> DImode zero extension, because
merge_def_and_ext checks:
  && GET_MODE (SET_DEST (*sub_rtx)) == ext_src_mode
and in this case ext_src_mode is QImode, but SET_DEST has HImode.
In bar ree doesn't optimize it away either, first merge_def_and_ext_checks is
called with the QImode ext_src_mode (which doesn't match) and only afterwards
on the HImode -> DImode extension, which is optimized (that is correct).
In baz (which is the same as bar in #c0 testcase) unfortunately
merge_def_and_ext is first called on the HImode -> DImode extension, which is
optimized (that is fine) by turning the HImode load into a DImode zero_extend
load from HImode and removing the HImode -> DImode extension.
But then when make_defs_and_copies_lists is called on the QImode -> DImode
extension, we reach:
  /* Initialize the work list.  */
  if (!get_defs (extend_insn, src_reg, &work_list))
{
  VEC_free (rtx, heap, work_list);
  /* The number of defs being equal to zero can only mean that all the
 definitions have been previously merged.  */
  return 2;
}
and because the definition has been changed already.  But nothing performs the
ext_src_mode check that used to be performed otherwise.
So we either need to do the src mode checking earlier when we haven't started
modifying insns (in add_removable_extension?), or we'd need to look even at the
newly added defs and see what mode they extend from.

[Bug rtl-optimization/51924] [4.7 regression] wrong code with -O -free -fno-rename-registers -ftree-vectorize -funroll-loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  2012-01-21 
15:25:18 UTC ---
Possibly related to PR51933.

[Bug rtl-optimization/51933] [4.7 Regression] Wrong-code due to -free

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  2012-01-21 
15:44:46 UTC ---
> But then when make_defs_and_copies_lists is called on the QImode -> DImode
> extension, we reach:
>   /* Initialize the work list.  */
>   if (!get_defs (extend_insn, src_reg, &work_list))
> {
>   VEC_free (rtx, heap, work_list);
>   /* The number of defs being equal to zero can only mean that all the
>  definitions have been previously merged.  */
>   return 2;
> }
> and because the definition has been changed already.

Yes, this particular return embodies some implicit assumptions...  Will fix.

[Bug target/51934] New: FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) on powerpc*-*-*

[dominiq at lps dot ens.fr]

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

 Bug #: 51934
   Summary: FAIL: g++.dg/torture/pr51344.C  -O0  (test for excess
errors) on powerpc*-*-*
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: kti...@gcc.gnu.org, pthau...@us.ibm.com
  Host: powerpc*-*-*
Target: powerpc*-*-*
 Build: powerpc*-*-*


The test g++.dg/torture/pr51344.C fails on powerpc*-*-* (see
http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg02019.html )

FAIL: g++.dg/torture/pr51344.C  -O0  (test for excess errors)
FAIL: g++.dg/torture/pr51344.C  -O1  (test for excess errors)
FAIL: g++.dg/torture/pr51344.C  -O2  (test for excess errors)
FAIL: g++.dg/torture/pr51344.C  -O3 -fomit-frame-pointer  (test for excess
errors)
FAIL: g++.dg/torture/pr51344.C  -O3 -g  (test for excess errors)
FAIL: g++.dg/torture/pr51344.C  -Os  (test for excess errors)
FAIL: g++.dg/torture/pr51344.C  -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: g++.dg/torture/pr51344.C  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)

with (at least on powerpc-apple-darwin9)

[karma] f90/bug% /opt/gcc/gcc4.7w/bin/g++ -c
/opt/gcc/work/gcc/testsuite/g++.dg/torture/pr51344.C
/opt/gcc/work/gcc/testsuite/g++.dg/torture/pr51344.C:7:58: warning: 'cdecl'
attribute directive ignored [-Wattributes]
/opt/gcc/work/gcc/testsuite/g++.dg/torture/pr51344.C:7:58: warning: 'cdecl'
attribute directive ignored [-Wattributes]

Is the attribute 'cdecl' supposed to exist on powerpc?

[Bug rtl-optimization/51933] [4.7 regression] wrong code due to -free

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2012-01-21 
15:57:23 UTC ---
Completely untested fix:
--- gcc/ree.c.jj2011-12-28 10:52:44.0 +0100
+++ gcc/ree.c2012-01-21 16:55:27.290731139 +0100
@@ -776,6 +776,23 @@ add_removable_extension (rtx x ATTRIBUTE
   }
 return;
   }
+else
+  {
+rtx set = single_set (DF_REF_INSN (def->ref));
+if (set == NULL_RTX
+|| !REG_P (SET_DEST (set))
+|| GET_MODE (SET_DEST (set)) != GET_MODE (XEXP (src, 0)))
+  {
+if (dump_file)
+  {
+fprintf (dump_file, "Cannot eliminate extension:\n");
+print_rtl_single (dump_file, rei->insn);
+fprintf (dump_file,
+ " because def insn has different mode\n");
+  }
+return;
+  }
+  }

   /* Then add the candidate to the list and insert the reaching
definitions
  into the definition map.  */

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[tg at mirbsd dot org]

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

--- Comment #4 from Thorsten Glaser  2012-01-21 16:04:41 
UTC ---
Mikael, you are amazing! I’m sort of sorry that I’ve led you to so much
effort and fighting against bugs and build system issues.

I’ve only ever built gcj with fastjar, even in the gcc 3.4 times on MirBSD.
I didn’t even know it could generate a wrapper script… Looking at it, I
guess that your zip (Info-ZIP) may be broken, as it merely uses that.
Do you still have the jar file that generates an NPE lying around? If so,
mail it to me privately, and I can have a look at that when I’m back from
vacation.

[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) on powerpc*-*-*

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson  2012-01-21 
16:10:15 UTC ---
Also broken on 4.6 and 4.5 branches (don't know yet about 4.4, but the
offending change was backported to it too), see:

http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg02026.html
http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg01992.html
http://gcc.gnu.org/ml/gcc-testresults/2012-01/msg01945.html

[Bug fortran/51913] [4.6/4.7 Regression][OOP] bug when submitting a class pointer to a subroutine

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2012-01-21 
16:11:55 UTC ---
Author: burnus
Date: Sat Jan 21 16:11:47 2012
New Revision: 183369

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183369
Log:
2012-01-21  Tobias Burnus  

PR fortran/51913
* interface.c (compare_parameter): Fix CLASS comparison.

2012-01-21  Tobias Burnus  

PR fortran/51913
* gfortran.dg/class_47.f90: New.


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

[Bug fortran/51913] [4.6/4.7 Regression][OOP] bug when submitting a class pointer to a subroutine

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Tobias Burnus  2012-01-21 
16:12:40 UTC ---
FIXED on the trunk (4.7) and on the 4.6 branch.

Thanks for reporting the bug!

[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) on powerpc*-*-*

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2012-01-21 
16:15:52 UTC ---
> Also broken on 4.6 and 4.5 branches ...

Mikael can you confirm that the failures are due to the warning "'cdecl'
attribute directive ignored"?

[Bug debug/45682] missing namespace parent die when using -gdwarf-4

[jan.kratochvil at redhat dot com]

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

--- Comment #6 from Jan Kratochvil  
2012-01-21 17:02:36 UTC ---
Confirming it has fixed:
-XFAIL: gdb.cp/static-method.exp: info addr A::func() (PRMS gcc/45682)
+PASS: gdb.cp/static-method.exp: info addr A::func()
-XFAIL: gdb.cp/static-method.exp: list static-method.cc:xxx::(anonymous
namespace)::A::func (PRMS gcc/45682)
-XFAIL: gdb.cp/static-method.exp: list 'static-method.cc:xxx::(anonymous
namespace)::A::func' (PRMS gcc/45682)
-XFAIL: gdb.cp/static-method.exp: list 'static-method.cc':'xxx::(anonymous
namespace)::A::func' (PRMS gcc/45682)
-XFAIL: gdb.cp/static-method.exp: list static-method.cc:'xxx::(anonymous
namespace)::A::func' (PRMS gcc/45682)
+PASS: gdb.cp/static-method.exp: list static-method.cc:xxx::(anonymous
namespace)::A::func
+PASS: gdb.cp/static-method.exp: list 'static-method.cc:xxx::(anonymous
namespace)::A::func'
+PASS: gdb.cp/static-method.exp: list 'static-method.cc':'xxx::(anonymous
namespace)::A::func'
+PASS: gdb.cp/static-method.exp: list static-method.cc:'xxx::(anonymous
namespace)::A::func'

There are still other few GDB testsuite regressions by -fdebug-types-section, I
will re-check them with this fix in, thanks.

[Bug bootstrap/51935] New: Configure fails on included mpc/mpfr

[psmith at gnu dot org]

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

 Bug #: 51935
   Summary: Configure fails on included mpc/mpfr
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: psm...@gnu.org


Created attachment 26404
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26404
Add /src to mpfr directories in configure.ac

I was trying to follow the advice of various people by including GMP/MPC/MPFR
into the GCC source tree (GCC 4.6.2 / GMP 5.0.2 / MPFR 3.1.0 / MPC 0.9),
however this failed during configure:

checking whether time.h and sys/time.h may both be included... yes
checking for creal in -lm... yes
checking for __gmpz_init in -lgmp... yes
checking for MPFR... yes
checking for recent GMP... yes
checking for recent MPFR... no
configure: error: MPFR version >= 2.4.2 required
make[4]: *** [configure-stage1-mpc] Error 1
make[4]: Leaving directory `/usr/src/gcc/obj-stage1/gcc'
make[3]: *** [stage1-bubble] Error 2
make[3]: Leaving directory `/usr/src/gcc/obj-stage1/gcc'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/usr/src/gcc/obj-stage1/gcc'
make[1]: *** [/usr/src/gcc/.stamp/stage1.install] Error 2

Investigating, I found the configure was using the wrong path to location mpfr
headers and libraries; for example mpc/config.log says:

configure:11278: checking for recent MPFR
configure:11290: gcc -c -g -fkeep-inline-functions
-I/usr/src/gcc/obj-stage1/gcc
/./gmp -I/usr/src/gcc/gcc-4.6.2/mpfr  conftest.c >&5
conftest.c:34:3: error: #error "Minimal MPFR version is 2.4.2"
conftest.c:35: error: expected '=', ',', ';', 'asm' or '__attribute__' at
end of
 input
configure:11290: $? = 1

This is due to the configure script assuming that MPFR headers are in the root
MPFR directory, but they're not: they live the "src" subdirectory in MPFR.  If
you fix the headers then it will fail during link because it's looking for
libmpfr.a in the wrong place, too.

I have an MPFR installed natively on the system, but it's version 2.2.1.  My
suspicion is that most people who test this already have a "new enough" MPFR
installed in /usr/include so they don't notice that this path is wrong, since
configure finds the one in /usr/include and is happy with it.

The attached patch to configure.ac that fixes things.

[Bug fortran/50556] cannot save namelist group name

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org 2012-01-21 17:32:15 UTC ---
Author: kargl
Date: Sat Jan 21 17:32:12 2012
New Revision: 183370

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183370
Log:
2012-01-21  Tobias Burnus  
Steven G. Kargl  

PR fortran/50556
* symbol.c (check_conflict): namelist-group-name cannot have the SAVE
attribure.

2012-01-21  Steven G. Kargl  

PR fortran/50556
* gfortran.dg/namelist_74.f90: New test.
* gfortran.dg/namelist_59.f90: Remove SAVE attribute.

Added:
trunk/gcc/testsuite/gfortran.dg/namelist_74.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/namelist_59.f90

[Bug fortran/50556] cannot save namelist group name

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org 2012-01-21 17:37:40 UTC ---
Fixed on trunk.  Thanks for the bug reports.

[Bug c++/51936] New: template function not instantiated

[blaffablaffa at gmail dot com]

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

 Bug #: 51936
   Summary: template function not instantiated
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: blaffabla...@gmail.com


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

It appears that in some circumstances g++ fails to instantiate a template
function, and so end up in link time errors.

Consider the code in attachment. If compiled with:

g++ -Wall -std=c++0x testcase.cpp

the result is:

testcase.cpp:(.text+0x13): undefined reference to `int asd(int*)'
collect2: ld returned 1 exit status

whereas if compiled with:

g++ -Wall -std=c++0x -DWORKAROUND testcase.cpp

it does warn for the unused variable 'inted', but compiles and run correctly.


It looks like that getting the pointer of a template function and immediately
cast it to something else "weakens" the usage of the template, so that g++
doesn't instantiate it.

[Bug rtl-optimization/51040] ICE: RTL check: access of elt 1 of 'not' with last elt 0 in gen_rtx_fmt_ee_stat, at ./genrtl.h:33 with __atomic_nand_fetch()

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Zdenek Sojka  2012-01-21 18:01:20 
UTC ---
This seems to no longer ICE, thanks for fixing it.

[Bug middle-end/48833] gcc.c-torture/execute/pr34415.c FAILs with -flto -fipa-cp-clone -fno-merge-constants

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

  Known to work||4.6.2, 4.7.0

--- Comment #2 from Zdenek Sojka  2012-01-21 18:08:25 
UTC ---
I can no longer reproduce it with 4.7 r183351 and 4.6 r180325. (even gentoo's
4.6.1 seems to work)

[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously

[psmith at gnu dot org]

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

psmith at gnu dot org changed:

   What|Removed |Added

 CC||psmith at gnu dot org

--- Comment #4 from psmith at gnu dot org 2012-01-21 18:14:00 UTC ---
Oops I filed a duplicate bug #51935

That bug includes a patch to fix the problem.

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

[psmith at gnu dot org]

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

--- Comment #1 from psmith at gnu dot org 2012-01-21 18:15:24 UTC ---
Created attachment 26406
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26406
Handle both old and new MPFR dir layouts

Added a new patch that works with both old and new layouts.

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

[psmith at gnu dot org]

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

--- Comment #2 from psmith at gnu dot org 2012-01-21 18:17:23 UTC ---
BTW, this is a duplicate of bug #50461

[Bug target/51871] FAIL: gcc.c-torture/execute/20010122-1.c execution

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

  Component|middle-end  |target
Summary|[4.7 Regression] FAIL:  |FAIL:
   |gcc.c-torture/execute/20010 |gcc.c-torture/execute/20010
   |122-1.c execution   |122-1.c execution

--- Comment #5 from John David Anglin  2012-01-21 
18:21:18 UTC ---
Stub check in pa_return_addr_rtx is wrong for PA2.0 code.  PA2.0
uses different stub.

[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  2012-01-21 
18:23:20 UTC ---
*** Bug 51935 has been marked as a duplicate of this bug. ***

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Andrew Pinski  2012-01-21 
18:23:20 UTC ---
Dup of bug 50461 so closing.

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

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-01-21 
18:27:18 UTC ---
The prerequisites page says:
"While any sufficiently new version of required tools usually work, library
requirements are generally stricter. Newer versions may work in some cases, but
it's safer to use the exact versions documented."

The contrib/download_prerequisites script gets the exact versions documented.

[Bug fortran/51754] [OOP] ICE on valid with class arrays

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2012-01-21 
18:28:46 UTC ---
TODO: The ICE for the valid code (gfc_conv_descriptor_offset).

This comment is for the second issue:

(In reply to comment #0)
> If I remove the "allocatable" I instead get:
> $ gfortran -c test.F90 -o test.o
> f951: internal compiler error: Segmentation fault

Draft patch - for some reason, two error messages are printed for the line
  class(componentB), dimension(:) :: componentB

The change in gfc_default_initializer fixes the initial issue (and causes the
duplicated error message be printed in resolve.c) [Before, resolve was not
reached as the function was already called during variable declaration.] -- The
other parts are to avoid later segfault ("error recovery").

--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3761,3 +3761,9 @@ gfc_default_initializer (gfc_typespec *ts)
-if (comp->initializer || comp->attr.allocatable
-   || (comp->ts.type == BT_CLASS && CLASS_DATA (comp)->attr.allocatable))
-  break;
+{
+  if (comp->ts.type == BT_CLASS && !comp->attr.class_ok)
+   return NULL;
+
+  if (comp->initializer || comp->attr.allocatable
+ || (comp->ts.type == BT_CLASS
+ &&  CLASS_DATA (comp)->attr.allocatable))
+   break;
+}
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -2020 +2020 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag, bool
sub_flag,
-  else if (component->ts.type == BT_CLASS
+  else if (component->ts.type == BT_CLASS && component->attr.class_ok
@@ -2188 +2188 @@ gfc_variable_attr (gfc_expr *expr, gfc_typespec *ts)
-   if (comp->ts.type == BT_CLASS)
+   if (comp->ts.type == BT_CLASS && comp->attr.class_ok)
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -4836,2 +4836,2 @@ gfc_type_compatible (gfc_typespec *ts1, gfc_typespec
*ts2)
-  bool is_class1 = (ts1->type == BT_CLASS);
-  bool is_class2 = (ts2->type == BT_CLASS);
+  bool is_class1 = (ts1->type == BT_CLASS && ts1->u.derived->attr.class_ok);
+  bool is_class2 = (ts2->type == BT_CLASS && ts2->u.derived->attr.class_ok);

[Bug rtl-optimization/51933] [4.7 regression] wrong code due to -free

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2012-01-21 
18:40:23 UTC ---
That unfortunately slightly pessimizes it.  E.g. on i686-linux bootstrap
on:
../../gcc/config/i386/i386.c ix86_memory_move_cost
../../gcc/config/i386/i386.c ix86_register_move_cost
../../../../libgfortran/io/write.c write_float
../../../libgfortran/io/write.c write_float
s-regpat.adb system__regpat__dump_until
/usr/src/gcc/gcc/testsuite/gcc.target/i386/avx-vpackuswb-1.c do_test
/usr/src/gcc/gcc/testsuite/gcc.target/i386/sse2-packuswb-1.c do_test
/usr/src/gcc/libstdc++-v3/testsuite/ext/rope/1.cc _S_tree_concat
/usr/src/gcc/libstdc++-v3/testsuite/ext/rope/2.cc _S_tree_concat
/usr/src/gcc/libstdc++-v3/testsuite/ext/rope/3.cc _S_tree_concat
/usr/src/gcc/libstdc++-v3/testsuite/ext/rope/44963.cc _S_tree_concat
/usr/src/gcc/libstdc++-v3/testsuite/ext/rope/4.cc _S_tree_concat
/usr/src/gcc/libstdc++-v3/testsuite/ext/rope/pthread7-rope.cc _S_tree_concat
and on x86_64-linux bootstrap sans regtest:
../../gcc/ada/par.adb par__prag__process_restrictions_or_restriction_warnings
../../gcc/config/i386/i386.c ix86_memory_move_cost
../../gcc/config/i386/i386.c ix86_register_move_cost
../../gcc/java/jcf-parse.c rewrite_reflection_indexes
../../../libgfortran/io/write.c write_float
s-regpat.adb system__regpat__dump_until

The problem is if the def insn satisfies is_cond_copy_insn, then it can be in a
wider mode, yet all definitions could still be in a narrower mode.
So, perhaps we'd need to have a recursive function that for is_cond_copy_insn
defs calls get_defs on both args and recurses, checking mode of real
definitions only.  Not sure if we'd need also this is_insn_visited array for it
to avoid recursing infinitely.

BTW, for 4.8, I guess a couple of ree.c cleanups will be needed, e.g. several
functions allocate and free way too many heap allocated vectors, I guess if we
allocate them in the caller (or caller's caller) and just pass addresses of
those vectors around, we could just VEC_truncate the vectors and avoid the
permanent malloc/free.

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

[psmith at gnu dot org]

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

--- Comment #5 from psmith at gnu dot org 2012-01-21 18:54:37 UTC ---
It's fine to close this bug as a dup as it's later than the other, but note
I've attached a fix to this bug (there's no fix attached to the other) so
please don't lose the patch.

Cheers!

[Bug fortran/51754] [OOP] ICE on valid with class arrays

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2012-01-21 
19:22:27 UTC ---
(In reply to comment #1)
One additionally needs the following - otherwise, e.g., PR 41600 comment 1
fails at resolve time claiming that the type is not the same.

--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -385,2 +385,3 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute
*attr,
   fclass->attr.abstract = ts->u.derived->attr.abstract;
+  fclass->attr.class_ok = 1;
   if (ts->u.derived->f2k_derived)

[Bug fortran/41600] [OOP] SELECT TYPE with associate-name => exp: Arrays not supported

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-01-21 
19:57:07 UTC ---
(Those comments are for the example in comment 1)
The ICE happens for:
  integer :: X = -999.0
where one calls gfc_trans_scalar_assign with ts.type == BT_INTEGER and fold
convert fails to convert the constant 999.0 to an integer.

Without type spec, one uses the _vtab->__def_init while with type spec, one
directly assigns. That's toggled in resolve.c:7018 (resolve_allocate_expr).
With type spec, one has a call to gfc_default_initializer.

In principle, the FE should convert 999.0 into 999. This happens twice via
gfc_convert_type_warn, which is called via: resolve_types -> resolve_values ->
resolve_structure_cons. But seemingly there is still some loop whole where it
does not happen.

Draft:
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3776,3 +3782,8 @@ gfc_default_initializer (gfc_typespec *ts)
   if (comp->initializer)
-   ctor->expr = gfc_copy_expr (comp->initializer);
+   {
+ ctor->expr = gfc_copy_expr (comp->initializer);
+ if (comp->ts.type != comp->initializer->ts.type
+ || comp->ts.kind != comp->initializer->ts.kind)
+   gfc_convert_type_warn (ctor->expr, &comp->ts, 2, false);
+   }

* * *

OK, that fixed comment 1. But comment 0 still has issues:

a) As is, it fails at:
hfj3af.f90:1:0: internal compiler error: in gfc_conv_component_ref, at
fortran/trans-expr.c:997

Breakpoint 1, gfc_conv_component_ref
997   gcc_assert (f2);
(gdb) p f2
$1 = (tree_node *) 0x0
#1  0x005d484e in gfc_conv_variable (se=0x7fffd130, expr=0x16c4280)
at fortran/trans-expr.c:1238
#2  0x005d4154 in gfc_conv_expr_val (se=0x7fffd130, expr=) at fortran/trans-expr.c:5450
#3  0x005ffb96 in gfc_trans_integer_select (code=) at
fortran/trans-stmt.c:1821
#4  gfc_trans_select (code=0x16cb9a0) at fortran/trans-stmt.c:2380

If one looks in gfc_conv_variable just before the ICEing gfc_conv_component_ref
at the values, one finds: One has an EXPR_VARIABLE ("bar") which points to
("ref") to _vptr->_hash. The issue already occurs for expr->ref where one has
in gfc_conv_component_ref:

991   tree f2 = c->norestrict_decl;

But that's NULL. If one sets f2 to c->backend_decl, one now iterates through f2
= DECL_CHAIN (f2), does not find the suitable field, and fails at the same
assert line.


b) If one comments the type is(t0) line and the print line, one gets a
segfault.

 Invalid read of size 8
at 0x5ABD0B: gfc_conv_scalarized_array_ref(gfc_se*, gfc_array_ref*)
(trans-array.c:3016)
by 0x5AC7A1: gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_symbol*,
   locus*) (trans-array.c:3112)
by 0x5D47B7: gfc_conv_variable(gfc_se*, gfc_expr*) (trans-expr.c:1230)

That's the line:
  expr = ss->info->expr;

For some reason, this empty select type wants to get scalarized. The cally has:
  /* Handle scalarized references separately.  */
  if (ar->type != AR_ELEMENT)
{
  gfc_conv_scalarized_array_ref (se, ar);

[Bug target/45771] Source operands for conditional moves

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  2012-01-21 
20:17:38 UTC ---
Fixed by:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01567.html

[Bug rtl-optimization/47698] CMOV accessing volatile memory with read side effect

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  2012-01-21 
20:18:48 UTC ---
Fixed.

[Bug c++/51936] template function not instantiated

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-01-21 
20:23:27 UTC ---
The standard says in [expr.reinterpret.cast]
"A function pointer can be explicitly converted to a function pointer of a
different type. The effect of calling a function through a pointer to a
function type (8.3.5) that is not the same as the type used in the definition
of the function is undefined."

So I think the program has undefined behaviour.  Because you never call
asd as part of a valid expression it doesn't need to be instantiated.


Clang++ fails in the same way as G++ 4.6, but it works with G++ 4.7

[Bug c++/51930] [4.7 regression] Explicitly instantiated template gets hidden visibility

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-01-21
Summary|Explicitly instantiated |[4.7 regression] Explicitly
   |template gets hidden|instantiated template gets
   |visibility  |hidden visibility
 Ever Confirmed|0   |1

--- Comment #2 from Jason Merrill  2012-01-21 
20:26:03 UTC ---
The explicit visibility on the explicit instantiation should cause it to have
default visibility; without that it should have hidden visibility.

[Bug fortran/50362] ICE on x86 architecture with -O2 or higher

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-01-21
 CC||kargl at gcc dot gnu.org
 Ever Confirmed|0   |1
   Severity|major   |normal

--- Comment #2 from kargl at gcc dot gnu.org 2012-01-21 20:27:30 UTC ---
Like Janus, I cannot reproduce this problem with trunk or
recent 4.5 and 4.6 compilers.  OP, does this problem still
exist?

[Bug target/40454] [4.4/4.5/4.6/4.7 regression] zlib is about 20% slower when compiled with GCC 4.4.1

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski  2012-01-21 
20:32:14 UTC ---
Can someone try to get new numbers?

[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) on powerpc*-*-*

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson  2012-01-21 
21:15:47 UTC ---
(In reply to comment #2)
> > Also broken on 4.6 and 4.5 branches ...
> 
> Mikael can you confirm that the failures are due to the warning "'cdecl'
> attribute directive ignored"?

Yes, the 4.6 failures are caused by that cdecl attribute ignored warning.

BTW, 4.6 fails on sparc64-linux in the same way.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

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

--- Comment #54 from Jonathan Wakely  2012-01-21 
21:27:57 UTC ---
Author: redi
Date: Sat Jan 21 21:27:49 2012
New Revision: 183376

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183376
Log:
PR libstdc++/50982
* testsuite/30_threads/*: Add powerpc-ibm-aix* to target selectors.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/30_threads/async/42819.cc
trunk/libstdc++-v3/testsuite/30_threads/async/49668.cc
trunk/libstdc++-v3/testsuite/30_threads/async/any.cc
trunk/libstdc++-v3/testsuite/30_threads/async/async.cc
trunk/libstdc++-v3/testsuite/30_threads/async/launch.cc
trunk/libstdc++-v3/testsuite/30_threads/async/sync.cc
trunk/libstdc++-v3/testsuite/30_threads/call_once/39909.cc
trunk/libstdc++-v3/testsuite/30_threads/call_once/49668.cc
trunk/libstdc++-v3/testsuite/30_threads/call_once/call_once1.cc
trunk/libstdc++-v3/testsuite/30_threads/condition_variable/cons/1.cc
trunk/libstdc++-v3/testsuite/30_threads/condition_variable/members/1.cc
trunk/libstdc++-v3/testsuite/30_threads/condition_variable/members/2.cc
   
trunk/libstdc++-v3/testsuite/30_threads/condition_variable/native_handle/typesizes.cc
trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/50862.cc
trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/cons/1.cc
trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/members/1.cc
trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/members/2.cc
trunk/libstdc++-v3/testsuite/30_threads/future/cons/move.cc
trunk/libstdc++-v3/testsuite/30_threads/future/members/45133.cc
trunk/libstdc++-v3/testsuite/30_threads/future/members/get.cc
trunk/libstdc++-v3/testsuite/30_threads/future/members/get2.cc
trunk/libstdc++-v3/testsuite/30_threads/future/members/share.cc
trunk/libstdc++-v3/testsuite/30_threads/future/members/valid.cc
trunk/libstdc++-v3/testsuite/30_threads/future/members/wait.cc
trunk/libstdc++-v3/testsuite/30_threads/future/members/wait_for.cc
trunk/libstdc++-v3/testsuite/30_threads/future/members/wait_until.cc
trunk/libstdc++-v3/testsuite/30_threads/lock/1.cc
trunk/libstdc++-v3/testsuite/30_threads/lock/2.cc
trunk/libstdc++-v3/testsuite/30_threads/lock/3.cc
trunk/libstdc++-v3/testsuite/30_threads/lock/4.cc
trunk/libstdc++-v3/testsuite/30_threads/lock_guard/cons/1.cc
trunk/libstdc++-v3/testsuite/30_threads/mutex/cons/1.cc
trunk/libstdc++-v3/testsuite/30_threads/mutex/dest/destructor_locked.cc
trunk/libstdc++-v3/testsuite/30_threads/mutex/lock/1.cc
trunk/libstdc++-v3/testsuite/30_threads/mutex/native_handle/1.cc
trunk/libstdc++-v3/testsuite/30_threads/mutex/native_handle/typesizes.cc
trunk/libstdc++-v3/testsuite/30_threads/mutex/try_lock/1.cc
trunk/libstdc++-v3/testsuite/30_threads/mutex/try_lock/2.cc
trunk/libstdc++-v3/testsuite/30_threads/mutex/unlock/1.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/49668.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/1.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/2.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/3.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/alloc.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/move.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/move_assign.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/get_future.cc
   
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/get_future2.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke2.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke3.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke4.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke5.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/reset.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/reset2.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/swap.cc
trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/valid.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/cons/1.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/cons/alloc.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/cons/move.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/cons/move_assign.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/members/get_future.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/members/get_future2.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_exception.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_exception2.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_value.cc
trunk/libstdc++-v3/testsuite

[Bug rtl-optimization/40987] Wrong optimization with if-conversion

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target|i686|
   Host|i686|HWI == 32
  Build|i686|

--- Comment #11 from Andrew Pinski  2012-01-21 
21:27:18 UTC ---
This bug is now hard to hit on the trunk as i?86 requires host wide word as
64bit.

[Bug rtl-optimization/51933] [4.7 regression] wrong code due to -free

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  2012-01-21 
21:27:40 UTC ---
> But then when make_defs_and_copies_lists is called on the QImode -> DImode
> extension, we reach:
>   /* Initialize the work list.  */
>   if (!get_defs (extend_insn, src_reg, &work_list))
> {
>   VEC_free (rtx, heap, work_list);
>   /* The number of defs being equal to zero can only mean that all the
>  definitions have been previously merged.  */
>   return 2;
> }
> and because the definition has been changed already.  But nothing performs the
> ext_src_mode check that used to be performed otherwise.
> So we either need to do the src mode checking earlier when we haven't started
> modifying insns (in add_removable_extension?), or we'd need to look even at 
> the
> newly added defs and see what mode they extend from.

OK, I didn't realize that there could be an implicit truncation hidden within
an extension.  And I think that your change to add_removable_extension is fine,
as it still leaves the new flavor of the pass more powerful than the old one.

The other PR is a different problem.

[Bug middle-end/28779] internal compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:106

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #18 from Andrew Pinski  2012-01-21 
21:29:13 UTC ---
Closing as fixed.  Also note --combine has now been removed from 4.6 and above.

[Bug c++/17805] too liberal operator lookup

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2005-12-30 07:12:30 |2012-01-21 0:00

--- Comment #9 from Andrew Pinski  2012-01-21 
21:33:25 UTC ---
The patch was approved but never applied.

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses fold

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  2012-01-21 
22:01:00 UTC ---
I actually have a patch to do this but only for the late PHIOPT as it keeps
around cond_expr.

[Bug tree-optimization/15357] [tree-ssa] combing if statements

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  2012-01-21 
22:02:24 UTC ---
I have a patch which implements this.  I will be posting it for 4.8.

gcc-bugs@gcc.gnu.org

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  2012-01-21 
22:03:16 UTC ---
I am taking this over.

[Bug tree-optimization/20083] Missed optimization with conditional and basically ||

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  2012-01-21 
22:04:34 UTC ---
I will take care of this one too.

[Bug c++/17805] too liberal operator lookup

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|gcc-bugs at gcc dot gnu.org |jason at gcc dot gnu.org,
   ||paolo.carlini at oracle dot
   ||com

--- Comment #10 from Paolo Carlini  2012-01-21 
22:10:25 UTC ---
Jason, better delaying this to Stage 1? Is the patch otherwise technically
ready to be reapplied to current mainline?!?

[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

[howarth at nitro dot med.uc.edu]

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

--- Comment #7 from Jack Howarth  2012-01-21 
22:11:12 UTC ---
This issue is starting to look like a darwin11-specific linker bug. If I build
the 30_threads/recursive_mutex/try_lock/1.cc test case under Xcode 4.2 on
darwin10 and
then run it under darwin11 using...

setenv DYLD_LIBRARY_PATH .
setenv LD_LIBRARY_PATH .

to allow the same libgcc_s.1.dylib and libstdc++.6.dylib built on darwin10 to
be used.
the test case doesn't crash. However if I build the
30_threads/recursive_mutex/try_lock/1.cc test case
under darwin11 using -mmacosx-version-min=10.6 and run it the same way, it
crashes on both
darwin11 and darwin10.

[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) on powerpc*-*-*

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  2012-01-21 
22:22:50 UTC ---
> Yes, the 4.6 failures are caused by that cdecl attribute ignored warning.
>
> BTW, 4.6 fails on sparc64-linux in the same way.

Thanks, setting the PR to NEW.

[Bug bootstrap/44642] bootstrap fails to build libgcc when gold is built (at least on Solaris_x86)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||MOVED

--- Comment #3 from Andrew Pinski  2012-01-21 
22:26:33 UTC ---
Let's close this as moved then.  Since it was moved over to those binutils bug
reports.

[Bug other/46542] GCC 4.7 pending patches meta-bug

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #10 from Andrew Pinski  2012-01-21 
22:31:12 UTC ---
Closing as fixed as 4.7 is stage 4 now.

[Bug other/51937] New: [meta-bug] GCC 4.8 pending patches

[pinskia at gcc dot gnu.org]

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

 Bug #: 51937
   Summary: [meta-bug] GCC 4.8 pending patches
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org


Place to attach GCC 4.8 pending patches and PRs.

[Bug other/51937] [meta-bug] GCC 4.8 pending patches

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug tree-optimization/51938] New: missed optimization: 2 comparisons

[marc.glisse at normalesup dot org]

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

 Bug #: 51938
   Summary: missed optimization: 2 comparisons
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org


Hello,

this is possibly related to bug 28685, or to the bugs about the tracking of
flag register values.

void f();
enum Sign { NEG=-1, ZERO, POS };
enum Sign sign(double x){
if(x>0) return POS;
if(x<0) return NEG;
return ZERO;
}
void g(double x){
if(sign(x)==NEG) f();
}


Ideally, the compiler would realize that g is equivalent to:
if(x<0) f();

but on x86_64 I get with 4.6 (optimization -O3):

xorpd%xmm1, %xmm1
ucomisd%xmm1, %xmm0
ja.L8
ucomisd%xmm0, %xmm1
jbe.L8
xorl%eax, %eax
jmpf
.L8:
rep
ret

And with 4.7:

xorpd%xmm1, %xmm1
ucomisd%xmm1, %xmm0
jbe.L12
.L9:
rep
ret
.L12:
ucomisd%xmm0, %xmm1
jbe.L9
xorl%eax, %eax
jmpf

Other compilers: clang 2.9 does the optimization (it has only one ucomisd and
j*), but neither Intel 11.1 nor Oracle 5.12.

In my application, this optimization has a 5% impact on the total runtime.

[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) on powerpc*-*-*

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  2012-01-21 
22:35:58 UTC ---
The test just should use some attribute that is common to all targets, like
__attribute__((noinline)) or similar, unless it didn't fail with that attribute
before the fix.  If it didn't, then the test needs to be limited to targets
that support it.

[Bug c++/25973] [4.4/4.5/4.6/4.7 Regression] Wrong warning: control reaches end of non-void function

[paolo.carlini at oracle dot com]

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

--- Comment #15 from Paolo Carlini  2012-01-21 
22:50:40 UTC ---
Well, actually Stage 3 ended while I was in vacations. Sorry about the
misleading note.

[Bug libstdc++/50982] AIX libstdc++ GTHREADS incompatibility

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #55 from Jonathan Wakely  2012-01-21 
22:50:42 UTC ---
Closing, as all the libstdc++-v3/testsuite/30_threads pass now, except the ones
which require sched_yield which are UNSUPPORTED (which like GNU/Linux might
only run when GCC is configured with --enable-libstdcxx-time=rt)

[Bug c++/51577] dependent name lookup finds operator in global namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  2012-01-21 
22:53:40 UTC ---
the problem exists for any operator, it's not specific to ==

here's a reduced form using unary operator+

template
void test( T v )
{
+v;
}

namespace A
{
struct X { };
}

void operator+(A::X) { }

int main()
{
  test( A::X() );
}

[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) on powerpc*-*-*

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  2012-01-21 
23:15:31 UTC ---
> The test just should use some attribute that is common to all targets, like
> __attribute__((noinline)) or similar, unless it didn't fail with that 
> attribute
> before the fix.  If it didn't, then the test needs to be limited to targets
> that support it.

The attribute format seems to do the trick: it hangs on 4.6.2 and compiles with
recent trunk.

--- ../_clean/gcc/testsuite/g++.dg/torture/pr51344.C2012-01-20
11:40:19.0 +0100
+++ gcc/testsuite/g++.dg/torture/pr51344.C2012-01-22 00:13:16.0
+0100
@@ -4,7 +4,7 @@ class A;
 template 
 class B
 {
-  friend __attribute__((cdecl)) A& operator >>(A& a, B& b)
+  friend __attribute__((format)) A& operator >>(A& a, B& b)
   {
 return a;
   }

[Bug bootstrap/51935] Configure fails on included mpc/mpfr

[psmith at gnu dot org]

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

--- Comment #6 from psmith at gnu dot org 2012-01-21 23:24:18 UTC ---
Created attachment 26407
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26407
Fix typo

[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) on powerpc*-*-*

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2012-01-21 
23:30:25 UTC ---
You mean errors out?  format attribute must have 3 arguments.
Try leaf, or nothrow etc. attributes instead, format is a bad idea for a method
that isn't printf/scanf like.

[Bug other/46542] GCC 4.7 pending patches meta-bug

[manu at gcc dot gnu.org]

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

--- Comment #11 from Manuel López-Ibáñez  2012-01-21 
23:43:11 UTC ---
(In reply to comment #10)
> Closing as fixed as 4.7 is stage 4 now.

Before closing this, all pending patches from 4.7 should be moved to the 4.8
meta-bug. Otherwise, they will get lost. It wouldn't be the first time that
patches are lost.

[Bug other/46542] GCC 4.7 pending patches meta-bug

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski  2012-01-21 
23:47:07 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > Closing as fixed as 4.7 is stage 4 now.
> 
> Before closing this, all pending patches from 4.7 should be moved to the 4.8
> meta-bug. Otherwise, they will get lost. It wouldn't be the first time that
> patches are lost.

All of those patches have already been lost as far as I can see.  Most of them
are over a year old and some have been in the pending patches meta-bug for 2 or
3 major releases already.

[Bug target/51934] FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors) on powerpc*-*-*

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  2012-01-21 
23:58:19 UTC ---
> You mean errors out?  format attribute must have 3 arguments.
> Try leaf, or nothrow etc. attributes instead, format is a bad idea for a 
> method
> that isn't printf/scanf like.

Well, format was the first attribute I have found with your requirements:
common to all platforms, hangs before the commit and passes after it (aligned,
cold, flatten, malloc, noclone, noinline,  nothrow, pure don't work; ifunc ,
no_instrument_function, noreturn, no_split_stack give warnings or errors).
nonnull meets also the above criteria, but is also supposed to use arguments.
If someone has more patience than me, be my guest!

Now if its use without arguments should yields an error, it is another bug.

[Bug rtl-optimization/49847] [4.6/4.7 Regression] m68k gcj-4.6 NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[mikpe at it dot uu.se]

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

--- Comment #5 from Mikael Pettersson  2012-01-22 
00:46:53 UTC ---
(In reply to comment #3)
> It's triggered by Joseph Myers' "Table-based default_options_optimization"
> change in r165823:
> http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg01009.html
> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01849.html

Before this change, flag_trapping_math was 1 when compiling C and C++ code but
0 when compiling java .class files, and things worked.  After this change,
flag_trapping_math remains set to 1 when compiling java .class files, and gcc
ICEs compiling java.util.Random.nextGaussian() for m68k.  Force-disabling
flag_trapping_math at the end of opts.c:default_options_optimization() allows
the java classes to be compiled ok and the build to complete.  I'm not yet sure
if this is an m68k backend regression or a java frontend regression from
r165823.

You don't need a native environment to reproduce this problem, a simple cross
to m68k-linux suffices.

[Bug tree-optimization/29333] Jump threading getting in the way of PHI-OPT

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  2012-01-22 
00:47:00 UTC ---
This is the patch which I am testing:
Index: gcc/passes.c
===
--- gcc/passes.c(revision 183381)
+++ gcc/passes.c(working copy)
@@ -1300,11 +1300,11 @@ init_optimization_passes (void)
   NEXT_PASS (pass_phiprop);
   NEXT_PASS (pass_fre);
   NEXT_PASS (pass_copy_prop);
-  NEXT_PASS (pass_merge_phi);
   NEXT_PASS (pass_vrp);
   NEXT_PASS (pass_dce);
   NEXT_PASS (pass_cselim);
   NEXT_PASS (pass_tree_ifcombine);
+  NEXT_PASS (pass_merge_phi);
   NEXT_PASS (pass_phiopt);
   NEXT_PASS (pass_tail_recursion);
   NEXT_PASS (pass_ch);
@@ -1401,6 +1401,7 @@ init_optimization_passes (void)
   NEXT_PASS (pass_late_warn_uninitialized);
   NEXT_PASS (pass_dse);
   NEXT_PASS (pass_forwprop);
+  NEXT_PASS (pass_merge_phi);
   NEXT_PASS (pass_phiopt);
   NEXT_PASS (pass_fold_builtins);
   NEXT_PASS (pass_optimize_widening_mul);

[Bug middle-end/51939] New: ICE: in compute_affine_dependence, at tree-data-ref.c:4103

[marbacz at gmail dot com]

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

 Bug #: 51939
   Summary: ICE: in compute_affine_dependence, at
tree-data-ref.c:4103
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marb...@gmail.com


Created attachment 26408
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26408
Reduced test case

This fails with gcc-4.7.0-alpha20120114, works with gcc-4.5.3.
Reduced test case attached.


x86_64-pc-linux-gnu-gcc-4.7.0-alpha20120114 -O1 -fcheck-data-deps
-D_LARGEFILE64_SOURCE=1 -c bug.c 

(Number of distance vectors differ: Banerjee has 3, Omega has 2.
Banerjee dist vectors:
  0   0 
  0   1 
  1   0 
Omega dist vectors:
  0   0 
  1   0 
data dependence relation:
(Data Dep: 
#(Data Ref: 
#  bb: 9 
#  stmt: D.1732_13 = s_4(D)->strstart;
#  ref: s_4(D)->strstart;
#  base_object: s_4(D)->strstart;
#)
#(Data Ref: 
#  bb: 9 
#  stmt: s_4(D)->strstart = D.1733_14;
#  ref: s_4(D)->strstart;
#  base_object: s_4(D)->strstart;
#)
  inner loop index: 0
  loop nest: (1 2 )
  distance_vector:   0   0 
  distance_vector:   1   0 
  direction_vector: ==
  direction_vector: +=
)
)
bug.c: In function ‘deflate’:
bug.c:14:5: internal compiler error: in compute_affine_dependence, at
tree-data-ref.c:4103
Please submit a full bug report,
with preprocessed source if appropriate.



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