[Bug libfortran/50105] Possibly: [4.3/4.4/4.5/4.6/4.7 Regression] I/O with g6.5 - wrong number of "**" shown

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  2011-08-17 
06:40:00 UTC ---
Bob's point is that for 1.0, the following rule (10.7.5.2.2) applies:

"Magnitude of Internal Value" is 1.0 and thus the "Equivalent Conversion" is
F2.5,4(' '). Thus, one has "**" for F followed by 4 spaces.

Cf. http://j3-fortran.org/pipermail/j3/2011-August/004575.html

[Bug libfortran/50105] Possibly: [4.3/4.4/4.5/4.6/4.7 Regression] I/O with g6.5 - wrong number of "**" shown

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  2011-08-17 
06:22:20 UTC ---
Actually, I think that this bug is invalid - but wait for the answers at the J3
mailing list. The reason I think that I think that 6 asterisks should be
produced are stated below. However, it would not be the first time that I
missed something.


We have (refs = F2008):

  R1007 data-edit-desc  is  ...
or  G w [ . d [ E e ] ]

such that for G6.5, one has "w = 6".


And thus, I expect 6 "*" as: if the "characters produced exceeds the field
width, the processor shall fill the entire field of width w with asterisks"


Full quote:

10.7.2 Numeric editing, 10.7.2.1 General rules states:

"(5) On output, if an exponent exceeds its specified or implied width using the
E, EN, ES, D, or G edit descriptor, or the number of characters produced
exceeds the field width, the processor shall fill the entire field of width w
with asterisks. However, the processor shall not produce asterisks if the field
width is not exceeded when optional characters are omitted."

[Bug libfortran/50105] New: Possibly: [4.3/4.4/4.5/4.6/4.7 Regression] I/O with g6.5 - wrong number of "**" shown

[burnus at gcc dot gnu.org]

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

 Bug #: 50105
   Summary: Possibly: [4.3/4.4/4.5/4.6/4.7 Regression] I/O with
g6.5 - wrong number of "**" shown
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: jvdeli...@gcc.gnu.org, thenl...@users.sourceforge.net


Bob Corbett (formally SUN, now Oracle) wonders at
http://j3-fortran.org/pipermail/j3/2011-August/004573.html
what the following program should print:

 PROGRAM MAIN
   PRINT '(G6.5)', 1.0
 END


Crayftn 7.1.4.111, gfortran 4.3 and 4.7, ifort 11.1, openf95, sunf95, and
pathf95 produce the following output (when piped through "od -a"):

000   *   *   *   *   *   *  nl
007


While g95, gfortran 4.1, NAG f95 5.1 and PGI 11.5 produce:

000   *   *  sp  sp  sp  sp  nl
007


Bob thinks that only the latter is correct.

[Bug target/50104] New: internal compiler error: in extract_insn

[raj.khem at gmail dot com]

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

 Bug #: 50104
   Summary: internal compiler error: in extract_insn
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: raj.k...@gmail.com
CC: ber...@gcc.gnu.org
  Host: x86_64-linux
Target: arm-eabi
 Build: x86_64-linux


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

gcc 4.6 branch and trunk have this ICE happening on ARM when attached test case
is compiled with -march=armv7-a -O2. It works ok with gcc 4.5

here is error

vfprintf.c: In function ‘ust_safe_vfprintf’:
vfprintf.c:956:1: error: unrecognizable insn:
(insn 3644 3643 3645 145 (set (subreg:SI (reg/v:DI 160 [ _umax ]) 0)
(sign_extend:SI (mem:QI (plus:SI (mult:SI (reg/v:SI 166 [ nextarg ])
(const_int 8 [0x8]))
(reg/f:SI 1405 [ argtable.7 ])) [4 *D.5277_569+0 S1 A32])))
vfprintf.c:555 -1
 (nil))
vfprintf.c:956:1: internal compiler error: in extract_insn, at recog.c:2127


I have traced it to a regression after the patch for bug 43137 was committed to
trunk.

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

[Bug bootstrap/50103] New: gcc-4.4.6/gcc/config/rs6000/rs6000.md:153: internal compiler error: Segmentation fault

[murthys at us dot ibm.com]

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

 Bug #: 50103
   Summary: gcc-4.4.6/gcc/config/rs6000/rs6000.md:153: internal
compiler error: Segmentation fault
Classification: Unclassified
   Product: gcc
   Version: 4.4.6
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: murt...@us.ibm.com


I am trying to compile GCC 4.4.6 using  xlc 11.1.0.0 on AIX 6.1 TL-05 SP-2.

_1_)
I use a bash script to drive the build process and the name of the script is

#!/usr/bin/bash
##@@
##@@ build-gcc446.bash
##@@

export pct="%"
export RUNTIME="$(date +${pct}Y${pct}m${pct}d-${pct}H${pct}M${pct}S)"
export CONFIG_SHELL=/usr/bin/bash
export TOPDIR=/work
export SRCDIR=${TOPDIR}/gcc-4.4.6
export OBJSRC=${TOPDIR}/objsrc-gcc-4.4.6
export LOGFILE=${TOPDIR}/logs/`basename $0`${1}-log-${RUNTIME}
export PREFIX=/usr/local/gcc-4.4.6
export CC="/usr/bin/cc"
export M4="/opt/freeware/bin/m4"
export PATH="$PATH:/usr/java5/bin:"
{

  echo "START: `date`"
  echo "="
  echo "PATH: $PATH"

  echo "ENV:"
  env

  ulimit -a

  echo "="

  if [[ ${PWD} != "${OBJSRC}" ]]; then
echo " ERROR !!! This script must be run from '${OBJSRC}' directory"
exit 1
  fi

  case $1 in
  -config)
  cmd="${SRCDIR}/configure --prefix=${PREFIX}  --enable-threads=aix"
  cmd="$cmd  --disable-nls --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld"
  cmd="$cmd --with-ar=/usr/ccs/bin/ar"
  echo "COMMAND: $cmd"
  ${SRCDIR}/configure --prefix=${PREFIX}  --enable-threads=aix \
--disable-nls --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld \
--with-ar=/usr/ccs/bin/ar
  echo "RC($?)"
  echo "===" ;;
  -make)
 echo "COMMAND: 'gmake  bootstrap'\n\n"
 gmake  bootstrap
 echo "RC($?)"

 echo "===" ;;

  -install)
echo "COMMAND: 'gmake  install'\n\n"
gmake  install
echo "RC($?)"
echo "="
## echo "COMMAND: 'cp
${TOPDIR}/scripts/linklib-gcc334-bs_vac7000.ksh ${PREFIX}/lib/'"
## cp ${TOPDIR}/scripts/linklib-gcc334-bs_vac7000.ksh
${PREFIX}/lib/
## echo "RC($?)"
echo "=" ;;
  esac
  echo "END: `date`"
} 2>&1 | tee ${LOGFILE}



_2_)
I invoke build-gcc446.bash -config

The script completes without any issues as follows:

=
COMMAND: /work/gcc-4.4.6/configure --prefix=/usr/local/gcc-4.4.6 
--enable-threads=aix  --disable-nls --with-as=/usr/ccs/bin/as --with-ld=/us
r/ccs/bin/ld --with-ar=/usr/ccs/bin/ar
checking build system type... powerpc-ibm-aix6.1.0.0
checking host system type... powerpc-ibm-aix6.1.0.0
checking target system type... powerpc-ibm-aix6.1.0.0
checking for a BSD-compatible install... /work/gcc-4.4.6/install-sh -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... /usr/bin/cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether /usr/bin/cc accepts -g... yes
checking for /usr/bin/cc option to accept ANSI C... none needed
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... xlC_r
checking whether we are using the GNU C++ compiler... no
checking whether xlC_r accepts -g... no
checking for gnatbind... no
checking for gnatmake... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... tail +16c $$f1 > tmp-foo1; tail
+16c $$f2 > tmp-foo2; cmp tmp-foo1 tmp-foo2
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... yes
checking for version 0.10 of PPL... no
checking for correct version of CLooG... no
The following languages will be built: c,c++,fortran,java,objc
*** This configuration is not supported in the following subdirectories:
 target-libmudflap target-libssp target-libffi target-zlib target-libjava
