[Bug c/51712] New: -Wtype-limits should not trigger for types of implementation-defined signedness

[jrnieder at gmail dot com]

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

 Bug #: 51712
   Summary: -Wtype-limits should not trigger for types of
implementation-defined signedness
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jrnie...@gmail.com
CC: m...@gcc.gnu.org


Hi,

$ gcc -c -std=gnu99 -Wtype-limits -x c - <<-\EOF
enum test_enum {
FOO,
BAR
};

int valid(enum test_enum arg)
{
return arg >= FOO && arg <= BAR;
}
EOF
: In function ‘valid’:
:8:9: warning: comparison of unsigned expression >= 0 is always true
[-Wtype-limits]
$ 

Since C99 (WG14/N1256 p105, lang.decl.typespec.enum.4) only says:

Each enumerated type shall be compatible with char, a signed
integer type, or an unsigned integer type. The choice of type
is implementation-defined) but shall be capable of
representing the values of all the members of the enumeration.

the (arg >= FOO) test is not actually redundant. It would be nice to
automatically suppress the warning in this case.

What do you think? Feasible?

Originally reported as http://bugs.debian.org/615525

[Bug bootstrap/51686] "make install-strip-gcc" didn't install liblto-plugin* files

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-30
 Ever Confirmed|0   |1

--- Comment #2 from Andrew Pinski  2011-12-30 
06:36:06 UTC ---
Confirmed.

[Bug middle-end/51677] don't suggest giving main() __attribute__((const))

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-30
  Component|c   |middle-end
 Ever Confirmed|0   |1
   Severity|normal  |minor

--- Comment #1 from Andrew Pinski  2011-12-30 
06:34:55 UTC ---
Confirmed.

[Bug c/51676] -Wsuggest-attribute={pure,const} should give line number of declaration, not definition

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-12-30 
06:33:44 UTC ---
Not all places have both a definition and a declaration.  Also we merge the
definition and the declaration giving the DECL internally as just the
definition's location.

[Bug other/51662] Temporary objects gets garbage collected in cc1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011-12-30
 Ever Confirmed|0   |1

--- Comment #3 from Andrew Pinski  2011-12-30 
06:31:55 UTC ---
Waiting for a testcase.

[Bug c++/51666] NSDMI parse fails for template'd intializer

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  2011-12-30 
06:30:47 UTC ---
I bet a beer this is related to PR 57 (one of the most duplicated bugs in
bugzilla).  In fact the same work around fixes this testcase.  
Jason can you comment if DR 325 applies to NSDMI and not just default
arguments?

