[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[jb at gcc dot gnu.org]

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

--- Comment #12 from Janne Blomqvist  2012-05-05 
07:59:28 UTC ---
Author: jb
Date: Sat May  5 07:59:22 2012
New Revision: 187191

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187191
Log:
PR 49010,24518 MOD/MODULO fixes.

gcc/fortran:

2012-05-05  Janne Blomqvist  

PR fortran/49010
PR fortran/24518
* intrinsic.texi (MOD, MODULO): Mention sign and magnitude of result.
* simplify.c (gfc_simplify_mod): Use mpfr_fmod.
(gfc_simplify_modulo): Likewise, use copysign to fix the result if
zero.
* trans-intrinsic.c (gfc_conv_intrinsic_mod): Remove fallback as
builtin_fmod is always available. For modulo, call copysign to fix
the result when signed zeros are enabled.


testsuite:

2012-05-05  Janne Blomqvist  

PR fortran/49010
PR fortran/24518
* gfortran.dg/mod_sign0_1.f90: New test.
* gfortran.dg/mod_large_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/mod_large_1.f90
trunk/gcc/testsuite/gfortran.dg/mod_sign0_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/24518] Intrinsic MOD incorrect for large arg1/arg2 and slow.

[jb at gcc dot gnu.org]

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

--- Comment #25 from Janne Blomqvist  2012-05-05 
07:59:30 UTC ---
Author: jb
Date: Sat May  5 07:59:22 2012
New Revision: 187191

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187191
Log:
PR 49010,24518 MOD/MODULO fixes.

gcc/fortran:

2012-05-05  Janne Blomqvist  

PR fortran/49010
PR fortran/24518
* intrinsic.texi (MOD, MODULO): Mention sign and magnitude of result.
* simplify.c (gfc_simplify_mod): Use mpfr_fmod.
(gfc_simplify_modulo): Likewise, use copysign to fix the result if
zero.
* trans-intrinsic.c (gfc_conv_intrinsic_mod): Remove fallback as
builtin_fmod is always available. For modulo, call copysign to fix
the result when signed zeros are enabled.


testsuite:

2012-05-05  Janne Blomqvist  

PR fortran/49010
PR fortran/24518
* gfortran.dg/mod_sign0_1.f90: New test.
* gfortran.dg/mod_large_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/mod_large_1.f90
trunk/gcc/testsuite/gfortran.dg/mod_sign0_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/49010] Result of MOD and MODULO intrinsic has wrong sign

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #13 from Janne Blomqvist  2012-05-05 
08:11:35 UTC ---
Closing as fixed. The new behavior should now be identical for constant and
non-constant arguments (assuming that at runtime the target inline expands fmod
(at least x86(-64) does this) or the library fmod conforms to C99 Annex F).

Wrt. the sign of the result, we now provide the following behavior (again,
assuming that also the runtime behavior of fmod conforms to C99 Annex F) which
also applies when the result is (signed) zero:

MOD(A, P): The result has the sign of A and a magnitude less than
that of P.  

MODULO(A, P): The result has the sign of P and a magnitude less than
that of P.

Note that this is not the same as calculating the result according to the
formula in the standard using the IEEE 754 rules for signed zero arithmetic,
but rather makes sure that the sign behavior is consistent for zero and
non-zero results.

[Bug libstdc++/53244] New: internal compiler error while build for target c6x-elf

[daniel.calcoen at cern dot ch]

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

 Bug #: 53244
   Summary: internal compiler error while build for target c6x-elf
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.calc...@cern.ch


I’m trying to build a cross compiler for the c6x using the same script I use to
generated cross compiler for Renesas m32c and Renesas RX.
On may 4 I did a pull from the git repositories and build from master (trunk).
Binutils build ok, the first part of gcc and newlib also but at the end I get
an error in the final part of gcc.

---
libtool: compile:  /home/dcalcoen/ti/bld/linux/gcc/./gcc/xgcc -shared-libgcc
-B/home/dcalcoen/ti/bld/linux/gcc/./gcc -nostdinc++
-L/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3/src
-L/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3/src/.libs
-B/home/dcalcoen/ti/pre/linux/c6x-elf/bin/
-B/home/dcalcoen/ti/pre/linux/c6x-elf/lib/ -isystem
/home/dcalcoen/ti/pre/linux/c6x-elf/include -isystem
/home/dcalcoen/ti/pre/linux/c6x-elf/sys-include
-I/home/dcalcoen/gitMirror/gcc/libstdc++-v3/../libgcc
-I/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3/include/c6x-elf
-I/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3/include
-I/home/dcalcoen/gitMirror/gcc/libstdc++-v3/libsupc++ -std=gnu++11
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=regex.lo -g -O2 -c
/home/dcalcoen/gitMirror/gcc/libstdc++-v3/src/c++11/regex.cc -o regex.o
In file included from
/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3/include/bits/stl_algo.h:68:0,
 from
/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3/include/algorithm:63,
 from
/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3/include/regex:38,
 from
/home/dcalcoen/gitMirror/gcc/libstdc++-v3/src/c++11/regex.cc:25:
/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3/include/functional: In
member function ‘std::__regex::_StateIdT
std::__regex::_Nfa::_M_insert_accept()’:
/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3/include/functional:2057:63:
internal compiler error: tree check: expected tree_vec, have error_mark in
comp_template_args_with_info, at cp/pt.c:7038
  using _Requires = typename enable_if<_Cond::value, _Tp>::type;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[4]: *** [regex.lo] Error 1