target-libada gnattools target-boehm-gc
(Any other directories should still work fine.)
checking for bison... bison -y
checking for bison... bison
checking for gm4... /opt/freeware/bin/m4
checking for flex... no
checking for lex... lex
checking for flex... no
checking for makeinfo... no
checking for expect... expect
checking for

[Bug c++/50096] GCC 4.X doesn't compile Clang on Sparc Solaris

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #6 from Jonathan Wakely  2011-08-16 
23:54:56 UTC ---
Because clang trunk compiles fine with g++ on GNU/Linux and there's nothing
special about sparc Solaris that should make it fail, so I looked at the clang
code and worked out how that error could happen.

Closing, not a bug

[Bug c++/50056] Binding a temporary object to a reference

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  2011-08-16 
23:43:19 UTC ---
clang 2.8 and EDG 4.3 behave the same way as G++, so I don't think this is a
bug in GCC; feel free to raise it as a language issue, though.

This section could use to be reformulated in terms of class prvalues.  S() is a
class prvalue, but static_cast(S()) is an lvalue.

[Bug c++/50054] Fails to recover from type error in function signature

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Jason Merrill  2011-08-16 
23:37:49 UTC ---
Fixed for 4.6.2.

[Bug c++/50054] Fails to recover from type error in function signature

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jason at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.6.2

[Bug c++/50054] Fails to recover from type error in function signature

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  2011-08-16 
23:36:03 UTC ---
Author: jason
Date: Tue Aug 16 23:35:59 2011
New Revision: 177814

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177814
Log:
PR c++/50054
* typeck2.c (cxx_incomplete_type_diagnostic): Handle
init_list_type_node.

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

[Bug c++/50086] [C++0x] Error on lookup of template function address with variadic template arguments

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  2011-08-16 
23:36:44 UTC ---
Fixed for 4.6.2.

[Bug c++/50086] [C++0x] Error on lookup of template function address with variadic template arguments

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-08-16 
23:36:11 UTC ---
Author: jason
Date: Tue Aug 16 23:36:07 2011
New Revision: 177815

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177815
Log:
PR c++/50086
* pt.c (unify_pack_expansion): Correct overloaded unification
logic.

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

[Bug c++/50086] [C++0x] Error on lookup of template function address with variadic template arguments

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  2011-08-16 
23:26:13 UTC ---
Author: jason
Date: Tue Aug 16 23:26:08 2011
New Revision: 177813

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177813
Log:
PR c++/50086
* pt.c (unify_pack_expansion): Correct overloaded unification
logic.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic-unresolved.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/50054] Fails to recover from type error in function signature

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-08-16 
23:25:49 UTC ---
Author: jason
Date: Tue Aug 16 23:25:43 2011
New Revision: 177810

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177810
Log:
PR c++/50054
* typeck2.c (cxx_incomplete_type_diagnostic): Handle
init_list_type_node.

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

[Bug c++/50102] New: ICE in cp/mangle.c:write_type()

[pthaugen at gcc dot gnu.org]

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

 Bug #: 50102
   Summary: ICE in cp/mangle.c:write_type()
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pthau...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


Appears this started back in 4.5, still appears in trunk. Testcase is reduced,
original source did not have extra errors.

> cat test.cpp 
namespace std {
namespace decimal {

template 
class _FmtTraits<_PackedDecimal<_Digits, _Scale> > {
};

template 
class _DecBase {
};

class decimal32 : public _DecBase<_FmtTraits > {
};

inline long double decimal32_to_long_double(decimal32 _D)
{ return _DecNumber(_D)._ToLongDouble(); }

}
}

> ~/install/gcc/trunk_debug/bin/g++ -c test.cpp 
test.cpp:4:11: error: ‘uint32_t’ has not been declared
test.cpp:4:29: error: ‘uint32_t’ has not been declared
test.cpp:5:7: error: ‘_FmtTraits’ is not a template
test.cpp:5:18: error: ‘_PackedDecimal’ was not declared in this scope
test.cpp:5:50: error: expected unqualified-id before ‘>’ token
test.cpp:12:35: error: ‘std::decimal::_FmtTraits’ is not a template
test.cpp: In function ‘long double
std::decimal::decimal32_to_long_double(std::decimal::decimal32)’:
test.cpp:16:31: error: ‘_DecNumber’ was not declared in this scope
test.cpp: At global scope:
test.cpp:15:20: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


From gdb:

Program received signal SIGSEGV, Segmentation fault.
0x1049f348 in write_type (type=0xfffb6dfc828)
at /home/pthaugen/src/gcc/trunk_debug/gcc/gcc/cp/mangle.c:1797
1797type = TREE_TYPE (first_field (type));
(gdb) call debug_tree(type)
  constant 8>
unit size  constant 1>
align 8 symtab 0 alias set -1 canonical type 0xfffb6dfc828
fields  unit size 
align 8 symtab 0 alias set -1 canonical type 0xfffb6dfc828 fields
 context 
full-name "class std::decimal::decimal32"
X() X(constX&) this=(X&) n_parents=1 use_template=0
interface-unknown
chain >
nonlocal decl_4 VOID file test.cpp line 12 col 59
align 1 context  result

   > context 
full-name "class std::decimal::decimal32"
X() X(constX&) this=(X&) n_parents=1 use_template=0 interface-unknown
chain >
(gdb) bt 10
#0  0x1049f348 in write_type (type=0xfffb6dfc828)
at /home/pthaugen/src/gcc/trunk_debug/gcc/gcc/cp/mangle.c:1797
#1  0x104a34e0 in write_method_parms (parm_types=0xfffb6e42fa8,
method_p=0, 
decl=0xfffb6e35f00) at
/home/pthaugen/src/gcc/trunk_debug/gcc/gcc/cp/mangle.c:2373
#2  0x104a3008 in write_bare_function_type (type=0xfffb6dfcc18, 
include_return_type_p=0, decl=0xfffb6e35f00)
at /home/pthaugen/src/gcc/trunk_debug/gcc/gcc/cp/mangle.c:2313
#3  0x10494ecc in write_encoding (decl=0xfffb6e35f00)
at /home/pthaugen/src/gcc/trunk_debug/gcc/gcc/cp/mangle.c:735
#4  0x10493a28 in write_mangled_name (decl=0xfffb6e35f00, top_level=1
'\001')
at /home/pthaugen/src/gcc/trunk_debug/gcc/gcc/cp/mangle.c:684
#5  0x104a9c90 in mangle_decl_string (decl=0xfffb6e35f00)
at /home/pthaugen/src/gcc/trunk_debug/gcc/gcc/cp/mangle.c:3124
#6  0x104a9f30 in mangle_decl (decl=0xfffb6e35f00)
at /home/pthaugen/src/gcc/trunk_debug/gcc/gcc/cp/mangle.c:3146
#7  0x10fc7a44 in decl_assembler_name (decl=0xfffb6e35f00)
at /home/pthaugen/src/gcc/trunk_debug/gcc/gcc/tree.c:538
#8  0x101c71bc in cxx_comdat_group (decl=0xfffb6e35f00)
at /home/pthaugen/src/gcc/trunk_debug/gcc/gcc/cp/decl.c:13770
#9  0x102e991c in comdat_linkage (decl=0xfffb6e35f00)
at /home/pthaugen/src/gcc/trunk_debug/gcc/gcc/cp/decl2.c:1591