[Bug c++/51633] [c++0x] [4.6/4.7 Regression] ICE with invalid constexpr constructor

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2011-12-30 
06:20:47 UTC ---
(In reply to comment #1)
> By the way, calling these issues "Regression" doesn't seem appropriate:
> granted, 4.5 may have parsed some constrexpr usages, but didn't have any
> semantics implemented, could very hardly fail.

In the past we decided accepts invalid changing into an ICE is a regression
which is why this was considered a regression (I Can find the previous bug
reports that mention that).

[Bug bootstrap/51627] cannot compute suffix of object files mipsel

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011-12-30
 Ever Confirmed|0   |1

--- Comment #10 from Andrew Pinski  2011-12-30 
06:18:59 UTC ---
Are they really installed as mipsel-as/mipsel-ld/mipsel-nm and are in the
current path ?

[Bug c++/51625] -Wconversion should be on by default, or at least included in -Wall

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Andrew Pinski  2011-12-30 
06:17:21 UTC ---
Actually we document why we don't want this by default in that wiki page:
Why Wconversion is not enabled by -Wall or at least by -Wextra?

Implicit conversions are very common in C. This tied with the fact that there
is no data-flow in front-ends (see next question) results in hard to avoid
warnings for perfectly working and valid code. Wconversion is designed for a
niche of uses (security audits, porting 32 bit code to 64 bit, etc.) where the
programmer is willing to accept and workaround invalid warnings. Therefore, it
shouldn't be enabled if it is not explicitly requested.

[Bug c++/51625] -Wconversion should be on by default, or at least included in -Wall

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-12-30 
06:16:22 UTC ---
I don't we (GCC) want -Wconversion turned on by -Wall or by default.

See http://gcc.gnu.org/wiki/NewWconversion .

[Bug libstdc++/51711] regex.h contains incorrect code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-30
  Component|other   |libstdc++
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2011-12-30 
06:15:17 UTC ---
Still a bug on the trunk:
t.cc:8:21:   required from here
/home/pinskia/local-gcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/regex.h:2229:14:
error: could not convert ‘__result’ from ‘std::string {aka
std::basic_string}’ to ‘std::basic_string’

[Bug c++/51620] [c++0x] [4.6/4.7 Regression] ICE with private destructor

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-30
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2011-12-30 
06:12:08 UTC ---
Confirmed.

[Bug c++/51614] [4.6/4.7 Regression] ICE with ambiguous base class

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-30
 Ever Confirmed|0   |1

--- Comment #1 from Andrew Pinski  2011-12-30 
06:10:47 UTC ---
Confirmed.

[Bug tree-optimization/39621] Delaying operation to end of function causes high stack usage

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #4 from Andrew Pinski  2011-12-30 
06:08:28 UTC ---
Fixed on the trunk most likely by:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49749

[Bug other/51711] New: regex.h contains incorrect code

[ryanmolden at gmail dot com]

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

 Bug #: 51711
   Summary: regex.h contains incorrect code
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ryanmol...@gmail.com


The code in regex_replace looks like this

template 
inline basic_string<_Ch_type>
regex_replace(const basic_string<_Ch_type>& __s,
  const basic_regex<_Ch_type, _Rx_traits>& __e,
  const basic_string<_Ch_type>& __fmt,
  regex_constants::match_flag_type __flags,
  = regex_constants::match_default)
{
std::string __result;
regex_replace(std::back_inserter(__result),
  __s.begin(), __s.end(), __e, __fmt, __flags);
return __result;
}

However, the std::string is incorrect if you are attempting to use wstring and
wregex here (which should be allowed by all the other code which goes to pains
to use basic_string<_Ch_type>).

This code repros the bug:

#include 
#include 

int main(int argc, char **argv)
{
std::wstring toProcess(L"Bug\r\n");
std::wstring result = std::regex_replace(toProcess, std::wregex(L"\\r"),
std::wstring(L"\\r"));
return 0;
}

compiled with:

g++  -std=c++0x +Wall

In file included from /usr/include/c++/4.6/regex:62:0,
 from Test.cpp:1:
/usr/include/c++/4.6/bits/regex.h: In function std::basic_string<_Ch_type>
std::regex_replace(const std::basic_string<_Ch_type>&, const
std::basic_regex<_Ch_type, _Rx_traits>&, const std::basic_string<_Ch_type>&,
std::regex_constants::match_flag_type) [with _Rx_traits =
std::regex_traits, _Ch_type = wchar_t,
std::regex_constants::match_flag_type = std::bitset<11ul>]:
Test.cpp:7:96:   instantiated from here
/usr/include/c++/4.6/bits/regex.h:2225:14: error: could not convert __result
from std::string {aka std::basic_string} to std::basic_string

on Ubuntu 11.10 Server 64 bit edition with GCC 4.6.1

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #16 from Steve Kargl  
2011-12-30 04:01:52 UTC ---
On Thu, Dec 29, 2011 at 11:12:39PM +, redi at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> --- Comment #13 from Jonathan Wakely  2011-12-29 
> 23:12:39 UTC ---
> (In reply to comment #10)
> > I have no qualms with this.  If it does not support C++03, then
> > should advertise that it does.
> 
> (Assuming you meant should *not*) that's not very useful in practice.  If no
> headers anywhere in existence actually use 'export' then do you seriously 
> argue
> that no compiler should ever define __cplusplus == 199711L?

Yes, I meant 'not'.

Yes, if 'export' is not support, then __cplusplus should not be defined 
to indicate that g++ supports that standard.

I have no problem with -std=c++11 enabling C++11 features and evening
trying to apply a strict interpretation of C++11.  But, if g++ does
not support the entire language at 201103L, then it should not advertise
that it does.  

> > If this is the case, then it definitely should not advertise
> > that it does support C++11.
> 
> But pragmatically, it helps more users to do the Right Thing for what users 
> use
> and want.  Clearly we have a real problem here for FreeBSD, and should be 
> fixed
> by not defining __cplusplus==201103L or via fixincludes, but I maintain it was
> pretty silly to update headers to use bleeding edge features before checking 
> if
> they work with bleeding edge compilers.  Yes, GCC 4.7 might be bleeding edge,
> but so is [[noreturn]] support so not checking it works before using it is 
> just
> sloppy.

Given the area FreeBSD that Ed works on, I suspect it is supported by
at least one compiler.  

> (In reply to comment #11)
> > But this has nothing to do with FreeBSD specifically. It will apply to
> > basically any operating system in the future.
> > 
> > Say, GCC 4.8 (late 2012?) will support [[noreturn]] properly and some OS 
> > vendor
> > decides to start using it by the year 2016 in its header files. That will 
> > still
> > prevent you from compiling GCC 4.7 then, in case some piece of software 
> > depends
> > on it.
> 
> *ahem* It will prevent you using 4.7.0 20111229 (experimental) - this problem
> doesn't exist with any released version. We can get it fixed (FreeBSD is a
> primary platform after all, so this should be P2 or even P1) if we identify 
> the
> problem correctly.  I believe the right fix is fixincludes.  Feel free to keep
> arguing otherwise, but wherever the problem lies, it's not that libstdc++ uses
> C++11 features (note that libstdc++ only ever checks 
> __GXX_EXPERIMENTAL_CXX0X__
> so is agnostic about the value of __cplusplus)

Well, the correct fix is for g++ not to define __cplusplus as 201103L.
Or, the correct fix is for the g++ developers to implement [[noreturn]].
But, common sense, here a hack to make it work on FreeBSD.

2011-12-29  Steven G. Kargl  

* inclhack.def:  Disgusting hack to workaround brain damage of
defining __cplusplus as 201103L with -std=c++11 when g++ does
not support c++11.
* fixincl.x: regenerated.
* genfixes: Fix a version test.

Index: inclhack.def
===
--- inclhack.def(revision 182738)
+++ inclhack.def(working copy)
@@ -20,6 +20,21 @@ autogen definitions fixincl;
 FIXINC_DEBUG = yes;
 #endif

+/*
+ * g++ -std=c++11 defines __cplusplus to 201103L, which lies about
+ * the level of support g++ has for the C++11 standard.
+ */
+fix = {
+hackname  = cdef_cplusplus;
+mach  = "*-*-freebsd10.*";
+files = sys/cdefs.h;
+select= "[[noreturn]]";
+sed   = "s/[[noreturn]]/__dead2/";
+test_text = "#include ";
+};
+
+
+
 /* On AIX when _LARGE_FILES is defined stdio.h defines fopen to
  * fopen64 etc. and this causes problems when building with g++
  * because cstdio udefs everything from stdio.h, leaving us with
Index: fixincl.x
===
--- fixincl.x(revision 182738)
+++ fixincl.x(working copy)
@@ -2,11 +2,11 @@
  * 
  * DO NOT EDIT THIS FILE   (fixincl.x)
  * 
- * It has been AutoGen-ed  November  7, 2011 at 01:16:39 PM by AutoGen 5.10
+ * It has been AutoGen-ed  December 29, 2011 at 06:29:22 PM by AutoGen 5.12
  * From the definitionsinclhack.def
  * and the template file   fixincl
  */
-/* DO NOT SVN-MERGE THIS FILE, EITHER Mon Nov  7 13:16:39 EST 2011
+/* DO NOT SVN-MERGE THIS FILE, EITHER Thu Dec 29 18:29:22 PST 2011
  *
  * You must regenerate it.  Use the ./genfixes script.
  *
@@ -15,7 +15,7 @@
  * certain ANSI-incompatible system hea

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
   Severity|normal  |blocker

[Bug c++/51710] New: decltype and SFINAE

[solodon at mail dot com]

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

 Bug #: 51710
   Summary: decltype and SFINAE
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: solo...@mail.com


Hi,

I think the following code is well formed, but it fails to compile in g++ 4.6.1
and 4.5.2 (those that I had available). The code compiles in MS Visual C++
2010.

The problem is that decltype(foo(e1,e2)) in the result_type of enable_if below
fails the compilation instead of SFINAE.

#include 

/// Some meta-predicate on two types
template 
struct some_condition
{
enum { value = false }; // Change to true to see it compile
};

/// Class can only be instantiated when some_condition::value is true
template 
struct some_result_type
{
/// Just an expression that will only compile when E1 and E2 are such
int m[0-!some_condition::value];
};

/// This function doesn't have enable_if on it because 
/// I will only call it on the right types
template  
some_result_type foo(E1&& e1, E2&& e2)
{
return some_result_type();
} 

/// operator+ is overloaded for E1,E2 satisfying some_condition only
template  
inline auto operator+(E1&& e1, E2&& e2) 
-> typename std::enable_if<
   some_condition::value, // We check condition
   decltype(foo(e1,e2)) // but this part fails the compilation
   >::type 
{ 
return foo(std::forward(e1),std::forward(e2)); 
}

std::string my() { return "a"; }

void foo() 
{
// The operator+ above should be disabled on arguments of these types
// and regular addition of strings should be picked 
std::string result = "a" + my(); 
}

int main() { foo(); }

When I compile this program I get:

In instantiation of 'some_result_type >':
exp2.cpp: 53:39:   instantiated from here
exp2.cpp: 26:42: error: size of array is negative

My system is Windows 7 Professional, with g++ 4.6.1 coming from MinGW release
from 2011-11-18 and g++ 4.5.2 coming from an earlier MinGW release. Command
line used: g++.exe -Wall -m32 -time -O2 -std=c++0x -o "exp2" "exp2.cpp"

Thanks,
Yuriy

[Bug target/50749] SH Target: Post-increment addressing used only for first memory access

[kkojima at gcc dot gnu.org]

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

--- Comment #11 from Kazumoto Kojima  2011-12-30 
03:24:01 UTC ---
(In reply to comment #10)
> If OK, I'd like to change it from target PR to middle-end PR.

Sure.

[Bug target/51709] armv7 target is not using unaligned access to packed fields sometimes (halfwords, loads?)

[johnvb at broadcom dot com]

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

--- Comment #3 from John A. Van Boxtel  2011-12-30 
02:28:35 UTC ---
Created attachment 26203
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26203
gcc_armv7_unaligned_test.s

[Bug target/51709] armv7 target is not using unaligned access to packed fields sometimes (halfwords, loads?)

[johnvb at broadcom dot com]

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

--- Comment #2 from John A. Van Boxtel  2011-12-30 
02:27:51 UTC ---
Created attachment 26202
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26202
gcc_armv7_unaligned_test.i

[Bug target/51709] armv7 target is not using unaligned access to packed fields sometimes (halfwords, loads?)

[johnvb at broadcom dot com]

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

--- Comment #1 from John A. Van Boxtel  2011-12-30 
02:27:15 UTC ---
Created attachment 26201
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26201
gcc_armv7_unaligned_test.c

[Bug target/51709] New: armv7 target is not using unaligned access to packed fields sometimes (halfwords, loads?)

[johnvb at broadcom dot com]

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

 Bug #: 51709
   Summary: armv7 target is not using unaligned access to packed
fields sometimes (halfwords, loads?)
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joh...@broadcom.com


armv7 target is not always producing unaligned access to packed fields using
the appropriate half and full word instructions.  Rather sometimes it uses
bytes accesses with shifts and or's.

Below is a program which produces the problem:

typedef unsigned char  uint8;
typedef unsigned short uint16;
typedef unsigned int uint32;

#define HALFWORD 1
#define ADD_BYTE 0
#define PACKED 1

#if HALFWORD
#define FIELD_T uint16
#else
#define FIELD_T uint32
#endif

#if PACKED
#define PACKED_ATTRIBUTE __attribute__ ((packed))
#else
#define PACKED_ATTRIBUTE
#endif

typedef struct PACKED_ATTRIBUTE {
#if ADD_BYTE
uint8  field0;
#endif
FIELD_T field1;
FIELD_T field2;
} packed_struct_t;

typedef struct {
#if ADD_BYTE
uint8  field0;
#endif
FIELD_T field1;
FIELD_T field2;
} natural_struct_t;

void
test_function(natural_struct_t *natural, packed_struct_t *packed)
{
natural->field1 = packed->field1;
packed->field2 = natural->field2;
}

This produces

test_function:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrbr3, [r1, #1]@ zero_extendqisi2  @ tmp141,
ldrbip, [r1, #0]@ zero_extendqisi2  @ tmp140,* packed
orr r2, ip, r3, lsl #8  @, tmp143, tmp140, tmp141,
ldrhr3, [r0, #2]@, natural_3(D)->field2
strhr2, [r0, #0]@ movhi @ tmp143, natural_3(D)->field1
strhr3, [r1, #2]@ unaligned @ natural_3(D)->field2,
bx  lr  @
.size   test_function, .-test_function
.ident  "GCC: (Sourcery CodeBench Lite 2011.09-69) 4.6.1"

The load from the packed structure is decomposed to byte accesses but note the
stores are not.  Also if you try full words by changing the define HALFWORD the
generated code is as expected.  Adding a byte to the beginning of the packed
and natural structure by changing the define ADD_BYTE doesn't change the
results.  It appears to only be the half word load that is having the problem.  

Note in the above assembly output, that the @unaligned is missing from the load
though present on the store.  If you look at the assembly for the full word
compile, the @unaligned is present on both the load and store.

I claim this is a sometimes result because I have looked at cases in my more
complicated source and I can see that sometimes packed half word loads do not
use byte accesses.

[Bug target/50749] SH Target: Post-increment addressing used only for first memory access

[oleg.e...@t-online.de]

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

--- Comment #10 from Oleg Endo  2011-12-30 02:14:00 UTC 
---
(In reply to comment #9)
> (In reply to comment #8)
> > Specifying -fno-tree-forwprop doesn't seem to have any effect on these 
> > cases.
> 
> For that function, -fdump-tree-all shows that the tree loop ivopts
> optimization does it.  Try -fno-tree-forwprop -fno-ivopts.

This makes even worse code.
Anyway, I think this issue should be addressed by the auto_inc_dec pass.

If OK, I'd like to change it from target PR to middle-end PR.

[Bug target/51708] New: SH Target: SHAD / SHLD constant not CSE-ed

[oleg.e...@t-online.de]

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

 Bug #: 51708
   Summary: SH Target: SHAD / SHLD constant not CSE-ed
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
Target: sh*-*-*


If the shift amount is a constant for SHAD / SHLD insns it should be CSE-ed.
This could be done in a similar way as in the movnegt insn.
Example function:

int foo (int* a, int x, int n)
{
  int i;
  int count;

  for (i = 0; i < n; i ++)
count += (*(a + i) << 12);

  return count;
}

compiled with -m4 -O3:
cmp/pl  r6
bf  .L11
shll2   r6
add #-4,r6
shlr2   r6
add #1,r6
.L9:
mov.l   @r4+,r1
mov #12,r2! load constant in loop
dt  r6
shldr2,r1 ! use constant in loop
bf/s.L9
add r1,r0
.L11:
rts
nop


better:
cmp/pl  r6
bf  .L11
shll2   r6
add #-4,r6
shlr2   r6
add #1,r6
mov #12,r2! load constant before loop
.L9:
mov.l   @r4+,r1
dt  r6
shldr2,r1 ! use constant in loop
bf/s.L9
add r1,r0
.L11:
rts
nop

[Bug c++/51707] New: [c++11] constexpr constructor cannot initialize const reference member

[mg200 at uni dot brighton.ac.uk]

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

 Bug #: 51707
   Summary: [c++11] constexpr constructor cannot initialize const
reference member
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mg...@uni.brighton.ac.uk




struct S {
constexpr S() {}
};

struct T {
constexpr T(S const& s) : s{s} {}
S const& s;
};

constexpr S s {};
constexpr T t { s };



$ g++ -Wall -std=c++11 constexpr_ref_construct.cpp
constexpr_ref_construct.cpp: In constructor ‘constexpr T::T(const S&)’:
constexpr_ref_construct.cpp:6:34: internal compiler error: in
build_data_member_initialization, at cp/semantics.c:5788

Curiously everything works fine if instead of struct S we typedef S to be an
int (or any other intrinsic type).

[Bug fortran/49693] Spurious "unused-variable" warnings for COMMON block module variables.

[harald at klimachs dot de]

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

Harald Klimach  changed:

   What|Removed |Added

 CC||harald at klimachs dot de

--- Comment #2 from Harald Klimach  2011-12-30 
00:12:07 UTC ---
Just also want to confirm this, I get the same messages with the mpi module of
openmpi. And I wanted to add, that these messages even persist, if I use an
only clause in the use mpi statement.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #15 from Steve Kargl  
2011-12-29 23:55:20 UTC ---
On Thu, Dec 29, 2011 at 11:30:19PM +, ed at 80386 dot nl wrote:
> 
> But this discussion starts to turn into an infinite loop. Doesn't Bugzilla
> allow a bug reporter to unsubscribe? I trust you folks will get it sorted out
> eventually.
> 

Unfortunately, I believe as the original submitter of the bug
report, you cannot unsubscribe.   If this is the case, I'll
close this report and re-open a new report so that you are
subjected to the audit trail.

This appears to be a chicken-and-egg problem.  libstdc++ 
uses some portion of the subset of C++11 features supported
by g++, so it uses -std=c++11 during building.  This then
forces g++ to define __cplusplus, where upon any vendor with
more advance support for C++11 in their system headers will
be bitten.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[ed at 80386 dot nl]

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

--- Comment #14 from Ed Schouten  2011-12-29 23:30:19 UTC 
---
(In reply to comment #13)
> Feel free to keep
> arguing otherwise, but wherever the problem lies, it's not that libstdc++ uses
> C++11 features

Steve and I merely have our doubts about the current value of __cplusplus
during the compilation of libstdc++ -- not whether C++11 features are used
inside libstdc++.

But this discussion starts to turn into an infinite loop. Doesn't Bugzilla
allow a bug reporter to unsubscribe? I trust you folks will get it sorted out
eventually.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  2011-12-29 
23:12:39 UTC ---
(In reply to comment #10)
> I have no qualms with this.  If it does not support C++03, then
> should advertise that it does.

(Assuming you meant should *not*) that's not very useful in practice.  If no
headers anywhere in existence actually use 'export' then do you seriously argue
that no compiler should ever define __cplusplus == 199711L?

> If this is the case, then it definitely should not advertise
> that it does support C++11.

But pragmatically, it helps more users to do the Right Thing for what users use
and want.  Clearly we have a real problem here for FreeBSD, and should be fixed
by not defining __cplusplus==201103L or via fixincludes, but I maintain it was
pretty silly to update headers to use bleeding edge features before checking if
they work with bleeding edge compilers.  Yes, GCC 4.7 might be bleeding edge,
but so is [[noreturn]] support so not checking it works before using it is just
sloppy.

(In reply to comment #11)
> But this has nothing to do with FreeBSD specifically. It will apply to
> basically any operating system in the future.
> 
> Say, GCC 4.8 (late 2012?) will support [[noreturn]] properly and some OS 
> vendor
> decides to start using it by the year 2016 in its header files. That will 
> still
> prevent you from compiling GCC 4.7 then, in case some piece of software 
> depends
> on it.

*ahem* It will prevent you using 4.7.0 20111229 (experimental) - this problem
doesn't exist with any released version. We can get it fixed (FreeBSD is a
primary platform after all, so this should be P2 or even P1) if we identify the
problem correctly.  I believe the right fix is fixincludes.  Feel free to keep
arguing otherwise, but wherever the problem lies, it's not that libstdc++ uses
C++11 features (note that libstdc++ only ever checks __GXX_EXPERIMENTAL_CXX0X__
so is agnostic about the value of __cplusplus)

(In reply to comment #12)
> I do not see how one can draw the conclusion that it is sloppy
> engineering, when an OS vendor writes code that is properly
> protected:
> 
> #if defined(__cplusplus) && __cplusplus >= 201103L
> #define _Noreturn   [[noreturn]]
> #endif

Without testing if it actually works on relevant compilers? That's very sloppy.

Writing code based purely on (very recently published) specs without testing
that code is poor engineering.

> Building libstdc++ is using -std=c++11 ... 
> 
> > If your issue is with the value of __cplusplus, that's not set by 
> > libstdc++, so
> > I've set component=bootstrap.
> 
> which is causing __cplusplus to become defined.  This, then is, causing
> bootstrap to die in libstdc++ because the well-written code above has
> been decieved by the compiler.

As I said above, libstdc++ doesn't set or test the value of __cplusplus, so
it's not a libstdc++ problem.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl  
2011-12-29 23:05:25 UTC ---
On Thu, Dec 29, 2011 at 10:26:52PM +, redi at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> (In reply to comment #7)
> > Thanks for the condescending email.  Testing with GCC is 
> > exactly how the problem was found.  g++ is telling the
> > FreeBSD libc++ developers, 'Yes, I support C++11'.  The
> > FreeBSD libc++ developers are using C++11 features, and
> > implementing the required C++11 library support.  g++ chokes.
> 
> Yep, the problem exists, the problem was found by testing, and the problem
> needs to be fixed, but saying the problem is that libstdc++ uses C++11 
> features
> is silly.  Suggesting that testing should be done before updating libc headers
> is not condescending. Updating libc to use features supported by what? one,
> maybe two compilers?  and not even testing the latest version of GCC? that's
> just sloppy engineering.  Reporting failures caused by sloppy changes by 
> saying
> "C++11 support should not be used during its own compilation step" is silly.

I do not see how one can draw the conclusion that it is sloppy
engineering, when an OS vendor writes code that is properly
protected:

#if defined(__cplusplus) && __cplusplus >= 201103L
#define _Noreturn   [[noreturn]]
#endif

Building libstdc++ is using -std=c++11 ... 

> If your issue is with the value of __cplusplus, that's not set by libstdc++, 
> so
> I've set component=bootstrap.

which is causing __cplusplus to become defined.  This, then is, causing
bootstrap to die in libstdc++ because the well-written code above has
been decieved by the compiler.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[ed at 80386 dot nl]

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

--- Comment #11 from Ed Schouten  2011-12-29 22:40:26 UTC 
---
But this has nothing to do with FreeBSD specifically. It will apply to
basically any operating system in the future.

Say, GCC 4.8 (late 2012?) will support [[noreturn]] properly and some OS vendor
decides to start using it by the year 2016 in its header files. That will still
prevent you from compiling GCC 4.7 then, in case some piece of software depends
on it. In the year 2016, OS vendors will simply expect they can do the
following without causing any negative side-effects.

#if defined(__STDC__) && __STDC_VERSION__ >= 201112L
_Noreturn
#if defined(__cplusplus) && __cplusplus >= 201103L
[[noreturn]]
#endif
void exit(int);

Simply because C++11 is the standard that introduced it.

I _really_ think you guys are doing a good job with C++11 and there's _nothing_
wrong with the compiler. The issue is that forcing the compiler to expose C++11
support during its own compilation phase is not conservative.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  
2011-12-29 22:29:55 UTC ---
On Thu, Dec 29, 2011 at 10:21:35PM +, chris at bubblescope dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> --- Comment #8 from Chris Jefferson  2011-12-29 
> 22:21:35 UTC ---
> (In reply to comment #4)
> > On Thu, Dec 29, 2011 at 08:56:20PM +, chris at bubblescope dot net 
> > wrote:
> > > Better take out C++03 support as well, seeing as there is no support for 
> > > the
> > > 'export' keyword.
> > > 
> > > But seriously, the C++11 support is as complete as any other compiler, 
> > > and in
> > > common usage. Further, parts of libstdc++ need to be built in C++0x mode.
> > > 
> > 
> > Please, re-read Ed's comment #2.  g++ is telling the
> > OS that "yes, I support C++11", when in fact it does 
> > not.  For me, this means I can no longer work on
> > gfortran until some work-around is in place to avoid
> > this bug in g++.
> 
> Please read my comment.

I did.

> You could make the same argument that using g++ should not report
> as supporting C++03, as it does not support the 'export' keyword
> and you could use this in headers.

I have no qualms with this.  If it does not support C++03, then
should advertise that it does.

> It is likely to be a very long time until g++ supports every
> single corner case of C++11.  Based on our experience with C++03,
> it may never happen.

If this is the case, then it definitely should not advertise
that it does support C++11.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target||*-*-freebsd
  Component|libstdc++   |bootstrap
Version|unknown |4.7.0
Summary|Build infrastructure should |FreeBSD uses unsupported
   |not use -std=c++0x until|C++11 features when
   |g++ properly supports it|__cplusplus == 201103L

--- Comment #9 from Jonathan Wakely  2011-12-29 
22:26:52 UTC ---
(In reply to comment #7)
> Thanks for the condescending email.  Testing with GCC is 
> exactly how the problem was found.  g++ is telling the
> FreeBSD libc++ developers, 'Yes, I support C++11'.  The
> FreeBSD libc++ developers are using C++11 features, and
> implementing the required C++11 library support.  g++ chokes.

Yep, the problem exists, the problem was found by testing, and the problem
needs to be fixed, but saying the problem is that libstdc++ uses C++11 features
is silly.  Suggesting that testing should be done before updating libc headers
is not condescending. Updating libc to use features supported by what? one,
maybe two compilers?  and not even testing the latest version of GCC? that's
just sloppy engineering.  Reporting failures caused by sloppy changes by saying
"C++11 support should not be used during its own compilation step" is silly.

If you're going to add support for bleeding edge language features then test
with a bleeding edge compiler. Not doing so is just silly.

Test the changes, report problems, resolve the problem, then commit the
changes.  Just making the changes and claiming there's a bug in libstdc++...
That's sloppy.

If your issue is with the value of __cplusplus, that's not set by libstdc++, so
I've set component=bootstrap.

Please follow the bug reporting guidelines at http://gcc.gnu.org/bugs/ and
describe the problem fully (e.g. version=4.7.0, target=*-*-freebsd), so a
FreeBSD maintainer has enough info to update fixincludes to fix it.

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[chris at bubblescope dot net]

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

--- Comment #8 from Chris Jefferson  2011-12-29 
22:21:35 UTC ---
(In reply to comment #4)
> On Thu, Dec 29, 2011 at 08:56:20PM +, chris at bubblescope dot net wrote:
> > Better take out C++03 support as well, seeing as there is no support for the
> > 'export' keyword.
> > 
> > But seriously, the C++11 support is as complete as any other compiler, and 
> > in
> > common usage. Further, parts of libstdc++ need to be built in C++0x mode.
> > 
> 
> Please, re-read Ed's comment #2.  g++ is telling the
> OS that "yes, I support C++11", when in fact it does 
> not.  For me, this means I can no longer work on
> gfortran until some work-around is in place to avoid
> this bug in g++.

Please read my comment.

You could make the same argument that using g++ should not report as supporting
C++03, as it does not support the 'export' keyword and you could use this in
headers.

It is likely to be a very long time until g++ supports every single corner case
of C++11. Based on our experience with C++03, it may never happen.

[Bug c++/51706] New: default copy assignment incorrectly deleted

[b.r.longbons at gmail dot com]

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

 Bug #: 51706
   Summary: default copy assignment incorrectly deleted
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 26200
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26200
minimal testcase

If a move constructor is defined, then the copy assignment operator is deleted,
even if a copy constructor is defined.

In the n3092 draft, it is:
12.8 "Copying and moving class objects" [class.copy], paragraphs 20,25
which doesn't say move constructors should affect copy assignment.

(Background: I used "= default" on my copy and move constructors to work around
a bug in GCC 4.6)

testcase also at http://ideone.com/U1nvV

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  
2011-12-29 22:06:59 UTC ---
On Thu, Dec 29, 2011 at 09:39:12PM +, redi at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> --- Comment #5 from Jonathan Wakely  2011-12-29 
> 21:39:12 UTC ---
> So change component to 'bootstrap' and get a FreeBSD maintainer to
> update fixincludes and/or tell the FreeBSD libc team to test with
> esoteric third-party compilers such as the little-known GCC before
> making such changes

Thanks for the condescending email.  Testing with GCC is 
exactly how the problem was found.  g++ is telling the
FreeBSD libc++ developers, 'Yes, I support C++11'.  The
FreeBSD libc++ developers are using C++11 features, and
implementing the required C++11 library support.  g++ chokes.

I personally could not care less about C++; until it 
makes it much more difficult for me to work on gfortran. 

(Ed, I'm sorry I asked you to submit a bug.  I can
understand your reluctance.)

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[ed at 80386 dot nl]

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

--- Comment #6 from Ed Schouten  2011-12-29 21:59:38 UTC ---
(In reply to comment #5)
> So change component to 'bootstrap' and get a FreeBSD maintainer to update
> fixincludes and/or tell the FreeBSD libc team to test with esoteric 
> third-party
> compilers such as the little-known GCC before making such changes

This problem only in combination with GCC 4.7, which is unreleased. From my
point of view, an unreleased version of GCC _is_ an esoteric third-party
little-known compiler.

[Bug libstdc++/51608] [4.7 Regression][C++11] Unordered containers end(size_type) isn't constant time

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Paolo Carlini  2011-12-29 
21:45:42 UTC ---
Fixed.

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-12-29 
21:39:12 UTC ---
So change component to 'bootstrap' and get a FreeBSD maintainer to update
fixincludes and/or tell the FreeBSD libc team to test with esoteric third-party
compilers such as the little-known GCC before making such changes

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  
2011-12-29 21:27:18 UTC ---
On Thu, Dec 29, 2011 at 08:56:20PM +, chris at bubblescope dot net wrote:
> Better take out C++03 support as well, seeing as there is no support for the
> 'export' keyword.
> 
> But seriously, the C++11 support is as complete as any other compiler, and in
> common usage. Further, parts of libstdc++ need to be built in C++0x mode.
> 

Please, re-read Ed's comment #2.  g++ is telling the
OS that "yes, I support C++11", when in fact it does 
not.  For me, this means I can no longer work on
gfortran until some work-around is in place to avoid
this bug in g++.

[Bug rtl-optimization/51623] PowerPC section type conflict

[meissner at gcc dot gnu.org]

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

--- Comment #5 from Michael Meissner  2011-12-29 
21:13:15 UTC ---
Author: meissner
Date: Thu Dec 29 21:13:10 2011
New Revision: 182731

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182731
Log:
Update PR 51623, to eliminate checks against being in the text section.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[chris at bubblescope dot net]

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

Chris Jefferson  changed:

   What|Removed |Added

 CC||chris at bubblescope dot
   ||net

--- Comment #3 from Chris Jefferson  2011-12-29 
20:56:20 UTC ---
Better take out C++03 support as well, seeing as there is no support for the
'export' keyword.

But seriously, the C++11 support is as complete as any other compiler, and in
common usage. Further, parts of libstdc++ need to be built in C++0x mode.

[Bug c++/51214] [C++11] name lookup issue with c++11 enums

[fabien at gcc dot gnu.org]

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

--- Comment #1 from fabien at gcc dot gnu.org 2011-12-29 20:02:15 UTC ---
Here is a correct testcase for this bug.

// { dg-do compile }
// { dg-options "-std=c++0x" }

enum { A = 1 };
struct T
{
int i1, i2, i3, i4, i5, i6, i7;
enum E2 : int;
};

enum T::E2 : int { A1 = A };
int i = T::A1;

[Bug tree-optimization/51704] [4.7 Regression] ICE: vector VEC(vec_void_p,base) index domain error, in vinfo_for_stmt at tree-vectorizer.h:620 with -O3 -fno-tree-copy-prop -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-29
 CC||jakub at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2011-12-29 
19:55:58 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173856

[Bug tree-optimization/51704] [4.7 Regression] ICE: vector VEC(vec_void_p,base) index domain error, in vinfo_for_stmt at tree-vectorizer.h:620 with -O3 -fno-tree-copy-prop -fno-tree-fre

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[ed at 80386 dot nl]

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

--- Comment #2 from Ed Schouten  2011-12-29 19:42:12 UTC ---
Well, there is the difference. g++ may support C++11 constructs and libstdc++
should be able to use them, but it's wrong to announce __cplusplus == 201103L
to the operating system's headers until it actually does support C++11.

But it could well be the case that changing fixincludes to do the right thing
is sufficient.

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-12-29 
19:34:31 UTC ---
(In reply to comment #0)
> Essentially GCC is free to announce __cplusplus == 201103L for its 
> experimental
> C++11 support, but the C++11 support should not be used during its own
> compilation step if it's not finished yet.

How should files needed for that C++11 support be compiled then?

It needs to be used to compile e.g. src/thread.cc which defines the functions
declared in the C++11 header 

Until attributes are supported I think this should be dealt with by removing
[[noreturn]] using fixincludes.

[Bug libstdc++/51705] New: Build infrastructure should not use -std=c++0x until g++ properly supports it

[ed at 80386 dot nl]

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

 Bug #: 51705
   Summary: Build infrastructure should not use -std=c++0x until
g++ properly supports it
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: e...@80386.nl


FreeBSD recently added support for C11 and C++11 keywords to its sys/cdefs.h
file. This header file is used by FreeBSD header files and source code to write
code that is portable across different compiler versions.

GCC 4.7's build system adds -std=c++0x to the compiler to build libstdc++. This
means that code is built with __cplusplus == 201103L. This is wrong, because
now sys/cdefs.h starts to use C++11 constructs such as [[noreturn]].
[[noreturn]] is not supported by GCC yet.

Essentially GCC is free to announce __cplusplus == 201103L for its experimental
C++11 support, but the C++11 support should not be used during its own
compilation step if it's not finished yet.

Alternatively, this could be fixed by simply implementing [[noreturn]], of
course, but that's a different issue altogether.

[Bug testsuite/50988] gcc.target/powerpc/*: Several tests fail incorrectly on powerpc-linux-gnuspe

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #4 from Michael Meissner  2011-12-29 
19:01:40 UTC ---
I decided to go ahead, and just commit the changes.  Reopen the bug if it does
not fix it for your system.  Change committed in subversion id 182728.

[Bug tree-optimization/51704] New: [4.7 Regression] ICE: vector VEC(vec_void_p,base) index domain error, in vinfo_for_stmt at tree-vectorizer.h:620 with -O3 -fno-tree-copy-prop -fno-tree-fre

[zsojka at seznam dot cz]

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

 Bug #: 51704
   Summary: [4.7 Regression] ICE: vector VEC(vec_void_p,base)
index domain error, in vinfo_for_stmt at
tree-vectorizer.h:620 with -O3 -fno-tree-copy-prop
-fno-tree-fre
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O3 -fno-tree-copy-prop -fno-tree-fre
testsuite/gfortran.dg/inline_sum_1.f90
testsuite/gfortran.dg/inline_sum_1.f90: In function 'MAIN__':
testsuite/gfortran.dg/inline_sum_1.f90:14:0: internal compiler error: vector
VEC(vec_void_p,base) index domain error, in vinfo_for_stmt at
tree-vectorizer.h:620
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  internal_error (gmsgid=0x1526a70 "vector %s %s domain error, in %s at
%s:%u") at /mnt/svn/gcc-trunk/gcc/diagnostic.c:839
#1  0x012226c9 in vec_assert_fail (op=0x14e80a0 "index",
struct_name=0x132b3ef "VEC(vec_void_p,base)", file=, line=620, 
function=0x132ef3a "vinfo_for_stmt") at /mnt/svn/gcc-trunk/gcc/vec.c:517
#2  0x00bfdff7 in VEC_vec_void_p_base_index (ix_=,
vec_=, file_=, line_=, 
function_=) at /mnt/svn/gcc-trunk/gcc/tree-vectorizer.h:603
#3  vinfo_for_stmt (stmt=) at
/mnt/svn/gcc-trunk/gcc/tree-vectorizer.h:620
#4  vect_detect_hybrid_slp_stmts (node=0x1b217d0) at
/mnt/svn/gcc-trunk/gcc/tree-vect-slp.c:1740
#5  0x00bfe61e in vect_detect_hybrid_slp (loop_vinfo=)
at /mnt/svn/gcc-trunk/gcc/tree-vect-slp.c:1770
#6  0x00bf3b55 in vect_analyze_loop_2 (loop_vinfo=) at
/mnt/svn/gcc-trunk/gcc/tree-vect-loop.c:1610
#7  vect_analyze_loop (loop=0x759d4550) at
/mnt/svn/gcc-trunk/gcc/tree-vect-loop.c:1667
#8  0x00c02ef7 in vectorize_loops () at
/mnt/svn/gcc-trunk/gcc/tree-vectorizer.c:203
#9  0x00960335 in execute_one_pass (pass=0x1842ba0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2080
#10 0x009606d5 in execute_pass_list (pass=0x1842ba0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2135
#11 0x009606e7 in execute_pass_list (pass=0x1842d80) at
/mnt/svn/gcc-trunk/gcc/passes.c:2136
#12 0x009606e7 in execute_pass_list (pass=0x1842000) at
/mnt/svn/gcc-trunk/gcc/passes.c:2136
#13 0x00ac16ae in tree_rest_of_compilation (fndecl=0x75bb5100) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:421
#14 0x0071715a in cgraph_expand_function (node=0x75a95c60) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1818
#15 0x00718efc in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1885
#16 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2198
#17 0x0071966a in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1327
#18 0x0090aa8d in write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/langhooks.c:303
#19 0x00a54dec in compile_file () at
/mnt/svn/gcc-trunk/gcc/toplev.c:573
#20 do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1935
#21 toplev_main (argc=16, argv=0x7fffd928) at
/mnt/svn/gcc-trunk/gcc/toplev.c:2011
#22 0x761cc09d in __libc_start_main () from /lib64/libc.so.6
#23 0x005833f1 in _start ()

Tested revisions:
r182703 - crash
4.6 r180325 - OK

[Bug libstdc++/51608] [4.7 Regression][C++11] Unordered containers end(size_type) isn't constant time

[fdumont at gcc dot gnu.org]

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

--- Comment #1 from François Dumont  2011-12-29 
17:58:57 UTC ---
Author: fdumont
Date: Thu Dec 29 17:58:51 2011
New Revision: 182727

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182727
Log:
2011-12-29  François Dumont 

PR libstdc++/51608
* include/bits/hashtable_policy.h (_Equal_helper<>): New, change the
way the _Equal functor is used depending on whether hash code is
cached or not.
(_Ebo_helper<>): New helper type to introduce EBO when possible.
(_Hash_code_base): Use _Ebo_helper to limit memory footprint. Move
_Equal functor management...
(_Hashtable_base): ...here, new, use _Equal_helper.
(_Local_iterator_base<>, _Locale_iterator<>, _Locale_const_iterator<>):
New, use _Hash_code_base, implementation of...
* include/bits/hashtable.h (_Hashtable<>::local_iterator,
_Hashtable<>::const_local_iterator): ...those. Add static assertions
checking that some functors are empty depending on whether hash code
is cache or not.
(_Hashtable<>::_M_bucket_index): New overloads using current bucket
count, use through out the _Hastable<> implementation.
* include/bits/unordered_set.h (__unordered_set<>,
__unordered_multiset<>): Cache hash code iff hash functor is not
empty and not final.
* include/bits/unordered_map.h (__unordered_map<>,
__unordered_multimap<>): Likewise.
* include/debug/unordered_map
(unordered_map<>::_S_to_local, unordered_multimap<>::_S_to_local):
Adapt to match new local iterator implementation.
* include/debug/unordered_set (unordered_set<>::_S_to_local,
unordered_multiset<>::_S_to_local): Likewise.
* include/profile/unordered_map (unordered_map<>::_M_profile_destruct,
unordered_multimap<>::_M_profile_destruct): Enhance thanks to usage of
local iterators.
* include/profile/unordered_set (unordered_set<>::_M_profile_destruct,
unordered_multiset<>::_M_profile_destruct): Likewise.
* testsuite_files/23_containers/unordered_set/instantiation_neg.cc:
Fix error line.
* testsuite_files/23_containers/unordered_set/final_hash.cc: New.
* testsuite_files/23_containers/unordered_multiset/final_hash.cc: New.
* testsuite_files/23_containers/unordered_map/final_hash.cc: New.
* testsuite_files/23_containers/unordered_multimap/final_hash.cc: New.

Added:
trunk/libstdc++-v3/testsuite/23_containers/unordered_map/final_hash.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/final_hash.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/final_hash.cc
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/final_hash.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/hashtable.h
trunk/libstdc++-v3/include/bits/hashtable_policy.h
trunk/libstdc++-v3/include/bits/unordered_map.h
trunk/libstdc++-v3/include/bits/unordered_set.h
trunk/libstdc++-v3/include/debug/unordered_map
trunk/libstdc++-v3/include/debug/unordered_set
trunk/libstdc++-v3/include/profile/unordered_map
trunk/libstdc++-v3/include/profile/unordered_set
   
trunk/libstdc++-v3/testsuite/23_containers/unordered_set/instantiation_neg.cc

[Bug fortran/51569] documentation on sign intrinsic

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org 2011-12-29 17:55:09 UTC ---
(In reply to comment #2)
> -0.0 does not exist in Fortran except when using the IEEE module IIRC.

Nope.  The IEEE module is not necessary.  Negative zero falls into
the wonderful world of processor-dependent behavior.

Fortran 2003, 1.6.1:

(3) If the processor can distinguish between positive and negative
real zero, this standard requires different returned values for
ATAN2(Y,X) when X < 0 and Y is negative real zero and for LOG(X)
and SQRT(X) when X is complex with REAL(X) < 0 and negative zero
imaginary part.

Fortran 2003, 1.6.3:

(5) If the processor can distinguish between positive and negative
real zero, the behavior of the SIGN intrinsic function when the
second argument is negative real zero is changed by this
standard.

Fortran 2003, 4.4.2:

The real type includes a zero value.  Processors that distinguish
between positive and negative zeros shall treat them as equivalent
(1)  in all relational operations,
(2)  as actual arguments to intrinsic procedures other than
 those for which it is explicitly specified that negative
 zero is distinguished, and
(3)  as the scalar-numeric-expr in an arithmetic IF.

I've read gfortan's description for SIGN(), and IMHO, there is
nothing to change.

[Bug testsuite/51703] New: FAIL: gfortran.dg/io_real_boz_[345].f90 -O (test for excess errors)

[danglin at gcc dot gnu.org]

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

 Bug #: 51703
   Summary: FAIL: gfortran.dg/io_real_boz_[345].f90  -O  (test for
excess errors)
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dang...@gcc.gnu.org
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu


Executing on host:
/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortr
an -B/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/home/dave/gnu/gc
c/objdir/hppa-linux-gnu/./libgfortran/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfor
tran.dg/io_real_boz_3.f90-O  -std=f2008 
-B/home/dave/gnu/gcc/objdir/hppa-li
nux-gnu/./libgfortran/.libs
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfor
tran/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs  -lm  
 -o ./io_real_boz_3.exe(timeout = 300)
spawn /home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/home/da
ve/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/home/dave/gnu/gcc/objdir/hppa
-linux-gnu/./libgfortran/
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/io_re
al_boz_3.f90 -O -std=f2008
-B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfort
ran/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs
-L/home
/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs -lm -o
./io_real_boz_3.e
xe
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/io_real_boz_3.f90:12.17:

   x = 1.0_16 + 2.0_16**(-105)
 1
Error: Invalid real kind 16 at (1)
compiler exited with status 1
output is:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/io_real_boz_3.f90:12.17:

   x = 1.0_16 + 2.0_16**(-105)
 1
Error: Invalid real kind 16 at (1)

FAIL: gfortran.dg/io_real_boz_3.f90  -O  (test for excess errors)
Excess errors:
/home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/io_real_boz_3.f90:12:17:
Error: Invalid real kind 16 at (1)

UNRESOLVED: gfortran.dg/io_real_boz_3.f90  -O  compilation failed to produce
executable

Target doesn't support real kind 16.

[Bug testsuite/51702] Several of the vector tests in gcc.dg fail on powerpc-linux in 32-bit mode

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #1 from Michael Meissner  2011-12-29 
17:49:06 UTC ---
Fixed in subversion revision 182726.

[Bug testsuite/51702] New: Several of the vector tests in gcc.dg fail on powerpc-linux in 32-bit mode

[meissner at gcc dot gnu.org]

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

 Bug #: 51702
   Summary: Several of the vector tests in gcc.dg fail on
powerpc-linux in 32-bit mode
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: meiss...@gcc.gnu.org
ReportedBy: meiss...@gcc.gnu.org
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux


Several of the tests in gcc.dg get an extra warning when run on 32-bit
powerpc-linux systems, which causes the test to fail.  The cause is these tests
are testing the machine independent vector support, and the compiler issues a
warning message about passing vectors by value, because the Altivec ABI is not
enabled.  Adding -mabi=altivec for the tests, enables them to pass.

[Bug libstdc++/51701] Remove reference to Henry Suter's RWLock from documentation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  2011-12-29 
15:43:28 UTC ---
done

[Bug libstdc++/51701] Remove reference to Henry Suter's RWLock from documentation

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-12-29 
15:41:45 UTC ---
Author: redi
Date: Thu Dec 29 15:41:37 2011
New Revision: 182724

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182724
Log:
PR libstdc++/51701
* doc/xml/manual/extensions.xml (Input and Output): Remove reference
to RWLock class.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/extensions.xml

[Bug libstdc++/51701] Remove reference to Henry Suter's RWLock from documentation

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-12-29 
15:31:05 UTC ---
For the record the code can be found at
http://web.archive.org/web/20070810183256/http://suter.home.cern.ch/suter/RWLock.html
but I agree that referring to it from the libstdc++ manual isn't very useful

[Bug libstdc++/51699] Clang refuses to compile ext/rope citing scope resolution issues

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  2011-12-29 
15:22:08 UTC ---
If you have the time, seems indeed a good idea.

[Bug libstdc++/51701] Remove reference to Henry Suter's RWLock from documentation

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/51699] Clang refuses to compile ext/rope citing scope resolution issues

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-12-29 
15:08:09 UTC ---
I'm tempted to backport the library fixes, as I've been frustrated by
http://bugzilla.redhat.com/show_bug.cgi?id=702256 and would like to see a
working combination of clang and libstdc++ in F17

[Bug libstdc++/51699] Clang refuses to compile ext/rope citing scope resolution issues

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2011-12-29 
14:54:18 UTC ---
Oh very well, thanks Jon, indeed now I remember that work.

[Bug libstdc++/51701] New: Remove reference to Henry Suter's RWLock from documentation

[jb at gcc dot gnu.org]

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

 Bug #: 51701
   Summary: Remove reference to Henry Suter's RWLock from
documentation
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


In the libstdc++ manual at

http://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_io.html

it says "If you want to access a filebuf's file descriptor to implement file
locking (e.g. using the fcntl() system call) then you might be interested in
Henry Suter's RWLock class. "

There are a couple issues with this RWLock class:

- The code has apparently disappeared from the internet, I was able to locate
it only via the Wayback machine.

- Having looked at the code, it is racy and wrong: 

1) For the code to operate correctly, opening a file and reading and writing
stuff from that file would need to be atomic. No target I'm aware of provides
such a guarantee.

2) It leaks memory; RWLockFileName is not deleted in the destructor.


Thus, I suggest that the sentence I quoted above should be removed.

[Bug c++/24163] dependent Base class scope examined during unqualified name lookup in template

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||fedorabugmail at yahoo dot
   ||com

--- Comment #10 from Jonathan Wakely  2011-12-29 
14:45:14 UTC ---
*** Bug 51699 has been marked as a duplicate of this bug. ***

[Bug libstdc++/51699] Clang refuses to compile ext/rope citing scope resolution issues

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Jonathan Wakely  2011-12-29 
14:45:14 UTC ---
the rope code has already been fixed in trunk by Jason when he fixed the G++
lookup bug

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

[Bug libstdc++/51699] Clang refuses to compile ext/rope citing scope resolution issues

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-12-29 
14:35:18 UTC ---
I think there is a front-end bug about this, I'll try to find it.
I've encountered it myself when compiling code with Clang and needed to fix
code that G++ accepts in order to find names in dependent base classes

[Bug c++/51700] Cannot subscript packed vector type in g++ (works in C)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Paolo Carlini  2011-12-29 
10:31:30 UTC ---
Yes, thanks.

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

[Bug c++/51033] generic vector subscript and shuffle support was not added to C++

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||nicholasbishop at gmail dot
   ||com

--- Comment #9 from Paolo Carlini  2011-12-29 
10:31:30 UTC ---
*** Bug 51700 has been marked as a duplicate of this bug. ***

[Bug c++/51700] Cannot subscript packed vector type in g++ (works in C)

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #1 from Marc Glisse  2011-12-29 
10:16:38 UTC ---
Dup of Bug 51033 ?

[Bug libstdc++/51699] Clang refuses to compile ext/rope citing scope resolution issues

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2011-12-29 
10:15:31 UTC ---
Unfortunately rope is largely unmaintained. Assuming these issues are easy to
handle somebody with access to clang should do the work.

Note: before touching the library at all, the C++ issue should be analyzed in
detail, make sure we have a Bugzilla open for it, etc, it doesn't really make
sense blindly "fixing" the library for the benefit of another compiler without
being able to double check what is going on with GCC. Is there a Bugzilla open
for the C++ front-end issue? Otherwise, can you please open one?

[Bug c++/51700] New: Cannot subscript packed vector type in g++ (works in C)

[nicholasbishop at gmail dot com]

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

 Bug #: 51700
   Summary: Cannot subscript packed vector type in g++ (works in
C)
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nicholasbis...@gmail.com


Example code (full program):

typedef int v4si __attribute__ ((vector_size (16)));
int main() {
v4si x;
x[0] = 33;
return 0;
}

Compiling with gcc produces a working program and no console output, but g++
complains:
$ gcc -Wall -Wextra vecbug.c 
$ g++ -Wall -Wextra vecbug.c 
vecbug.c: In function ‘int main()’:
vecbug.c:4:5: error: invalid types ‘v4si {aka __vector(4) int}[int]’ for array
subscript

Verbose output:
$ g++ -v -Wall -Wextra vecbug.c

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 
COLLECT_GCC_OPTIONS='-v' '-Wall' '-Wextra' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.6.1/cc1plus -quiet -v -imultilib . -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE vecbug.c -quiet -dumpbase vecbug.c
-mtune=generic -march=x86-64 -auxbase vecbug -Wall -Wextra -version
-fstack-protector -o /tmp/ccNwRhl7.s
GNU C++ (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (x86_64-linux-gnu)
compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.6
 /usr/include/c++/4.6/x86_64-linux-gnu/.
 /usr/include/c++/4.6/backward
 /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.6.1/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++ (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (x86_64-linux-gnu)
compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 63a745aba0054d1605090177d8e4bbb4
vecbug.c: In function ‘int main()’:
vecbug.c:4:5: error: invalid types ‘v4si {aka __vector(4) int}[int]’ for array
subscript

[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-12-29
   Target Milestone|--- |4.7.0
 Ever Confirmed|0   |1

--- Comment #2 from Uros Bizjak  2011-12-29 08:12:42 
UTC ---
Confirmed [1].

[1] http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg02739.html