make[4]: Leaving directory
`/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3/src/c++11'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/home/dcalcoen/ti/bld/linux/gcc/c6x-elf/libstdc++-v3'
make: *** [all-target-libstdc++-v3] Error 2
---

I attached my build scripts and the output of the fail makefile.

If I can help in any way please let me know

With many thanks in advance
Daniel Calcoen

[Bug libstdc++/53244] internal compiler error while build for target c6x-elf

[daniel.calcoen at cern dot ch]

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

--- Comment #1 from daniel.calcoen at cern dot ch 2012-05-05 08:20:29 UTC ---
Created attachment 27313
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27313
output makefile plus build scripts used

[Bug c/53245] New: ice in expand_case

[dcb314 at hotmail dot com]

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

 Bug #: 53245
   Summary: ice in expand_case
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dcb...@hotmail.com


Created attachment 27314
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27314
C source code

I just tried to compile the package ruby-1.9.3.194-10.1
on gcc-4.8 trunk dated 20120503 on an AMD x86_64 box.

The compiler said

parse.y: In function 'ruby_yyparse':
parse.y:6668:5: internal compiler error: in expand_case, at stmt.c:2116
 switch (c = nextc()) {
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Preprocessed source code attached. Flag -O2 required.

[Bug fortran/53191] [OOP] C614 (F2003) or C618 (F2008) not implemented for class expressions

[pault at gcc dot gnu.org]

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

--- Comment #1 from Paul Thomas  2012-05-05 08:49:54 
UTC ---
Author: pault
Date: Sat May  5 08:49:43 2012
New Revision: 187192

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187192
Log:
2012-05-05  Paul Thomas  

PR fortran/41600
* trans-array.c (build_array_ref): New static function.
(gfc_conv_array_ref, gfc_get_dataptr_offset): Call it.
* trans-expr.c (gfc_get_vptr_from_expr): New function.
(gfc_conv_derived_to_class): Add a new argument for a caller
supplied vptr and use it if it is not NULL.
(gfc_conv_procedure_call): Add NULL to call to above.
symbol.c (gfc_is_associate_pointer): Return true if symbol is
a class object.
* trans-stmt.c (trans_associate_var): Handle class associate-
names.
* expr.c (gfc_get_variable_expr): Supply the array-spec if
possible.
* trans-types.c (gfc_typenode_for_spec): Set GFC_CLASS_TYPE_P
for class types.
* trans.h : Add prototypes for gfc_get_vptr_from_expr and
gfc_conv_derived_to_class. Define GFC_CLASS_TYPE_P.
* resolve.c (resolve_variable): For class arrays, ensure that
the target expression has all the necessary _data references.
(resolve_assoc_var): Throw a "not yet implemented" error for
class array selectors that need a temporary.
* match.c (copy_ts_from_selector_to_associate,
select_derived_set_tmp, select_class_set_tmp): New functions.
(select_type_set_tmp): Call one of last two new functions.
(gfc_match_select_type): Copy_ts_from_selector_to_associate is
called if associate-name is typed.

PR fortran/53191
* resolve.c (resolve_ref): C614 applied to class expressions.


2012-05-05  Paul Thomas  

PR fortran/41600
* gfortran.dg/select_type_26.f03 : New test.
* gfortran.dg/select_type_27.f03 : New test.

PR fortran/53191
* gfortran.dg/select_type_28.f03 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/select_type_26.f03
trunk/gcc/testsuite/gfortran.dg/select_type_27.f03
trunk/gcc/testsuite/gfortran.dg/select_type_28.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog

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

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas  2012-05-05 08:49:53 
UTC ---
Author: pault
Date: Sat May  5 08:49:43 2012
New Revision: 187192

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187192
Log:
2012-05-05  Paul Thomas  

PR fortran/41600
* trans-array.c (build_array_ref): New static function.
(gfc_conv_array_ref, gfc_get_dataptr_offset): Call it.
* trans-expr.c (gfc_get_vptr_from_expr): New function.
(gfc_conv_derived_to_class): Add a new argument for a caller
supplied vptr and use it if it is not NULL.
(gfc_conv_procedure_call): Add NULL to call to above.
symbol.c (gfc_is_associate_pointer): Return true if symbol is
a class object.
* trans-stmt.c (trans_associate_var): Handle class associate-
names.
* expr.c (gfc_get_variable_expr): Supply the array-spec if
possible.
* trans-types.c (gfc_typenode_for_spec): Set GFC_CLASS_TYPE_P
for class types.
* trans.h : Add prototypes for gfc_get_vptr_from_expr and
gfc_conv_derived_to_class. Define GFC_CLASS_TYPE_P.
* resolve.c (resolve_variable): For class arrays, ensure that
the target expression has all the necessary _data references.
(resolve_assoc_var): Throw a "not yet implemented" error for
class array selectors that need a temporary.
* match.c (copy_ts_from_selector_to_associate,
select_derived_set_tmp, select_class_set_tmp): New functions.
(select_type_set_tmp): Call one of last two new functions.
(gfc_match_select_type): Copy_ts_from_selector_to_associate is
called if associate-name is typed.

PR fortran/53191
* resolve.c (resolve_ref): C614 applied to class expressions.


2012-05-05  Paul Thomas  

PR fortran/41600
* gfortran.dg/select_type_26.f03 : New test.
* gfortran.dg/select_type_27.f03 : New test.

PR fortran/53191
* gfortran.dg/select_type_28.f03 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/select_type_26.f03
trunk/gcc/testsuite/gfortran.dg/select_type_27.f03
trunk/gcc/testsuite/gfortran.dg/select_type_28.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/symbol.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog

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

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  2012-05-05 08:52:31 
UTC ---
Fixed on trunk

Thanks for the report and sorry that it took more than two years to fix!

Paul

[Bug fortran/53191] [OOP] C614 (F2003) or C618 (F2008) not implemented for class expressions

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #2 from Paul Thomas  2012-05-05 08:53:51 
UTC ---
Fixed on trunk.

Paul

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

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #13 from Paul Thomas  2012-05-05 08:54:40 
UTC ---
oops - forgot to mark it as resolved

[Bug libstdc++/53244] internal compiler error while build for target c6x-elf

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  2012-05-05 08:56:27 
UTC ---
Hello,

isn't that the same as PR53209 (and at least 2 other duplicates)? Does this
patch fix it for you?
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00280.html

[Bug c/53245] ice in expand_case

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #1 from Markus Trippelsdorf  
2012-05-05 09:14:29 UTC ---
Started with revision 186579.

Reduced:

int a;
char b;
void fn1 ()
{
  a = (unsigned char)b;
  switch (a)
{
case '\0':
case -1:
  return;
default:
  fn1 ();
}
}

(dcb please have a look at
http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction.
It's would be easier if you could reduce your testcases yourself and it isn't 
that hard, actually.)

[Bug c/53245] ice in expand_case

[markus at trippelsdorf dot de]

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

--- Comment #2 from Markus Trippelsdorf  
2012-05-05 09:16:39 UTC ---
CC'ing Steven.

[Bug libstdc++/53244] internal compiler error while build for target c6x-elf

[daniel.calcoen at cern dot ch]

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

--- Comment #3 from daniel.calcoen at cern dot ch 2012-05-05 09:47:57 UTC ---
(In reply to comment #2)
> Hello,
> isn't that the same as PR53209 (and at least 2 other duplicates)? Does this
> patch fix it for you?
> http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00280.html

I'm sorry I didn't notice that now trunk is v4.8.0 open for development
with branch v4.7.1 builds ok

[Bug fortran/53111] [4.7/4.8 Regression] Derived types cannot be USE-associated again with -std=f95

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus  2012-05-05 
09:53:25 UTC ---
Author: burnus
Date: Sat May  5 09:53:21 2012
New Revision: 187193

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

Backport from mainline:
2012-05-04  Tobias Burnus  

PR fortran/53111
* resolve.c (resolve_fl_derived): Fix -std=f95
diagnostic for generic vs. DT names.

2012-05-05  Tobias Burnus  

Backport from mainline:
2012-05-04  Tobias Burnus  

PR fortran/53111
* gfortran.dg/constructor_7.f90: New.
* gfortran.dg/constructor_8.f90: New.


Added:
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/constructor_7.f90
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/constructor_8.f90
Modified:
branches/gcc-4_7-branch/gcc/fortran/ChangeLog
branches/gcc-4_7-branch/gcc/fortran/resolve.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug c++/53209] [4.7/4.8 Regression] tree check ICE: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||daniel.calcoen at cern dot
   ||ch

--- Comment #8 from Paolo Carlini  2012-05-05 
09:59:58 UTC ---
*** Bug 53244 has been marked as a duplicate of this bug. ***

[Bug libstdc++/53244] internal compiler error while build for target c6x-elf

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #4 from Paolo Carlini  2012-05-05 
09:59:58 UTC ---
Dup

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

[Bug lto/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #22 from Jan Hubicka  2012-05-05 
10:02:15 UTC ---
great, backporting to 4.7 should be easy, right?

[Bug fortran/53111] [4.7/4.8 Regression] Derived types cannot be USE-associated again with -std=f95

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #5 from Tobias Burnus  2012-05-05 
10:05:49 UTC ---
FIXED on the trunk (4.8) and on the 4.7 branch. (It will be in GCC 4.7.1.)

Thanks for the bug report!

[Bug bootstrap/52391] [4.7/4.8 regression] genattrtab almost 5X slower for m68k than in 4.6 and earlier releases

[steven at gcc dot gnu.org]

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

--- Comment #12 from Steven Bosscher  2012-05-05 
10:06:32 UTC ---
Created attachment 27315
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27315
Avoid diving deep through generated IOR trees for EQ_ATTR

This patch tries to keep IOR-trees for EQ_ATTR tests together. This improves
genattrtab run time and also the generated code because more get_attr_* results
are cached.

On gcc110, the run time for genattrtab for m68k goes down from 9m3s to 4m15s.
The difference in insn-attrtab looks like an improvement at first glance, but I
could use some help interpreting the differences. (Will attach shortly.)

(The cf.md bit only sorts the attributes alphabetically but doesn't change the
genattrtab run time.)

[Bug bootstrap/52391] [4.7/4.8 regression] genattrtab almost 5X slower for m68k than in 4.6 and earlier releases

[steven at gcc dot gnu.org]

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

--- Comment #13 from Steven Bosscher  2012-05-05 
10:13:48 UTC ---
Created attachment 27316
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27316
Difference in insn-attrtab.c before/after applyin
PR52391_compare_IOP_tree_v1.diff

tmp-attrtab.c is *with* the patch applied, insn-attrtab.c is without patch, for
GCC trunk at r186902.

Typical difference:

$ grep m68k_sched_branch_type v1_insn-attrtab.diff | grep "^\-" | wc
116 4644524
$ grep m68k_sched_branch_type v1_insn-attrtab.diff | grep "^\+" | wc
   23609440   92040

If someone could help interpret the differences, I'd be very grateful. With or
without patch, insn-attrtab is a monster...

[Bug c/43772] Errant -Wlogical-op warning when testing limits

[manu at gcc dot gnu.org]

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

--- Comment #21 from Manuel López-Ibáñez  2012-05-05 
11:31:03 UTC ---
Author: manu
Date: Sat May  5 11:30:57 2012
New Revision: 187194

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187194
Log:
2012-05-05  Manuel López-Ibáñez  

PR c/43772
c-family/
* c-common.c (warn_logical_operator): Do not warn if either side
is already true or false.
testsuite/
* c-c++-common/pr43772.c: New.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug c/43772] Errant -Wlogical-op warning when testing limits

[manu at gcc dot gnu.org]

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

--- Comment #22 from Manuel López-Ibáñez  2012-05-05 
11:32:30 UTC ---
Author: manu
Date: Sat May  5 11:32:26 2012
New Revision: 187195

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187195
Log:
2012-05-05  Manuel López-Ibáñez  

PR c/43772
testsuite/
* c-c++-common/pr43772.c: New.

Added:
trunk/gcc/testsuite/c-c++-common/pr43772.c

[Bug target/53246] New: failure building cross compiler for arm7tdmi (arm-none-eabi) in libgcc (multilib)

[patriciak784-gccmainling at yahoo dot de]

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

 Bug #: 53246
   Summary: failure building cross compiler for arm7tdmi
(arm-none-eabi) in libgcc (multilib)
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patriciak784-gccmainl...@yahoo.de


I tried to build a cross compiler on the GCC 4.7 branch rev 187011 from svn on
my x86_64 linux machine with the following configure line:
../../tree/armcompilersource/gcctree4.7/configure --target=arm-none-eabi
--disable-decimal-float --prefix=/opt/myarmgcc --with-cpu=arm7tdmi
--with-arch=armv4t --with-mode=thumb --with-tune=arm7tdmi  --enable-languages=c
--disable-libssp --disable-libquadmath --disable-libquadmath-support
--disable-libgomp --disable-nls --with-newlib --disable-shared --enable-lto
--disable-threads --disable-tls --with-system-zlib

Make will fail trying to build the target libgcc for the fpu multilib
...
Running configure in multilib subdir fpu
pwd: /home/testuser/gccbuild/arm-none-eabi
mkdir fpu
configure: creating cache ./config.cache
checking build system type... x86_64-unknown-linux-gnu
checking host system type... arm-none-eabi
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking for arm-none-eabi-ar... /opt/myarmgcc/arm-none-eabi/bin/ar
checking for arm-none-eabi-lipo... arm-none-eabi-lipo
checking for arm-none-eabi-nm... /home/testuser/gccbuild/./gcc/nm
checking for arm-none-eabi-ranlib... /opt/myarmgcc/arm-none-eabi/bin/ranlib
checking for arm-none-eabi-strip... /opt/myarmgcc/arm-none-eabi/bin/strip
checking whether ln -s works... yes
checking for arm-none-eabi-gcc... /home/testuser/gccbuild/./gcc/xgcc
-B/home/testuser/gccbuild/./gcc/ -B/opt/myarmgcc/arm-none-eabi/bin/
-B/opt/myarmgcc/arm-none-eabi/lib/ -isystem /opt/myarmgcc/arm-none-eabi/include
-isystem /opt/myarmgcc/arm-none-eabi/sys-include  -mfloat-abi=hard
checking for suffix of object files... configure: error: in
`/home/testuser/gccbuild/arm-none-eabi/fpu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Fehler 1
make[1]: Leaving directory `/home/testuser/gccbuild'
make: *** [all] Fehler 2

config.log says:
configure:3625: checking for suffix of object files
configure:3647: /home/testuser/gccbuild/./gcc/xgcc
-B/home/testuser/gccbuild/./gcc/ -B/opt/myarmgcc/arm-none-eabi/bin/
-B/opt/myarmgcc/arm-none-eabi/lib/ -isystem /opt/myarmgcc/arm-none-eabi/include
-isystem /opt/myarmgcc/arm-none-eabi/sys-include  -mfloat-abi=hard -c -g -O2 
conftest.c >&5
conftest.c: In function 'main':
conftest.c:12:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI
configure:3651: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3665: error: in `/home/testuser/gccbuild/arm-none-eabi/fpu/libgcc':
configure:3668: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.