> ~/install/gcc/trunk_debug/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/pthaugen/install/gcc/trunk_debug/bin/g++
COLLECT_LTO_WRAPPER=/home/pthaugen/install/gcc/trunk_debug/libexec/gcc/powerpc64-linux/4.7.0/lto-wrapper
Target: powerpc64-linux
Configured with: /home/pthaugen/src/gcc/trunk_debug/gcc/configure
--prefix=/home/pthaugen/install/gcc/trunk_debug --target=powerpc64-linux
--host=powerpc64-linux --build=powerpc64-linux --enable-secureplt
--enable-threads=posix --enable-shared --enable-__cxa_atexit
--with-long-double-128 --enable-decimal-float --disable-alsa --enable-checking
--with-lto --with-as=/home/wschmidt/binutils/install/bin/as
--with-ld=/home/wschmidt/binutils/install/bin/ld
--with-libelf=/home/pthaugen/install/gcc-host-libs
--with-gmp=/home/pthaugen/install/gcc-host-libs
--with-mpfr=/home/pthaugen/install/gcc-host-libs
--with-mpc=/home/pthaugen/install/gcc-host-libs
--with-ppl=/home/pthaugen/install/gcc-host-libs
--

[Bug c++/50086] [C++0x] Error on lookup of template function address with variadic template arguments

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/50096] GCC 4.X doesn't compile Clang on Sparc Solaris

[javpicorel at gmail dot com]

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

--- Comment #5 from Javier  2011-08-16 21:52:21 
UTC ---
(In reply to comment #4)
> Are you sure you haven't edited Stmt.cpp to remove 'const' from the definition
> of the getSourceRange_t typedef?  That would also explain the error.

ups! I though I didn't touch it but that was the problem!!! Thank you! Sorry
for bother...

just one thing, how did you know it?

Regards

[Bug c++/50087] [C++0x] Weird optimization anomaly with constexpr

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #4 from Paolo Carlini  2011-08-16 
21:48:59 UTC ---
(for the record: I somehow wrongly understood long, "forever" *compile*-time)

[Bug c++/50087] [C++0x] Weird optimization anomaly with constexpr

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-16
 Ever Confirmed|0   |1

--- Comment #3 from Jason Merrill  2011-08-16 
21:38:01 UTC ---
This is more or less expected behavior.  Since a const variable declaration has
different semantics depending on whether or not the initializer is a
constant-expression, a compiler needs to find a constant value if there is one.
 So we do, and joe is initialized with that constant value.

But in the second testcase, there is no semantic constraint on whether or not
the call fib(92) is a constant-expression, so we don't try to reduce it to a
constant, assuming that normal optimization can do just as well.

But for whatever reason, in this case normal optimization isn't doing as well
as constexpr evaluation can.

[Bug fortran/50094] [4.7 Regression] FAIL: gfortran.dg/coarray_6.f90

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Tobias Burnus  2011-08-16 
21:34:39 UTC ---
(In reply to comment #5)
> New Revision: 177801
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177801

Mark as FIXED. Thanks for the report HJ and for the debugging Dominique! Sorry
for the breakage - and for the delay as I don't have a checked-out GCC tree at
work.


(In reply to comment #4)
> Is this PR more than a trivial typo?

No. It was just the typo mentioned in comment 2, which somehow crept in.


> Hm, so this PR is in the assigned state but not yet assigned to anyone?
> What's up with that?

That's a useability bug of Bugzilla 3 and 4. Before, one could simply mark the
bug as assigned to oneself (combobox + checkbox). Now with BZ3 (and with the
just installed 4.0.2), one has to use "Status: ASSIGNED" and then one needs to
move to the top of the page, click on "(edit)" in the "Assigned To" line and
change the email address, which I forgot when trying to assign the bug to me.

[Bug fortran/50094] [4.7 Regression] FAIL: gfortran.dg/coarray_6.f90

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  2011-08-16 
21:26:26 UTC ---
Author: burnus
Date: Tue Aug 16 21:26:23 2011
New Revision: 177801

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177801
Log:
2011-08-16  Tobias Burnus  
Dominique Dhumieres  

PR fortran/50094
* resolve.c (resolve_symbol): Fix stupid typo.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug fortran/49962] [OOP] ICE when using type-bound function returning vector

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #10 from janus at gcc dot gnu.org 2011-08-16 21:24:40 UTC ---
Fixed on the 4.5 branch with r177800. Closing.

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[janus at gcc dot gnu.org]

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

--- Comment #22 from janus at gcc dot gnu.org 2011-08-16 21:22:36 UTC ---
Author: janus
Date: Tue Aug 16 21:22:31 2011
New Revision: 177800

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177800
Log:
2011-08-16  Paul Thomas  

PR fortran/42051
PR fortran/43896
PR fortran/49962
* trans-expr.c (gfc_conv_derived_to_class): Handle array-valued
functions with CLASS formal arguments.


2011-08-16  Paul Thomas  

PR fortran/42051
PR fortran/43896
PR fortran/49962
* gfortran.dg/class_23.f03: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/class_23.f03
Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/trans-expr.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug fortran/49962] [OOP] ICE when using type-bound function returning vector

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org 2011-08-16 21:22:36 UTC ---
Author: janus
Date: Tue Aug 16 21:22:31 2011
New Revision: 177800

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177800
Log:
2011-08-16  Paul Thomas  

PR fortran/42051
PR fortran/43896
PR fortran/49962
* trans-expr.c (gfc_conv_derived_to_class): Handle array-valued
functions with CLASS formal arguments.


2011-08-16  Paul Thomas  

PR fortran/42051
PR fortran/43896
PR fortran/49962
* gfortran.dg/class_23.f03: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/class_23.f03
Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/trans-expr.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug fortran/42051] [OOP] ICE on array-valued function with CLASS formal argument

[janus at gcc dot gnu.org]

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

--- Comment #27 from janus at gcc dot gnu.org 2011-08-16 21:22:36 UTC ---
Author: janus
Date: Tue Aug 16 21:22:31 2011
New Revision: 177800

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177800
Log:
2011-08-16  Paul Thomas  

PR fortran/42051
PR fortran/43896
PR fortran/49962
* trans-expr.c (gfc_conv_derived_to_class): Handle array-valued
functions with CLASS formal arguments.


2011-08-16  Paul Thomas  

PR fortran/42051
PR fortran/43896
PR fortran/49962
* gfortran.dg/class_23.f03: New test.

Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/class_23.f03
Modified:
branches/gcc-4_5-branch/gcc/fortran/ChangeLog
branches/gcc-4_5-branch/gcc/fortran/trans-expr.c
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/50101] GCC 4.5 and 4.6 generate suboptimal code on ppc for countdown loops when the CTR register cannot be used

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  2011-08-16 
20:57:01 UTC ---
Created attachment 25026
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25026
Example test case

[Bug rtl-optimization/50101] New: GCC 4.5 and 4.6 generate suboptimal code on ppc for countdown loops when the CTR register cannot be used

[meissner at gcc dot gnu.org]

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

 Bug #: 50101
   Summary: GCC 4.5 and 4.6 generate suboptimal code on ppc for
countdown loops when the CTR register cannot be used
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: meiss...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


When GCC switched over to the IRA register allocator in GCC 4.5, it made some
loops run slower on the PowerPC.  In particular, the powerpc has a count down
register (CTR) that the compiler can use with the -fbranch-count-reg
optimization.  However, if the CTR register is not available in the loop, the
compiler does not use a GPR register for the loop index, but instead loads the
index value from memory, increments it, and stores it back to the stack.

For example, in the code:

int code[65536];

