[Bug c++/47774] [C++0x] constexpr specifier on ctor not ignored when template instantiation causes ctor to not satify constexpr requirements

[dev.lists at jessamine dot co.uk]

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

--- Comment #9 from Adam Butcher  2011-03-03 
08:40:28 UTC ---
Great.  That's got rid of the need for the preprocessor hacks to remove
constexpr usage from libstdc++ in c++0x mode.  A full build of our tree from
GCC 4.6 HEAD (including unmodified libstdc++) works fine now.

[Bug c++/47964] New: logical || returns false result, optimization level 02 or 03

[rob.bob.301 at hotmail dot com]

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

   Summary: logical || returns false result, optimization level 02
or 03
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rob.bob@hotmail.com


A very simple expression 
return a < C || ~a < C;
 produces incorrect result if compiled with optimization level O2 or O3.
"a" is an unsigned, "C" is const unsigned,
gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292].
Optimization levels O1 and O0 work fine.

Note that all works fine if compiled with O2 or O3 and gcc version
gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]

Valgrind reports no errors. Please read the few lines of code below.
Please read cout statements, and the printout. They demonstrate the
problem. t_mdb_id is unsigned (typedef).
You will see that the same logical || in cout also produces incorrect
results.
The function is in anonymous namespace.
When I copy the function to a simple
project the problem disappears. 
Note that removing "inline" changes the result to the correct 
value if cout statements stay as they are, but does not change the 
result if complied with cout statements commented out.


inline bool is_valid( t_mdb_id a0 )
{
std::cout << " a0: " << a0 << " ~a0: " << (~a0) << " cv: " <<
exampler::CONST_VOID << std::endl;
std::cout << " l: " << (a0 < exampler::CONST_VOID) << std::endl;
std::cout << " r: " << (~a0 < exampler::CONST_VOID) << std::endl;
std::cout << " is: " << ((a0 < exampler::CONST_VOID) || (~a0 <
exampler::CONST_VOID)) << std::endl;
  return a0 < exampler::CONST_VOID || ~a0 < exampler::CONST_VOID;
}


---
 a0: 1 ~a0: 4294967294 cv: 101
 l: 1
 r: 0
 is: 0
---

[Bug c++/47950] [4.6 Regression] [C++0x] Internal compiler error: non-dependent declaration as condition causes tsubst_copy_and_build assertion failure.

[dev.lists at jessamine dot co.uk]

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

Adam Butcher  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Adam Butcher  2011-03-03 
08:47:09 UTC ---
Great.  Full build of our tree works from clean with latest 4.6 HEAD now.

[Bug testsuite/47965] New: gfortran testsuite failures on mingw32

[thenlich at users dot sourceforge.net]

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

   Summary: gfortran testsuite failures on mingw32
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thenl...@users.sourceforge.net


Problem 2 reported in Bug 42950 also occurs on mingw32, the others (1, 3-6)
not.

(2) /dev/null test (gfortran.dg/dev_null.F90 and gfortran.dg/write_to_null.F90)
where seemingly

#if defined  _WIN32
#define DEV_NULL "nul"

does not work as one gets:
  Fortran runtime error: File '/dev/null' does not exist

[Bug c++/47964] logical || returns false result, optimization level 02 or 03

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  2011-03-03 
09:11:43 UTC ---
You need to provide self-contained testcase, this is not self-contained.