I tried to disable the fpu multilib by adding --disable-fpu to the configure
line:
../../tree/armcompilersource/gcctree4.7/configure --target=arm-none-eabi
--disable-decimal-float --prefix=/opt/myarmgcc --with-cpu=arm7tdmi
--with-arch=armv4t --with-mode=thumb --with-tune=arm7tdmi  --enable-languages=c
--disable-libssp --disable-libquadmath --disable-libquadmath-support
--disable-libgomp --disable-nls --with-newlib --disable-shared --enable-lto
--disable-threads --disable-tls --with-system-zlib --disable-fpu

The gcc build now succeeds but if I execute arm-none-eabi-gcc -print-multi-lib,
it will report:
.;
thumb;@mthumb
fpu;@mfloat-abi=hard
So this GCC thinks it has a fpu multilib; but this has been disabled and no fpu
multilib part of libgcc has not been built.
This is a problem because building newlib with this GCC will fail because
newlib depends on the correctness of the output of -print-multi-lib

Please fix the configure process so that it won't fail builing the fpu multilib
part of libgcc and fix the output of gcc -print-multi-lib if gcc has been
configured with --disable-fpu.

Thank you

[Bug tree-optimization/30318] VRP does not create ANTI_RANGEs on overflow

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

  Attachment #27311|0   |1