mike()
{
  int j;
  long addr;

  for (j = 0; j < 65536; j+=4) {
asm("mtctr %1" : "=c" (addr) : "r" (&code[j]));
asm("bctrl" : : "c" (addr) : "lr" );
  }
}

It generates the following on 4.3 (Sles 11SP1 host compiler):

.L.mike:
mflr 0
ld 9,.LC0@toc(2)
li 11,16384
std 0,16(1)
.p2align 4,,15
.L2:
#APP
 # 10 "test-ppc-ctr.c" 1
mtctr 9
 # 0 "" 2
 # 11 "test-ppc-ctr.c" 1
bctrl
 # 0 "" 2
#NO_APP
addic. 11,11,-1
addi 9,9,16
bne 0,.L2
ld 0,16(1)
mtlr 0
blr

If I go to a 4.4 based compiler such as the RHEL6 host compiler I get:

.L.mike:
mflr 0
ld 9,.LC0@toc(2)
std 0,16(1)
li 0,16384
std 0,-16(1)
.p2align 4,,15
.L2:
#APP
 # 10 "test-ppc-ctr.c" 1
mtctr 9
 # 0 "" 2
 # 11 "test-ppc-ctr.c" 1
bctrl
 # 0 "" 2
#NO_APP
ld 0,-16(1)
addi 9,9,16
addic. 11,0,-1
std 11,-16(1)
bne 0,.L2
ld 0,16(1)
mtlr 0
blr

Notice that it stores and loads the loop index value.  If I use
-fno-branch-count-reg, it generates code to use the GPRS:

.L.mike:
mflr 0
ld 9,.LC0@toc(2)
std 0,16(1)
addis 0,9,0x4
.p2align 4,,15
.L2:
#APP
 # 10 "test-ppc-ctr.c" 1
mtctr 9
 # 0 "" 2
 # 11 "test-ppc-ctr.c" 1
bctrl
 # 0 "" 2
#NO_APP
addi 9,9,16
cmpd 7,9,0
bne 7,.L2
ld 0,16(1)
mtlr 0
blr

This is fixed in the GCC 4.7 development sources.  The development source
revision that fixed this was subversion id 171649, created on March 28th, 2011
by Vladimir Makarov  , in his large rewrite of the ira
register allocator.

As an experiment, I built the Spec 2006 benchmark suite with
-fno-branch-count-reg.  As expected, there are a number of benchmarks that
regress if the count register optimization, but there are a few benchmarks that
get a large speed up by disabling this optimization, which probably indicates
they are being mis-optimized.  The benchmarks with the speedup include:
464.h264ref (19.65% improvement), 434.zeusmp (17.92% improvement) and
459.GemsFDTD (13.02% improvement).

[Bug target/50099] ICE: internal compiler error: in extract_insn, at recog.c:2113 while building lttng-ust

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #2 from Mikael Pettersson  2011-08-16 
20:28:54 UTC ---
It's caused by r163935:

Author: bernds
Date: Mon Sep  6 22:32:26 2010
New Revision: 163935

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163935
Log:
PR target/43137
* config/arm/iterators.md (qhs_zextenddi_cond, qhs_sextenddi_cond):
New define_mode_attrs.
* config/arm/arm.md (zero_extendsidi2, arm_zero_extendsidi2,
arm_exxtendsidi2, arm_extendsidi2): Delete patterns.
(zero_extenddi2, extenddi2 and related splits): New.
(thumb1_zero_extendhisi2): Remove code to handle LABEL_REFs.
Remove pool_range attribute.
(arm_zero_extendhisi2, arm_zero_extendhisi2_v6, arm_zero_extendqisi2,
arm_zero_extendqisi2_v6, thumb1_zero_extendqisi2_v6): Remove
pool_range and neg_pool_range attributes.
* config/arm/thumb2.md (thumb2_zero_extendsidi2,
thumb2_zero_extendhidi2, thumb2_zero_extendqidi2, thumb2_extendsidi2,
thumb2_extendhidi2, thumb2_extendqidi2): Delete.

[Bug fortran/50094] [4.7 Regression] FAIL: gfortran.dg/coarray_6.f90

[hp at gcc dot gnu.org]

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

--- Comment #4 from Hans-Peter Nilsson  2011-08-16 
20:07:56 UTC ---
Is this PR more than a trivial typo?

Hm, so this PR is in the assigned state but not yet assigned to anyone?
What's up with that?

[Bug web/50100] 4.6.1 C++ Manuals Missing

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-08-16 
18:43:25 UTC ---
4.6.0 exists though.

[Bug web/50100] New: 4.6.1 C++ Manuals Missing

[joel at gcc dot gnu.org]

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

 Bug #: 50100
   Summary: 4.6.1 C++ Manuals Missing
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


http://gcc.gnu.org/onlinedocs/ has the following lines:

# GCC 4.6.1 Standard C++ Library Manual (also in PDF or XML or an HTML tarball)
# GCC 4.6.1 Standard C++ Library Reference Manual (also in PDF or XML or an
HTML tarball)

All links are broken.  

It may or may not be related but the contents of
http://gcc.gnu.org/onlinedocs/libstdc++/ are dated 2009.  Doxygen output
indicates it was generated in 2009.

[Bug rtl-optimization/49936] [4.7 Regression] IRA handles CANNOT_CHANGE_MODE_CLASS poorly, + spills to memory on 4.7

[vmakarov at redhat dot com]

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

