[Bug c/53083] gcc bug in moving from the SSE registers back onto the heap.

[da_fox at mad dot scientist.com]

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

--- Comment #7 from Da Fox  2012-05-01 
07:54:54 UTC ---
(In reply to comment #6)
...
> The latest available gcc-version for my distribution (gentoo) appears to be
> 4.6.2, which I will try next.

This seems to still happen with 4.6.2 at least.

[Bug middle-end/27139] Optimize double INT->FP->INT conversions with -ffast-math

[marc.glisse at normalesup dot org]

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

--- Comment #4 from Marc Glisse  2012-05-01 
09:32:25 UTC ---
Hello Uros,
is there any other case you think should be handled, or should we close the
bug?

[Bug c++/53173] PROD02

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Jonathan Wakely  2012-05-01 
09:36:50 UTC ---
(In reply to comment #2)
> 2. error: no matching function for call to ‘std::pair boost::shared_ptr >::pair(long unsigned int, const
> a::b::c::Config*)’

There is no implicit conversion from Config* to shared_ptr, it was a
bug in GCC that the code compiled previously.

You need to create the pair with a shared_ptr as the second argument,
not a Config*

> 5. error: declaration of ‘~typename a::b::c::dControl PrivateSecurityID, ControlQueue, StatusQueue, Queue>::dControl’ as member of
> ‘a::b::c::dControl FeedControlQueue,
> StatusQueue, Queue>’

You're declaring a destructor with the wrong type.

[Bug bootstrap/53112] Fails at Configuring stage 1 in sparc64-sun-solaris2.10/libgcc: error: cannot compute suffix of object files: cannot compile

[birender.singh at hotmail dot com]

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

--- Comment #13 from birender.singh at hotmail dot com 2012-05-01 09:40:31 UTC 
---
The error removed when configured with --enable-languages=c,c++   only.
Is this correct? or if this gcc is build then does it make effect to java ?
beacuse don't know gcc + java releation..?

[Bug c++/53173] PROD02

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-05-01 
09:40:53 UTC ---
(In reply to comment #0)
> 4. error: no matching function for call to ‘make_pair(std::string&,
> std::string&)’

If you're calling make_pair with an explicit template argument list e.g. 
  pair p = make_pair(s1, s2);
then that won't work in C++11

Just construct a pair directly, it's pointless to use make_pair if you don't
want to deduce the argument types:

  auto p = pair(s1, s2);
or
  pair p(s1, s2);

[Bug c++/53173] PROD02

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-05-01 
09:41:34 UTC ---
Also, please give more useful bug descriptions, "PROD02" is completely
meaningless

[Bug fortran/51267] loop optimization error using LOC function

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #10 from Thomas Koenig  2012-05-01 
09:45:54 UTC ---
(In reply to comment #9)
> Is there any progress with this? The issue persists with gcc 4.7.0 final and
> the workaround with -fno-tree-dse stopped working.

The test case violates the standard.  The compiler knows that the array
tab cannot be accessed in a legal way, and that the stores into array
ius are not used later.  Therefore, they are removed.

This part of Fortran semantics allows a lot of optimizations, and we
will not make other programs slower to accommodate this non-standard
usage. 

So, your best bet is to simulate dynamic memory some other way, for
example by handing out parts of a COMMON block, or use F90+ memory
management.

Your second best bet is to compile all relevant code parts with -O0,
and keep your fingers crossed that it keeps on working.  This is likely,
but not guaranteed.

Closing as invalid.

[Bug bootstrap/53112] Fails at Configuring stage 1 in sparc64-sun-solaris2.10/libgcc: error: cannot compute suffix of object files: cannot compile

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME

--- Comment #14 from Eric Botcazou  2012-05-01 
10:08:09 UTC ---
> The error removed when configured with --enable-languages=c,c++   only.
> Is this correct? or if this gcc is build then does it make effect to java ?
> beacuse don't know gcc + java releation..?

If you don't need the Java compiler (GCJ) included in GCC but only the C and
C++ compilers, yes, that's fine.  That's orthogonal to the pre-existing Java
setup on the machine.

[Bug c++/52538] Extend C++11 UDLs to be compatible with inttypes.h macros

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  2012-05-01 
10:37:59 UTC ---
let's confirm this :)

[Bug middle-end/53100] Optimize __int128 with range information

[marc.glisse at normalesup dot org]

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

--- Comment #3 from Marc Glisse  2012-05-01 
12:47:03 UTC ---
(In reply to comment #2)
> and not to introduce them just before an optimization that removes them.

Usually, doing (long)num1*(__int128)(long)num2 does the right thing. I tried in
the example here replacing the plain __int128 multiplications with:

inline bool g1(__int128 x){
  //return(x<=LONG_MAX)&&(x>=LONG_MIN);
  //on 2 lines because of PR30318, unless you apply the patch I posted there
  bool b1 = x<=LONG_MAX;
  bool b2 = x>=LONG_MIN;
  return b1&&b2;
}
inline __int128 mul(__int128 a,__int128 b){
  bool B=g1(a)&&g1(b);
  if(__builtin_constant_p(B)&&B)
return (long)a*(__int128)(long)b;
  return a*b;
}

__builtin_constant_p does detect we are in the right case, however, because of
bad timing between the various optimizations, the double cast
(__int128)(long)(u-x) is simplified to just (u-x) before it gets a chance to
help. I need to replace the subtraction instead (or in addition) to the
multiplication:

inline __int128 sub(__int128 a,__int128 b){
  bool B=g1(a)&&g1(b)&& g1(a-b);
  if(__builtin_constant_p(B)&&B)
return (long)a-(long)b;
  return a-b;
}

But it would fit better inside the compiler than as a fragile use of
__builtin_constant_p.

[Bug debug/44664] CU DW_AT_low_pc, DW_AT_entry_pc are 0x0

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

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

--- Comment #2 from Mark Wielaard  2012-05-01 15:00:01 
UTC ---
I think the DW_AT_entry_pc issue was resolved by:

commit cb18bd3ce42532858cc65a1f20f3d79d5c253dde
Author: mark 
Date:   Fri Apr 1 18:24:52 2011 +

Don't add DW_AT_low_pc if the CU has no associated code.

* dwarf2out.c (dwarf2out_finish): Don't add low_pc and/or
high_pc attribute if the CU has no associated code. Only output
DW_AT_entry_pc for CU if not generating strict dwarf and
dwarf_version < 4.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@171846
138bc75d-0d04-0410-96

Since comment #1 said "So, from (a) IMHO only the point about DW_AT_entry_pc
not allowed on CU is valid." Can this issue now be closed?

[Bug target/53101] Recognize casts to sub-vectors

[marc.glisse at normalesup dot org]

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

--- Comment #2 from Marc Glisse  2012-05-01 
15:10:26 UTC ---
(In reply to comment #1)
> We get MEM[(T * {ref-all})&x] for the casting (not a BIT_FIELD_REF for
> example).
> This gets expanded to
> 
> (insn 6 5 7 (set (reg:OI 63)
> (subreg:OI (reg/v:V4DF 61 [ x ]) 0)) t.c:8 -1
>  (nil))
> 
> (insn 7 6 8 (set (reg:V2DF 60 [  ])
> (subreg:V2DF (reg:OI 63) 0)) t.c:8 -1
>  (nil))
> 
> but that should be perfectly optimizable.

A bit hard for me (never touched those md files before)... This obviously
incorrect code does the transformation:

(define_peephole2
[
(set
 (match_operand:V8SF 2 "memory_operand")
 (match_operand:V8SF 1 "register_operand")
)
(set
 (match_operand:V4SF 0 "register_operand")
 (match_operand:V4SF 3 "memory_operand")
)
]
  "TARGET_AVX"
[(const_int 0)]
{
  emit_insn (gen_vec_extract_lo_v8sf (operands[0], operands[1]));
  DONE;
})

(the code in this experiment uses __v4sf and __v8sf instead of __m128d/__m256d
in the description above)

but operands[2] and operands[3] don't compare equal with rtx_equal_p, and
trying a match_dup refuses to compile because of the mode mismatch, so I don't
know how to constrain 2 and 3 to be "the same". I tried adding some (subreg:
...) in there, but it didn't match, and looking at the rtl peephole dump, there
isn't any subreg there.

Then maybe peephole isn't the right place, but that's the only one where I
managed to get something that compiles and is executed by the compiler on this
testcase.

[Bug target/53133] XOR AL,AL to zero lower 8 bits of EAX/RAX causes partial register stall (Intel Core 2)

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  2012-05-01 16:42:32 
UTC ---
(In reply to comment #2)
> However, Core architecture is not listed under X86_TUNE_PARTIAL_REG_STALL,
> although my documentation says that following latency should be added due to
> partial reg stall:
> 
> PPro, P2, P3  : 5
> Core  : 1-5
> Core2, Corei7 : 1-6
> 
> H.J., should we consider these processors as affected by partial reg stall?

8bit/16bit load ops need to save and restore the upper bits when
updating the lower 8bits/16bits.  They are expensive ops on Intel
Core, Core 2 and Core i7 processors.  We will check the overall
impact of X86_TUNE_PARTIAL_REG_STALL on Core i7.

[Bug target/53101] Recognize casts to sub-vectors

[marc.glisse at normalesup dot org]

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

--- Comment #3 from Marc Glisse  2012-05-01 
17:17:42 UTC ---
(In reply to comment #2)
> but operands[2] and operands[3] don't compare equal with rtx_equal_p, and
> trying a match_dup refuses to compile because of the mode mismatch, so I don't
> know how to constrain 2 and 3 to be "the same".

rtx_equal_p (XEXP (operands[2], 0), XEXP (operands[3], 0))

seems to give the right answer in the 3 manual tests I did. Currently checking
if the testsuite finds something. It is very likely not the right way to do it,
but I didn't find any inspiring pattern in the .md files.

Then I'll see if I understand how the fancy macros make it possible to have a
single piece of code for all modes, and if instead of calling
gen_vec_extract_lo_v8sf I shouldn't give a replacement pattern like (set
(match_dup 0) (vec_select (match_dup 1) (const_int 0))).

[Bug fortran/53175] New: Fortran 4.8 undefined reference to a variable in a module

[michael.a.richmond at nasa dot gov]

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

 Bug #: 53175
   Summary: Fortran 4.8 undefined reference to a variable in a
module
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.a.richm...@nasa.gov
  Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
 Build: i686-pc-linux-gnu


This error occurs only in gnu Fortran 4.8 dated 04/08/2012 or later.

If I type "gfortran main.f90 e.f90 s.f90" I get the following error message:

/tmp/ccwf6p16.o: In function `default_settings.1813':
s.f90:(.text+0x1b): undefined reference to `__energy_function_MOD_dim'
/tmp/ccwf6p16.o: In function `set_simplex_options.1815':
s.f90:(.text+0x1cd): undefined reference to `__energy_function_MOD_dim'
collect2: error: ld returned 1 exit status

If I concatenate e.f90 and s.f90 so that they are compiled as a single file,
the error goes away.

Listed below are the contents of these files:

main.f90

PROGRAM main
END PROGRAM main

e.f90

MODULE ENERGY_FUNCTION
   IMPLICIT NONE

   TYPE PARAM
  PRIVATE
 INTEGER :: WHICH_VECTOR
   END TYPE PARAM

   INTEGER, PRIVATE :: DIM
   CONTAINS

  FUNCTION ENERGY_FUNCTION_CURRENT_ARGS()
 INTEGER, DIMENSION(DIM) :: ENERGY_FUNCTION_CURRENT_ARGS
  END FUNCTION ENERGY_FUNCTION_CURRENT_ARGS

  FUNCTION ENERGY_FUNCTION_GET_PARAMS()
 TYPE(PARAM), DIMENSION(DIM) :: ENERGY_FUNCTION_GET_PARAMS
  END FUNCTION ENERGY_FUNCTION_GET_PARAMS   

END MODULE ENERGY_FUNCTION

s.f90

MODULE SEARCH_EMIN
   USE ENERGY_FUNCTION
   IMPLICIT NONE
   CONTAINS
 SUBROUTINE SEARCH_EMIN_START()
 TYPE(PARAM), DIMENSION(:), ALLOCATABLE  :: EF_PARAMS
 DOUBLE PRECISION, DIMENSION(:), ALLOCATABLE :: START_PARAMETERS

 CALL SET_SIMPLEX_OPTIONS

 CONTAINS
SUBROUTINE SET_SIMPLEX_OPTIONS
   EF_PARAMS = ENERGY_FUNCTION_GET_PARAMS()
   CALL DEFAULT_SETTINGS
END SUBROUTINE SET_SIMPLEX_OPTIONS

SUBROUTINE DEFAULT_SETTINGS
   START_PARAMETERS = ENERGY_FUNCTION_CURRENT_ARGS()
END SUBROUTINE DEFAULT_SETTINGS

 END SUBROUTINE SEARCH_EMIN_START
END MODULE SEARCH_EMIN

[Bug rtl-optimization/53176] New: [4.8 Regression] gcc.target/i386/movbe-2.c and gcc.dg/lower-subreg-1.c

[hjl.tools at gmail dot com]

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

 Bug #: 53176
   Summary: [4.8 Regression] gcc.target/i386/movbe-2.c and
gcc.dg/lower-subreg-1.c
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: areg.melikadam...@gmail.com, rsand...@gcc.gnu.org


On Linux/ia32, revision 187015:

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

caused:

FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg"
FAIL: gcc.target/i386/movbe-2.c scan-assembler-times movbe[ \t] 4

[Bug rtl-optimization/53176] [4.8 Regression] gcc.target/i386/movbe-2.c and gcc.dg/lower-subreg-1.c

[zadeck at naturalbridge dot com]

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

Kenneth Zadeck  changed:

   What|Removed |Added

 CC||zadeck at naturalbridge dot
   ||com

--- Comment #1 from Kenneth Zadeck  2012-05-01 
18:32:32 UTC ---
hj

this is exactly the kind of regression that we expect!!!   The difference
between this version and the previous versions of lower-subreg, is that this
version takes into account the rtl costs of the operations transformed.If
the rtl costs do not indicate that this would be profitable, then the
transformations are not preformed.

it is up to the port maintainer to set the rtl costs correctly for their port. 
  If the port maintainer believes that his/her costs are correct and we are
still missing optimizations, then we will look into it.

Lower-subreg is most likely a terrible transformation to do on later x86s but
is likely to have been useful on the earlier ones.  So this regression is
likely a good thing.

kenny

[Bug libstdc++/53115] [4.7/4.8 Regression] _Hashtable::_M_rehash_aux(false_type) is broken

[fdumont at gcc dot gnu.org]

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

--- Comment #5 from François Dumont  2012-05-01 
19:38:35 UTC ---
Author: fdumont
Date: Tue May  1 19:38:28 2012
New Revision: 187023

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187023
Log:
2012-05-01  François Dumont  

PR libstdc++/53115
* include/bits/hashtable.h
(_Hashtable<>::_M_rehash_aux(size_type, false_type)): Fix buckets
after insertion of several equivalent elements.
* testsuite/23_containers/unordered_multiset/insert/53115.cc: New.
* testsuite/23_containers/unordered_multimap/insert/53115.cc: New.

Added:
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/53115.cc
   
branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_multiset/insert/53115.cc
Modified:
branches/gcc-4_7-branch/libstdc++-v3/ChangeLog
branches/gcc-4_7-branch/libstdc++-v3/include/bits/hashtable.h

[Bug c++/53177] New: 20_util/function/cons/callable.cc failed with -m32 -march=corei7

[hjl.tools at gmail dot com]

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

 Bug #: 53177
   Summary: 20_util/function/cons/callable.cc failed with -m32
-march=corei7
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/ia32, I got

/export/gnu/import/git/gcc-regression/master/186948/bld/./gcc/g++
-shared-libgcc -B/export/gnu/import/git/gcc-regression/master/186948/bld/./gcc
-nostdinc++
-L/export/gnu/import/git/gcc-regression/master/186948/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/src
-L/export/gnu/import/git/gcc-regression/master/186948/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-B/export/gnu/import/git/gcc-regression/master/186948/usr/x86_64-unknown-linux-gnu/bin/
-B/export/gnu/import/git/gcc-regression/master/186948/usr/x86_64-unknown-linux-gnu/lib/
-isystem
/export/gnu/import/git/gcc-regression/master/186948/usr/x86_64-unknown-linux-gnu/include
-isystem
/export/gnu/import/git/gcc-regression/master/186948/usr/x86_64-unknown-linux-gnu/sys-include
-m32
-B/export/gnu/import/git/gcc-regression/master/186948/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE  -DLOCALEDIR="." -nostdinc++
-I/export/gnu/import/git/gcc-regression/master/186948/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/export/gnu/import/git/gcc-regression/master/186948/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include
-I/export/gnu/import/git/gcc-regression/gcc/libstdc++-v3/libsupc++
-I/export/gnu/import/git/gcc-regression/gcc/libstdc++-v3/include/backward
-I/export/gnu/import/git/gcc-regression/gcc/libstdc++-v3/testsuite/util
/export/gnu/import/git/gcc-regression/gcc/libstdc++-v3/testsuite/20_util/function/cons/callable.cc
  -std=gnu++0x -S  -m32 -march=corei7 -o callable.s 
In file included from
/export/gnu/import/git/gcc-regression/gcc/libstdc++-v3/testsuite/20_util/function/cons/callable.cc:21:0:
/export/gnu/import/git/gcc-regression/master/186948/bld/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/functional:
In function ‘void test01()’:
/export/gnu/import/git/gcc-regression/master/186948/bld/x86_64-unknown-linux-gnu/32/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.

[Bug other/53178] New: fixinclude needed for iso/ctype_iso.h on Solaris 8

[skunk at iskunk dot org]

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

 Bug #: 53178
   Summary: fixinclude needed for iso/ctype_iso.h on Solaris 8
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: i386-pc-solaris2.8
Target: i386-pc-solaris2.8
 Build: i386-pc-solaris2.8


Created attachment 27273
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27273
/usr/include/iso/ctype_iso.h from Solaris 8

$ cat ctype.c
#include 

int main(void)
{
char c = 'A';

return isgraph(c);
}

$ gcc -W -Wall -c ctype.c
ctype.c: In function 'main':
ctype.c:7:2: warning: array subscript has type 'char' [-Wchar-subscripts]

This is bad if you're building with -Werror.

The problem:

$ grep isgraph /usr/include/iso/ctype_iso.h
extern int isgraph(int);
inline int isgraph(int c) { return (__ctype_mask[c] & _ISGRAPH); }
inline int isgraph(int c) { return ((__ctype + 1)[c] & (_P | _U | _L | _N)); }
#defineisgraph(c)(__ctype_mask[c] & _ISGRAPH)
#defineisgraph(c)((__ctype + 1)[c] & (_P | _U | _L | _N))
#defineisgraph(c)((_ctype + 1)[c] & (_P | _U | _L | _N))

The solution:

$ grep isgraph
/opt/gcc/lib/gcc/i386-pc-solaris2.8/4.7.0/include-fixed/iso/ctype_iso.h
extern int isgraph(int);
inline int isgraph(int c) { return (__ctype_mask[c] & _ISGRAPH); }
inline int isgraph(int c) { return ((__ctype + 1)[c] & (_P | _U | _L | _N)); }
#defineisgraph(c)(__ctype_mask[(int)(c)] & _ISGRAPH)
#defineisgraph(c)((__ctype + 1)[(int)(c)] & (_P | _U | _L | _N))
#defineisgraph(c)((_ctype + 1)[(int)(c)] & (_P | _U | _L | _N))

Same deal with the other isx() routines. I'm attaching the unmodified
system header file for reference.

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

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com
  Known to fail||

--- Comment #4 from Ian Lance Taylor  2012-05-01 20:06:35 
UTC ---
Potential patch: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00042.html

[Bug other/53179] New: fixinclude needed for pthread.h on AIX 5.3 (PTHREAD_ONCE_INIT)

[skunk at iskunk dot org]

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

 Bug #: 53179
   Summary: fixinclude needed for pthread.h on AIX 5.3
(PTHREAD_ONCE_INIT)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sk...@iskunk.org
  Host: powerpc-ibm-aix5.3.0.0
Target: powerpc-ibm-aix5.3.0.0
 Build: powerpc-ibm-aix5.3.0.0


Created attachment 27274
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27274
/usr/include/pthread.h from AIX 5.3

$ cat pth.c
#include 

pthread_once_t once = PTHREAD_ONCE_INIT;

int main(void) { return 0; }

$ OBJECT_MODE=32 gcc -W -Wall -c pth.c
pth.c:3:1: warning: missing braces around initializer
pth.c:3:1: warning: (near initialization for 'once.__on_word')

$ gcc -maix64 -W -Wall -c pth.c
pth.c:3:1: warning: missing braces around initializer
pth.c:3:1: warning: (near initialization for 'once.__on_word')

This is bad if you're building with -Werror.

Inexplicably, both the 32- and 64-bit forms of the PTHREAD_ONCE_INIT
initializer lack a pair of curly-braces. This despite other initializers in the
same file having the same form, and the correct double-brace syntax.

I am attaching a copy of both the original, unmodified pthread.h header, and my
manually-fixed version.

[Bug other/53179] fixinclude needed for pthread.h on AIX 5.3 (PTHREAD_ONCE_INIT)

[skunk at iskunk dot org]

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

--- Comment #1 from Daniel Richard G.  2012-05-01 
20:17:24 UTC ---
Created attachment 27275
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27275
Fixed version of pthread.h

[Bug rtl-optimization/53180] New: Revision 186378 generates incorrect code for cpu2006 416.gamess

[pthaugen at gcc dot gnu.org]

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

 Bug #: 53180
   Summary: Revision 186378 generates incorrect code for cpu2006
416.gamess
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pthau...@gcc.gnu.org
CC: berg...@gcc.gnu.org, ber...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


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

416.gamess benchmark started failing with r186378 due to segfault when running
the benchmark. I've tracked down to what appears to be bad code for register
spilling. Subroutine with bad code is attatched, compile with "gfortran -O3
-m64 -mcpu=power7 -funroll-loops -ffast-math".

Snippets from the dump files for the insns of interest:

193r.ira

r186377:

(insn 6636 6631 6639 43 (set (reg:SI 2943 [ D.2378 ])
(plus:SI (reg:SI 2944 [ MEM[base: D.4806_3018, index: ivtmp.1254_3009,
offset: 0B] ])
(subreg/s:SI (reg/v:DI 454 [ nx+-4 ]) 4))) hsandt.f:200 78
{*addsi3_internal1}
 (expr_list:REG_DEAD (reg:SI 2944 [ MEM[base: D.4806_3018, index:
ivtmp.1254_3009, offset: 0B] ])
(expr_list:REG_EQUIV (mem:SI (plus:DI (reg/f:DI 4113)
(reg:DI 2445 [ D.4808 ])) [3 MEM[base: D.4809_3021, index:
ivtmp.1232_213, offset: 0B]+0 S4 A32])
(nil
...
(insn 6637 6632 6640 43 (set (mem:SI (plus:DI (reg/f:DI 4113)
(reg:DI 2445 [ D.4808 ])) [3 MEM[base: D.4809_3021, index:
ivtmp.1232_213, offset: 0B]+0 S4 A32])
(reg:SI 2943 [ D.2378 ])) hsandt.f:200 377 {*movsi_internal1}
 (expr_list:REG_DEAD (reg/f:DI 4113)
(expr_list:REG_DEAD (reg:SI 2943 [ D.2378 ])
(nil


r186378:

(insn 6636 6631 6639 43 (set (reg:SI 2943 [ D.2378 ])
(plus:SI (reg:SI 2944 [ MEM[base: D.4806_3018, index: ivtmp.1254_3009,
offset: 0B] ])
(subreg/s:SI (reg/v:DI 454 [ nx+-4 ]) 4))) hsandt.f:200 78
{*addsi3_internal1}
 (expr_list:REG_DEAD (reg:SI 2944 [ MEM[base: D.4806_3018, index:
ivtmp.1254_3009, offset: 0B] ])
(nil)))
...
(insn 6637 6632 6640 43 (set (mem:SI (plus:DI (reg/f:DI 4113)
(reg:DI 2445 [ D.4808 ])) [3 MEM[base: D.4809_3021, index:
ivtmp.1232_213, offset: 0B]+0 S4 A32])
(reg:SI 2943 [ D.2378 ])) hsandt.f:200 377 {*movsi_internal1}
 (expr_list:REG_DEAD (reg/f:DI 4113)
(expr_list:REG_DEAD (reg:SI 2943 [ D.2378 ])
(nil

Note that insn 6636 no longer contains the REG_EQUIV note in r186378. Not sure
of the significance yet, but something I noticed.



194r.reload

r186377:

changing reg in insn 6636
changing reg in insn 6637
 Register 2943 now on stack.
...
(insn 6636 6631 8007 43 (set (reg:SI 18 18)
(plus:SI (reg:SI 18 18 [orig:2944 MEM[base: D.4806_3018, index:
ivtmp.1254_3009, offset: 0B] ] [2944])
(reg:SI 11 11 [orig:454 nx ] [454]))) hsandt.f:200 78
{*addsi3_internal1}
 (expr_list:REG_EQUIV (mem:SI (plus:DI (reg/f:DI 19 19 [4113])
(reg:DI 6 6 [orig:2445 D.4808 ] [2445])) [3 MEM[base:
D.4809_3021, index: ivtmp.1232_213, offset: 0B]+0 S4 A32])
(nil)))

(insn 8007 6636 6639 43 (set (mem/c:SI (plus:DI (reg/f:DI 19 19 [4113])
(reg:DI 6 6 [orig:2445 D.4808 ] [2445])) [3 MEM[base:
D.4809_3021, index: ivtmp.1232_213, offset: 0B]+0 S4 A32])
(reg:SI 18 18)) hsandt.f:200 377 {*movsi_internal1}
 (nil))


r186378:

changing reg in insn 6636
changing reg in insn 6637
  Assigning 2943(freq=2) slot 13 of 524 2290
 Register 2943 now on stack.
...
(insn 6636 6631 8052 43 (set (reg:SI 18 18)
(plus:SI (reg:SI 18 18 [orig:2944 MEM[base: D.4806_3018, index:
ivtmp.1254_3009, offset: 0B] ] [2944])
(reg:SI 11 11 [orig:454 nx ] [454]))) hsandt.f:200 78
{*addsi3_internal1}
 (nil))

(insn 8052 6636 6639 43 (set (mem/c:SI (plus:DI (reg/f:DI 1 1)
(const_int 17664 [0x4500])) [32 %sfp+17664 S4 A64])
(reg:SI 18 18)) hsandt.f:200 377 {*movsi_internal1}
 (nil))

In both cases insn 6637 is deleted, but as you can see above r186378 stores to
the stack, and that value is not subsequently copied into the original target
location of insn 6637.

I can provide more information/details if needed, just don't know what to throw
in that will be useful at the moment.

Configured with: /home/pthaugen/src/gcc/temp/gcc/configure
--prefix=/home/pthaugen/install/gcc/temp --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/pthaugen/install/binutils/binutils-2.21.1

[Bug libstdc++/53115] [4.7/4.8 Regression] _Hashtable::_M_rehash_aux(false_type) is broken

[fdumont at gcc dot gnu.org]

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

--- Comment #6 from François Dumont  2012-05-01 
20:29:24 UTC ---
Author: fdumont
Date: Tue May  1 20:29:16 2012
New Revision: 187025

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187025
Log:
2012-05-01  François Dumont  

PR libstdc++/53115
* include/bits/hashtable.h
(_Hashtable<>::_M_rehash_aux(size_type, false_type)): Fix buckets
after insertion of several equivalent elements.
* testsuite/23_containers/unordered_multiset/insert/53115.cc: New.
* testsuite/23_containers/unordered_multimap/insert/53115.cc: New.

Added:
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/53115.cc
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/insert/53115.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable.h

[Bug c/37743] Bogus printf format warning with __builtin_bswap32.

[jyasskin at gcc dot gnu.org]

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

Jeffrey Yasskin  changed:

   What|Removed |Added

 CC||jyasskin at gcc dot gnu.org

--- Comment #7 from Jeffrey Yasskin  2012-05-01 
20:45:33 UTC ---
This also causes the result of __builtin_bswap32 to fail overload resolution:

$ cat test.cc
void foo(unsigned int x);
void foo(int x);

void bar(long long x) {
  foo(__builtin_bswap32(x));
}
$ g++-4.8pre -c test.cc
test.cc: In function ‘void bar(long long int)’:
test.cc:5:27: error: call of overloaded ‘foo(unsigned int)’ is ambiguous
test.cc:5:27: note: candidates are:
test.cc:1:6: note: void foo(unsigned int)
test.cc:2:6: note: void foo(int)
$ g++-4.8pre --version
g++-4.8pre (GCC) 4.8.0 20120330 (experimental)


It's not terribly important to me: a wrapper can easily cast to the expected
type.

[Bug c/37743] Bogus printf format warning with __builtin_bswap32.

[jyasskin at gcc dot gnu.org]

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

--- Comment #8 from Jeffrey Yasskin  2012-05-01 
20:47:00 UTC ---
Arguably, the bad diagnostic (reporting "unsigned int!=unsigned int") is more
serious than the bswap bug, since it may show up for other functions.

[Bug c++/53177] 20_util/function/cons/callable.cc failed with -m32 -march=corei7

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  2012-05-01 
20:59:00 UTC ---
mine

[Bug c++/53177] 20_util/function/cons/callable.cc failed with -m32 -march=corei7

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2012-05-01 
21:06:37 UTC ---
Created attachment 27277
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27277
testcase

I was seeing an ICE in the same place with an earlier version of the changes
which caused this testcase regression.  I have only managed to reduce it to 10k
lines so far - that delta-reduced file is attached, I haven't had time to try
manually reducing it.

Presumably fixing the ICE for this file will also fix it for this the testcase
regression.

[Bug c++/53177] 20_util/function/cons/callable.cc failed with -m32 -march=corei7

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  2012-05-01 
21:08:16 UTC ---
Unassigning myself.  I don't think there's any more I can do beyond providing
the testcase.  Let me know if my patch needs to be reverted.

[Bug gcov-profile/49484] gcov crash if two(or more) forks happen at the same time

[asharif at gcc dot gnu.org]

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

--- Comment #24 from asharif at gcc dot gnu.org 2012-05-01 21:22:51 UTC ---
Author: asharif
Date: Tue May  1 21:22:47 2012
New Revision: 187026

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187026
Log:
Backported r185231 from trunk.

2012-03-12  Richard Guenther  

* gthr.h (__GTHREAD_MUTEX_INIT_FUNCTION): Adjust specification.
* gthr-posix.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
(__gthread_mutex_init_function): New function.
* gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.

PR gcov/49484
* libgcov.c: Include gthr.h.
(__gcov_flush_mx): New global variable.
(init_mx, init_mx_once): New functions.
(__gcov_flush): Protect self with a mutex.
(__gcov_fork): Re-initialize mutex after forking.
* unwind-dw2-fde.c: Change condition under which to use
__GTHREAD_MUTEX_INIT_FUNCTION.

Modified:
branches/google/gcc-4_6/   (props changed)
branches/google/gcc-4_6/gcc/ChangeLog.google-4_6
branches/google/gcc-4_6/gcc/gthr-posix.h
branches/google/gcc-4_6/gcc/gthr-single.h
branches/google/gcc-4_6/gcc/gthr.h
branches/google/gcc-4_6/gcc/libgcov.c
branches/google/gcc-4_6/gcc/unwind-dw2-fde.c
branches/google/gcc-4_6/libgcc/ChangeLog

Propchange: branches/google/gcc-4_6/
('svn:mergeinfo' modified)

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

[ian at gcc dot gnu.org]

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

--- Comment #5 from ian at gcc dot gnu.org  2012-05-01 
21:25:20 UTC ---
Author: ian
Date: Tue May  1 21:25:15 2012
New Revision: 187027

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187027
Log:
gcc/:
PR c/37303
* c-decl.c (build_compound_literal): Make the decl readonly if it
an array of a readonly type.
* gimplify.c (gimplify_compound_literal_expr): Add fallback
parameter.  Change all callers.  If the decl is not addressable
and is not an l-value, make it readonly.
gcc/testsuite:
PR c/37303
* gcc.dg/pr37303.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr37303.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-decl.c
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog

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

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

  Known to work||4.8.0

--- Comment #6 from Ian Lance Taylor  2012-05-01 21:26:28 
UTC ---
Fixed on mainline for the future 4.8.0 release.

[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit

[davem at gcc dot gnu.org]

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

--- Comment #3 from davem at gcc dot gnu.org 2012-05-01 22:27:11 UTC ---
Sadly, the bug is even more severe.

Even something as simple as:

long double f(long double a, long double b)
{
   return a + b;
}

will be miscompiled with -O1 -ffloat-store on 64-bit.  The problem
is that the call instructions emitted lack the reg use notes so that
the compiler can see the stack frame inputs to the libcall.  Strangely,
the notes are created properly on 32-bit.

Then DSE thinks that the stack stores can be eliminated and proceeds
to kill those insns off.

Also, code generation is significantly better with -ffloat-store
enabled.  If you don't believe me, see for yourself.

[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit

[davem at gcc dot gnu.org]

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

--- Comment #4 from davem at gcc dot gnu.org 2012-05-01 22:44:08 UTC ---
Ok, I see why 32-bit works.  On 32-bit we use real libfuncs in the optabs, so
the compiler can see all the typing information and emit the proper information
to stick into the CALL_INSN_FUNCTION_USAGE lists.

But when we emit soft TFmode libcalls by hand, as on 64-bit, this information
is lost.  So DSE has nothing to work with and can't see that the temporary
stack slots are inputs to the libcall.

We'll have to tack on our own reg use notes by hand in functions like
emit_soft_tfmode_libcall() and sparc_emit_float_lib_cmp().

[Bug bootstrap/52847] "case" shell quoting problem in top-level makefile

[skunk at iskunk dot org]

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

--- Comment #3 from Daniel Richard G.  2012-05-01 
23:01:28 UTC ---
(In reply to comment #1)
> You should not need -mminimal-toc because of this toplevel makefile part.

Ah, good to know. If I don't set -mminimal-toc in CC, I see this when larger
executables are being linked...

ld: 0711-783 WARNING: TOC overflow. TOC size: 474420Maximum size: 65536
Extra instructions are being generated for each reference to a TOC
symbol if the symbol is in the TOC overflow area.

...but the warning is non-fatal, and bootstrapping is otherwise unaffected.

[Bug target/52684] [4.7 regression] glibc long double math tests fail on sparc 64-bit

[davem at gcc dot gnu.org]

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

--- Comment #5 from davem at gcc dot gnu.org 2012-05-01 23:12:46 UTC ---
Strange, I added code to tack the function usage information onto
TFmode libcalls, but DSE still removes the stack slot stores :-/

[Bug go/52586] libgo fails to build for mips*64-linux-gnu (reference to undefined name 'SYS_GETDENTS64')

[doko at gcc dot gnu.org]

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

--- Comment #9 from Matthias Klose  2012-05-01 
23:14:15 UTC ---
Native configuration is mipsel-unknown-linux-gnu

=== libgo tests ===


Running target unix
FAIL: archive/zip

=== libgo Summary for unix ===

# of expected passes122
# of unexpected failures1

Running target unix/-mabi=n32
FAIL: archive/zip
FAIL: os/user

=== libgo Summary for unix/-mabi=n32 ===

# of expected passes121
# of unexpected failures2

Running target unix/-mabi=64
FAIL: archive/zip
FAIL: os/user

=== libgo Summary for unix/-mabi=64 ===

# of expected passes121
# of unexpected failures2

=== libgo Summary ===

# of expected passes364
# of unexpected failures5


this seems to work. the fails are:


--- FAIL: zip.TestReader (2.72 seconds)
reader_test.go:254: error=open testdata/go-no-datadesc-sig.zip: No such
file or directory, want 
reader_test.go:254: error=open testdata/go-with-datadesc-sig.zip: No
such file or directory, want 
panic: Error reading go-with-datadesc-sig.zip: open
testdata/go-with-datadesc-sig.zip: No such file or directory
 [recovered]
panic: Error reading go-with-datadesc-sig.zip: open
testdata/go-with-datadesc-sig.zip: No such file or d
irectory
FAIL: archive/zip
../../../src/libgo/testsuite/gotest: line 448: gotest-timeout: No such file or
directory


--- FAIL: user.TestCurrent (0.14 seconds)
user_test.go:35: Current: user: unknown userid 1174
--- FAIL: user.TestLookup (0.00 seconds)
user_test.go:76: Current: user: unknown userid 1174
--- FAIL: user.TestLookupId (0.00 seconds)
user_test.go:92: Current: user: unknown userid 1174
FAIL
FAIL: os/user

note that the user is not present in /etc/passwd.

[Bug libstdc++/53115] [4.7/4.8 Regression] _Hashtable::_M_rehash_aux(false_type) is broken

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
  Known to fail|4.7.1, 4.8.0|

--- Comment #7 from Paolo Carlini  2012-05-01 
23:42:29 UTC ---
Fixed for mainline and 4.7.1.

[Bug c++/53181] New: static_assert sees as non constant the comparison between a constexpr and a template argument

[blaffablaffa at gmail dot com]

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

 Bug #: 53181
   Summary: static_assert sees as non constant the comparison
between a constexpr and a template argument
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: blaffabla...@gmail.com


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

As per title.
The weird is that it seems that the constexpr-ness seems to changes if the
expression inside static_assert evaluates to true (compiles, expression seen as
constexpr) or false (fails to compile, but not due to the assertion failing but
to the described error).

[Bug c++/53177] 20_util/function/cons/callable.cc failed with -m32 -march=corei7

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #4 from Marc Glisse  2012-05-02 
00:54:38 UTC ---
(In reply to comment #2)
> I was seeing an ICE in the same place with an earlier version of the changes
> which caused this testcase regression.  I have only managed to reduce it to 
> 10k
> lines so far - that delta-reduced file is attached, I haven't had time to try
> manually reducing it.

If you only want a small example causing the ICE, here is one (-std=c++0x is
enough, no need for -m32 or -march). If you want something that looks vaguely
like a valid C++ program, it's going to be bigger...

extern "C++" namespace __attribute__ ) template < } template < typename >
struct add_rvalue_reference ; template < _Tp > typename declval ( ) noexcept ;
struct { typedef long __type } struct { } template < typename _Res , typename
... _ArgTypes > class function < _Res ( _ArgTypes ) { _Signature_type (
_ArgTypes ) template < typename _Functor > using _Invoke decltype ( ( declval <
_Functor > ) ) template < typename , typename > struct _CheckResult { }
template < ; template < typename _Functor > using _Callable _CheckResult <
_Invoke < _Functor > , _Res > template < typename , typename > using _Requires
template < typename _Functor , typename = _Requires < _Callable < _Functor > ,
void > > function ( _Functor ; } ; f ( function < void > ) { f ( [ ] )

[Bug c/53182] New: GNU C: attributes without underscores should be discouraged / no longer be documented e.g. as examples

[vincent-gcc at vinc17 dot net]

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

 Bug #: 53182
   Summary: GNU C: attributes without underscores should be
discouraged / no longer be documented e.g. as examples
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincent-...@vinc17.net


Attributes without underscores can conflict with the ISO C standard. For
instance, if the C11  header is included, this breaks GCC's

  __attribute__ ((noreturn))

(such problems may occur in particular if different libraries, with different
expectations, are used). To avoid such a clash, only the __noreturn__ version
should be used. Other attributes without __ may also lead to conflicts with a
future C standard. You can see

  http://lists.gnu.org/archive/html/bug-gnulib/2012-05/msg00024.html

and the corresponding discussion, from which I've reported this bug.

I suggest the following changes:

* Fix the GCC manual: the versions without __ should be discouraged (explain
why) and the examples should always use the __ version, e.g. change

  void fatal () __attribute__ ((noreturn));

to

  void fatal () __attribute__ ((__noreturn__));

* Possibly issue a warning if an attribute without __ is used.

[Bug bootstrap/53183] New: [4.7/4.8 Regression] libgcc does not always figure out the size of double/long double

[pinskia at gcc dot gnu.org]

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

 Bug #: 53183
   Summary: [4.7/4.8 Regression] libgcc does not always figure out
the size of double/long double
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org


When compiling for a cross compiler to mips64-linux-gnu, we need to build a
minimal compiler which does not have any libc headers including stdio.h.

So when we go to link n32 (or n64) glibc, it fails saying undefined symbols for
the TF functions.  

The reason why it fails is because libgcc's configure did not figure out the
size of long double.  The reason why that test fails is because there is an
include for stdio.h.  The default AC_CHECK_SIZEOF uses the default include
requirements which include stdio.h unconditionally.

Add to configure.ac and regenerate.
# The libgcc should not depend on any header files
AC_DEFUN([_AC_INCLUDES_DEFAULT_REQUIREMENTS],
  [m4_divert_text([DEFAULTS],
[ac_includes_default='/* none */'])]) 

--- CUT ---

I will submit this patch after I finish testing it but I wanted to file this as
a bug so it does not get lost.

[Bug go/52586] libgo fails to build for mips*64-linux-gnu (reference to undefined name 'SYS_GETDENTS64')

[ian at airs dot com]

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

--- Comment #10 from Ian Lance Taylor  2012-05-02 04:33:56 
UTC ---
I don't understand the archive/zip test failure.  The files in question are
libgo/go/archive/zip/testdata/go-with-datadesc-sig.zip and
go-no-datadesc-sig.zip.  They exist in the repository.  Do they exist in your
source tree?

The os/user test will fail if run by a user ID for which the libc function
getpwuid_r does not return any information.

[Bug fortran/53175] [4.8 Regression] link failure for private module variables used in function specification

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||rejects-valid
   Last reconfirmed||2012-05-02
 CC||burnus at gcc dot gnu.org
 Ever Confirmed|0   |1
Summary|Fortran 4.8 undefined   |[4.8 Regression] link
   |reference to a variable in  |failure for private module
   |a module|variables used in function
   ||specification
   Target Milestone|--- |4.8.0

--- Comment #1 from Tobias Burnus  2012-05-02 
06:00:08 UTC ---
The regression has been caused by PR 52751 (cf. also PR 40973 and PR 52916).

The patch for those PRs marks the module variable "DIM" as nonpublic, which
increases the optimization possibilities for the compiler. However, "dim" is
used for the type parameter of the result variable of two (public) functions.

The solution is to do the same as for PR 52916 - but this time for module
variables: Setting attr.public_used for the module variable if it is used as
type parameter of public functions - even if those are only available
indirectly via generic interfaces.

[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 #2 from Tobias Burnus  2012-05-02 
06:08:20 UTC ---
Something like the following should work; it might require some refinement or
can be shorted. (Completely untested.)

--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12015,6 +12046,10 @@ resolve_fl_derived (gfc_symbol *sym)
   if (!sym->attr.is_class)
 gfc_find_symbol (sym->name, sym->ns, 0, &gen_dt);
   if (gen_dt && gen_dt->generic && gen_dt->generic->next
+  && (gen_dt->generic->next->next
+ || !gen_dt->generic->sym->attr.use_assoc
+ || gen_dt->generic->sym->module
+   != gen_dt->generic->next->sym->module)
   && gfc_notify_std (GFC_STD_F2003, "Fortran 2003: Generic name '%s' of "
 "function '%s' at %L being the same name as derived "
 "type at %L", sym->name,

[Bug c++/53184] New: Unnecessary anonymous namespace warnings

[orgads at gmail dot com]

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

 Bug #: 53184
   Summary: Unnecessary anonymous namespace warnings
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: org...@gmail.com


Created attachment 27279
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27279
sample code

The attached file (stripped preprocessor output) produces the following
warning:

foo.cpp:5:16: warning: 'Bar' has a field 'Bar::foo' whose type uses the
anonymous namespace [enabled by default]

[Bug tree-optimization/53185] New: segmentation fault in vectorizable_load

[gary at intrepid dot com]

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

 Bug #: 53185
   Summary: segmentation fault in vectorizable_load
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com
CC: ne...@intrepid.com
Target: x86_64


Created attachment 27280
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27280
script to demonstrate compiler segfault

GCC 4.8 trunk revision r187034 encounters a segfault when compiling the
attached test case.  This appears to be a relatively recent regression.

Here's the back trace.

Program received signal SIGSEGV, Segmentation fault.
0x00d93153 in vectorizable_load (stmt=0x71889460,
gsi=0x7fffd680, vec_stmt=0x7fffd5a0, slp_node=0x0,
slp_node_instance=0x0)
at gcc/tree-vect-stmts.c:4563
4563  ivstep = fold_build2 (MULT_EXPR, TREE_TYPE (ivstep), ivstep,
(gdb) where
#0  0x00d93153 in vectorizable_load (stmt=0x71889460,
gsi=0x7fffd680, vec_stmt=0x7fffd5a0, slp_node=0x0,
slp_node_instance=0x0)
at gcc/tree-vect-stmts.c:4563
#1  0x00d978e4 in vect_transform_stmt (stmt=0x71889460,
gsi=0x7fffd680, grouped_store=0x7fffd677 "", slp_node=0x0,
slp_node_instance=0x0)
at gcc/tree-vect-stmts.c:5639
#2  0x00dac324 in vect_transform_loop (loop_vinfo=0x1cd0630)
at gcc/tree-vect-loop.c:5461
#3  0x00dbfd08 in vectorize_loops ()
at gcc/tree-vectorizer.c:214
#4  0x00cbf6b4 in tree_vectorize ()
at gcc/tree-ssa-loop.c:218
#5  0x00a22eb0 in execute_one_pass (pass=0x19fdc40)
at gcc/passes.c:2181
#6  0x00a23096 in execute_pass_list (pass=0x19fdc40)
at gcc/passes.c:2236
#7  0x00a230b7 in execute_pass_list (pass=0x19fda60)
at gcc/passes.c:2237

To reproduce, copy the attached do-fail script and gasnet_core.i file to the
gcc build directory, and run do-fail.

The compiler was configured with --disable-bootstrap --disable-multilib and
--enable-checking, however, the failure occurred after a full bootstrap and
with various other configure switches as well.

[Bug tree-optimization/53185] segmentation fault in vectorizable_load

[gary at intrepid dot com]

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

--- Comment #1 from Gary Funck  2012-05-02 06:11:21 
UTC ---
Created attachment 27281
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27281
pre-processed source that demonstrates compiler segfault

[Bug go/52586] libgo fails to build for mips*64-linux-gnu (reference to undefined name 'SYS_GETDENTS64')

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski  2012-05-02 
06:20:16 UTC ---
>getpwuid_r does not return any information.

There is a bug in the upstream glibc with respect of setregid setresgid
setresuid setreuid.  I have a patch but I have not submitted them upstream yet.

[Bug c++/53184] Unnecessary anonymous namespace warnings

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2012-05-02 
06:25:50 UTC ---
>foo.cpp:5:16: warning: 'Bar' has a field 'Bar::foo' whose type uses the
anonymous namespace [enabled by default]

The warning just needs to be worded better but otherwise it is correct.  It is
using a type which is anonymous.

[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |ramana at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.8.0

[Bug tree-optimization/53185] segmentation fault in vectorizable_load

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #2 from Markus Trippelsdorf  
2012-05-02 06:42:19 UTC ---
 % cat test.i
unsigned short a, e;
int *b, *d;
int c;
extern int fn2();
void fn1 () {
  void *f;
  for (;;) {
fn2 ();
b = f;
e = 0;
for (; e < a; ++e)
  b[e] = d[e * c];
  }
}

 % gcc -O3 test.i
test.i: In function ‘fn1’:
test.i:5:6: internal compiler error: in vectorizable_load, at
tree-vect-stmts.c:4544
 void fn1 () {
  ^

[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

  Attachment #24234|0   |1
is obsolete||

--- Comment #10 from Ramana Radhakrishnan  
2012-05-02 06:51:12 UTC ---
Created attachment 27282
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27282
Rebased patch.


This patch originally by Richard Sandiford fixed PR target/48941 but the
problem was that lower-subreg was being a bit too aggressive with lowering
subreg moves in this case causing unnecessary spills to the stack. As shown in
my mail in the thread on lower-subreg.c the code generated is far better now
with this patch in play . I've rebased to trunk, double checked that the
generated files from the ml description match up and added a simple test that
makes sure that the original testcase from the PR doesn't emit a vector store
instruction ! That should be enough to catch all the cases that we worry about.
There are still a few vmov's between Vector registers but I suspect that is
because of the vcombine at the end for which RichardE might have something in
flight. For the record, this patch is not directly applicable to earlier
release branches as it depends on the new behaviour of lower-subreg.c which is
why this bug is only targeted at 4.8.0

[Bug c++/53184] Unnecessary anonymous namespace warnings

[orgads at gmail dot com]

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

--- Comment #2 from Orgad Shaneh  2012-05-02 06:56:28 
UTC ---
Anonymous types shouldn't produce any warnings. They are very commonly used in
headers needed for both C and C++ projects. The warning is meant for types
inside anonymous namespaces, which is not the case here.

Moreover, removing the volatile keyword resolves the warning. Why is that?