is obsolete||

--- Comment #9 from Marc Glisse  2012-05-05 13:17:43 
UTC ---
Created attachment 27317
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27317
Wrap plus/minus/mult

And now with MULT_EXPR as well. Strangely enough, tree-vrp doesn't mention
LSHIFT_EXPR anywhere, could be worth adding it, at least for the case with a
constant shift.

[Bug tree-optimization/30318] VRP does not create ANTI_RANGEs on overflow

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #10 from Paolo Carlini  2012-05-05 
13:27:43 UTC ---
Now for the testcases... ;) Seriously, I have no idea what's the "policy" about
this kind of optimization, how many testcases are normally added, in principle
if one wanted to minimally exercise every code path would be dozens, I guess.
Personally I would be more interested in knowing how many times the new code
triggers in eg, a bootstrap.

[Bug tree-optimization/30318] VRP does not create ANTI_RANGEs on overflow

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #11 from Marc Glisse  2012-05-05 
13:29:36 UTC ---
(In reply to comment #10)
> Now for the testcases... ;)

Yes, that w

 Seriously, I have no idea what's the "policy" about
> this kind of optimization, how many testcases are normally added, in principle
> if one wanted to minimally exercise every code path would be dozens, I guess.
> Personally I would be more interested in knowing how many times the new code
> triggers in eg, a bootstrap.

[Bug tree-optimization/30318] VRP does not create ANTI_RANGEs on overflow

[glisse at gcc dot gnu.org]

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