--- Comment #4 from Vladimir Makarov  2011-08-16 
17:27:12 UTC ---
(In reply to comment #3)
> Hmmm.  Is it possible to make the INT/memory/whatever decision based on move
> costs?  Or use a target hook to supply a hint about what to do?

I think I can restore the 4.6 behaviour by assigning GR_REGS for accum.  I'll
try to do a patch this week.  Such patches needs a lot of testing.  So I hope
it will be on the trunk next week.

[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9

[pinskia at gmail dot com]

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

--- Comment #3 from pinskia at gmail dot com  
2011-08-16 17:25:26 UTC ---
Because darwin's as does not support it. It only supports with r0.



Sent from my Palm Pre on AT&T
On Aug 16, 2011 10:13, ebotcazou at gcc dot gnu.org
 wrote: 

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



Eric Botcazou  changed:



   What|Removed |Added



 Status|UNCONFIRMED |ASSIGNED

   Last reconfirmed||2011-08-16

 AssignedTo|unassigned at gcc dot   |ebotcazou at gcc dot

   |gnu.org |gnu.org

 Ever Confirmed|0   |1



--- Comment #2 from Eric Botcazou 
2011-08-16 17:12:00 UTC ---

> Well, look at the PR - it was an ICE with graphite and stack-check, so
yes,

> of course.

> 

> stw 0,-12284(r1)

> 

> looks like some missing operand print thing to dump fancy regnames (r0
instead

> of 0).



How come the assembler chokes on this?  Looking into it...

[Bug fortran/49962] [OOP] ICE when using type-bound function returning vector

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-08-16
 Ever Confirmed|0   |1

--- Comment #8 from janus at gcc dot gnu.org 2011-08-16 17:23:30 UTC ---
(In reply to comment #7)
> > So: Paul, Tobias, what do you think? Ok to backport to 4.5?
> 
> I don't mind backporting - the patch is indeed simple and (applying to only to
> gfc_conv_derived_to_class) safe.

Alright then, I'll take care of the backport.

[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  2011-08-16 
17:12:00 UTC ---
> Well, look at the PR - it was an ICE with graphite and stack-check, so yes,
> of course.
> 
> stw 0,-12284(r1)
> 
> looks like some missing operand print thing to dump fancy regnames (r0 instead
> of 0).

How come the assembler chokes on this?  Looking into it...

[Bug rtl-optimization/50088] movzbl is generated instead of movl

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #25019|0   |1
is obsolete||

--- Comment #12 from H.J. Lu  2011-08-16 16:43:55 
UTC ---
Created attachment 25025
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25025
A patch to use the same mode for shift count

This is an untested patch to use the same mode for shift count.

[Bug c++/50025] C++0x initialization syntax doesn't work for class members of reference type

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-08-16 
16:21:37 UTC ---
sorry, I meant bullets 5 and 6 in paragraph 3

the 5th bullet applies before the 6th one, and that says for a reference type a
temporary is created. The 6th bullet is never reached for references.
Your example with int& works because GCC doesn't implement the FDIS wording
yet, according to the FDIS it should be rejected too, see
http://gcc.gnu.org/ml/gcc-help/2011-07/msg00053.html

this is a wording problem in the FDIS and will be core issue 1288 in the next
issues list

[Bug tree-optimization/50082] -Wstrict-overflow mishandles typedef

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Guenther  2011-08-16 
15:35:04 UTC ---
Fixed for 4.7.0.

[Bug tree-optimization/50082] -Wstrict-overflow mishandles typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2011-08-16 
15:32:21 UTC ---
Author: rguenth
Date: Tue Aug 16 15:32:17 2011
New Revision: 177788

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177788
Log:
2011-08-16  Richard GUenther  

PR tree-optimization/50082
* tree-ssa-forwprop.c (combine_cond_expr_cond): Handle overflow
warnings here, instead of ...
(ssa_forward_propagate_and_combine): ... here.
(forward_propagate_into_comparison_1): Adjust.
(forward_propagate_into_comparison): Likewise.
(forward_propagate_into_gimple_cond): Likewise.
(forward_propagate_into_cond): Likewise.

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

[Bug c++/50044] Attributes for explicit template instantiation are ignored after an implicit template instantiation occurred.

[m...@convergent-it.at]

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

--- Comment #11 from Martin Lederhilger  2011-08-16 
14:47:08 UTC ---
Created attachment 25024
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25024
Export table of the dll.

This is a part of i686-mingw32-objdump's output.

Contains the export table of the DLL for the following combinations:
with/without extern template and
with/without INTERFACE on the class template definition

[Bug rtl-optimization/50088] movzbl is generated instead of movl

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  2011-08-16 14:45:27 
UTC ---
Can we model shift instructions to take any QI/HI/SI/DI register
as shift count and make IRA to match the size when reading/writing
shift count?

[Bug rtl-optimization/50088] movzbl is generated instead of movl

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  2011-08-16 14:23:39 
UTC ---
The real problem is the store forward issue on Atom:

addl$1, 4(%esp) # 67*addsi_1/2  [length = 5]
andl$15, 4(%esp)# 68*andsi_1/1  [length = 5]
movl(%eax), %edi# 70*movsi_internal/1   [length = 2]
movzbl  4(%esp), %ecx   # 154   *movqi_internal/3   [length = 5]

That is we write 32bit and read 8bit, which performs very
poorly on Atom. We should write/read the same size.

[Bug c++/50044] Attributes for explicit template instantiation are ignored after an implicit template instantiation occurred.

[m...@convergent-it.at]

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

--- Comment #10 from Martin Lederhilger  2011-08-16 
14:18:38 UTC ---
Created attachment 25023
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25023
Output of i686-mingw32-nm for dll.dll

[Bug c++/50044] Attributes for explicit template instantiation are ignored after an implicit template instantiation occurred.

[m...@convergent-it.at]

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

--- Comment #9 from Martin Lederhilger  2011-08-16 
14:17:32 UTC ---
Results for:

template
class INTERFACE A : public Base
...

Case one without "extern template": warning is still there but links fine.
Case two with "extern template": still undefined reference to `typeinfo for
A'

I should note that I cannot use INTERFACE on the class template definition,
because I want to explicitly instantiate the template in multiple DLLs and then
I would need dllimport and dllexport at the same time on the class template
definition. For example instantiate A in A.dll, and A in B.dll:
When I want to use A and A in B.dll then I would need dllimport and
dllexport at the same time. Thats why I want to apply INTERFACE to "extern
template INTERFACE...".

Output from nm for case two (with "extern template...") generated by
i686-mingw32-nm dll.dll | i686-mingw32-c++filt > nm.txt

[Bug c++/50044] Attributes for explicit template instantiation are ignored after an implicit template instantiation occurred.

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2011-08-16 
14:00:12 UTC ---
(In reply to comment #0)
>   - When using "extern template..." there is something wrong with exporting 
> the
> symbols for the typeinfo (i686-mingw32-nm shows that they are in the dll, but
> it seems that they are not exported).

what exactly does nm show?

what happens if you put INTERFACE on the class template definition instead of
the instantiation:

template
class INTERFACE A : public Base
...

[Bug target/50099] ICE: internal compiler error: in extract_insn, at recog.c:2113 while building lttng-ust

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #1 from Mikael Pettersson  2011-08-16 
13:35:54 UTC ---
I can reproduce the ICE with 4.7-20110813 and 4.6-20110812, but not with
4.5-20110804, 4.4-20110719, or 4.3.5.

[Bug c++/50044] Attributes for explicit template instantiation are ignored after an implicit template instantiation occurred.

[m...@convergent-it.at]

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

Martin Lederhilger  changed:

   What|Removed |Added

Version|4.5.2   |4.6.1

--- Comment #7 from Martin Lederhilger  2011-08-16 
13:17:44 UTC ---
I have also tried it with a newer version of gcc, but I receive the same
results. Information about the new gcc version is listed below:

Using built-in specs.
COLLECT_GCC=i686-mingw32-g++
COLLECT_LTO_WRAPPER=/home/martin/mingw-4.6.1/install-i686-pc-linux-gnu/libexec/gcc/i686-mingw32/4.6.1/lto-wrapper
Target: i686-mingw32
Configured with: ../configure --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --target=i686-mingw32
--prefix=/home/martin/mingw-4.6.1/install-i686-pc-linux-gnu
--with-gmp=/home/martin/mingw-4.6.1/install-i686-pc-linux-gnu
--with-mpfr=/home/martin/mingw-4.6.1/install-i686-pc-linux-gnu
--with-mpc=/home/martin/mingw-4.6.1/install-i686-pc-linux-gnu
--with-ppl=/home/martin/mingw-4.6.1/install-i686-pc-linux-gnu
--with-cloog=/home/martin/mingw-4.6.1/install-i686-pc-linux-gnu
--enable-cloog-backend=isl --enable-threads=win32 --enable-tls
--enable-languages=c,c++
--with-sysroot=/home/martin/mingw-4.6.1/install-i686-pc-linux-gnu/i686-mingw32
--disable-win32-registry --enable-sjlj-exceptions --disable-libstdcxx-pch
--with-host-libstdcxx='-lstdc++ -lsupc++'
Thread model: win32
gcc version 4.6.1 (GCC)

I think I should use
  extern template class INTERFACE A;
in A.h, and then
  template class A;
to explicitly instantiate it in A.cpp.

Is my use of "extern template ..." right - in the meaning that I should specify
the attributes there? Does the warning "type attributes ignored after type is
already defined" just wants to protect me of having instances of the same type
with different attributes in one translation unit (if that is even possible)?

In general (not 100 % related to my problem) "extern template ..." would also
help me to have the same attributes on the type, if I used it in other
translation units as well - I could think that it makes problems (which version
should the linker use?) while linking if there are template instantiations with
different attributes (I got this enlightenment from bug #38175) - have I
understood this correctly?

Then since I should probably use "extern template ...", what should I do about
the undefined reference to the typeinfo? Could this be related to bug #21243?

Thank you,

Martin

[Bug target/50099] New: ICE: internal compiler error: in extract_insn, at recog.c:2113 while building lttng-ust

[enrico.scholz at informatik dot tu-chemnitz.de]

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

 Bug #: 50099
   Summary: ICE: internal compiler error: in extract_insn, at
recog.c:2113 while building lttng-ust
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: enrico.sch...@informatik.tu-chemnitz.de


Created attachment 25022
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25022
preprocessed sources (ust-0.15/snprintf/vfprintf.c)

$ arm-linux-gnueabi-gcc -march=armv7-a /tmp/x2.c -c -O1
/tmp/x2.c: In function ‘ust_safe_vfprintf’:
/tmp/x2.c:4533:1: error: unrecognizable insn:
(insn 3114 3113 3115 139 (set (subreg:SI (reg/v:DI 153 [ _umax ]) 0)
(sign_extend:SI (mem:QI (plus:SI (mult:SI (reg/v:SI 159 [ nextarg ])
(const_int 8 [0x8]))
(reg/f:SI 347 [ argtable.7 ])) [0 *D.5277_569+0 S1 A32])))
/tmp/x2.c:4325 -1
 (nil))
/tmp/x2.c:4533:1: internal compiler error: in extract_insn, at recog.c:2113
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


$ arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=$P/sysroots/x86_64-oe-linux/usr/libexec/armv5te-linux-gnueabi/gcc/arm-linux-gnueabi/4.6.1/lto-wrapper
Target: arm-linux-gnueabi
Configured with: $P/work-shared/gcc-4.6.1+svnr175454/gcc-4_6-branch/configure
--build=x86_64-oe-linux --host=x86_64-oe-linux --target=arm-linux-gnueabi
--prefix=$P/sysroots/x86_64-oe-linux/usr
--exec_prefix=$P/sysroots/x86_64-oe-linux/usr
--bindir=$P/sysroots/x86_64-oe-linux/usr/bin/armv5te-linux-gnueabi
--sbindir=$P/sysroots/x86_64-oe-linux/usr/bin/armv5te-linux-gnueabi
--libexecdir=$P/sysroots/x86_64-oe-linux/usr/libexec/armv5te-linux-gnueabi
--datadir=$P/sysroots/x86_64-oe-linux/usr/share
--sysconfdir=$P/sysroots/x86_64-oe-linux/etc
--sharedstatedir=$P/sysroots/x86_64-oe-linux/com
--localstatedir=$P/sysroots/x86_64-oe-linux/var
--libdir=$P/sysroots/x86_64-oe-linux/usr/lib/armv5te-linux-gnueabi
--includedir=$P/sysroots/x86_64-oe-linux/usr/include
--oldincludedir=$P/sysroots/x86_64-oe-linux/usr/include
--infodir=$P/sysroots/x86_64-oe-linux/usr/share/info
--mandir=$P/sysroots/x86_64-oe-linux/usr/share/man --disable-silent-rules
--with-libtool-sysroot=$P/sysroots/x86_64-oe-linux --with-gnu-ld
--enable-shared --enable-languages=c,c++ --enable-threads=posix
--disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu
--enable-libstdcxx-pch --program-prefix=arm-linux-gnueabi-
--enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap
--disable-libgomp --disable-libmudflap --enable-cheaders=c_global
--with-abi=aapcs-linux --with-float=soft
--with-local-prefix=$P/sysroots/toradex-colibri320/usr
--with-gxx-include-dir=/usr/include/c++
--with-sysroot=$P/sysroots/toradex-colibri320
--with-build-sysroot=$P/sysroots/toradex-colibri320
--enable-poison-system-directories
--with-headers=$P/sysroots/toradex-colibri320/usr/include
--disable-libunwind-exceptions --with-mpfr=$P/sysroots/x86_64-oe-linux/usr
--with-system-zlib --enable-nls --enable-__cxa_atexit --enable-__cxa_atexit
Thread model: posix
gcc version 4.6.1 20110627 (prerelease) (GCC) 


(it is the gcc-4.6 from OpenEmbedded Core)

[Bug target/50068] Invalid memory access in incr_ticks_for_insn

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 Target|shle--netbsdelf |sh*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-16
 CC||kkojima at gcc dot gnu.org
 Ever Confirmed|0   |1
  Known to fail||4.4.6, 4.5.3, 4.6.1, 4.7.0

--- Comment #5 from Kazumoto Kojima  2011-08-16 
13:00:12 UTC ---
I've added gcc_assert (last_basic_block >= NUM_FIXED_BLOCKS) line
to init_resource_info and confirmed that trunk and all released branches
fail with the testcase given in #1 for sh4-unknown-linux-gnu.
Perhaps

  if (optimize > 0 && flag_delayed_branch)
dbr_schedule (insns);

in sh.c:sh_output_mi_thunk might not be a big deal.  I'm testing
a patch which simply removes these lines.

C6X fails to build in FSF mainline

[Nick Clifton]

Hi Bernd,

  You probably know this already.  The c6x-elf target fails to build
  libgcc with the current FSF mainline sources:

  gcc/libgcc2.c: In function ‘__gnu_mulsc3’:
  gcc/libgcc2.c:1928:1: internal compiler error: in scan_trace, at 
dwarf2cfi.c:2433
  Please submit a full bug report,

  I assume that it is because the C6X has more than one delay slot ?
  
Cheers
  Nick

[Bug libgomp/50098] New: The OpenMP ordered construct blocks parallelism, when appearing at the beginning of a loop body

[terechko at gmail dot com]

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

 Bug #: 50098
   Summary: The OpenMP ordered construct blocks parallelism, when
appearing at the beginning of a loop body
Classification: Unclassified
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: terec...@gmail.com


Created attachment 25021
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25021
program illustrating the performance issue of the ordered construct

According to the OpenMP spec, the ordered construct enforces sequential
ordering of the ordered region. In the GNU OpenMP implementation it works fine,
if the ordered construct resides at the end of the loop body. However, when it
is in the beginning, the parallelism is blocked.

Using the attached C program, the timing figures for the sequential, ordered in
the beginning and ordered in the end versions of the code are presented on a
4-core Intel CPU. The timing shows that the version, where the ordered
construct sits in the beginning of the loop body, has a slowdown, whereas the
version with the ordered construct at the end of the loop body is faster than
the sequential code.

andrei@jos:~/src$ gcc ordered_perf_bug.c -o /tmp/a.out
andrei@jos:~/src$ time /tmp/a.out

real0m5.411s
user0m5.400s
sys0m0.000s
andrei@jos:~/src$ gcc -fopenmp ordered_perf_bug.c -o /tmp/a.out
andrei@jos:~/src$ time /tmp/a.out

real0m6.155s
user0m24.530s
sys0m0.010s
andrei@jos:~/src$ gcc -DFAST_ORDERED -fopenmp ordered_perf_bug.c -o /tmp/a.out
andrei@jos:~/src$ time /tmp/a.out

real0m3.082s
user0m12.290s
sys0m0.000s

andrei@jos:~/src$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

andrei@jos:~/src$ uname -a
Linux jos 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC 2010 x86_64
GNU/Linux
andrei@jos:~/src$ lshw 
jos   
description: Computer
width: 64 bits
capabilities: vsyscall64 vsyscall32
  *-core
   description: Motherboard
   physical id: 0
 *-memory
  description: System memory
  physical id: 0
  size: 3922MiB
 *-cpu
  product: Intel(R) Core(TM) i5 CPU 760  @ 2.80GHz
  vendor: Intel Corp.
  physical id: 1
  bus info: cpu@0
  size: 1197MHz
  capacity: 1197MHz
  width: 64 bits
  capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8
apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht
tm pbe syscall nx rdtscp x86-64 constant_tsc arch_perfmon pebs bts rep_good
xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2
ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida tpr_shadow vnmi
flexpriority ept vpid cpufreq
...

P.S. Looking at the GOMP_ordered_end(void) implementation, I suspect that it
needs some synchronization code to fix the reported performance issue.

[Bug c++/50097] Private base class enumeration

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-08-16 
11:55:08 UTC ---
bah, you'll need to copy that entire URL, bugzilla inserted linebreaks

it's probably PR 41437 or PR 47346

[Bug c++/50097] Private base class enumeration

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-08-16 
11:53:16 UTC ---
this is a duplicate of at least one of these bugs:
http://gcc.gnu.org/bugzilla/buglist.cgi?list_id=653&short_desc=access
template&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&short_desc_type=allwordssubstr&component=c%2B%2B&product=gcc

[Bug c++/50097] New: Private base class enumeration

[wolfgang.roe...@gi-de.com]

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

 Bug #: 50097
   Summary: Private base class enumeration
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wolfgang.roe...@gi-de.com


Hi all,

I would like to post a bug report for the GNU C/C++ compiler version 4.5.2
(powerpc-rtems4.11).

We use the compiler to generate code for a PowerPC processor.

The compiler is invoked with the following options:

ccppc -c -x c++ -ansi -Wall -Werror -g -mcpu=8540 -fverbose-asm -mbig
  -mfloat-gprs=double -mspe -mabi=spe -meabi -msdata -fno-common
  -mmultiple -mno-string -misel -mstrict-align -fgcse-sm
  -fno-rename-registers -fno-section-anchors -G 8 -Os
  -fno-exceptions -fno-rtti
  -I
  -D
  X.CPP -oX.O

// file X.CPP

class X
{
enum E { E1, E2 };
public:
void f1 (E);
};

template 
struct Y : private X
{
void f2 ();
};


template 
void Y::f2 ()
{ this->f1 (X::E1); } // <--- accessing private enum of X

Y y;

void f3 ()
{ y.f2 (); }


The code compiles fine even though function Y<>::f2() accesses the private
X::E1 enumerator.

BTW, Comeau online rejects the code above.

Kind regards
W. Roehrl

[Bug tree-optimization/50082] -Wstrict-overflow mishandles typedef

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|c   |tree-optimization
 AssignedTo|unassigned at gcc dot   |rguenth at gcc dot gnu.org
   |gnu.org |

--- Comment #7 from Richard Guenther  2011-08-16 
11:29:41 UTC ---
Patch posted, thus mine.

[Bug c++/50096] GCC 4.X doesn't compile Clang on Sparc Solaris

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-08-16 
10:29:30 UTC ---
Are you sure you haven't edited Stmt.cpp to remove 'const' from the definition
of the getSourceRange_t typedef?  That would also explain the error.

[Bug c++/45114] implement C++0x alias-declaration

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||marc.coiffier at free dot
   ||fr

--- Comment #6 from Jonathan Wakely  2011-08-16 
10:20:00 UTC ---
*** Bug 42085 has been marked as a duplicate of this bug. ***

[Bug c++/42085] Typedef templates

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #5 from Jonathan Wakely  2011-08-16 
10:19:59 UTC ---
I think clang might have implemented template aliases.

Implementing them in G++ is PR 45114

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

[Bug driver/41844] lto1: warning: unknown register name: line-length-none

[joseph at codesourcery dot com]

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

--- Comment #5 from joseph at codesourcery dot com  2011-08-16 10:02:40 UTC ---
I don't think there's any real change from what I said in 
: the information 
may be in the .opt files (if an option is marked for a front end *and* is 
not marked as Common or Target, then it's front-end-specific) though the 
relevant parts of the driver may still be working with different 
structures; you could implement it, but you'd need to get the logical 
option information to the right part of the driver.

[Bug c++/50096] GCC 4.X doesn't compile Clang on Sparc Solaris

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-08-16 
09:44:48 UTC ---
the C++ front end doesn't care about x86 vs sparc, so I don't see why the
platform would matter, but as it compiles on other platforms that's all the
more reason that you need to provide preprocessed source. A URL of a file
(without the headers it includes) that compiles on most platforms is not
helpful, you're assuming GCC devs have access to a suitable Solaris sparc box
and are willing to download and configure the whole llvm and clang repo to test
this.

[Bug c++/50096] GCC 4.X doesn't compile Clang on Sparc Solaris

[javpicorel at gmail dot com]

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

--- Comment #2 from Javier  2011-08-16 09:36:53 
UTC ---
(In reply to comment #1)
> please read the bug reporting instructions and provide the information
> requested:
> http://gcc.gnu.org/bugs/ - specifically provide preprocessed source, not a 
> URL.
>  Ideally reduce the code to the minimum example demonstrating the problem.
> 
> To me the error looks like it would be produced by this incorrect code:
> 
> namespace clang
> {
> 
> struct SourceRange { };
> 
> struct Stmt { };
> 
> struct AsmStmt : Stmt {
>   SourceRange f() const;
> };
> 
> SourceRange (clang::Stmt::*p)() = &AsmStmt::f;
> 
> }

Sorry about that I forgot to read them. 

This code do compile on x86 so this has to be some c++ front-end bug, that is
what clang guys told me.

[Bug fortran/50070] Segmentation fault at size_binop_loc in fold-const.c

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org 2011-08-16 09:19:07 UTC ---
Here is a patch which rejects the test case with a different error message than
comment #6:


Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 19)
+++ gcc/fortran/resolve.c(working copy)
@@ -10169,15 +10169,22 @@ resolve_fl_variable (gfc_symbol *sym, int mp_flag)

   if (!gfc_is_constant_expr (e)
   && !(e->expr_type == EXPR_VARIABLE
-   && e->symtree->n.sym->attr.flavor == FL_PARAMETER)
-  && sym->ns->proc_name
-  && (sym->ns->proc_name->attr.flavor == FL_MODULE
-  || sym->ns->proc_name->attr.is_main_program)
-  && !sym->attr.use_assoc)
+   && e->symtree->n.sym->attr.flavor == FL_PARAMETER))
 {
-  gfc_error ("'%s' at %L must have constant character length "
- "in this context", sym->name, &sym->declared_at);
-  return FAILURE;
+  if (!sym->attr.use_assoc && sym->ns->proc_name
+  && (sym->ns->proc_name->attr.flavor == FL_MODULE
+  || sym->ns->proc_name->attr.is_main_program))
+{
+  gfc_error ("'%s' at %L must have constant character length "
+"in this context", sym->name, &sym->declared_at);
+  return FAILURE;
+}
+  if (sym->attr.in_common)
+{
+  gfc_error ("COMMON variable '%s' at %L must have constant "
+ "character length", sym->name, &sym->declared_at);
+  return FAILURE;
+}
 }
 }

[Bug c/50082] -Wstrict-overflow mishandles typedef

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther  2011-08-16 
09:10:12 UTC ---
(In reply to comment #5)
> "rguenth at gcc dot gnu.org"  writes:
> 
> > I suppose the forwprop code wants to force a warning at -Wstrict-overflow=1
> > if the conditional becomes optimized to a constant at compile-time?
> 
> Yes.  But perhaps it is overly aggressive--are these conditionals being
> optimized to a constant?  Maybe the condition for the first argument to
> fold_undefer_overflow_warnings needs to be fixed.

In this case not.  forwprop doesn't do anything more fancy than calling
fold, so fold should already handle optimizing to a constant specially, no?
So I guess the first argument to fold_undefer_overflow_warnings should be
zero?  I'll be posting a patch and CC you.

[Bug middle-end/50074] [4.7 Regression] gcc.dg/sibcall-6.c execution test on x86_64-apple-darwin10

[kirill.yukhin at intel dot com]

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

--- Comment #8 from Yukhin Kirill  2011-08-16 
08:48:21 UTC ---
Hi,
I agree, this is a performance regression. Fix to tail-call optimization made
it very conservative. By using some additional tweaks, we may relax it.
However, my fix cured a stability problem (see, 49519 for details).

[Bug target/50092] [4.4/4.5/4.6/4.7 Regression] internal compiler error: in elimination_costs_in_insn, at reload1.c:3633

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-16
  Known to work||4.3.6
   Target Milestone|--- |4.4.7
Summary|internal compiler error: in |[4.4/4.5/4.6/4.7
   |elimination_costs_in_insn,  |Regression] internal
   |at reload1.c:3633   |compiler error: in
   ||elimination_costs_in_insn,
   ||at reload1.c:3633
 Ever Confirmed|0   |1
  Known to fail||4.4.6, 4.5.3, 4.6.1

--- Comment #1 from Richard Guenther  2011-08-16 
08:42:04 UTC ---
Confirmed.  Reduced testcase:

int main(int argc, char **argv) 
{
  int i;
  _Complex long double vector[1];
  for (i=0 ; i<10 ; i++)
printf("Valor: %Lf\n", (long double) rand()/ 2147483648.0);
  printf ("La posicion 5 tiene el valor: %Le\n", (long double) vector[5]);
} 


ICEs in various ways depending on optimization level.  With -m32 the
array is diagnosed as being too large.  At -O1:

t.3.i: In function 'main':
t.3.i:6:5: warning: incompatible implicit declaration of built-in function
'printf' [enabled by default]
t.3.i:8:1: error: unrecognizable insn:
(insn 46 15 18 3 (parallel [
(set (reg:XF 71)
(float:XF (reg:SI 63 [ D.2730 ])))
(clobber (mem/c:SI (plus:DI (reg/f:DI 20 frame)
(const_int -320004 [0x4143dffc])) [0 S4
A32]))
]) t.3.i:6 -1
 (nil))
t.3.i:8:1: internal compiler error: in extract_insn, at recog.c:2115
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

4.3 is happy with the code.

[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org
   Target Milestone|--- |4.5.4

--- Comment #1 from Richard Guenther  2011-08-16 
08:29:39 UTC ---
Well, look at the PR - it was an ICE with graphite and stack-check, so yes,
of course.

stw 0,-12284(r1)

looks like some missing operand print thing to dump fancy regnames (r0 instead
of 0).

[Bug fortran/50094] [4.7 Regression] FAIL: gfortran.dg/coarray_6.f90

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug driver/41844] lto1: warning: unknown register name: line-length-none

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #4 from Richard Guenther  2011-08-16 
08:26:24 UTC ---
It should be possible now(?) to filter all frontend options from
COLLECT_GCC_OPTIONS.  Joseph, is the option merging progressed far enough?

[Bug driver/50095] -ffixed-REG and -ffixed-line-length-132 conflict

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Richard Guenther  2011-08-16 
08:24:03 UTC ---
Dup.

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

[Bug driver/41844] lto1: warning: unknown register name: line-length-none

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from Richard Guenther  2011-08-16 
08:24:03 UTC ---
*** Bug 50095 has been marked as a duplicate of this bug. ***

[Bug c++/50096] GCC 4.X doesn't compile Clang on Sparc Solaris

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011-08-16
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-08-16 
08:01:56 UTC ---
please read the bug reporting instructions and provide the information
requested:
http://gcc.gnu.org/bugs/ - specifically provide preprocessed source, not a URL.
 Ideally reduce the code to the minimum example demonstrating the problem.

To me the error looks like it would be produced by this incorrect code:

namespace clang
{

struct SourceRange { };

struct Stmt { };

struct AsmStmt : Stmt {
  SourceRange f() const;
};

SourceRange (clang::Stmt::*p)() = &AsmStmt::f;

}

[Bug c++/50096] New: GCC 4.X doesn't compile Clang on Sparc Solaris

[javpicorel at gmail dot com]

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

 Bug #: 50096
   Summary: GCC 4.X doesn't compile Clang on Sparc Solaris
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: javpico...@gmail.com


Machine: SunOS parsapc12 5.10 Generic_142909-17 sun4u sparc SUNW,Sun-Blade-1000
GCC: Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../configure --with-gnu-as --with-as=/usr/local/bin/as
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-shared
--enable-languages=c,c++ --with-gmp=/usr/local --with-mpfr=/usr/local
--prefix=/export/home/parsa/tools/gcc4.3.3
Thread model: posix
gcc version 4.3.3 (GCC)
LLVM: trunk
Clang: trunk

I've tried GCC 4.3.3, GCC 4.5.3 and GCC 4.7.0 and they misscompile this clang
library:

/export/home/picorel/filesCloud9/llvm-trunk/obj-debug/tools/clang/lib/AST/
Stmt.cpp

This type of errors (there are hundreds but refering to different StmtNodes.in
line) :

In file included from
/export/home/picorel/filesCloud9/llvm-trunk/tools/clang/lib/AST/Stmt.cpp:138:

/export/home/picorel/filesCloud9/llvm-trunk/obj-debug/tools/clang/lib/AST/../../include/clang/AST/StmtNodes.inc:
In function 'void check_implementations()':

/export/home/picorel/filesCloud9/llvm-trunk/obj-debug/tools/clang/lib/AST/../../
include/clang/AST/StmtNodes.inc:15:

error: cannot convert 'clang::SourceRange (clang::AsmStmt::*)()const' to
'clang::SourceRange (clang::Stmt::*)()' for argument '1' to
'::bad::implements_getSourceRange(clang::SourceRange
(clang::Stmt::*)

So looking at the code this is what what we have in Stmt.cpp:

static inline void check_implementations() {
00134 #define ABSTRACT_STMT(type)
00135 #define STMT(type, base) \
00136   ASSERT_IMPLEMENTS_children(type); \
00137   ASSERT_IMPLEMENTS_getSourceRange(type);
00138 #include "clang/AST/StmtNodes.inc"
00139 }

and in StmtNodes:

00012 #ifndef ASMSTMT
00013 #  define ASMSTMT(Type, Base) STMT(Type, Base)
00014 #endif
00015 ASMSTMT(AsmStmt, Stmt)
00016 #undef ASMSTMT

Clang guys told me that the code is correct and it works and that this is a gcc
issue.

Full Stmt.cpp here: http://clang.llvm.org/doxygen/Stmt_8cpp_source.html

Regards

[Bug rtl-optimization/50088] movzbl is generated instead of movl

[enkovich.gnu at gmail dot com]

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

--- Comment #9 from Ilya Enkovich  2011-08-16 
07:28:33 UTC ---
(In reply to comment #5)
> 
> It is for movqi.  We can only safely replace mozbl with movl if
> the source is 4byte aligned.  It should a new backend option.

That should work. 

A better solution here would be to not generate movqi at all. But probably it
was performed intentionally and is profitable for some platforms. In this case
we should choose movl generation for movqi.

[Bug rtl-optimization/50065] -Os, -O2, -O3 optimization breaks LD/ST ordering on 32-bit SPARC

[mikpe at it dot uu.se]

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

--- Comment #10 from Mikael Pettersson  2011-08-16 
07:24:48 UTC ---
(In reply to comment #9)
> > Regarding the spinlock_unlock in linux, the regular arch_spin_unlock is
> > implemented with a single inline assembly. That will prevent the memory
> > reordering in C. However, for the 32-bit port the arch_write_unlock is still
> > defined as the following without a memory barrier in
> > arch/sparc/include/asm/spinlock_32.h
> > 
> > #define arch_write_unlock(rw)   do { (rw)->lock = 0; } while(0)
> > 
> > OTH, the 64-bit implemention is ok. Or did I miss something here.
> > Anyway, I think this is a separated issue from this thread.
> 
> The discrepancy is a little surprising, indeed.

That was a bug in the sparc32 Linux kernel.  I sent a patch yesterday to fix
it.