[Bug c/47963] [4.5/4.6 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'integer_cst' in is_global_var, at tree-flow-inline.h:599 on invalid code with -fopenmp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.03.03 09:29:45
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-03-03 
09:29:45 UTC ---
Created attachment 23521
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23521
gcc46-pr47963.patch

Untested fix.

[Bug libstdc++/47913] [C++0x] improve ratio_add to overflow less often

[paolo.carlini at oracle dot com]

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

--- Comment #20 from Paolo Carlini  2011-03-03 
09:51:16 UTC ---
Ah, ok then: when I looked a bit into boost::rational it seemed pretty simple,
didn't notice that additional simplification. Thanks for the additional set of
tests, anyway, as soon as 4.6 is out of the door, we'll move ahead.

[Bug target/47961] media-libs/xvid-1.3.0 fails to build on SPARC unless -mvis flag stripped

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-03-03 
10:11:21 UTC ---
*** Bug 47962 has been marked as a duplicate of this bug. ***

[Bug c/47963] [4.5/4.6 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'integer_cst' in is_global_var, at tree-flow-inline.h:599 on invalid code with -fopenmp

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.5.3

[Bug c/47962] media-libs/xvid-1.3.0 fails to build on SPARC unless -mvis flag stripped

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Richard Guenther  2011-03-03 
10:11:21 UTC ---
.

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

[Bug c++/47964] logical || returns false result, optimization level 02 or 03

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.03.03 10:13:18
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-03-03 
10:13:18 UTC ---
Self-contained as in, compilable and runnable and showing the failure.

[Bug c/47966] New: GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

   Summary: GCC 3.4.6 and 4.4.3 generate wrong stabs debugging
information for global variables explicitly
initialized with 0.
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joni...@gmail.com


extern int printf (const char *, ...);

static int var1;
static int var2 = 0;
static int var3 = 1;

int
main(int argc, char *argv[])
{
printf("v1=%d v2=%d v3=%d\n", var1, var2, var3);

return 0;
}

Old compiler 2.95.2 was putting var1 in .bss section and both var2 and var3 in
.data section. 

GCC 3.4.6 is smarter and puts var2 in .bss section, but seems forgot to update
generation of debugging information. For var2 it generates:
  .stabs "var2:S1",38,0,4,_var2
where 38=0x26=N_STSYM - data segment variable. It have to be 40=0x28=N_LCSYM.

objdump confirms wrong debbugging info.

0804a020 l O .bss0004  var1
0804a024 l O .bss0004  var2
0804a014 l O .data0004  var3 
27 LCSYM  0  0  0804a020 719var1:S(0,1)
28 STSYM  0  0  0804a024 731var2:S(0,1)# BUG: Must be LCSYM
29 STSYM  0  0  0804a014 743var3:S(0,1) 

When I use gcc with -S switch to generate .s assembler file and then manually
fix the .stab from 38 to 40 to say that it is in .bss section then everything
works fine in our GDB 6.8 (proprietary FreeBSD based system).

I've also verified on Ubuntu 10.04 gcc 4.4.3-4ubuntu5 that this bug is still
present. I had no chance to verify anything newer than 4.4.3


Seems that GDB 6.8 for ELF format is smart enough and does ignore the wrong
address that debug symbols provide. 

On our platform for A.OUT format files the GDB 6.8 is confused by wrong
debugging information and tries to get variable information from some bogus
address in .data section. We will have to patch our GDB to trust the symbol
table more than debugging information. Ideally GCC also will be changed.

[Bug c++/47964] logical || returns false result, optimization level 02 or 03

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  2011-03-03 
10:17:45 UTC ---
bool foo (unsigned int a0)
{
  return a0 < 101U || ~a0 < 101U;
}

int
main ()
{
  __builtin_printf ("%d\n", (int) foo (1));
}

certainly prints one, not 0.

[Bug c/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #1 from Dainis Jonitis  2011-03-03 
10:21:03 UTC ---
Created attachment 23522
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23522
GCC generated wrong assembler file

[Bug c/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #2 from Dainis Jonitis  2011-03-03 
10:21:44 UTC ---
Created attachment 23523
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23523
nm utility output

[Bug c/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #3 from Dainis Jonitis  2011-03-03 
10:22:33 UTC ---
Created attachment 23524
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23524
objdump utility output with wrong N_LCSYM debugging information

[Bug c/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #4 from Dainis Jonitis  2011-03-03 
10:22:57 UTC ---
Created attachment 23525
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23525
makefile

[Bug debug/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.03 10:43:15
  Component|c   |debug
 Ever Confirmed|0   |1

--- Comment #5 from Richard Guenther  2011-03-03 
10:43:15 UTC ---
Probably nobody will care, there are nearly no stabs users left.

Well, confirmed anyway.

[Bug target/47920] strange code generated for expression (a+7)/8

[ibolton at gcc dot gnu.org]

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

Ian Bolton  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.03.03 10:49:54
 CC||ibolton at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #4 from Ian Bolton  2011-03-03 10:49:54 
UTC ---
I don't think "strange code" applies any more, thanks to input from Mikael and
Jakub.  I am wondering whether to reject this bug.  Any further comments?

[Bug target/47719] [4.6 regression] ICE compiling libavcodec/adxdec.c (FFmpeg) for ARM

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  2011-03-03 
11:19:10 UTC ---
Marking as P1; ARM people, can this be resolved soon, so that it doesn't block
4.6 release for too long?
As the comments in postreload.c say, it might turn a movhi into
zero_extendhisi2 or
movqi into extendqisi2 for TARGET_THUMB, for arm_arch4 just movqi into
zero_extendqisi2 and for BYTES_BIG_ENDIAN movhi into extendhisi2.  Not sure for
which of the myriad of arm subtargets minipool is applicable though, or if
minipool is even applicable for movqi.  But if you emit some assembly insn
which in one case needs minipool attributes and from another zero/sign extend
insn
you emit exactly the same assembly, but don't have the minipool attributes on
it, it is a bug.

[Bug rtl-optimization/47899] [4.5/4.6 Regression] ICE in get_loop_body, at cfgloop.c:831

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/47957] [4.3/4.4/4.5/4.6 Regression] Type mismatch when a class derived a same name with template parameter

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/47963] [4.5/4.6 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'integer_cst' in is_global_var, at tree-flow-inline.h:599 on invalid code with -fopenmp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug lto/47799] LTO debug info for early inlined functions missing

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #2 from Richard Guenther  2011-03-03 
11:24:36 UTC ---
*** Bug 47941 has been marked as a duplicate of this bug. ***

[Bug lto/47941] [4.6 Regression] FAIL: gcc.dg/guality/vla-2.c

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Richard Guenther  2011-03-03 
11:24:36 UTC ---
.

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

[Bug lto/47936] [4.6 Regression] Missed optimization with LTO due to strict aliasing issues

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P5

--- Comment #3 from Richard Guenther  2011-03-03 
11:25:22 UTC ---
But downgrading priority.

[Bug tree-optimization/47679] [4.6 Regression] Strange uninitialized warning after SRA

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.03 11:26:57
 Ever Confirmed|0   |1

--- Comment #6 from Richard Guenther  2011-03-03 
11:26:57 UTC ---
> Another thing is why the MEM_REF in the diagnostic isn't printed as
> aNewItem.m_storage.dummy_ or aNewItem.m_storage.dummy_.data or
> aNewItem.m_storage.

this is because it doesn't usually match the source and in some cases
is ambiguous.  It's by design.

[Bug middle-end/44440] [4.6 regression] ira_initialization and buitins construction taking too much of startup time

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2011-03-03 
11:29:36 UTC ---
Can it be a side-effect of turning target macros into target hooks?

[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Guenther  2011-03-03 
12:10:44 UTC ---
Author: rguenth
Date: Thu Mar  3 12:10:40 2011
New Revision: 170650

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170650
Log:
2011-03-03  Richard Guenther  

PR middle-end/47283
* tree-ssa-alias.c (ptr_deref_may_alias_decl_p): Make code
match comment.
(refs_may_alias_p_1): For release branches return true if
we are confused by our input.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-alias.c

[Bug c/47837] FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Target|hppa1.1-hp-hpux10.20|hppa1.1-hp-hpux10.20,
   ||s390x-ibm-linux
 CC||krebbel at gcc dot gnu.org
   Host|hppa1.1-hp-hpux10.20|hppa1.1-hp-hpux10.20,
   ||s390x-ibm-linux
  Build|hppa1.1-hp-hpux10.20|hppa1.1-hp-hpux10.20,
   ||s390x-ibm-linux

--- Comment #1 from Andreas Krebbel  2011-03-03 
12:43:34 UTC ---
I see the same on s390x.

[Bug tree-optimization/47967] New: [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fipa-cp on undefined code

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: verify_stmts failed: conversion
of register to a different size with -fipa-cp on
undefined code
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23526
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23526
reduced testcase

$ gcc testcase.c -O -fipa-cp
testcase.c: In function 'bar.constprop.0':
testcase.c:10:1: error: conversion of register to a different size
VIEW_CONVERT_EXPR(D.2694_2);

i_1 = VIEW_CONVERT_EXPR(D.2694_2);

testcase.c:10:1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Tested revisions:
r170622 - crash
4.5 r170013 - OK
4.4 r170013 - OK

[Bug rtl-optimization/47968] New: ICE: in gen_lowpart_general, at rtlhooks.c:51 when converting vector of double to vector of float

[zsojka at seznam dot cz]

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

   Summary: ICE: in gen_lowpart_general, at rtlhooks.c:51 when
converting vector of double to vector of float
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23527
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23527
reduced testcase

Compiler output:
$ gcc -O testcase.c
testcase.c: In function 'foo':
testcase.c:7:3: internal compiler error: in gen_lowpart_general, at
rtlhooks.c:51
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


(gdb) bt
#0  fancy_abort (file=0x115e428 "/mnt/svn/gcc-trunk/gcc/rtlhooks.c", line=51,
function=0x115e490 "gen_lowpart_general")
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892
#1  0x00874ccb in gen_lowpart_general (mode=SFmode, x=) at /mnt/svn/gcc-trunk/gcc/rtlhooks.c:51
#2  0x0069bb04 in extract_bit_field (str_rtx=,
bitsize=, bitnum=, 
unsignedp=, packedp=,
target=, mode=SFmode, tmode=SFmode)
at /mnt/svn/gcc-trunk/gcc/expmed.c:1684
#3  0x006a9562 in expand_expr_real_1 (exp=0x75ba5280, target=, tmode=SFmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /mnt/svn/gcc-trunk/gcc/expr.c:9211
#4  0x006af03d in expand_expr_real (exp=0x75ba5280, target=, tmode=, 
modifier=, alt_rtl=) at
/mnt/svn/gcc-trunk/gcc/expr.c:7206
#5  expand_expr_real (exp=0x75ba5280, target=,
tmode=, modifier=, 
alt_rtl=) at /mnt/svn/gcc-trunk/gcc/expr.c:7174
#6  0x006ab820 in expand_expr (exp=0x75ba41b8,
target=0x75b948e0, tmode=SFmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /mnt/svn/gcc-trunk/gcc/expr.h:422
#7  expand_expr_real_1 (exp=0x75ba41b8, target=0x75b948e0,
tmode=SFmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at /mnt/svn/gcc-trunk/gcc/expr.c:8807
#8  0x008d065b in expand_expr (retval=0x77ff91f8) at
/mnt/svn/gcc-trunk/gcc/expr.h:422
#9  expand_return (retval=0x77ff91f8) at /mnt/svn/gcc-trunk/gcc/stmt.c:1812
#10 0x005e0e8b in expand_gimple_stmt_1 (stmt=0x75b89510) at
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:1951
#11 expand_gimple_stmt (stmt=0x75b89510) at
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:2080
#12 0x005e2f29 in expand_gimple_basic_block (bb=0x75b851a0) at
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:3609
#13 0x005e81d9 in gimple_expand_cfg () at
/mnt/svn/gcc-trunk/gcc/cfgexpand.c:4092
#14 0x007f7056 in execute_one_pass (pass=0x1638ac0) at
/mnt/svn/gcc-trunk/gcc/passes.c:1556
#15 0x007f7355 in execute_pass_list (pass=0x1638ac0) at
/mnt/svn/gcc-trunk/gcc/passes.c:1611
#16 0x0093a2b6 in tree_rest_of_compilation (fndecl=0x75b86f00) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:422
#17 0x00b02312 in cgraph_expand_function (node=0x75ba6000) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1576
#18 0x00b04a5a in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1635
#19 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1899
#20 0x00b04fda in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1096
#21 0x005097bc in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9872
#22 0x008e3248 in compile_file (argc=13, argv=0x7fffdbd8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:591
#23 do_compile (argc=13, argv=0x7fffdbd8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1900
#24 toplev_main (argc=13, argv=0x7fffdbd8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1963
#25 0x76446bbd in __libc_start_main () from /lib/libc.so.6
#26 0x004f036d in _start ()

Tested revisions:
r170622 - crash
4.5 r170013 - crash
4.4 r170013 - crash
4.4.5 (release checking) - crash
4.3.5 (release checking) - OK

Maybe it's a regression from 4.3.

[Bug rtl-optimization/47968] ICE: in gen_lowpart_general, at rtlhooks.c:51 when converting vector of double to vector of float

[zsojka at seznam dot cz]

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

Zdenek Sojka  changed:

   What|Removed |Added

  Attachment #23527|0   |1
is obsolete||

--- Comment #1 from Zdenek Sojka  2011-03-03 13:06:51 
UTC ---
Created attachment 23528
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23528
reduced testcase

http://gcc.gnu.org/bugzilla/attachment.cgi?id=23527&action=edit is for PR47967

[Bug tree-optimization/47967] [4.6 Regression] ICE: verify_stmts failed: conversion of register to a different size with -fipa-cp on undefined code

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.03 13:10:11
 CC||jamborm at gcc dot gnu.org
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-03-03 
13:10:11 UTC ---
Confirmed.

[Bug middle-end/47968] ICE: in gen_lowpart_general, at rtlhooks.c:51 when converting vector of double to vector of float

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.03 13:15:19
  Component|rtl-optimization|middle-end
 Ever Confirmed|0   |1

--- Comment #2 from Richard Guenther  2011-03-03 
13:15:19 UTC ---
Confirmed.

#1  0x0098a3b8 in gen_lowpart_general (mode=SFmode, x=0x75b36900)
at /space/rguenther/src/svn/trunk/gcc/rtlhooks.c:51
51  gcc_assert (result != 0);
(gdb) p x
$1 = (rtx) 0x75b36900
(gdb) call debug_rtx (x)
(reg:DF 64)

Happens during expanding of BIT_FIELD_REF  from

;; Function foo (foo)

foo (double2 d2)
{
  float D.2687;
  vector(4) float f4.0;

  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  f4.0_2 = VIEW_CONVERT_EXPR(d2_1(D));
  D.2687_3 = BIT_FIELD_REF ;
  return D.2687_3;

[Bug middle-end/47968] ICE: in gen_lowpart_general, at rtlhooks.c:51 when converting vector of double to vector of float

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Guenther  2011-03-03 
13:30:28 UTC ---
We call extract_bit_field SFmode [0, 32] on (subreg:V4SF (reg/v:V2DF 62 [ d2 ])
0) which then ends up using the vec_extract optabs, but those are obviously
not designed for a mode-changing extraction (and we stripped the subreg
before using it - whether that's a good idea is another question).

We try to find a "better" vector mode but end up with V2DF again because
we want to preserve NUNITS of the inner reg (for whatever reason again).

We can obviously guard the vec_extract optab use by GET_MODE_INNER (GET_MODE
(op0)) == tmode, but we can as well try to find a "better" mode that also
is going to work ...

Testing a patch, CCing Andrew who added this code.

Patch:

Index: gcc/expmed.c
===
--- gcc/expmed.c(revision 170649)
+++ gcc/expmed.c(working copy)
@@ -1205,7 +1205,6 @@ extract_bit_field_1 (rtx str_rtx, unsign
   && GET_MODE_INNER (GET_MODE (op0)) != tmode)
 {
   enum machine_mode new_mode;
-  int nunits = GET_MODE_NUNITS (GET_MODE (op0));

   if (GET_MODE_CLASS (tmode) == MODE_FLOAT)
new_mode = MIN_MODE_VECTOR_FLOAT;
@@ -1221,8 +1220,7 @@ extract_bit_field_1 (rtx str_rtx, unsign
new_mode = MIN_MODE_VECTOR_INT;

   for (; new_mode != VOIDmode ; new_mode = GET_MODE_WIDER_MODE (new_mode))
-   if (GET_MODE_NUNITS (new_mode) == nunits
-   && GET_MODE_SIZE (new_mode) == GET_MODE_SIZE (GET_MODE (op0))
+   if (GET_MODE_SIZE (new_mode) == GET_MODE_SIZE (GET_MODE (op0))
&& targetm.vector_mode_supported_p (new_mode))
  break;
   if (new_mode != VOIDmode)

[Bug middle-end/47968] ICE: in gen_lowpart_general, at rtlhooks.c:51 when converting vector of double to vector of float

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther  2011-03-03 
13:34:50 UTC ---
Btw, I wonder since when (and why) we accept

  float4 f4 = (float4) d2;

as valid code.

[Bug c++/47969] New: [C++0x] ICE: SIGSEGV in compute_array_index_type (cp/decl.c:7522)

[zsojka at seznam dot cz]

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

   Summary: [C++0x] ICE: SIGSEGV in compute_array_index_type
(cp/decl.c:7522)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 23529
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23529
reduced testcase

$ gcc -std=c++0x testcase.C
testcase.C:8:9: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Doesn't crash when operator int is uncommented.

(gdb) bt
#0  compute_array_index_type (name=0x75ba0058, size=0x0, complain=3) at
/mnt/svn/gcc-trunk/gcc/cp/decl.c:7522
#1  0x00539100 in create_array_type_for_decl (declarator=0x1942220,
declspecs=0x7fffd880, decl_context=NORMAL, initialized=0, 
attrlist=0x7fffd768) at /mnt/svn/gcc-trunk/gcc/cp/decl.c:7784
#2  grokdeclarator (declarator=0x1942220, declspecs=0x7fffd880,
decl_context=NORMAL, initialized=0, attrlist=0x7fffd768)
at /mnt/svn/gcc-trunk/gcc/cp/decl.c:8671
#3  0x0053efd8 in start_decl (declarator=0x1942220,
declspecs=0x7fffd880, initialized=0, attributes=0x0, prefix_attributes=0x0, 
pushed_scope_p=0x7fffd810) at /mnt/svn/gcc-trunk/gcc/cp/decl.c:4211
#4  0x005e45f0 in cp_parser_init_declarator (parser=0x75ba00b0,
decl_specifiers=0x7fffd880, checks=0x0, 
function_definition_allowed_p=0 '\000', member_p=0 '\000',
declares_class_or_enum=0, function_definition_p=0x7fffd8ef "", 
maybe_range_for_decl=0x0) at /mnt/svn/gcc-trunk/gcc/cp/parser.c:14653
#5  0x005ea030 in cp_parser_simple_declaration (parser=0x75ba00b0,
function_definition_allowed_p=1 '\001', maybe_range_for_decl=0x0)
at /mnt/svn/gcc-trunk/gcc/cp/parser.c:9712
#6  0x005ea3e9 in cp_parser_block_declaration (parser=0x75ba00b0,
statement_p=0 '\000') at /mnt/svn/gcc-trunk/gcc/cp/parser.c:9598
#7  cp_parser_block_declaration (parser=0x75ba00b0, statement_p=0 '\000')
at /mnt/svn/gcc-trunk/gcc/cp/parser.c:9532
#8  0x005ee132 in cp_parser_declaration (parser=0x75ba00b0) at
/mnt/svn/gcc-trunk/gcc/cp/parser.c:9503
#9  cp_parser_declaration (parser=0x75ba00b0) at
/mnt/svn/gcc-trunk/gcc/cp/parser.c:9410
#10 0x005ecc5a in cp_parser_declaration_seq_opt (parser=0x75ba00b0)
at /mnt/svn/gcc-trunk/gcc/cp/parser.c:9389
#11 0x005ee7a9 in cp_parser_translation_unit () at
/mnt/svn/gcc-trunk/gcc/cp/parser.c:3463
#12 c_parse_file () at /mnt/svn/gcc-trunk/gcc/cp/parser.c:25293
#13 0x006c4285 in c_common_parse_file () at
/mnt/svn/gcc-trunk/gcc/c-family/c-opts.c:1077
#14 0x00a2c95c in compile_file (argc=14, argv=0x7fffdba8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:579

Tested revisions:
r170622 - crash

[Bug middle-end/47968] ICE: in gen_lowpart_general, at rtlhooks.c:51 when converting vector of double to vector of float

[zsojka at seznam dot cz]

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

--- Comment #5 from Zdenek Sojka  2011-03-03 13:56:06 
UTC ---
The testcase is accepted (compiles fine) by 3.3.6, 3.4.6, 4.0.4, 4.1.2, 4.2.4,
4.3.5.

The are files in the testsuite that use that style, at least
gcc.c-torture/compile/vector-[123].c

Changing the code to
  float4 f4 = *(float4 *) &d2;
doesn't prevent the crash

[Bug libfortran/47802] [4.6 Regression] libgfortran/intrinsics/ctime.c:75:3: error: too few arguments to function 'ctime_r'

[dave at hiauly1 dot hia.nrc.ca]

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

--- Comment #30 from dave at hiauly1 dot hia.nrc.ca 2011-03-03 13:56:25 UTC ---
On Fri, 25 Feb 2011, burnus at gcc dot gnu.org wrote:

> Please shout loudly if there you still encounter a build failure!
> 
> 
> TO BE DONE: The HP-UX (et al.?) compile warning regarding the _r functions and
> _REENTRANT, cf. comment 20 and comment 23.

In testing fix for above, I see:

../../../gcc/libgfortran/intrinsics/ctime.c: In function 'strctime':
../../../gcc/libgfortran/intrinsics/ctime.c:43:20: warning: initialization
makes pointer from integer without a cast [enabled by default]

Unfortunately, localtime_r has a different proto:

int localtime_r(const time_t *timer, struct tm *result);

Dave

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #15 from Janne Blomqvist  2011-03-03 
14:03:40 UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > could it be that it was the intention to set __USE_MINGW_ANSI_STDIO in 
> > effect?
> 
> Yes - and that is what does happen for _POSIX=1 on MinGW64. But it does not
> happen for _POSIX=1 on the 32bit MinGW.
> 
> Jerry et al.: Do you think the following patch is OK?
> 
> --- a/libgfortran/libgfortran.h
> +++ b/libgfortran/libgfortran.h
> @@ -33,6 +33,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If
> not, see
> any system header file is included.  */
>  #if defined __MINGW32__
>  #  define _POSIX 1
> +#  define _POSIX_SOURCE 1
>  #  define gfc_printf gnu_printf
>  #else
>  #  define gfc_printf __printf__

Well, first a disclaimer: I don't use Windows myself, and I have little
experience with win32 programming, and finally, I have no way of testing mingw
specific functionality.

That being said, I'm not sure this patch accomplishes anything. Looking at the
_mingw.h you linked to in another post, __USE_MINGW_ANSI_STDIO is set also if
_GNU_SOURCE is set. Which AFAICS is always set when compiling libgfortran
(there's even a bit of belt-and-suspenders approach here, in that _GNU_SOURCE
is set from both AC_USE_SYSTEM_EXTENSIONS as well as explicitly added to
AM_CFLAGS in Makefile.am; probably the second one can be removed as a
janitorial patch once 4.7 opens).

Secondly, IIRC mingw64 also sets __MINGW32__, so there should be no difference
between mingw32 and ming64 here.

Third, I'm somewhat wary of playing with preprocessor defines this close to a
release. As this issue doesn't seem particularly critical, I'd vote for
postponing it until 4.7. That is, unless Kai or someone else who actually
understands mingw pops in and says it's completely safe and will fix the issue.

[Bug libfortran/47970] New: c99_functions.c:611:5: warning: implicit declaration of function 'round'

[danglin at gcc dot gnu.org]

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

   Summary: c99_functions.c:611:5: warning: implicit declaration
of function 'round'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa1.1-hp-hpux10*
Target: hppa1.1-hp-hpux10*
 Build: hppa1.1-hp-hpux10*


libtool: compile:  /xxx/gnu/gcc/objdir/./gcc/xgcc -B/xxx/gnu/gcc/objdir/./gcc/
-
B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/bin/
-B/opt/gnu/gcc/gcc-4.6/hppa1.1-h
p-hpux10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/include
-isy
stem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/sys-include -DHAVE_CONFIG_H -I.
-
I../../../../gcc/libgfortran -iquote../../../../gcc/libgfortran/io
-I../../../..
/gcc/libgfortran/../gcc -I../../../../gcc/libgfortran/../gcc/config
-I../../../.
./gcc/libgfortran/../libquadmath -I../../.././gcc -D_GNU_SOURCE -std=gnu99
-Wall
 -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra
-Wwrite
-strings -fcx-fortran-rules -g -O2 -threads -MT c99_functions.lo -MD -MP -MF
.de
ps/c99_functions.Tpo -c ../../../../gcc/libgfortran/intrinsics/c99_functions.c
-fPIC -DPIC -o .libs/c99_functions.o
../../../../gcc/libgfortran/intrinsics/c99_functions.c: In function 'roundl':
../../../../gcc/libgfortran/intrinsics/c99_functions.c:611:5: warning: implicit
declaration of function 'round' [-Wimplicit-function-declaration]
../../../../gcc/libgfortran/intrinsics/c99_functions.c:611:12: warning:
incompat
ible implicit declaration of built-in function 'round' [enabled by default]

Target does not have `round' and round implementation follows use.

[Bug libfortran/47970] c99_functions.c:611:5: warning: implicit declaration of function 'round'

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.03 14:29:24
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-03-03 
14:29:24 UTC ---
Confirmed.

[Bug c++/47971] New: [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11725 on valid code

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11725
on valid code
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 23530
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23530
reduced testcase

$ gcc testcase.C
testcase.C: In constructor 'S<  >::S() [with
 = double]':
testcase.C:7:11:   instantiated from here
testcase.C:4:10: internal compiler error: in tsubst_copy, at cp/pt.c:11725
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  fancy_abort (file=0x120a958 "/mnt/svn/gcc-trunk/gcc/cp/pt.c", line=11725,
function=0x120fcbd "tsubst_copy")
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:892
#1  0x0055cb25 in tsubst_copy (t=,
args=0x75bee050, complain=3, in_decl=0x75bec450)
at /mnt/svn/gcc-trunk/gcc/cp/pt.c:11725
#2  0x0055ff61 in tsubst_copy_and_build (t=0x75bdc690,
args=0x75bee050, complain=3, in_decl=0x75bec450, function_p=0 '\000', 
integral_constant_expression_p=) at
/mnt/svn/gcc-trunk/gcc/cp/pt.c:13382
#3  0x0055fbab in tsubst_copy_and_build (t=0x75bc8840,
args=0x75bee050, complain=3, in_decl=0x75bec450, 
function_p=, integral_constant_expression_p=0 '\000')
at /mnt/svn/gcc-trunk/gcc/cp/pt.c:12980
#4  0x005608a2 in tsubst_copy_and_build (t=0x75bc8880,
args=0x75bee050, complain=3, in_decl=0x75bec450, function_p=0 '\000', 
integral_constant_expression_p=) at
/mnt/svn/gcc-trunk/gcc/cp/pt.c:12862
#5  0x00554e39 in tsubst_expr (t=0x75bc8880, args=0x75bee050,
complain=3, in_decl=0x75bec450, 
integral_constant_expression_p=0 '\000') at
/mnt/svn/gcc-trunk/gcc/cp/pt.c:12422
#6  0x00555bc9 in tsubst_expr (t=0x77ecea80, args=0x75bee050,
complain=3, in_decl=0x75bec450, 
integral_constant_expression_p=0 '\000') at
/mnt/svn/gcc-trunk/gcc/cp/pt.c:11998
#7  0x00554ee9 in tsubst_expr (t=0x75bc8800, args=0x75bee050,
complain=3, in_decl=0x75bec450, 
integral_constant_expression_p=0 '\000') at
/mnt/svn/gcc-trunk/gcc/cp/pt.c:12163
#8  0x0005 in tsubst_expr (t=,
args=0x75bee050, complain=3, in_decl=0x75bec450, 
integral_constant_expression_p=0 '\000') at
/mnt/svn/gcc-trunk/gcc/cp/pt.c:11984
#9  0x00554ee9 in tsubst_expr (t=0x75bc87c0, args=0x75bee050,
complain=3, in_decl=0x75bec450, 
integral_constant_expression_p=0 '\000') at
/mnt/svn/gcc-trunk/gcc/cp/pt.c:12163
#10 0x00581fe2 in instantiate_decl (d=0x75bdf500, defer_ok=, expl_inst_class_mem_p=0 '\000')
at /mnt/svn/gcc-trunk/gcc/cp/pt.c:17421
#11 0x00589444 in instantiate_pending_templates (retries=) at /mnt/svn/gcc-trunk/gcc/cp/pt.c:17518
#12 0x005b7942 in cp_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/cp/decl2.c:3684
#13 0x00a2c998 in compile_file (argc=13, argv=0x7fffdbc8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:591


Tested revisions:
r170622 - crash
4.5 r170013 - OK
4.4 r170013 - OK

[Bug debug/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for global variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #6 from Dainis Jonitis  2011-03-03 
14:40:18 UTC ---
Problem is actually only with static file scope variables. Only then the
N_LCSYM and N_STSYM stabs are used. With global variables there is no problem
as N_GSYM stab is used instead.

[Bug libfortran/47972] New: error.c:158:7: warning: return makes pointer from integer without a cast

[danglin at gcc dot gnu.org]

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

   Summary: error.c:158:7: warning: return makes pointer from
integer without a cast
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa1.1-hp-hpux10*
Target: hppa1.1-hp-hpux10*
 Build: hppa1.1-hp-hpux10*


libtool: compile:  /xxx/gnu/gcc/objdir/./gcc/xgcc -B/xxx/gnu/gcc/objdir/./gcc/
-
B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/bin/
-B/opt/gnu/gcc/gcc-4.6/hppa1.1-h
p-hpux10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/include
-isy
stem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/sys-include -DHAVE_CONFIG_H -I.
-
I../../../../gcc/libgfortran -iquote../../../../gcc/libgfortran/io
-I../../../..
/gcc/libgfortran/../gcc -I../../../../gcc/libgfortran/../gcc/config
-I../../../.
./gcc/libgfortran/../libquadmath -I../../.././gcc -D_GNU_SOURCE -std=gnu99
-Wall
 -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra
-Wwrite
-strings -fcx-fortran-rules -g -O2 -threads -MT error.lo -MD -MP -MF
.deps/error
.Tpo -c ../../../../gcc/libgfortran/runtime/error.c  -fPIC -DPIC -o
.libs/error.
o
../../../../gcc/libgfortran/runtime/error.c: In function 'gf_strerror':
../../../../gcc/libgfortran/runtime/error.c:158:7: warning: return makes
pointer from integer without a cast [enabled by default]

Proto:
int strerror_r(int errnum, char *buffer, int buflen);

Declaration is in string.h.

[Bug libfortran/47973] New: error.c:158:7: warning: return makes pointer from integer without a cast

[danglin at gcc dot gnu.org]

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

   Summary: error.c:158:7: warning: return makes pointer from
integer without a cast
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa1.1-hp-hpux10*
Target: hppa1.1-hp-hpux10*
 Build: hppa1.1-hp-hpux10*


libtool: compile:  /xxx/gnu/gcc/objdir/./gcc/xgcc -B/xxx/gnu/gcc/objdir/./gcc/
-
B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/bin/
-B/opt/gnu/gcc/gcc-4.6/hppa1.1-h
p-hpux10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/include
-isy
stem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/sys-include -DHAVE_CONFIG_H -I.
-
I../../../../gcc/libgfortran -iquote../../../../gcc/libgfortran/io
-I../../../..
/gcc/libgfortran/../gcc -I../../../../gcc/libgfortran/../gcc/config
-I../../../.
./gcc/libgfortran/../libquadmath -I../../.././gcc -D_GNU_SOURCE -std=gnu99
-Wall
 -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra
-Wwrite
-strings -fcx-fortran-rules -g -O2 -threads -MT error.lo -MD -MP -MF
.deps/error
.Tpo -c ../../../../gcc/libgfortran/runtime/error.c  -fPIC -DPIC -o
.libs/error.
o
../../../../gcc/libgfortran/runtime/error.c: In function 'gf_strerror':
../../../../gcc/libgfortran/runtime/error.c:158:7: warning: return makes
pointer from integer without a cast [enabled by default]

Proto:
int strerror_r(int errnum, char *buffer, int buflen);

Declaration is in string.h.

[Bug c++/47974] New: [4.6 Regression] ICE: tree check: expected tree_vec, have error_mark in tsubst_template_args, at cp/pt.c:8969 on invalid code

[zsojka at seznam dot cz]

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

   Summary: [4.6 Regression] ICE: tree check: expected tree_vec,
have error_mark in tsubst_template_args, at
cp/pt.c:8969 on invalid code
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz


Created attachment 23531
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23531
reduced testcase

$ gcc testcase.C
testcase.C:5:12: error: 'double' is not a valid type for a template constant
parameter
testcase.C:8:16: error: 'double' is not a valid type for a template constant
parameter
testcase.C:8:43: error: 'N' was not declared in this scope
testcase.C:10:3: error: '' is not a valid type for a template
constant parameter
testcase.C:10:3: internal compiler error: tree check: expected tree_vec, have
error_mark in tsubst_template_args, at cp/pt.c:8969
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Tested revisions:
r170622 - crash
4.5 r170013 - OK

[Bug libfortran/47945] REAL(8) output conversion error on MinGW32

[thenlich at users dot sourceforge.net]

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

--- Comment #16 from Thomas Henlich  
2011-03-03 14:58:35 UTC ---
My _mingw.h has the following:

#if defined(_POSIX) && !defined(__USE_MINGW_ANSI_STDIO)
/* Enable __USE_MINGW_ANSI_STDIO if _POSIX defined
 * and If user did _not_ specify it explicitly... */
#  define __USE_MINGW_ANSI_STDIO1
#endif

So _POSIX_SOURCE really seems to be the wrong way and I wonder what the values
of _POSIX and __USE_MINGW_ANSI_STDIO actually are.

[Bug middle-end/47968] ICE: in gen_lowpart_general, at rtlhooks.c:51 when converting vector of double to vector of float

[zsojka at seznam dot cz]

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

--- Comment #6 from Zdenek Sojka  2011-03-03 15:19:55 
UTC ---
Created attachment 23532
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23532
testcase using long instead of double

This one fails the same way.

[Bug c++/47974] [4.6 Regression] ICE: tree check: expected tree_vec, have error_mark in tsubst_template_args, at cp/pt.c:8969 on invalid code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.03.03 15:30:07
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from Paolo Carlini  2011-03-03 
15:30:07 UTC ---
Seems easy.

[Bug target/47975] New: ICE: in expand_shift, at expmed.c:2299 when using 256b vectors without -mavx

[zsojka at seznam dot cz]

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

   Summary: ICE: in expand_shift, at expmed.c:2299 when using 256b
vectors without -mavx
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


Created attachment 23533
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23533
reduced testcase

$ gcc testcase.c
testcase.c: In function 'foo':
testcase.c:6:5: internal compiler error: in expand_shift, at expmed.c:2299
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ gcc-4.5.2 testcase.c
testcase.c: In function 'foo':
testcase.c:6:5: error: invalid operands to binary << (have '__vector(8) int'
and '__vector(8) int')

Tested revisions:
r170622 - crash
4.5 - code is rejected

[Bug target/47976] New: Recent fortran testsuite regressions

[ams at gcc dot gnu.org]

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

   Summary: Recent fortran testsuite regressions
   Product: gcc
   Version: 4.5.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@gcc.gnu.org


Some where between svn167945 and svn170352, the gcc 4.5 branch has acquired two
test regressions:

FAIL: default/gfortran.sum:gfortran.dg/actual_array_constructor_3.f90 -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions execution test
FAIL: default/gfortran.sum:gfortran.dg/actual_array_constructor_3.f90 -O3
-fomit-frame-pointer -funroll-loops execution test

These both used to pass. Both now fail with segmentation faults.

My configuration: --target=arm-none-linux-gnueabi --with-arch=armv7-a
--with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb

[Bug debug/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for static file scope variables explicitly initialized with 0.

[jonitis at gmail dot com]

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

--- Comment #7 from Dainis Jonitis  2011-03-03 
15:44:04 UTC ---
Everything works fine in Ubuntu GDB, because the Assembler (2.20.1) is smart
enough to ignore wrong debug symbols and still generate correct object file
with correct addresses in stabs that match symbol table addresses. 

It fails on our system because we use prehistoric assembler 1.92.3 that is
confused by wrong debug symbols and produces the wrong stab addresses in object
file.

[Bug c++/47971] [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11725 on valid code

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.03 15:59:24
   Target Milestone|--- |4.6.0
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-03-03 
15:59:24 UTC ---
Confirmed.

[Bug libfortran/47972] error.c:158:7: warning: return makes pointer from integer without a cast

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-03-03 
15:59:49 UTC ---
*** Bug 47973 has been marked as a duplicate of this bug. ***

[Bug libfortran/47973] error.c:158:7: warning: return makes pointer from integer without a cast

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Richard Guenther  2011-03-03 
15:59:49 UTC ---
.

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

[Bug target/47975] ICE: in expand_shift, at expmed.c:2299 when using 256b vectors without -mavx

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.03.03 16:01:27
 Ever Confirmed|0   |1

--- Comment #1 from Richard Guenther  2011-03-03 
16:01:27 UTC ---
Confirmed.

[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek  2011-03-03 
16:06:38 UTC ---
Author: jakub
Date: Thu Mar  3 16:06:33 2011
New Revision: 170654

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170654
Log:
PR debug/47283
* cfgexpand.c (expand_debug_expr) : If MEM_REF
first operand is not is_gimple_mem_ref_addr, try to fold it.
If the operand still isn't is_gimple_mem_ref_addr, clear
MEM_EXPR on op0.

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

[Bug c/47977] New: powerpc (-mcpu=8548) Wrong code for double operations in little endian mode

[m.lazzarotto at robox dot it]

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

   Summary: powerpc (-mcpu=8548) Wrong code for double operations
in little endian mode
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m.lazzaro...@robox.it


* Output of gcc -v :

COLLECT_GCC=~/gcc-powerpc-4.5.2/bin/powerpc-eabi-gcc
COLLECT_LTO_WRAPPER=~/gcc-powerpc-4.5.2/libexec/gcc/powerpc-eabi/4.5.2/lto-wrapper
Target: powerpc-eabi
Configured with: ~/build-gcc-4.5/src/gcc-4.5.2/configure --prefix
~/gcc-powerpc-4.5.2 --with-local-prefix=~/gcc-powerpc-4.5.2
--enable-languages=c,c++ --target=powerpc-eabi --disable-threads --disable-tls
--disable-libmudflap --disable-libssp --disable-libgomp --with-gnu-ld
--enable-e500-double
Thread model: single
gcc version 4.5.2 (GCC)

* The program that triggers the bug :

[test_fp.c]

double test_fp(double val)
{
return val + val;
}


* Command line for big-endian :

~/gcc-powerpc-4.5.2/bin/powerpc-eabi-gcc-4.5.2 -c   -mhard-float
-fomit-frame-pointer -fno-exceptions   -Wall -Werror -fpack-struct=8 -G8  
-mcpu=8548 -misel=yes -meabi -O2 -mno-strict-align -mno-multiple
-Wno-strict-aliasing -msdata=none  -S -mbig test_fp.c -o test_fp-be.s

* Command line for little-endian :

~/gcc-powerpc-4.5.2/bin/powerpc-eabi-gcc-4.5.2 -c   -mhard-float
-fomit-frame-pointer -fno-exceptions   -Wall -Werror -fpack-struct=8 -G8  
-mcpu=8548 -misel=yes -meabi -O2 -mno-strict-align -mno-multiple
-Wno-strict-aliasing -msdata=none  -S -mlittle test_fp.c -o test_fp-le.s

* * * The output files, with comments:

$ cat test_fp-be-COMMMENTED.s
.file   "test_fp.c"
.gnu_attribute 4, 2
.gnu_attribute 8, 1
.gnu_attribute 12, 1
.section".text"
.align 2
.globl test_fp
.type   test_fp, @function
test_fp:
stwu 1,-16(1)
efdadd 3,3,3# val = val + val
lwz 9,8(1)  # What's the purpose ?
lwz 10,12(1)# What's the purpose ?
evmergehi 9,3,3 # R9 = HIGH DWORD (correct in big
endian mode)
mr 10,3 # R10 = LOW DWORD (correct in big
endian mode)
stw 9,8(1)  # What's the purpose ?
mr 3,9  # R3 = R9, HIGH dword correct (big
endian)
stw 10,12(1)# What's the purpose ?
mr 4,10 # R4 = R10, LOW dword correct (big
endian)
addi 1,1,16
blr # remarque: is there a way to exit with
a 64 bit register (f.i. R3) ?
.size   test_fp, .-test_fp
.ident  "GCC: (GNU) 4.5.2"


$ cat test_fp-le-COMMENTED.s
.file   "test_fp.c"
.gnu_attribute 4, 2
.gnu_attribute 8, 1
.gnu_attribute 12, 1
.section".text"
.align 2
.globl test_fp
.type   test_fp, @function
test_fp:
stwu 1,-16(1)
efdadd 3,3,3# val = val + val
lwz 9,8(1)  # What's the purpose ?
lwz 10,12(1)# What's the purpose ?
evmergehi 9,3,3 # R9 = HIGH DWORD (error in little
endian mode???)
mr 10,3 # R10 = LOW DWORD (error in little
endian mode???)
stw 9,8(1)  # What's the purpose ?
mr 3,9  # R3 = R9, LOW dword expected (little
endian) but R9 is HIGH dword
stw 10,12(1)# What's the purpose ?
mr 4,10 # R4 = R10, HIGH dword expected (little
endian) but R10 is LOW dword!!!
addi 1,1,16
blr # remarque: is there a way to exit with
a 64 bit register (f.i. R3) ?
.size   test_fp, .-test_fp
.ident  "GCC: (GNU) 4.5.2"

[Bug c/47963] [4.5/4.6 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'integer_cst' in is_global_var, at tree-flow-inline.h:599 on invalid code with -fopenmp

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  2011-03-03 
16:09:59 UTC ---
Author: jakub
Date: Thu Mar  3 16:09:55 2011
New Revision: 170655

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170655
Log:
PR c/47963
* gimplify.c (omp_add_variable): Only call omp_notice_variable
on TYPE_SIZE_UNIT if it is a DECL.

* gcc.dg/gomp/pr47963.c: New test.
* g++.dg/gomp/pr47963.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/gomp/pr47963.C
trunk/gcc/testsuite/gcc.dg/gomp/pr47963.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/47283] [4.6 regression] ICE in refs_may_alias_p_1, at tree-ssa-alias.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #24 from Jakub Jelinek  2011-03-03 
16:14:50 UTC ---
Fixed.

[Bug c/47963] [4.5 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'integer_cst' in is_global_var, at tree-flow-inline.h:599 on invalid code with -fopenmp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.6.0
Summary|[4.5/4.6 Regression] ICE:   |[4.5 Regression] ICE: tree
   |tree check: expected tree   |check: expected tree that
   |that contains 'decl common' |contains 'decl common'
   |structure, have |structure, have
   |'integer_cst' in|'integer_cst' in
   |is_global_var, at   |is_global_var, at
   |tree-flow-inline.h:599 on   |tree-flow-inline.h:599 on
   |invalid code with -fopenmp  |invalid code with -fopenmp
  Known to fail|4.6.0   |

--- Comment #3 from Jakub Jelinek  2011-03-03 
16:15:40 UTC ---
Fixed on the trunk so far.

[Bug target/47975] ICE: in expand_shift, at expmed.c:2299 when using 256b vectors without -mavx

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-03-03 
16:19:23 UTC ---
We lower the vector - vector shift to

:
  x.0_1 = x;
  x.1_2 = x;
  D.2689_4 = BIT_FIELD_REF ;
  D.2690_5 = BIT_FIELD_REF ;
  D.2691_6 = D.2689_4 << D.2690_5;
  D.2692_7 = BIT_FIELD_REF ;
  D.2693_8 = BIT_FIELD_REF ;
  D.2694_9 = D.2692_7 << D.2693_8;
  x.2_3 = {D.2691_6, D.2694_9};
  x = x.2_3;
  return;

but do not lower that shift further because type_for_widest_vector_mode
calls optab_handler with ashl_optab which happens because in
optab_for_tree_code
we have

case LSHIFT_EXPR:
  if (VECTOR_MODE_P (TYPE_MODE (type)))
{
  if (subtype == optab_vector)
return TYPE_SATURATING (type) ? NULL : vashl_optab;

  gcc_assert (subtype == optab_scalar);
}
  if (TYPE_SATURATING(type))
return TYPE_UNSIGNED(type) ? usashl_optab : ssashl_optab;
  return ashl_optab;

and we have ...

#define TYPE_MODE(NODE) \
  (TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \
   ? vector_type_mode (NODE) : (NODE)->type.mode)

which returns BLKmode instead of V8SImode.  Bah to whoever introduced
that hack to TYPE_MODE.

[Bug target/47975] ICE: in expand_shift, at expmed.c:2299 when using 256b vectors without -mavx

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Guenther  2011-03-03 
16:21:51 UTC ---
I have a patch.

[Bug target/47977] powerpc (-mcpu=8548) Wrong code for double operations in little endian mode

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Joseph S. Myers  2011-03-03 
16:22:13 UTC ---
Using --enable-e500-double for a non-e500 target will produce a broken
compiler.  So if you want e500 double code to work at all, try the
powerpc-eabispe target.  (Or else pass -mabi=spe explicitly.)

It is also known that all the insn patterns for e500 are only expected to work
for big-endian.  In general little-endian Power is hardly tested at all, but
the SPE case is specifically expected to be broken.

[Bug fortran/47978] New: [OOP] Invalid INTENT in overriding TBP not detected

[sfilippone at uniroma2 dot it]

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

   Summary: [OOP] Invalid INTENT in overriding TBP not detected
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sfilipp...@uniroma2.it


Hello,
The attached code looks invalid to me (and to the NAG and XLF compilers), but
is accepted by gnu fortran. 

[sfilippo@localhost bug33]$ gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gnu46/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/gnu46
--enable-languages=c,c++,fortran --with-gmp=/home/travel/GCC/BUILDS/gmp
--with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-mpc=/home/travel/GCC/BUILDS/mpc 
Thread model: posix
gcc version 4.6.0 20110225 (experimental) (GCC)

[sfilippo@localhost bug33]$ gfortran -c try_ext.f90 
[sfilippo@localhost bug33]$ 


[sfilippo@localhost bug33]$ nagfor -c try_ext.f90 -f2003
NAG Fortran Compiler Release 5.3(826),5.2(765)
Error: try_ext.f90, line 38: Argument J of overriding type-bound procedure BAR
of type EXTFOO has a different INTENT
Errors in declarations, no further processing for EXTFOO_MOD
[NAG Fortran Compiler error termination, 1 error]

---
bash-3.2$ xlf2003 -c try_ext.f90 
** foo_mod   === End of Compilation 1 ===
"try_ext.f90", line 25.27: 1514-593 (S) Dummy argument j of overridden binding
bar was declared with the INTENT(IN) attribute.  The corresponding dummy
argument of overriding binding bar must also be declared with the INTENT(IN)
attribute.
** extfoo_mod   === End of Compilation 2 ===
1501-511  Compilation failed for file try_ext.f90.

[Bug fortran/47978] [OOP] Invalid INTENT in overriding TBP not detected

[sfilippone at uniroma2 dot it]

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

--- Comment #1 from Salvatore Filippone  
2011-03-03 16:47:24 UTC ---
Created attachment 23534
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23534
test-case

[Bug c++/47950] [4.6 Regression] [C++0x] Internal compiler error: non-dependent declaration as condition causes tsubst_copy_and_build assertion failure.

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2011-03-03 
16:51:23 UTC ---
Author: jason
Date: Thu Mar  3 16:51:20 2011
New Revision: 170656

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170656
Log:
PR c++/47950
* pt.c (tsubst_copy_and_build) [TARGET_EXPR]: Retain TREE_CONSTANT.

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

[Bug c/47977] powerpc (-mcpu=8548) Wrong code for double operations in little endian mode

[froydnj at codesourcery dot com]

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

--- Comment #2 from froydnj at codesourcery dot com  2011-03-03 16:51:18 UTC ---
On Thu, Mar 03, 2011 at 04:08:53PM +, m.lazzarotto at robox dot it wrote:
> lwz 9,8(1)  # What's the purpose ?
> lwz 10,12(1)# What's the purpose ?
> stw 9,8(1)  # What's the purpose ?
> stw 10,12(1)# What's the purpose ?

These are an artifact of the lower-subreg pass; the E500 bits contain
some logic to clean up spurious moves introduced by using E500
floating-point, but the lower-subreg pass stymies those bits of logic.

A separate bug for a (sub-)target-specific pass to clean those artifacts
up would be appropriate, but I don't think it's going to happen any time
soon.

[Bug target/42240] [4.3/4.4 Regression] wrong epilogue on naked function

[denisc at gcc dot gnu.org]

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

--- Comment #21 from denisc at gcc dot gnu.org 2011-03-03 16:58:34 UTC ---
Author: denisc
Date: Thu Mar  3 16:58:26 2011
New Revision: 170657

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170657
Log:
Backport from mainline
2011-02-22  Georg-Johann Lay  

PR target/42240
* config/avr/avr.c (avr_cannot_modify_jumps_p): New function.
(TARGET_CANNOT_MODIFY_JUMPS_P): Define.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/avr/avr.c

[Bug c++/47974] [4.6 Regression] ICE: tree check: expected tree_vec, have error_mark in tsubst_template_args, at cp/pt.c:8969 on invalid code

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  
2011-03-03 17:07:32 UTC ---
Author: paolo
Date: Thu Mar  3 17:07:28 2011
New Revision: 170658

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170658
Log:
/cp
2011-03-03  Paolo Carlini  

PR c++/47974
* pt.c (tsubst_template_args): Check argument t for error_mark_node.

/testsuite
2011-03-03  Paolo Carlini  

PR c++/47974
* g++.dg/template/crash106.C: New.

Added:
trunk/gcc/testsuite/g++.dg/template/crash106.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/47974] [4.6 Regression] ICE: tree check: expected tree_vec, have error_mark in tsubst_template_args, at cp/pt.c:8969 on invalid code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Paolo Carlini  2011-03-03 
17:08:51 UTC ---
Done.

[Bug c/47837] FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)

[xinliangli at gmail dot com]

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

--- Comment #2 from davidxl  2011-03-03 17:32:06 
UTC ---
Please attach two dump files:

-fdump-tree-cddce2-blocks
-fdump-tree-uninit-details


David

[Bug c/47837] FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  2011-03-03 
17:38:48 UTC ---
Created attachment 23535
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23535
uninit-pred-7_a.c.126t.cddce2

[Bug c/47837] FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)

[krebbel at gcc dot gnu.org]

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

--- Comment #4 from Andreas Krebbel  2011-03-03 
17:39:12 UTC ---
Created attachment 23536
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23536
uninit-pred-7_a.c.128t.uninit

[Bug debug/47966] GCC 3.4.6 and 4.4.3 generate wrong stabs debugging information for static file scope variables explicitly initialized with 0.

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  2011-03-03 
17:42:53 UTC ---
IIRC a.out format support for freebsd has just been depercated.  Why use stabs
at all?  Elf and dwarf2 have been around for at least 10 years now and actually
make sense for 90% of the world; doesn't it make sense to update to using elf? 
Somethings will never work in a.out (or a.outb).

[Bug middle-end/47968] ICE: in gen_lowpart_general, at rtlhooks.c:51 when converting vector of double to vector of float

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  2011-03-03 
17:47:42 UTC ---
(In reply to comment #3)
> Patch:
> 
> Index: gcc/expmed.c

IIRC this is the patch which I had applied to the PS3 toolchain while at Sony. 
I don't have access to the sources any more so I cannot check.  But it looks
correct.

Thanks,
Andrew Pinski

[Bug middle-end/47968] ICE: in gen_lowpart_general, at rtlhooks.c:51 when converting vector of double to vector of float

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  2011-03-03 
17:50:38 UTC ---
(In reply to comment #4)
> Btw, I wonder since when (and why) we accept
> 
>   float4 f4 = (float4) d2;
> 
> as valid code.

Because it is documented as being valid code that is you can cast between the
same size of the vectors (not to mention integers that are the same size as the
vector also).  It acts like a bitwise conversion rather than a promotion.  This
is needed for compatibility with the Altivec and SPU specs.

-- Andrew

[Bug libfortran/47972] error.c:158:7: warning: return makes pointer from integer without a cast

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.03.03 17:58:32
 CC||jb at gcc dot gnu.org
 Ever Confirmed|0   |1
   Severity|normal  |trivial

--- Comment #2 from Janne Blomqvist  2011-03-03 17:58:32 
UTC ---
>From the code, with line numbers:


 153   /* TODO: How to prevent the compiler warning due to strerror_r of

 154  the untaken branch having the wrong return type?  */

 155   if (__builtin_classify_type (strerror_r (0, buf, 0)) == 5)

 156 {

 157   /* GNU strerror_r()  */

 158   return strerror_r (errnum, buf, buflen);

 159 }

 160   else

 161 {

 162   /* POSIX strerror_r ()  */

 163   strerror_r (errnum, buf, buflen);

 164   return buf;

 165 }


That is, this warning is not an indication of a real problem, as the "wrong"
branch is never taken. Unless somebody has a clever idea how to silence the
compiler warning, I'm planning on closing as WONTFIX.

[Bug c++/47971] [4.6 Regression] ICE: in tsubst_copy, at cp/pt.c:11725 on valid code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  2011-03-03 
18:00:19 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165307

[Bug c/47837] FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)

[xinliangli at gmail dot com]

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

--- Comment #5 from davidxl  2011-03-03 18:06:33 
UTC ---
While this exposes a limitation in uninit analysis, the cause of the warning is
that C FE behaves differently. On x86, the expression "n || l" is converted to
bitwise | expression, but on s390, it is not.  Any reason why it is the case?

David

[Bug libfortran/47972] error.c:158:7: warning: return makes pointer from integer without a cast

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  2011-03-03 
18:11:40 UTC ---
Try:
  return
__builtin_choose_expr (__builtin_classify_type (strerror_r (0, buf, 0))
   == 5,
   /* GNU strerror_r()  */
   strerror_r (errnum, buf, buflen),
   /* POSIX strerror_r ()  */
   (strerror_r (errnum, buf, buflen), buf));
?

[Bug c++/47964] logical || returns false result, optimization level 02 or 03

[rob.bob.301 at hotmail dot com]

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

--- Comment #4 from rob.bob.301 at hotmail dot com 2011-03-03 18:26:00 UTC ---
(In reply to comment #1)
> You need to provide self-contained testcase, this is not self-contained.

Thank you for running your simple experiment. Unfortunately, all my attempts to
create a simple self-contained test have failed. Of course, during this
process, I did play with exactly the same code you did. 
I have been aware of this problem for several months. I decided to file a bug
without a test because the problem appears to be critical and I hope somebody
who knows the optimization code might spot the issue.
All I can add is that my project is about 110k lines of code, the function in
question is in a .cpp file of about 560 lines. But I doubt it helps very much.

S.

[Bug c/47837] FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  2011-03-03 
18:36:58 UTC ---
(In reply to comment #5)
> While this exposes a limitation in uninit analysis, the cause of the warning 
> is
> that C FE behaves differently. On x86, the expression "n || l" is converted to
> bitwise | expression, but on s390, it is not.  Any reason why it is the case?
> 
> David

Because of BRANCH_COST is different.

[Bug c++/47964] logical || returns false result, optimization level 02 or 03

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  2011-03-03 
19:03:47 UTC ---
(In reply to comment #4)
> Unfortunately, all my attempts to
> create a simple self-contained test have failed. Of course, during this

The advice here may help you:

http://gcc.gnu.org/bugs/minimize.html

[Bug rtl-optimization/47979] New: Problem in comparing integers

[xiaofengguo at google dot com]

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

   Summary: Problem in comparing integers
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xiaofeng...@google.com


Hi,

Here is a short summary of the problem. In the upgrading of gcc from 3.3 to
4.4.3, my hash unit test failed. I did some investigation and wrote a simple
program, which is attached, to reproduce this problem.

I use command below to compile this program:
g++ -g -pipe -O9 -funroll-loops -ffast-math -DNDEBUG -march=pentiumpro -DLINUX
-fpic -DGEOTARGETING -D_NG_POSIX_THREAD -D_RWCONFIG_${RWDBGNUM}_$RWLIBVERSION
-DRW_MULTI_THREAD -DRW_NO_XMSG -DRW_POSIX_D10_THREADS -D_REENTRANT -Wall
-Werror -Wno-sign-compare -Wno-write-strings -Wno-strict-aliasing
-Wno-unused-result abs_error.cc

and the result shows me "hash<0" is false. If "-O9" is removed from the command
line, "hash<0" is true.

I disassembly the obj file by objdump (objdump -Sl a.out), and below is digest
of the optimized result:

...
 80484f1:   b8 49 5e 86 da  mov$0xda865e49,%eax
 80484f6:   89 e5   mov%esp,%ebp
 80484f8:   83 e4 f0and$0xfff0,%esp
 80484fb:   53  push   %ebx
 80484fc:   e8 4c 00 00 00  call   804854d <__i686.get_pc_thunk.bx>
 8048501:   81 c3 f3 1a 00 00   add$0x1af3,%ebx
 8048507:   83 ec 1csub$0x1c,%esp
 804850a:   89 44 24 08 mov%eax,0x8(%esp)
 804850e:   c7 04 24 01 00 00 00movl   $0x1,(%esp)
 8048515:   8d 8b ec e6 ff ff   lea-0x1914(%ebx),%ecx
 804851b:   89 4c 24 04 mov%ecx,0x4(%esp)
 804851f:   e8 dc fe ff ff  call   8048400 <__printf_chk@plt>
 8048524:   8d 83 f7 e6 ff ff   lea-0x1909(%ebx),%eax
 804852a:   ba 49 5e 86 da  mov$0xda865e49,%edx
 804852f:   89 54 24 08 mov%edx,0x8(%esp)
 8048533:   89 44 24 04 mov%eax,0x4(%esp)
 8048537:   c7 04 24 01 00 00 00movl   $0x1,(%esp)
 804853e:   e8 bd fe ff ff  call   8048400 <__printf_chk@plt>
...

Seems "hash" and "result" both assigned 0xda865e49 (-628728247 in oct)
directly, for the optimizations.

I am not sure whether it is a problem in optimizations of the compiler, so I am
not sure whether it is correct for me to assign bug on this component. And,
because I am not familiar with i86 assembly, just read some tutorial to
understand a bit of the asm code, there must be some problems in the
investigations. Please let me know what do you think of this issue. Sure, if it
is my problem or there is a duplication of this bug, please let me know and
close the bug freely.

And, because it is almost impossible for our project to move back to gcc 3.3 or
try one more upgrade in short period, would you share me some way for us to
walk around this problem? (Sure, to make sure other code won't face this
problem any more)

Many thanks for your help!

[Bug rtl-optimization/47979] Problem in comparing integers

[xiaofengguo at google dot com]

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

--- Comment #1 from Xiaofeng Guo  2011-03-03 
20:36:32 UTC ---
Because I can't find the attachment in the thread, add the text below for
debugging easily.

==
#include 
#include 

int main() {
  const char *str = "1234567";

  int hash = 17;
  for (int i = 0; i < strlen(str); ++i) {
hash = 37 * hash + str[i];
  }
  printf("hash = %d, %d\n", hash, hash < 0);
  int result = (hash < 0) ? (-hash) : hash;
  printf("result = %d\n", result);
  return 0;
}
===

[Bug rtl-optimization/47979] Problem in comparing integers

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2011-03-03 
20:37:56 UTC ---
overflow for signed integer is undefined.  Use unsigned integers if you want
defined wrapping behavior.

[Bug c++/46220] [4.3/4.4/4.5/4.6 Regression] Error: invalid covariant return type generated for incomplete class type and different qualifer

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #5 from Jason Merrill  2011-03-03 
20:52:00 UTC ---
(In reply to comment #4)
> Jason, is there a reason to disallow covariant returns where the return type
> only differs in cv-qualification of the class type?
> 
> Could the requirement for a complete type be incorporated into the second
> bullet of p5, since it has to be complete for us to know it's an accessible
> base?

Seems reasonable to me.  Or change "if the return type..." to "if the class in
the return type...". I note that EDG accepts the testcase.

> Why does the third bullet of p5 talk about the cv-qualification of pointers 
> and
> references, when top-level cv-quals in return types are ignored, and 
> references
> have no cv-quals?  Is this an artefact of ARM-era C++?

Top-level cv-quals are not ignored in return types, only in parameter types.

> Am I misreading the wording, or should I ask Mike to open an issue?

I think an issue to clarify this would be appropriate.  I'll go ahead and fix
the compiler.

[Bug c/47980] New: Inefficient code for local const char arrays

[rafael.espindola at gmail dot com]

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

   Summary: Inefficient code for local const char arrays
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rafael.espind...@gmail.com


gcc will compile


void f(const char *p);

void g(void) {
  const char foo[] = "aoeuaoeuaeouaeouaoeuaoeaoxbxod";
  f(foo);
}
--

to

.cfi_startproc
subq$40, %rsp
.cfi_def_cfa_offset 48
movl$.LC0, %esi
movl$31, %ecx
leaq1(%rsp), %rdi
rep movsb
leaq1(%rsp), %rdi
callf
addq$40, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc

No idea why it wants to copy the string before calling f.

[Bug c/47980] Inefficient code for local const char arrays

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

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

--- Comment #1 from Kai Tietz  2011-03-03 21:46:48 
UTC ---
This bug is invalid. The compiler did what you told him here. If you have the
opinion for 'char s[] = "text"' would be a pointer to the constant, you are
wrong.

[Bug c/47980] Inefficient code for local const char arrays

[rafael.espindola at gmail dot com]

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

--- Comment #2 from Rafael Avila de Espindola  2011-03-03 21:50:07 UTC ---
I agree that the code is correct. The bug is because of a missing optimization,
not about wrong behavior.

The only use of foo is passing it function expecting a const pointer. Gcc could
remove the copy and just pass a pointer to the global it created to hold the
string.

p.s.: how do I reopen the bug?

[Bug c/47980] Inefficient code for local const char arrays

[ktietz at gcc dot gnu.org]

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

Kai Tietz  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2011.03.03 21:52:14
 Resolution|INVALID |
 Ever Confirmed|0   |1

--- Comment #3 from Kai Tietz  2011-03-03 21:52:14 
UTC ---
As missed optimization it is valid. so reopened

[Bug c/47980] Inefficient code for local const char arrays

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  2011-03-03 
21:59:50 UTC ---
I believe f could do:
  assert (arg != "aoeuaoeuaeouaeouaoeuaoeaoxbxod");
which would then fail with the proposed optimization.  It is unspecified if
two string literals with the same content are distinct objects, but foo must be
a distinct object (ok, with static const char foo[] =
"aoeuaoeuaeouaeouaoeuaoeaoxbxod"; and -fmerge-all-constants which ignores some
C requirements it doesn't have to).

[Bug middle-end/47980] Inefficient code for local const char arrays

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
  Component|c   |middle-end
 Resolution||INVALID

--- Comment #5 from Andrew Pinski  2011-03-03 
22:00:36 UTC ---
Actually the copying is correct.
Take:
void f(const char *p);

void g(int t) {
  const char foo[] = "aoeuaoeuaeouaeouaoeuaoeaoxbxod";
  f(foo, t);
  if (!t)
g(1);
}

const char *a;

void f(const char *p, int t)
{
  if (!t)
a = p;
  else if (a == p)
abort ();
}

void main(void)
{
  g(0);
}

This program should not abort with your "optimization", it will.

[Bug target/47947] Variables of type vector double are not copied correctly in gcc-4.5.1 and gcc-4.6.0

[pthaugen at gcc dot gnu.org]

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

--- Comment #10 from Pat Haugen  2011-03-03 
22:12:12 UTC ---
This is looking like a dup of PR47862, note the following snippet of assembler.

stfd 0,360(1) #,
stfd 12,344(1) #,
stfd 13,352(1) #,
stfd 11,336(1) #,
...
bl .printf #
nop
lfd 11,336(1) #,
addi 9,1,384 #,,
addi 3,31,176 #, tmp156,
stxvd2x 11,0,9 # in0$hiVectorDouble,
...
bl .printf #
nop
lfd 13,352(1) #,
addi 9,1,384 #,,
addi 3,31,208 #, tmp156,
stxvd2x 13,0,9 # in0$loVectorDouble,

0,11,12,13 all hold vector values coming into this snippet, and you can see
we're just saving/restoring part of the vector across the printf calls.

[Bug rtl-optimization/47958] [x32] reload generates invalid address reference

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  2011-03-03 
22:15:29 UTC ---
Author: hjl
Date: Thu Mar  3 22:15:26 2011
New Revision: 170664

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170664
Log:
Put symbol reference in memory in ptr_mode.

gcc/

2011-03-02  H.J. Lu  

PR rtl-optimization/47958
* reload.c (find_reloads): Put symbol reference in memory
in ptr_mode.

gcc/testsuite/

2011-03-02  H.J. Lu  

PR rtl-optimization/47958
* gcc.dg/torture/pr47958-1.c: New.

Added:
branches/x32/gcc/testsuite/gcc.dg/torture/pr47958-1.c
Modified:
branches/x32/gcc/ChangeLog.x32
branches/x32/gcc/reload.c
branches/x32/gcc/testsuite/ChangeLog.x32

[Bug c++/44499] No default constructor available

[dirtyepic at gentoo dot org]

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

Ryan Hill  changed:

   What|Removed |Added

 CC||dirtyepic at gentoo dot org

--- Comment #10 from Ryan Hill  2011-03-03 
22:28:45 UTC ---
(In reply to comment #3)
> (In reply to comment #1)
> > gcc is correct, accepting the code previously was a bug that was fixed 
> > recently
> > 
> > You need to provide an initializer for g_d
> 
> This sort of changes should be documented in the changes.html page or in
> porting_to.html

Could this be added?  Some upstreams are arguing this is a bug in GCC.  In the
past we've found that if it's documented that this change was indeed
intentional, they're more willing to fix their code.

[Bug middle-end/47980] Inefficient code for local const char arrays

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #6 from Andrew Pinski  2011-03-03 
23:07:01 UTC ---
In fact my testcase in comment #5 is an exact duplicate of bug 38615.

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