--- Comment #12 from Marc Glisse  2012-05-05 
13:43:04 UTC ---
Er, sorry, don't know what key I accidentally pressed but it apparently sent
incomplete messages :-(

(In reply to comment #10)
> Now for the testcases... ;)

Yes, that was also my reaction when I looked at the patch...

> Seriously, I have no idea what's the "policy" about
> this kind of optimization, how many testcases are normally added, in principle
> if one wanted to minimally exercise every code path would be dozens, I guess.

You can test several almost at once, but yes, that's still quite a few.
Richard's old patch has some tests, and more importantly some nice framework to
write more.

> Personally I would be more interested in knowing how many times the new code
> triggers in eg, a bootstrap.

Some of the code (the quad_* stuff, the double_int overflow checks) is only for
__int128, so not tested a lot. On the other hand, any +/-/* operation on
unsigned types (and many on signed types, because some other pass replaces them
with unsigned) exercises this code. In a first version, because of a typo, I
ended up with a bootstrap failure caused by a miscompiled gengtype that would
create files named "gt-c-family-.h" without the "c-common" part inserted...

[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type

[wessjunk at gmail dot com]

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

Wes  changed:

   What|Removed |Added

 CC||wessjunk at gmail dot com

--- Comment #22 from Wes  2012-05-05 15:09:22 UTC ---
I agree with David.  My code has many instances of things like
a+=2
where a is a char and this makes -Wconversion useless to me.

It's too bad, since it would really be helpful as I am in the process of
changing some data types in the code.

If someone really thinks there should be a warning for this behavior, how about
adding a separate
-Wchar-arithmetic
warning which warns on all char arithmetic and see how much people use it.

[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type

[manu at gcc dot gnu.org]

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

--- Comment #23 from Manuel López-Ibáñez  2012-05-05 
15:30:06 UTC ---
(In reply to comment #22)
> If someone really thinks there should be a warning for this behavior, how 
> about
> adding a separate
> -Wchar-arithmetic
> warning which warns on all char arithmetic and see how much people use it.

I think adding a new option Wconversion-after-promotion that covers all cases
where the conversion occurs to the same type that was originally promoted from
would be the most appropriate. I have a feeling that it should not be hard to
implement, but I am not sure how, and I have many other things I would like to
do first. So, please David, Wes, photon, give it a try. The code is in
c-family/c-common.c (conversion_warning).

[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

[skunk at iskunk dot org]

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

--- Comment #4 from Daniel Richard G.  2012-05-05 
16:05:30 UTC ---
(In reply to comment #3)
> If you're using --enable-thread=posix then it should be defined.

I haven't used --enable-thread=posix, and if I invoke ".../xgcc -v", I see
"Thread model: aix". So it seems the test passes because _PTHREADS is not
defined.

Shouldn't the cpp conditional in the test be written as

#if !defined(_PTHREADS) || !defined(_POSIX_TIMEOUTS) || _POSIX_TIMEOUTS <=
0

?

[Bug c++/53247] New: [regression, c++11] can't use a function from a base class of the same name in a different namespace

[b.r.longbons at gmail dot com]

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

 Bug #: 53247
   Summary: [regression, c++11] can't use a function from a base
class of the same name in a different namespace
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


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

With gcc 4.7 and -std=c++11, 
the 'using' statement fails to bring in a function from the base class into the
current class. This is useful to prevent hiding.

Error message:
base.cpp:12:19: error: type ‘A’ is not a base type for type ‘A’

Workaround:
Create a new member function and explicitly call the base class function.

Versions tested:
Arch gcc (GCC) 4.7.0 20120114 (prerelease)
gcc-4.7 (Debian 4.7.0-3) 4.7.0

[Bug c++/53236] using declaration and base function template overloading

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-05-05 16:32:18 UTC ---
I agree that the code needs to be rejected, but I think the invalid expression
should be

ov.get()

instead of

ov.get()

as indicated by the code comment. The same defect also exists in 4.8.0 HEAD.

[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  2012-05-05 
17:40:29 UTC ---
Created attachment 27319
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27319
handle aix thread model

Ah, I see.  gthr-aix.h just does:

#ifdef _THREAD_SAFE
#include "gthr-posix.h"
#else
#include "gthr-single.h"
#endif

So it has everything in the posix thread model except the timedlock functions,
but doesn't match the case statement that only looks for "posix".

Your suggestion would work for the posix and aix thread models, but would break
e.g. win32, where _PTHREADS won't be defined but mutexes always support
timeouts (not that anyone has actually added __ghtread_mutex_timedlock to
gthr-win32.h yet, but they should do)

I think the right thing to do is define _PTHREADS for the aix thread model,
could you test this patch?  I've assumed that _THREAD_SAFE might be needed to
enable some thread-related features on AIX, I don't know if that's true.

An alternative patch would simply change  the case statement to match
posix|aix)

[Bug c++/53247] [regression, c++11] can't use a function from a base class of the same name in a different namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||fabien at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  2012-05-05 
17:43:01 UTC ---
Fabien, is this a dup of one of the other "using" regressions?

[Bug c++/53247] [regression, c++11] can't use a function from a base class of the same name in a different namespace

[fabien at gcc dot gnu.org]

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

fabien at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from fabien at gcc dot gnu.org 2012-05-05 17:57:27 UTC ---
(In reply to comment #1)
> Fabien, is this a dup of one of the other "using" regressions?

Definitely, this is a duplicate, thanks.

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

[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'

[fabien at gcc dot gnu.org]

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

fabien at gcc dot gnu.org changed:

   What|Removed |Added

 CC||b.r.longbons at gmail dot
   ||com

--- Comment #12 from fabien at gcc dot gnu.org 2012-05-05 17:57:27 UTC ---
*** Bug 53247 has been marked as a duplicate of this bug. ***

[Bug c++/53236] using declaration and base function template overloading

[fabien at gcc dot gnu.org]

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

fabien at gcc dot gnu.org changed:

   What|Removed |Added

 CC||fabien at gcc dot gnu.org

--- Comment #2 from fabien at gcc dot gnu.org 2012-05-05 18:04:26 UTC ---
The testcase does not seem to be reduced at the minimum. Would you mind
reducing it?

[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-05-05 
18:13:57 UTC ---
Created attachment 27320
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27320
diff of regenerated configure

N.B. you'll either need to run autoreconf or apply this patch to configure

[Bug c++/53236] using declaration and base function template overloading

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler  
2012-05-05 18:57:03 UTC ---
Reduced test-case:

//-
template
struct enable_same
{};

template
struct enable_same
{
  typedef U type;
};

template 
struct other_variant
{
  void get(){}
};

template 
struct other_variant : other_variant
{
  T u;

  using other_variant::get;

  template 
  typename enable_same::type
  get(){ return u; }
};

int main()
{
  other_variant ov;
  ov.get();
}
//-

It should be added, that it is important that other_variant has a second
template argument of double here (e.g. 'bool' won't work): It seems as if
within the member template get of the  partial specialization T behaves as if
it were type double within this member declaration. The hypotheses becomes some
evidence, if we change the implementation of the get template as follows:

  template 
  typename enable_same::type
  get(){
typename enable_same::type dummy;
return u;
  }

This also is accepted, even though T is of type int.

The curiosity increases about the interpretation of the deduced type of 'T'
within the partial specialization, if we add seemingly contradictory typedefs
to the class body of the specialization as follows:

//---
template
struct enable_same
{};

template
struct enable_same
{
  typedef U type;
};

template 
struct other_variant
{
  void get(){}
};

template 
struct other_variant : other_variant // Line 18
{
  T u;

  typename enable_same::type dummy1; // L. 22: Should be OK
  typename enable_same::type dummy2; // Should be an error

  using other_variant::get;

  template 
  typename enable_same::type
  get(){
typename enable_same::type dummy; // Should be an error
return u;
  }
};

int main()
{
  other_variant ov; // Line 37
  ov.get();
}
//---

On gcc 4.8.0 20120429 (experimental) I get the following diagnostics:

18|  required from 'struct other_variant'|
37|  required from here|
22|error: no type named 'type' in 'struct enable_same'|
37|  required from here|
23|error: no type named 'type' in 'struct enable_same'|
38|  required from here|
30|warning: unused variable 'dummy' [-Wunused-variable]|

Note that lines 22 and 23 describe the affected instantiations as

enable_same

and

enable_same

thus T seems to be once double and once int within the same instantiation -
quite amusing ;-)

[Bug bootstrap/37733] GCC Bootstrap fails in Stage 2 AIX 5.2

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #6 from David Edelsohn  2012-05-05 19:16:14 
UTC ---
No response and there are reports of GCC bootstrap on AIX 5.2, so this is
fixed.

[Bug libstdc++/53218] cmake segfaults on sparcv9

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-05-05
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Eric Botcazou  2012-05-05 
19:41:26 UTC ---
The segfault is in the system libstdc++ library though: was it compiled with
the problematic compiler?  If no, I suppose this works fine with the system
compiler, so can you find out what the problematic and the system compiler do
differently?

[Bug target/53219] inline function erroneously clobbers %i0 register on 64 bit sparc compile of perls regcomp.c

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-05-05
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1

--- Comment #6 from Eric Botcazou  2012-05-05 
19:46:22 UTC ---
> This is the generated assembler code:
> 
>0x4058f560 :
> brnz  %g1, 0x4058f570 
>0x4058f564 :add  %l3, %g1, %l5
>0x4058f568 :clr  [ %fp + 0x66b ]
>0x4058f56c :clr  [ %fp + 0x88f ], %i0
>0x4058f574 :and  %i0, 0xe0, %g1
>0x4058f578 :srl  %g1, 5, %g1
>0x4058f57c :cmp  %g1, 1
>0x4058f580 :
> be,pn   %icc, 0x40590ecc 
> 
> Note at the ==> marker, %i0 is reloaded without save before nor any restore
> later.

The assembly has apparently been mangled, please repost a correct version.

[Bug libstdc++/53248] New: std::array doesn't work when T is not default-constructible

[dwalker07 at yahoo dot com]

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

 Bug #: 53248
   Summary: std::array doesn't work when T is not
default-constructible
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dwalke...@yahoo.com


(I'm using GCC 4.7.0 from MacPorts on my Mac OS X 10.4.11/Tiger (32-bit
PowerPC).)  Here's a reduced example of my code:

//==
#include 
#include 
#include 

template < typename ...Types >
union super_union;

template < >
union super_union<>
{
static  auto optioned_types() -> std::array
{ return std::array{ {} }; }
};

template < typename Head, typename ...Tail >
union super_union
{
static
auto  optioned_types() -> std::array
{
using std::type_index;

return { {type_index(typeid(Head)), type_index(typeid(Tail))...} };
}

Head  data;
super_union  rest;
};

int  main()  { return 0; }
//==

When I compile it, I get:

//==
[daryle]$ g++-mp-4.7 -std=c++11 test_array.cpp
test_array.cpp: In static member function 'static std::array super_union<>::optioned_types()':
test_array.cpp:12:49: error: could not convert '()' from '' to
'std::array::value_type {aka std::type_index}'
//==

When I change the returned initialized value on line 12 to
"std::array{}", I get the same result.  But when I change
it to "std::array()", I get:

//==
[daryle]$ g++-mp-4.7 -std=c++11 test_array.cpp
test_array.cpp: In static member function 'static std::array super_union<>::optioned_types()':
test_array.cpp:12:45: error: use of deleted function
'std::array::array()'
In file included from test_array.cpp:1:0:
/opt/local/include/gcc47/c++/array:61:12: note: 'std::array::array()' is implicitly deleted because the default definition would be
ill-formed:
/opt/local/include/gcc47/c++/array:61:12: error: no matching function for call
to 'std::type_index::type_index()'
/opt/local/include/gcc47/c++/array:61:12: note: candidates are:
In file included from test_array.cpp:2:0:
/opt/local/include/gcc47/c++/typeindex:51:5: note:
std::type_index::type_index(const std::type_info&)
/opt/local/include/gcc47/c++/typeindex:51:5: note:   candidate expects 1
argument, 0 provided
/opt/local/include/gcc47/c++/typeindex:49:10: note: constexpr
std::type_index::type_index(const std::type_index&)
/opt/local/include/gcc47/c++/typeindex:49:10: note:   candidate expects 1
argument, 0 provided
/opt/local/include/gcc47/c++/typeindex:49:10: note: constexpr
std::type_index::type_index(std::type_index&&)
/opt/local/include/gcc47/c++/typeindex:49:10: note:   candidate expects 1
argument, 0 provided
//==

Looking at  on the web at your documentation pages, there is no
specialization of "std::array" for "std::array"; you just nudge the
element count to 1 when it would have been zero.  That secret element still
needs to be specified, since std::type_index doesn't have a default
constructor, although no initializers are logically necessary for an empty
array (i.e. the work-around abstraction leaks).

The first way I see around it is to make an explicit specialization that's
data-less.

[Bug ada/53230] s-fileio.adb:308:10: warning: ‘Errno’ may be used uninitialized in this function

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot
   ||gnu.org
 Resolution||WORKSFORME

--- Comment #1 from Eric Botcazou  2012-05-05 
20:14:12 UTC ---
False positive.

[Bug c/52682] [patch] gcc-4.7.0/gcc/c-family/c-lex.c doesn't compile with old C compilers

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||skunk at iskunk dot org

--- Comment #3 from Eric Botcazou  2012-05-05 
20:18:08 UTC ---
*** Bug 53237 has been marked as a duplicate of this bug. ***

[Bug bootstrap/53237] Bootstrap fails due to mixed declarations and code (c-lex.c)

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ebotcazou at gcc dot
   ||gnu.org
 Resolution||DUPLICATE

--- Comment #1 from Eric Botcazou  2012-05-05 
20:18:08 UTC ---
The search button is your friend.

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

[Bug middle-end/19805] sub-optimal initialisation of array on the stack

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||glisse at gcc dot gnu.org
  Known to work||4.4.7
 Resolution||FIXED
  Known to fail||4.2.4

--- Comment #3 from Marc Glisse  2012-05-05 20:46:39 
UTC ---
Closing, fixed since 4.3 according to my previous comment, and I re-checked
with 4.4 to trunk (don't have 4.3 anymore).

[Bug libstdc++/53248] std::array doesn't work when T is not default-constructible

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-05-05 21:16:36 UTC ---
(In reply to comment #0)
> Looking at  on the web at your documentation pages, there is no
> specialization of "std::array" for "std::array"; you just nudge the
> element count to 1 when it would have been zero.  That secret element still
> needs to be specified, since std::type_index doesn't have a default
> constructor, although no initializers are logically necessary for an empty
> array (i.e. the work-around abstraction leaks).
> 
> The first way I see around it is to make an explicit specialization that's
> data-less.

While I completely agree with your suggestion but I need to say that
unfortunately this is not what the library specification requires. The current
wording in fact allows implementations of the form found here. There is (again:
unfortunately) nothing that requires that std::array shall be
default-constructible irrespective of whether T is default-constructible, for
example.

I cannot speak for the decisions made in libstdc++ in regard to std::array's
optimized zero-size support, but I would like to encourage you to submit a
library issue to the email-address in the beginning of

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html

for this matter. I really think that it should be required that std::array is always default-constructible.

[Bug c++/53236] using declaration and base function template overloading

[fpelliccioni at gmail dot com]

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

--- Comment #4 from Fernando Pelliccioni  
2012-05-05 21:58:53 UTC ---
Created attachment 27321
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27321
simplified source code version

[Bug c++/53236] using declaration and base function template overloading

[fpelliccioni at gmail dot com]

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

--- Comment #5 from Fernando Pelliccioni  
2012-05-05 22:00:05 UTC ---
Here is a simplified code -> "gcc_error_simple.cpp"
Shows two facets of the error.

See the comments in the attached file.

[Bug c++/53236] using declaration and base function template overloading

[fpelliccioni at gmail dot com]

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

--- Comment #6 from Fernando Pelliccioni  
2012-05-05 22:01:23 UTC ---
// g++ -std=c++11 gcc_error_simple.cpp
// g++ -DWITH_USING_DECLARATION -std=c++11 gcc_error_simple.cpp

#include 
#include 
#include 

template 
struct Base
{
template 
typename std::enable_if::value, T>::type 
get()
{
}
};

template 
struct Derived : Base
{
typedef Base base;

#ifdef WITH_USING_DECLARATION
using base::get;
#endif

template 
typename std::enable_if::value, T>::type
get()
{
}
};


int main( /* int argc, char* argv[] */ )
{
Derived d;

auto xxx = d.get();
//std::cout << typeid(xxx).name() << std::endl;

auto yyy = d.get();// #ifndef WITH_USING_DECLARATION ->
Compile-time error-> GCC is behaving incorrectly. Base::get()
should not be hidden
// #ifdef 
WITH_USING_DECLARATION -> No Compile-time error -> GCC is behaving incorrectly.
Base::get() must be hidden.
//std::cout << typeid(yyy).name() << std::endl;

return 0;
}

[Bug bootstrap/53249] New: [4.8 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

 Bug #: 53249
   Summary: [4.8 Regression] Bootstrap failure
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: rsand...@gcc.gnu.org


On Linux/x86-64 with x32 enabled, revision 187199:

http://gcc.gnu.org/ml/gcc-cvs/2012-05/msg00195.html

caused:

../../../../src-trunk/libgomp/barrier.c: In function 'GOMP_barrier':
../../../../src-trunk/libgomp/barrier.c:34:21: internal compiler error: in
plus_constant, at explow.c:88
   struct gomp_team *team = thr->ts.team;
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[12]: *** [barrier.lo] Error 1

[Bug bootstrap/53249] [4.8 Regression] Bootstrap failure

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2012-05-05 22:22:27 
UTC ---
Created attachment 27322
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27322
A testcase

On Linux/x86-64:

[hjl@gnu-35 gcc]$ ./xgcc -B./ -O2 -mx32 -fPIC -S -ftls-model=initial-exec
/tmp/barrier.i -o /tmp/x.s
../../../../src-trunk/libgomp/barrier.c: In function \u2018GOMP_barrier\u2019:
../../../../src-trunk/libgomp/barrier.c:34:21: internal compiler error: in
plus_constant, at explow.c:88
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[hjl@gnu-35 gcc]$

[Bug libstdc++/53248] std::array doesn't work when T is not default-constructible

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2012-05-05 
23:27:26 UTC ---
The basic design of our std::array is rather old, dates back to the tr1::array
times, with updates. I bet we simply overlooked this issue, in terms of QoI.
Daniel, can you see other options besides adding a specialization? (which would
be a straightforward task, I may even get around to do pretty soon when I will
do debug-mode std::array, already in my todo list)

[Bug target/53250] New: [4.8 Regression] [SH] ICE: in change_address_1, at emit-rtl.c:2018

[kkojima at gcc dot gnu.org]

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

 Bug #: 53250
   Summary: [4.8 Regression] [SH] ICE: in change_address_1, at
emit-rtl.c:2018
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kkoj...@gcc.gnu.org
CC: olege...@gcc.gnu.org
Target: sh4-unknown-linux-gnu


On sh4-unknown-linux-gnu, there are many new failures after revision
187015.  The typical example is gcc.c-torture/compile/20071102-1.c
which fails with

internal compiler error: in change_address_1, at emit-rtl.c:2018

It seems that rtls like

(subreg:SF (reg:DI ...) 4)
(subreg:SF (reg:V2SF ...) 4)

cause this error when regs are on stack.  If my memory is correct,
the similar issue has popped up on oleg's work for QI/HImode addressing
with displacement.  The above rtls are not illegal but problematic
when regs are on stack because SH has no load/store instructions
for FP registers and memory with displacement.  Before lowering
subregs change in revision 187015, these subregs were decomposed
into subregs with zero byte count.
The trails of PR53716 say that the appropriate target-wise cost
computation is needed, though I can't find the way to enable
lowering the above subregs with adjusting SH's rtx cost computations.

[Bug c++/53251] New: template keyword ignored between -> and member under name collision with non-member

[potswa at mac dot com]

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

 Bug #: 53251
   Summary: template keyword ignored between -> and member under
name collision with non-member
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pot...@mac.com


Minimal testcase:

template< typename >
class set;

template< typename >
struct b {
template
void set();
};

template
struct d : b {
d() { this->template set(); }
};

int main()
{ d s; }

Diagnostic:

In constructor ‘d::d()’:
12:17: error: invalid use of ‘class set’

The name "set" is looked up in the context of the expression, outside the
class, perhaps per §3.4.5/1 [basic.lookup.classref]. Furthermore, a class found
by lookup in expression scope per 3.4.5/1 must agree with lookup in class scope
anyway (i.e. it must be a base class if class scope lookup succeeds) or the
program is ill-formed.

3.4.5/1 does not apply because the template keyword is used to mark a dependent
object expression. I suspect that somehow the hint carried by the keyword isn't
properly restricting name lookup.

For deeper discussion see http://stackoverflow.com/questions/10426428 .

[Bug c++/53251] template keyword ignored between -> and member under name collision with non-member

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-05-06 
01:04:58 UTC ---
Related to PR 11814 .

[Bug c++/53251] template keyword ignored between -> and member under name collision with non-member

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-05-06 
01:06:00 UTC ---
And PR 10200 .

[Bug c/37303] const compound initializers in structs are written to .data instead of .rodata

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  2012-05-06 
01:10:39 UTC ---
This test fails on MIPS because the section is rdata rather than rodata.

[Bug rtl-optimization/53252] New: Missed shrink wrapping opportunity

[law at redhat dot com]

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

 Bug #: 53252
   Summary: Missed shrink wrapping opportunity
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@redhat.com


Compile the attached code with -O3 -fprofile-generate, run the resulting
executable, then compile again with -O3 -fprofile-use.

Ideally the fast path through main_func would just do something like

test %dil,%dil
jnz 
xor %eax,%eax
ret

Unfortunately, we're getting frame setup/teardown in the fast path.

testcode:

#include 
volatile long x = 13;
void bar(long v)
{
printf("l = %li\n", v);
}

long foo(long l)
{
for (int i = 0; i != x; ++i)
{
l *= l ^ 47110815;
bar(l);
}

return l;
}

int main_func(bool b) __attribute__((noinline));
int main_func(bool b)
{
int ret = 0;
if (b)
{
for ( int i = 0; i != 1000; ++i )
ret += foo(i);
}
return ret;
}

int main( int argc, char** argv)
{
return main_func(argc != 1);
}

[Bug tree-optimization/53253] New: Missed opportunity to inline memcmp

[law at redhat dot com]

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

 Bug #: 53253
   Summary: Missed opportunity to inline memcmp
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@redhat.com


Compile with -O2.  Note the length of the memory to be compared via memcmp is
fixed and just 2 bytes.  It'd be more efficient and possibly smaller to just
inline the necessary comparisons.  Seems to me this ought to be addressed in
our tree optimizers.

int foo(const char* x) {
return memcmp(x,"xx",2) != 0;
}

[Bug tree-optimization/53254] New: Missed opportunity to aggregate consecutive stores into single larger store

[law at redhat dot com]

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

 Bug #: 53254
   Summary: Missed opportunity to aggregate consecutive stores
into single larger store
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l...@redhat.com


struct X {
X();
char a,b,c,d,e,f,g,h;
long long l;
};

X::X() : a(0), b(0), c(0), d(0), e(0), f(0), g(0), h(0), l(0)
{}

Compile with -O2.  Ideally we'd issue quadword stores.  I'm told VC++ manages
to get this right.

[Bug c/27214] The C frontend introduces undefined pointer overflow

[bugdal at aerifal dot cx]

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

Rich Felker  changed:

   What|Removed |Added

 CC||bugdal at aerifal dot cx

--- Comment #11 from Rich Felker  2012-05-06 04:11:03 
UTC ---
I would lean towards marking this one invalid. Under normal circumstances (and
I would argue, under ALL conditions, on a high-quality implementation), objects
cannot be larger than SIZE_MAX/2. This is because ptrdiff_t has been chosen to
be the signed type corresponding to size_t, and if objects larger than
SIZE_MAX/2 were allowed, valid pointer subtractions would overflow the signed
ptrdiff_t and result in undefined behavior.

There are three ways of addressing this issue; either:
(1) you say "subtracting pointers is unsafe unless the application makes an
effort to ensure that no huge objects exist" even though that's hard to do in
any portable way; OR
(2) you disallow objects sufficiently large that ptrdiff_t would overflow; OR
(3) you make ptrdiff_t a larger type (e.g. 64-bit on 32-bit systems). But this
is not an option since you're always dealing with an already-defined ABI.

If you take option (1), large objects (>SIZE_MAX/2) are already extremely
dangerous and so the additional wrapping issue in GCC's internal representation
is a really small matter in comparison. If you take option (2), offsets can
always be interpreted as the signed type.

[Bug c/39044] -Wformat warns on printf() with stringpointer as sole argument

[bugdal at aerifal dot cx]

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

Rich Felker  changed:

   What|Removed |Added

 CC||bugdal at aerifal dot cx

--- Comment #5 from Rich Felker  2012-05-06 04:23:14 
UTC ---
This warning is valid and highly desirable. Any call to printf with a single
non-string-literal argument is almost surely an extremely serious security bug.
And there's rarely a legitimate reason to make such a call; the closest thing
to a legitimate use I can think of would be lazy/sloppy use of gettext. If the
string is not a format string, you should use fputs or fwrite to print it.

[Bug tree-optimization/53253] Missed opportunity to inline memcmp

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  2012-05-06 
04:50:47 UTC ---
Confirmed.

[Bug rtl-optimization/19726] suboptimal constructor generated, consecutive stores should be done in a biggest mode

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #4 from Andrew Pinski  2012-05-06 
04:53:43 UTC ---
*** Bug 53254 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/53253] Missed opportunity to inline memcmp

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-05-06 
04:55:21 UTC ---
Related also to PR 12086.

[Bug tree-optimization/53254] Missed opportunity to aggregate consecutive stores into single larger store

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Andrew Pinski  2012-05-06 
04:53:43 UTC ---
An obvious dup of bug 19726.

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

[Bug tree-optimization/52171] memcmp/strcmp/strncmp can be optimized when the result is tested for [in]equality with 0

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  2012-05-06 
04:55:13 UTC ---
This really sounds like the same as PR 12086.

[Bug rtl-optimization/53252] Missed shrink wrapping opportunity

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  2012-05-06 
05:02:47 UTC ---
I think this is the same problem as mentioned in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474#c10 .

Confirmed.