[Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  2011-10-22 
08:10:45 UTC ---
Updated patch:

http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02003.html

[Bug c++/50810] c++0x-compat does not warn about narrowing conversions

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #7 from Paolo Carlini  2011-10-22 
09:18:12 UTC ---
Ok, thanks a lot Manuel and Jason, I can do this.

[Bug c++/29948] G++ OOM's when compiling kmail

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #5 from Manuel López-Ibáñez  2011-10-22 
11:49:48 UTC ---
4.1 is just too old, and this issue is too vague to be able to identify if
there is a problem at all, or g++ just needs that amount of memory. Sorry, I am
closing this. If you can  isolate a single file that makes g++ suddenly
increase memory without apparent limit, you may try generating a reduced
preprocessed testcase: http://gcc.gnu.org/bugs/#need and reopen this.

[Bug c++/33801] Missing warning: "type qualifiers are meaningless in this declaration"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

Summary|Missing warning |Missing warning: "type
   ||qualifiers are meaningless
   ||in this declaration"

--- Comment #5 from Manuel López-Ibáñez  2011-10-22 
12:07:48 UTC ---
What is the difference between this and this testcase:

typedef const double* const_double; 
void foo(const const_double);

Neither C nor C++ warn here with -Wall -Wextra. Clang neither warns in the
original testcase. I don't see how the const can hurt.

Anyway, adding a better description...

[Bug tree-optimization/50730] SLP vectorization confused by unrelated DRs

[irar at il dot ibm.com]

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

--- Comment #3 from Ira Rosen  2011-10-22 12:09:30 UTC 
---
(In reply to comment #2)
> First blush, looks like something could be abstracted as a function or a
> macro?!?

Hmm, I don't know. There is a 'continue' there...

[Bug c++/39478] please improve recursive template instantiation diagnostics

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011-10-22
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  2011-10-22 
12:16:25 UTC ---
I am sorry, but I don't understand what you are asking for. What kind of
message would you find more useful here?

Clang prints a similar error:

/tmp/webcompile/_25526_0.cc:11:14: error: field has incomplete type
'foo >'
  foo< bar > p;
 ^
/tmp/webcompile/_25526_0.cc:4:12: note: in instantiation of template class
'bar' requested here
  typename T::type dummy();
   ^
/tmp/webcompile/_25526_0.cc:14:19: note: in instantiation of template class
'foo >' requested here
foo< bar< int > > x;
  ^
/tmp/webcompile/_25526_0.cc:2:8: note: definition of 'foo >' is not
complete until the closing '}'
struct foo
   ^

but the last message seems even more confusing.

[Bug tree-optimization/50819] missed SLP vectorization

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-10-22
 CC||irar at il dot ibm.com
 AssignedTo|unassigned at gcc dot   |irar at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Ira Rosen  2011-10-22 12:25:30 UTC 
---
SLP data dependence analysis checks that all the loads are before all the
stores in the basic block, and for sum1 we get

  res_4(D)->theX = D.2306_31;
  D.2305_32 = res_4(D)->theY;
  D.2303_34 = D.2289_26 + D.2305_32;
  res_4(D)->theY = D.2303_34;
  D.2302_35 = res_4(D)->theZ;
  D.2300_37 = D.2287_24 + D.2302_35;
  res_4(D)->theZ = D.2300_37;
  D.2299_38 = res_4(D)->theT;
  D.2297_40 = D.2285_22 + D.2299_38;
  res_4(D)->theT = D.2297_40;

while for sum2 the loads and stores are not mixed:

  D.2391_29 = MEM[(const struct LorentzVector &)res_4(D)].theT;
  D.2389_31 = D.2365_22 + D.2391_29;
  D.2388_32 = MEM[(const struct LorentzVector &)res_4(D)].theZ;
  D.2386_34 = D.2367_24 + D.2388_32;
  D.2385_35 = MEM[(const struct LorentzVector &)res_4(D)].theY;
  D.2383_37 = D.2369_26 + D.2385_35;
  D.2382_38 = MEM[(const struct LorentzVector &)res_4(D)].theX;
  D.2380_40 = D.2371_28 + D.2382_38;
  res_4(D)->theX = D.2380_40;
  res_4(D)->theY = D.2383_37;
  res_4(D)->theZ = D.2386_34;
  res_4(D)->theT = D.2389_31;

The attached patch relaxes the above check a bit. Since we go through all the
ddrs anyway, we can check the order between the loads and the stores in
vect_analyze_data_ref_dependence. We don't care about independent load-store
pairs, so we only need to add this check to the pairs with unknown dependence.
(Known dependencies are already checked in vect_drs_dependent_in_basic_block).

[Bug c++/42356] confused compiler

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-10-22
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #7 from Manuel López-Ibáñez  2011-10-22 
12:27:11 UTC ---
Clang prints:

/tmp/webcompile/_26276_0.cc:17:19: error: no matching member function for call
to 'newNode'
bar*b = f.newNode();
~~^~~~
/tmp/webcompile/_26276_0.cc:6:13: note: candidate function template not viable:
requires 1 argument, but 0 were provided
T*  newNode(U u) { return newNode()->init(u); }
^
/tmp/webcompile/_26276_0.cc:6:13: note: candidate function template not viable:
requires 1 argument, but 0 were provided
/tmp/webcompile/_26276_0.cc:8:13: note: candidate function template not viable:
requires 2 arguments, but 0 were provided
T*  newNode(U u, V v) { return newNode()->init(u, v); }
^
/tmp/webcompile/_26276_0.cc:8:13: note: candidate function template not viable:
requires 2 arguments, but 0 were provided

which is nicer except for the duplicated messages.

The first thing that should go away is the "expected primary-expression" stuff.

[Bug tree-optimization/50819] missed SLP vectorization

[irar at il dot ibm.com]

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

--- Comment #2 from Ira Rosen  2011-10-22 12:27:51 UTC 
---
Created attachment 25574
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25574
Patch for this PR and also fo PR 50730

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

Summary|confused compiler   |improve list of candidates
   ||and error recovery for
   ||ambiguous call
   Severity|normal  |enhancement

[Bug rtl-optimization/50827] New: [4.7 Regression] ICE: RTL check: expected elt 0 type 'e' or 'u', have '0' (rtx entry_value) in loc_cmp, at var-tracking.c:3011

[zsojka at seznam dot cz]

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

 Bug #: 50827
   Summary: [4.7 Regression] ICE: RTL check: expected elt 0 type
'e' or 'u', have '0' (rtx entry_value) in loc_cmp, at
var-tracking.c:3011
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -O2 -fno-ipa-sra -g testcase.C 
testcase.C: In function 'void std::_Destroy(_ForwardIterator, _ForwardIterator,
_Allocator&) [with _ForwardIterator =
__gnu_cxx::_Pointer_adapter<__gnu_cxx::_Relative_pointer_impl > >; _Allocator = __gnu_cxx::vec_alloc_type]':
testcase.C:53:3: internal compiler error: RTL check: expected elt 0 type 'e' or
'u', have '0' (rtx entry_value) in loc_cmp, at var-tracking.c:3011
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

RTL checking is probably needed to reproduce.

Tested revisions:
r180324 - crash
r180260 - crash
r179959 - OK

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  2011-10-22 
13:00:32 UTC ---
(In reply to comment #2)
> Well, I see several issues with the diagnostics. 
> 
> 1) The call is not ambiguous, because if it were (only) ambiguous then 
> removing
> the base "baz" would disambiguate. Instead the case without "baz" gets you:
>s3:~/ootbc/memspec$ g++ foo.cc
>foo.cc: In function ‘int main()’:
>foo.cc:27: error: no matching function for call to ‘foo::newNode()’
> That is, a call cannot be both ambiguous and have no matching function.

The call is ambiguous, because the name is found in two different base classes,
see the rules in [class.member.lookup].  Removing one of the bases means the
names are only found from one scope, and so overload resolution can proceed,
which fails because there are no viable functions.

Name lookup happens first, then overload resolution.
In your case the result of name lookup is ambiguous, like this:

struct A {
  void f(int);
};
struct B {
  void f(double);
};
struct C : A, B { };

int main() {
  C c;
  c.f(0);
}

even though A::f(int) is a better match, the call is ambiguous.

Clang's diagnostic refers to viable functions, which is wrong, because finding
viable functions happens as part of overload resolution, which shouldn't even
happen here because name lookup is ambiguous.

> 2) The reported list of overloads include those which have the wrong number of
> arguments.

That's by design. Maybe that's the function you meant to call.  If you call a
function with the wrong number of args you want the compiler to tell you name
lookup found something, but overload resolution failed because the number of
arguments didn't match.

> 3) The diagnostic contains "freeList::newNode(U, V) [with U = U, V = V, T =
> bar]" as the call citation, which makes it look like the local U matches a
> (non-existent in this case) global U and local V matches a global V, the way
> that local T matches global bar. Perhaps it could say something like
> "freeList::newNode(U, V) [with U = ?, V = ?, T = bar]"

That might be an improvement, yes.  That's the only issue I see here.

[Bug bootstrap/50778] [4.7 Regression] Bootstrap failure on powerpc-apple-darwin9

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  
2011-10-22 13:07:06 UTC ---
Bootstrap completed with the patch here, regtesting in progress. Once the patch
is committed and regress is happy again, please close this pr as fixed. Thanks
for the fix.

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  2011-10-22 
13:07:50 UTC ---
(In reply to comment #8)
> That might be an improvement, yes.  That's the only issue I see here.

Actually, there is another issue in the list of candidates:

template T* freeList::newNode(U) [with U = U, T = baz]
T* freeList::newNode() [with T = baz]

The first one should say freeList not freeList.

That would help realise that the member name has been found in two classes.

With -fno-pretty-templates it's better:

f.C:17:17: error: request for member ‘newNode’ is ambiguous
f.C:8:15: error: candidates are: template baz*
freeList::newNode(U, V)
f.C:6:15: error: template baz*
freeList::newNode(U)
f.C:4:13: error: baz* freeList::newNode()
f.C:8:15: error: template bar*
freeList::newNode(U, V)
f.C:6:15: error: template bar*
freeList::newNode(U)
f.C:4:13: error: bar* freeList::newNode()

This makes it easier to see that name lookup found these functions:
  freeList::newNode(U, V)
  freeList::newNode(U)
  freeList::newNode(U,V)
  freeList::newNode(U)
so you can see they come from different scopes (it would be even clearer if
"bar" and "baz" weren't visually very similar!)

[Bug c++/33801] Missing warning: "type qualifiers are meaningless in this declaration"

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #6 from Paolo Carlini  2011-10-22 
13:08:04 UTC ---
Ok guys, let's close this.

[Bug c++/39478] please improve recursive template instantiation diagnostics

[d.frey at gmx dot de]

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

--- Comment #2 from Daniel Frey  2011-10-22 13:19:02 UTC 
---
I think I'm asking for the word "recursion" or "recursive" in the error
message, bonus points for clearly identifying the cycle. The example is
obviously too simple to demonstrate the usefulness, but real-world cases can be
hard to understand if the compiler is claiming a certain type is incomplete and
you don't see why. When the cycle starts after a long prologue, it's even
harder to spot.

[Bug c++/50828] New: class template parameter not printed for member function template in candidate list

[redi at gcc dot gnu.org]

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

 Bug #: 50828
   Summary: class template parameter not printed for member
function template in candidate list
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org


template
  struct A {
template
  void f() { }
  };

int main() {
  A a;
  a.f(0);
}

With -fpretty-templates this gives:

f.C: In function ‘int main()’:
f.C:9:8: error: no matching function for call to ‘A::f(int)’
f.C:9:8: note: candidate is:
f.C:4:12: note: template void A::f() [with U = U, T = void]

T is shown in the argument list, but not the signature. It should be:

f.C:4:12: note: template void A::f() [with U = U, T = void]
^^^

For a non-template member function the class template parameter is shown
correctly.

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  2011-10-22 
13:21:11 UTC ---
(In reply to comment #9)
> The first one should say freeList not freeList.

reported as PR 50828

[Bug c++/50828] class template parameter not printed for member function template in candidate list

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-10-22 
13:29:19 UTC ---
I noticed this while analysing PR 42356, the missing template argument makes it
much harder to see why name lookup results are ambiguous

template
  struct A {
template
  void f() { }
  };

struct B : A, A { };

int main() {
  B a;
  a.f();
}

f.C: In function ‘int main()’:
f.C:11:5: error: request for member ‘f’ is ambiguous
f.C:4:12: error: candidates are: template void A::f() [with U = U, T =
void]
f.C:4:12: error: template void A::f() [with U = U, T =
int]

Because T isn't shown in the signature it's not immediately obvious that name
lookup found A::f and A::f in different base classes.

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call

[manu at gcc dot gnu.org]

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

--- Comment #11 from Manuel López-Ibáñez  2011-10-22 
13:30:10 UTC ---
(In reply to comment #8)
> > 2) The reported list of overloads include those which have the wrong number 
> > of
> > arguments.
> 
> That's by design. Maybe that's the function you meant to call.  If you call a
> function with the wrong number of args you want the compiler to tell you name
> lookup found something, but overload resolution failed because the number of
> arguments didn't match.

I wonder why the detailed overload failure that Nathan implemented does not
trigger here. I would expect to give details of why overload failed.

g++ could also specify which ones are viable candidates, and which ones are not
even viable, and for the ones not viable, explain why.

> That might be an improvement, yes.  That's the only issue I see here.

There is also the issue of the "expected primary-expression" triggered two
times.

[Bug c++/16070] Bad error message

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  2011-10-22 
14:02:29 UTC ---
@Ivan, GCC 4.7 gives:

pr16070.cc:5:20: error: no matching function for call to ‘Bar()’
pr16070.cc:5:20: note: candidates are:
pr16070.cc:3:9: note: template void Bar(const T&)
pr16070.cc:3:9: note:   template argument deduction/substitution failed:
pr16070.cc:5:20: note:   couldn't deduce template parameter ‘T’
pr16070.cc:4:9: note: void Bar(int)
pr16070.cc:4:9: note:   no known conversion for argument 1 from ‘’ to ‘int’

which seems better, no?

Compare to Clang:

/tmp/webcompile/_30708_0.cc:5:15: error: no matching function for call to 'Bar'
int main() {  Bar(f); }
  ^~~
/tmp/webcompile/_30708_0.cc:4:9: note: candidate function not viable: no
overload of 'f' matching 'int' for 1st argument
voidBar(int i) {}
^
/tmp/webcompile/_30708_0.cc:3:9: note: candidate template ignored: couldn't
infer template argument 'T'
voidBar(const T& t) {}
^

so g++ is not as good as clang, but it got closer at GCC 4.7. Perhaps g++ could
handle better the "unresolved overloaded function type"?

(Gosh! how can clang be that good at this?)

[Bug c++/17693] use typedef name in diagnostic

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez  2011-10-22 
14:14:18 UTC ---
GCC 4.7 does away with the typedefs completely:

pr17693.cc: In instantiation of ‘void A::g() [with T = int]’:
pr17693.cc:13:16:   required from here
pr17693.cc:8:5: error: ‘a’ is not a member of ‘int’
pr17693.cc: In instantiation of ‘void B::f(T, U) [with T = int; U = char]’:
pr17693.cc:32:35:   required from here
pr17693.cc:27:5: error: invalid conversion from ‘char’ to ‘void*’
[-fpermissive]
pr17693.cc:21:8: error:   initializing argument 1 of ‘void B::g(void*,
B::mysize_t)’ [-fpermissive]

which in this case doesn't look so bad, but with very deeply nested stuff, it
probably looks awful.

[Bug target/50829] New: avx extra copy for _mm256_insertf128_pd

[marc.glisse at normalesup dot org]

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

 Bug #: 50829
   Summary: avx extra copy for _mm256_insertf128_pd
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
Target: x86_64-linux-gnu


With -Ofast -mavx (or -Os -mavx), this code:

__m256d concat(__m128d x){
__m256d z=_mm256_castpd128_pd256(x);
return _mm256_insertf128_pd(z,x,1);
}

is compiled (by a snapshot from Oct 10) to:

.cfi_startproc
pushq%rbp
.cfi_def_cfa_offset 16
vmovapd%xmm0, %xmm1
.cfi_offset 6, -16
movq%rsp, %rbp
.cfi_def_cfa_register 6
andq$-32, %rsp
addq$16, %rsp
vinsertf128$0x1, %xmm0, %ymm1, %ymm0
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc

Apart from all the fun with stack manipulation, this boils down to:
vmovapd%xmm0, %xmm1
vinsertf128$0x1, %xmm0, %ymm1, %ymm0

when it looks like this would be enough (and I tested it):
vinsertf128$0x1, %xmm0, %ymm0, %ymm0

I am not sure if gcc thinks that vinsertf128 shouldn't use the same register
for everything, or if it doesn't realize that it doesn't need to zero the upper
128 bits of the ymm register before calling insert. I understand that the avx
support is young, but avxintrin.h contains a comment saying that
_mm256_castpd128_pd256 "shouldn't generate any extra moves".

(I am not using broadcast because going through memory looks like a waste).

[Bug c++/21038] report unmatched brace as a note

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
Summary|Poor diagnostic |report unmatched brace as a
   ||note

--- Comment #4 from Manuel López-Ibáñez  2011-10-22 
14:27:48 UTC ---
Clang:

/tmp/webcompile/_32245_0.cc:5:11: error: expected '}'
int k;
  ^
/tmp/webcompile/_32245_0.cc:1:12: note: to match this '{'
void foo() {
   ^
1 error generated.

In the worst case, it will tell you from which point you should start looking.

[Bug c++/24607] wrong column numbers in diagnostics with templates

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
Summary|poor diagnostic |wrong column numbers in
   ||diagnostics with templates

--- Comment #2 from Manuel López-Ibáñez  2011-10-22 
14:37:05 UTC ---
(In reply to comment #1)
> If we used the caret way of doing things it would just work.

It won't work anyway if we don't have the columns right:

GCC 4.7:

pr24607.cc:7:37: error: template argument 1 is invalid  
pr24607.cc:7:42: error: invalid type in declaration before ‘;’ token

[Bug c++/25362] pretty printing of expression fails

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org,
   ||paolo.carlini at oracle dot
   ||com
Summary|Error message for unmatched |pretty printing of
   |overload is gobbledygook|expression fails

--- Comment #4 from Manuel López-Ibáñez  2011-10-22 
14:45:22 UTC ---
(In reply to comment #3)
> There has not been any movement on this bug in over a year.
> 
> Could someone explain to me the reason for the cryptic error message.
> Why can't gcc just report something like:
> 
>   no match for operator!=(, 

Indeed! I am totally convinced that %qE must die!

See also PR50817 and there are few others.

[Bug c++/50830] New: [c++0x] Variadic template, inner class error

[trashyankes at wp dot pl]

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

 Bug #: 50830
   Summary: [c++0x] Variadic template, inner class error
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: trashyan...@wp.pl
 Build: MinGW 4.6.0 20110210; MinGW 4.7.0 20110815


this code generate error `expected a class template, got 'template
struct aa'` (case `a4` and `a5`)
when i remove every `...` its compile without problems

-
template
struct list_type {};
template class...>
struct list_templates {};

template
struct aa {};
template
struct bb {};

template
struct test {};

template class... F>
struct test>
{
struct inner {};
};
template class... F, template class... F2>
struct test, list_templates>
{
struct inner {};
};

template
struct test>
{
struct inner {};
};
template
struct test, list_type>
{
struct inner {};
};

template class... F, class... T>
struct test, list_type>
{
struct inner {};
};
test> a1;
test> a2;
test, list_type> a3;
test, list_type> a4; // error
test, list_templates> a5; // error
-

[Bug tree-optimization/50819] missed SLP vectorization

[vincenzo.innocente at cern dot ch]

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

--- Comment #3 from vincenzo Innocente  
2011-10-22 14:50:01 UTC ---
excellent! 
thanks Ira for the fast fix.
It does work. No side effect at first look

[Bug libgcj/50831] New: [4.7 regression] SIGSEGV in link.cc:1904

[jojelino at gmail dot com]

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

 Bug #: 50831
   Summary: [4.7 regression] SIGSEGV in link.cc:1904
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jojel...@gmail.com
  Host: i686-pc-cygwin
Target: i686-pc-mingw32
 Build: i686-pc-cygwin


Running gcj-dbtool or gjar or any executable compiled with GCJ tag sigsegvs

/bin/sh ./libtool --tag=GCJ  --mode=link /tmp/gcc/host-i686-pc-cygwin/gcc/gcj
-B/tmp/gcc/i686-pc-mingw32/libjava/ -B/tmp/gcc/host-i686-pc-cygwin/gcc/
-L/tmp/gcc/i686-pc-mingw32/winsup/mingw
-L/tmp/gcc/i686-pc-mingw32/winsup/w32api/lib -isystem
/tmp/gcc/winsup/mingw/include -isystem /tmp/gcc/winsup/w32api/include
-B/usr/i686-pc-mingw32/bin/ -B/usr/i686-pc-mingw32/lib/ -isystem
/usr/i686-pc-mingw32/include -isystem /usr/i686-pc-mingw32/sys-include
--sysroot=/usr/i686-pc-mingw32/sys-root   -L/tmp/gcc/i686-pc-mingw32/libjava
-ffloat-store -fomit-frame-pointer -Usun -fno-omit-frame-pointer -g -O2  -o
gcj-dbtool.exe --main=gnu.gcj.tools.gcj_dbtool.Main -rpath
/usr/i686-pc-mingw32/lib -shared-libgcc   gnu/gcj/tools/gcj_dbtool/natMain.o
gnu/gcj/tools/gcj_dbtool.lo -L/tmp/gcc/i686-pc-mingw32/libjava/.libs libgcj.la
gdb --args .libs/gcj-dbtool.exe
(gdb) p klass->engine
$14 = (_Jv_ExecutionEngine *) 0x0
(gdb) p *klass
$15 = (java::lang::Class) {
   = {},
  members of java::lang::Class:
  static class$ = {
 = {},
members of java::lang::Class:
static class$ = ,
next_or_version = 0x0,
name = 0x6a04c874,
accflags = 0x31,
superclass = 0x69d57180,
constants = {
  size = 0x25,
  tags = 0x69d57620 "",
  data = 0x69d57580
},
{
  methods = 0x69d57660,
  element_type = 0x69d57660
},
method_count = 0x52,
vtable_method_count = 0x41,
fields = 0x0,
---Type  to continue, or q  to quit---
size_in_bytes = 0x90,
field_count = 0x0,
static_field_count = 0x0,
vtable = 0x69d57468,
otable = 0x0,
otable_syms = 0x0,
atable = 0x0,
atable_syms = 0x0,
itable = 0x0,
itable_syms = 0x0,
catch_classes = 0x69d57cc8,
interfaces = 0x69d57ce0,
loader = 0x0,
interface_count = 0x4,
state = 0xe,
thread = 0x1,
depth = 0x1,
ancestors = 0xa64ff0,
{
  idt = 0xa68fc8,
  ioffsets = 0xa68fc8
},
arrayclass = 0xa6ced8,
---Type  to continue, or q  to quit---
protectionDomain = 0x0,
assertion_table = 0x0,
hack_signers = 0x0,
chain = 0x69e6c120,
aux_info = 0x0,
engine = 0x6a3a95c0,
reflection_data = 0x6a04c8a0 "\001"
  },
  next_or_version = 0x400635d8,
  name = 0x4060bc,
  accflags = 0x21,
  superclass = 0x69d57180,
  constants = {
size = 0x32,
tags = 0x405420 "",
data = 0x4052c0
  },
  {
methods = 0x405460,
element_type = 0x405460
  },
  method_count = 0xa,
  vtable_method_count = 0x6,
---Type  to continue, or q  to quit---
  fields = 0x405528,
  size_in_bytes = 0x4,
  field_count = 0x1,
  static_field_count = 0x1,
  vtable = 0x4051a8,
  otable = 0x0,
  otable_syms = 0x0,
  atable = 0x0,
  atable_syms = 0x0,
  itable = 0x0,
  itable_syms = 0x0,
  catch_classes = 0x405538,
  interfaces = 0x0,
  loader = 0x0,
  interface_count = 0x0,
  state = 0x1,
  thread = 0x0,
  depth = 0x0,
  ancestors = 0x0,
  {
idt = 0x0,
ioffsets = 0x0
  },
---Type  to continue, or q  to quit---
  arrayclass = 0x0,
  protectionDomain = 0x0,
  assertion_table = 0x0,
  hack_signers = 0x0,
  chain = 0x0,
  aux_info = 0x0,
  engine = 0x0,
  reflection_data = 0x4060de ""
}

why do we have two engine field?

[Bug libgcj/50831] [4.7 regression] SIGSEGV in link.cc:1904

[jojelino at gmail dot com]

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

--- Comment #1 from gee  2011-10-22 15:15:07 UTC ---

$ gdb --args ./gcj-dbtool.exe
rGNU gdb (GDB) 7.3.50.20110903-cvs
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-cygwin".
For bug reporting instructions, please see:
...

warning: the current range check setting does not match the language.


warning: the current type check setting does not match the language.

Whether backtraces should continue past the entry point of a program is off.
Reading symbols from
/tmp/gcc/i686-pc-mingw32/libjava/.libs/gcj-dbtool.exe...done.
(gdb) r
Starting program: /tmp/gcc/i686-pc-mingw32/libjava/.libs/gcj-dbtool.exe
[New Thread 3860.0x1a7c]
[New Thread 3860.0x1c98]

Program received signal SIGSEGV, Segmentation fault.
0x69690e36 in verify_class (klass=0x405100) at ../.././libjava/link.cc:1904
1904  klass->engine->verify(klass);
(gdb) bt
#0  0x69690e36 in verify_class (klass=0x405100) at ../.././libjava/link.cc:1904
#1  _Jv_Linker::wait_for_state (klass=0x405100, state=0x9)
at ../.././libjava/link.cc:2074
#2  0x696c5280 in java::lang::Class::initializeClass (this=0x405100)
at ../.././libjava/java/lang/natClass.cc:722
#3  0x00401f38 in gnu.gcj.tools.gcj_dbtool.Main.main(java.lang.String[])void (
s=@a6af98) at /tmp/gcc/libjava/gnu/gcj/tools/gcj_dbtool/Main.java:26
#4  0x696bd552 in gnu::java::lang::MainThread::call_main (this=0xc0bf60)
at ../.././libjava/gnu/java/lang/natMainThread.cc:54
#5  0x696fad96 in gnu.java.lang.MainThread.run()void (this=@c0bf60)
at /tmp/gcc/libjava/gnu/java/lang/MainThread.java:106
#6  0x696cbeb2 in _Jv_ThreadRun (thread=0xc0bf60)
at ../.././libjava/java/lang/natThread.cc:335
#7  0x69684030 in _Jv_RunMain (vm_args=0x0, klass=0x405100, name=0x0,
argc=0x1, argv=0x3d8810, is_jar=0x0) at ../.././libjava/prims.cc:1789
#8  0x69684226 in _Jv_RunMain (klass=0x405100, name=0x0, argc=0x1,
argv=0x3d8810, is_jar=0x0) at ../.././libjava/prims.cc:1814
#9  0x6968428f in JvRunMain (klass=0x405100, argc=0x1, argv=0x3d8810)
at ../.././libjava/prims.cc:1820
#10 0x00401402 in _fu0___Jv_Compiler_Properties () at /tmp/ccMCI8VE.i:11
#11 0x004010bb in __mingw_CRTStartup ()
at
/usr/src/mingw-runtime/mingw-runtime-3.20-1/src/mingwrt-3.20-mingw32/crt1.c:244
---Type  to continue, or q  to quit---
#12 0x004012a8 in mainCRTStartup ()
at
/usr/src/mingw-runtime/mingw-runtime-3.20-1/src/mingwrt-3.20-mingw32/crt1.c:264
(gdb)

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call

[igodard at pacbell dot net]

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

--- Comment #12 from Ivan Godard  2011-10-22 
15:52:54 UTC ---
Manual said:
g++ could also specify which ones are viable candidates, and which ones are not
even viable, and for the ones not viable, explain why.

[Bug target/50829] avx extra copy for _mm256_insertf128_pd

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

   Keywords||ra

--- Comment #1 from Uros Bizjak  2011-10-22 16:10:12 
UTC ---
This looks similar to PR 34283, a RA problem.

[Bug libgcj/50831] [4.7 regression] __gcc_register_frame must throw error when failed to load dll

[jojelino at gmail dot com]

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

gee  changed:

   What|Removed |Added

Summary|[4.7 regression] SIGSEGV in |[4.7 regression]
   |link.cc:1904|__gcc_register_frame must
   ||throw error when failed to
   ||load dll

--- Comment #2 from gee  2011-10-22 16:30:35 UTC ---
in config/i386/{cygwin,mingw32}.h, LIBGCJ_SONAME is hard-coded so
__gcc_register_frame tries to load libgcj-12.dll, but in
libjava/libtool-version the major version is 13. for permanant fix, it would be
needed to generate header file on configuration time for proper libjava
version.

[Bug target/50617] [4.5, 4.6, 4.7 Regression] ICE: RTL flag check: INSN_ANNULLED_BRANCH_P used with unexpected rtx code 'simplify_immed_subreg' in output_bb, at config/pa/pa.c:6631

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

  Component|middle-end  |target
Summary|[4.7 Regression] ICE: RTL   |[4.5, 4.6, 4.7 Regression]
   |flag check: |ICE: RTL flag check:
   |INSN_ANNULLED_BRANCH_P used |INSN_ANNULLED_BRANCH_P used
   |with unexpected rtx code|with unexpected rtx code
   |'simplify_immed_subreg' in  |'simplify_immed_subreg' in
   |output_bb, at   |output_bb, at
   |config/pa/pa.c:6631 |config/pa/pa.c:6631

--- Comment #1 from John David Anglin  2011-10-22 
16:40:26 UTC ---
This is caused by a function naming conflict: output_bb is defined in both
pa.c and gimple-streamer-out.c.  It's a mystery how this worked at all.

gcc-4.5 and 4.6 are also affected.

Guess I'll change the target.

[Bug tree-optimization/44683] [4.4/4.5/4.6 Regression] Optimization bug with copysign builtin

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org
  Known to work||
  Known to fail||

--- Comment #11 from Eric Botcazou  2011-10-22 
16:56:59 UTC ---
While working on a related subject, the testcase started to regress.  IMHO the
fix only papers over the problem (try with -fno-trapping-math for example).
Even in the true edge of a conditional expression, you cannot infer a simple
equivalence as soon as there are or there might be signed zeros involved.

[Bug target/50829] avx extra copy for _mm256_insertf128_pd

[marc.glisse at normalesup dot org]

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

--- Comment #2 from Marc Glisse  2011-10-22 
17:01:51 UTC ---
(In reply to comment #1)
> This looks similar to PR 34283, a RA problem.

Ah, indeed. I also had a function that ended with:
vmovapd%xmm1, %xmm0
vmaxpd%xmm2, %xmm0, %xmm0
vzeroupper
ret

which looks related too. Thanks for the link.

[Bug target/50832] New: Strange ix86_attr_length_immediate_default

[hjl.tools at gmail dot com]

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

 Bug #: 50832
   Summary: Strange ix86_attr_length_immediate_default
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com


ix86_attr_length_immediate_default has

int
ix86_attr_length_immediate_default (rtx insn, bool shortform)
{
  int len = 0;
  int i;
  extract_insn_cached (insn);
  for (i = recog_data.n_operands - 1; i >= 0; --i)
if (CONSTANT_P (recog_data.operand[i]))
  { 
enum attr_mode mode = get_attr_mode (insn);

gcc_assert (!len);
...
  }

When there is a match, we always get assert.

[Bug java/50045] [4.7 regression] ICE in gcc/java/lang.c:427 with -ftree-dump-all

[jojelino at gmail dot com]

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

--- Comment #1 from gee  2011-10-22 17:35:01 UTC ---
and newer one.

(gdb) r
Starting program: /tmp/gcc/host-i686-pc-cygwin/gcc/jc1.exe gnu.zip
-fhash-synchronization -fuse-divide-subroutine -fcheck-references
-fuse-boehm-gc -fkeep-inline-functions -quiet -dumpbase gnu.zip -mtune=generic
-march=pentiumpro -auxbase-strip gnu/gcj/.libs/convert.o -g -O2 -Wno-deprecated
-version -ffloat-store -fno-omit-frame-pointer -fencoding=UTF-8
-fbootstrap-classes
-fsource-filename=/tmp/gcc/i686-pc-mingw32/libjava/classpath/lib/classes
-fdump-tree-all -fbootclasspath=./:../.././libjava/classpath/lib/
-faux-classpath gnu.zip -MD_ -MT gnu/gcj/convert.lo -MF gnu/gcj/convert.deps -o
/tmp/ccY2WWPD.s
[New Thread 5008.0xea0]
warning: section .gnu_debuglink not found in /cygdrive/d/cygwin/bin/cygwin1.dbg
[New Thread 5008.0x9d4]
GNU Java (GCC) version 4.7.0 20111021 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.7.0 20111020 (experimental), GMP version
5.0.2, MPFR version 3.2.0-dev, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Java (GCC) version 4.7.0 20111021 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.7.0 20111020 (experimental), GMP version
5.0.2, MPFR version 3.2.0-dev, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Class path starts here:
gnu.zip/ (zip)
./ (system)
../.././libjava/classpath/lib/ (system)

Program received signal SIGSEGV, Segmentation fault.
put_decl_node (node=, verbosity=0x2)
at ../.././gcc/java/lang.c:427
427   put_decl_node (TREE_VALUE (args), verbosity);
(gdb) bt
#0  put_decl_node (node=, verbosity=0x2)
at ../.././gcc/java/lang.c:427
#1  0x004376da in lang_printable_name (decl=0x7ff60780, v=0x2)
at ../.././gcc/java/lang.c:473
#2  0x005b320a in cgraph_node_name (node=0x7ff57a10)
at ../.././gcc/cgraph.c:1768
#3  0x009be355 in dump_inline_edge_summary (f=0x20137d0c, indent=0x4,
info=0x7fbf6378, node=) at ../.././gcc/ipa-inline-analysis.c:1094
#4  0x009c323c in dump_inline_summary (node=0x7ff52a00, f=0x20137d0c)
at ../.././gcc/ipa-inline-analysis.c:1194
#5  dump_inline_summary (f=0x20137d0c, node=0x7ff52a00)
at ../.././gcc/ipa-inline-analysis.c:1161
#6  0x009c4b34 in estimate_function_body_sizes (early=0x1, node=0x7ff52a00)
at ../.././gcc/ipa-inline-analysis.c:2053
#7  compute_inline_parameters (node=0x7ff52a00, early=0x1)
at ../.././gcc/ipa-inline-analysis.c:2129
#8  0x009c5760 in compute_inline_parameters_for_current ()
at ../.././gcc/ipa-inline-analysis.c:2147
#9  0x00514f0d in execute_one_pass (pass=0xd20c00) at ../.././gcc/passes.c:2064
#10 0x00515245 in execute_pass_list (pass=0xd20c00)
at ../.././gcc/passes.c:2119
#11 0x005144bc in do_per_function_toporder (
callback=0x515230 , data=0xd20a80)
---Type  to continue, or q  to quit---
at ../.././gcc/passes.c:1606
#12 0x005156a3 in execute_ipa_pass_list (pass=0xd20b40)
at ../.././gcc/passes.c:2436
#13 0x005c0c22 in ipa_passes () at ../.././gcc/cgraphunit.c:2033
#14 cgraph_optimize () at ../.././gcc/cgraphunit.c:2145
#15 0x005c128f in cgraph_finalize_compilation_unit ()
at ../.././gcc/cgraphunit.c:1327
#16 0x00588c3c in write_global_declarations () at ../.././gcc/langhooks.c:303
#17 0x004178ce in java_write_globals () at ../.././gcc/java/class.c:3241
#18 0x004fc3dc in compile_file () at ../.././gcc/toplev.c:581
#19 do_compile () at ../.././gcc/toplev.c:1930
#20 toplev_main (argc=0x22, argv=0x2003a368) at ../.././gcc/toplev.c:2006
#21 0x00cec270 in main (argc=0x22, argv=0x2003a368) at ../.././gcc/main.c:36
#22 0x610069a8 in _cygwin_exit_return ()
at /tmp/winsup/winsup/cygwin/dcrt0.cc:897
#23 0x61004e56 in _cygtls::call2 (this=0x5ecce64,
func=0x61005cd0 , arg=0x0, buf=0x5eccdc4)
at /tmp/winsup/winsup/cygwin/cygtls.cc:69

[Bug java/50045] [4.7 regression] ICE in gcc/java/lang.c:427 with -ftree-dump-all

[jojelino at gmail dot com]

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

--- Comment #2 from gee  2011-10-22 17:37:37 UTC ---
Created attachment 25576
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25576
testcase

[Bug rtl-optimization/50833] New: ICE: in maybe_record_trace_start, at dwarf2cfi.c:2243 with -fshrink-wrap

[zsojka at seznam dot cz]

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

 Bug #: 50833
   Summary: ICE: in maybe_record_trace_start, at dwarf2cfi.c:2243
with -fshrink-wrap
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
CC: ber...@gcc.gnu.org
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu


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

Compiler output:
$ gcc -fshrink-wrap testcase.c 
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2243
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  fancy_abort (file=0x1234f40 "/mnt/svn/gcc-trunk/gcc/dwarf2cfi.c",
line=2243, function=0x1236260 "maybe_record_trace_start")
at /mnt/svn/gcc-trunk/gcc/diagnostic.c:898
#1  0x006d9804 in maybe_record_trace_start (start=Unhandled dwarf
expression opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:2243
#2  0x006da3f4 in scan_trace (trace=Unhandled dwarf expression opcode
0xf3
) at /mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:2420
#3  0x006db9a7 in create_cfi_notes () at
/mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:2550
#4  execute_dwarf2_frame () at /mnt/svn/gcc-trunk/gcc/dwarf2cfi.c:2908
#5  0x008e5d68 in execute_one_pass (pass=0x179d860) at
/mnt/svn/gcc-trunk/gcc/passes.c:2064
#6  0x008e60d5 in execute_pass_list (pass=0x179d860) at
/mnt/svn/gcc-trunk/gcc/passes.c:2119
#7  0x008e60e7 in execute_pass_list (pass=0x179e840) at
/mnt/svn/gcc-trunk/gcc/passes.c:2120
#8  0x008e60e7 in execute_pass_list (pass=0x179e8a0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2120
#9  0x00a3df6e in tree_rest_of_compilation (fndecl=0x7568a100) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:420
#10 0x0069475a in cgraph_expand_function (node=0x755886c0) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1819
#11 0x006968ca in cgraph_output_in_order () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1984
#12 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2192
#13 0x00696baa in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1327
#14 0x0057939b in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9940
#15 0x009dbb84 in compile_file (argc=13, argv=0x7fffdb08) at
/mnt/svn/gcc-trunk/gcc/toplev.c:581
#16 do_compile (argc=13, argv=0x7fffdb08) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1930
#17 toplev_main (argc=13, argv=0x7fffdb08) at
/mnt/svn/gcc-trunk/gcc/toplev.c:2006
#18 0x76178d2d in __libc_start_main () from /lib64/libc.so.6
#19 0x0055cf19 in _start ()

Tested revisions:
r180324 - crash

[Bug libgcj/50053] [4.7 regression] SIGSEGV in natClass.cc:651

[jojelino at gmail dot com]

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

--- Comment #4 from gee  2011-10-22 19:33:19 UTC ---
;;
;; Full RTL generated for this function:
;;
(note 1 0 4 NOTE_INSN_DELETED)

(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)

(insn 2 4 3 2 (set (reg/f:SI 61 [ this ])
(reg:SI 2 cx [ this ]))
/tmp/gcc/libjava/gnu/gcj/convert/Input_8859_1.java:19 -1
 (nil))

cx again, maybe it would be related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50725 except that it is compiled
without -mtune=core2 -mstackrealign.

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  2011-10-22 
19:43:08 UTC ---
(In reply to comment #11)
> I wonder why the detailed overload failure that Nathan implemented does not
> trigger here. I would expect to give details of why overload failed.

Name lookup fails due to the ambiguity, so overload resolution never happens. 
The detailed overload resolution diagnostics won't be printed if overload
resolution isn't done.

> g++ could also specify which ones are viable candidates, and which ones are 
> not
> even viable, and for the ones not viable, explain why.

There are no viable candidates, because overload resolution is not performed.

Why bother performing overload resolution if the result of name lookup is
ambiguous?  How does it help you resolve the ambiguity?

The ambiguity can be resolved by qualifying the name or with a using
declaration, but overload resolution is irrelevant for either of them: you
qualify a *name* and a using declaration names a *name*, not an overload

[Bug c++/16070] print something useful instead of

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2011-10-22 
19:53:54 UTC ---
(In reply to comment #6)
> so g++ is not as good as clang, but it got closer at GCC 4.7. Perhaps g++ 
> could
> handle better the "unresolved overloaded function type"?

Could that be done by splitting the diagnostic into two?  When there is no
implicit conversion sequence for an argument which is an overload set print one
message (like clang's "no overload of 'f'") and otherwise print the existing
message.

> (Gosh! how can clang be that good at this?)

I prefer G++'s error for the second candidate, the process that fails is
template argument deduction, not template argument inference.

[Bug c++/21038] report unmatched brace as a note

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-10-22 
19:57:45 UTC ---
Using an editor that can jump between braces (e.g. % in vim) makes it trivial
to find if you've indented your code sensibly. As Andrew said in comment 1, the
compiler's hint might be completely misleading.

[Bug c++/50830] [c++0x] Variadic template, inner class error

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-10-22 
20:37:03 UTC ---
reduced:

template class...>
struct list_templates {};

template
struct aa {};

template
struct test {};

template class... F, class T>
struct test, T>
{
struct inner {};
};

test, int> a4; // error

[Bug target/50788] [4.7 Regression] ICE: in merge_overlapping_regs, at regrename.c:318 with -mavx -fpeel-loops -fstack-protector-all and __builtin_ia32_maskloadpd256

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||ebotcazou at gcc dot
   ||gnu.org, uros at gcc dot
   ||gnu.org
  Component|rtl-optimization|target
 AssignedTo|ebotcazou at gcc dot|unassigned at gcc dot
   |gnu.org |gnu.org

--- Comment #3 from Eric Botcazou  2011-10-22 
20:41:53 UTC ---
This appears to be a problem in the AVX maskmov patterns: operand 0 is seen as
a double output operand.  The solution is either to use a match_operand for the
input with constraint 0 or to use '+' instead of '=' in the constraint.  The
former is the preferred approach in this case though:

Index: config/i386/sse.md
===
--- config/i386/sse.md  (revision 180235)
+++ config/i386/sse.md  (working copy)
@@ -12298,7 +12298,7 @@ (define_insn "*avx2_maskmov 1 "register_operand" "x,x")
   (match_operand:VI48_AVX2 2 "nonimmediate_operand" "m,x")
-  (match_dup 0)]
+  (match_operand:VI48_AVX2 3 "nonimmediate_operand" "0,0")]
  UNSPEC_MASKMOV))]
   "TARGET_AVX2
&& (REG_P (operands[0]) == MEM_P (operands[2]))"
@@ -12313,7 +12313,7 @@ (define_insn "*avx_maskmov 1 "register_operand" "x,x")
   (match_operand:VF 2 "nonimmediate_operand" "m,x")
-  (match_dup 0)]
+  (match_operand:VF 3 "nonimmediate_operand" "0,0")]
  UNSPEC_MASKMOV))]
   "TARGET_AVX
&& (REG_P (operands[0]) == MEM_P (operands[2]))"

but the expanders have match_dup.  Uros, would you mind taking it over?  TIA.

[Bug c++/50830] [c++0x] Variadic template, inner class error

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  2011-10-22 
20:57:04 UTC ---
The reduced example compiles if the partial specialization is declared so the
pack expansion is last:

template class... F>
struct test, T>
{
struct inner {};
};

[Bug c++/50830] [c++0x] Variadic template, inner class error

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-10-22 
21:07:31 UTC ---
(In reply to comment #0)
> when i remove every `...` its compile without problems

N.B. that doesn't mean this is a G++ bug

[Bug c++/50830] [c++0x] Variadic template, inner class error

[daniel.kruegler at googlemail dot com]

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

--- Comment #4 from Daniel Krügler  
2011-10-22 21:15:20 UTC ---
(In reply to comment #3)
I agree, but the partial specialization

template class... F, class T>
struct test, T>;

should be fine, because only primary class templates require a template
parameter pack to be the last parameter (14.1 p11).

[Bug libstdc++/50196] [C++0x] std::thread not available under macos

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  2011-10-22 
21:31:28 UTC ---
Author: redi
Date: Sat Oct 22 21:31:24 2011
New Revision: 180329

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180329
Log:
PR libstdc++/50196
* acinclude.m4 (GLIBCXX_HAS_GTHREADS): Don't depend on _POSIX_TIMEOUTS.
* configure: Regenerate.
* include/std/mutex (timed_mutex, recursive_timed_mutex): Define
conditionally on GTHREADS_HAS_MUTEX_TIMEDLOCK.
* testsuite/lib/libstdc++.exp (check_v3_target_gthreads_timed): Define.
* testsuite/lib/dg-options.exp (dg-require-gthreads-timed): Define.
* testsuite/30_threads/recursive_timed_mutex/dest/destructor_locked.cc:
Use dg-require-gthreads-timed instead of dg-require-gthreads.
* testsuite/30_threads/recursive_timed_mutex/native_handle/
typesizes.cc: Likewise.
* testsuite/30_threads/recursive_timed_mutex/native_handle/1.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock_until/1.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock_until/2.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/cons/assign_neg.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/cons/1.cc: Likewise.
* testsuite/30_threads/recursive_timed_mutex/cons/copy_neg.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/requirements/typedefs.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock/1.cc: Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock/2.cc: Likewise.
* testsuite/30_threads/recursive_timed_mutex/lock/1.cc: Likewise.
* testsuite/30_threads/recursive_timed_mutex/lock/2.cc: Likewise.
* testsuite/30_threads/recursive_timed_mutex/unlock/1.cc: Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock_for/1.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock_for/2.cc:
Likewise.
* testsuite/30_threads/recursive_timed_mutex/try_lock_for/3.cc:
Likewise.
* testsuite/30_threads/timed_mutex/dest/destructor_locked.cc: Likewise.
* testsuite/30_threads/timed_mutex/native_handle/typesizes.cc:
Likewise.
* testsuite/30_threads/timed_mutex/native_handle/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock_until/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock_until/2.cc: Likewise.
* testsuite/30_threads/timed_mutex/cons/assign_neg.cc: Likewise.
* testsuite/30_threads/timed_mutex/cons/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/cons/copy_neg.cc: Likewise.
* testsuite/30_threads/timed_mutex/requirements/standard_layout.cc:
Likewise.
* testsuite/30_threads/timed_mutex/requirements/typedefs.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock/2.cc: Likewise.
* testsuite/30_threads/timed_mutex/lock/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/unlock/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock_for/1.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock_for/2.cc: Likewise.
* testsuite/30_threads/timed_mutex/try_lock_for/3.cc: Likewise.
* testsuite/30_threads/unique_lock/cons/5.cc: Likewise.
* testsuite/30_threads/unique_lock/cons/6.cc: Likewise.
* testsuite/30_threads/unique_lock/locking/3.cc: Likewise.
* testsuite/30_threads/unique_lock/locking/4.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/acinclude.m4
trunk/libstdc++-v3/configure
trunk/libstdc++-v3/include/std/mutex
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/cons/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/cons/assign_neg.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/cons/copy_neg.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/dest/destructor_locked.cc
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/lock/1.cc
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/lock/2.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/native_handle/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/native_handle/typesizes.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/requirements/typedefs.cc
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock/1.cc
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock/2.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/2.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/3.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_until/1.cc
   
trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_until/2.cc
trunk/libstdc++-v3

[Bug libstdc++/50196] [C++0x] std::thread not available under macos

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #8 from Jonathan Wakely  2011-10-22 
21:34:28 UTC ---
Should be fixed for 4.7 - std::timed_mutex and std::recursive_mutex are still
not available, because they require a library function which darwin doesn't
provide

This commit enables new tests for darwin which currently fail due to PR 50598,
I assume they will pass when that's fixed

[Bug c++/50828] class template parameter not printed for member function template in candidate list

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2011-10-22 
21:39:49 UTC ---
Seems due to the below, ie, no decoration for a primary. Remains to be seen if
in other contexts (in this case the call chain is dump_template_decl ->
dump_function_decl -> dump_type -> dump_aggr_type -> dump_template_parms) we
actually do *not* want decorations, otherwise seems easy to change.

/

/* Dump the template parameters from the template info INFO under control of
   FLAGS. PRIMARY indicates whether this is a primary template decl, or
   specialization (partial or complete). For partial specializations we show
   the specialized parameter values. For a primary template we show no
   decoration.  */

static void
dump_template_parms (tree info, int primary, int flags)
{
  tree args = info ? TI_ARGS (info) : NULL_TREE;

  if (primary && flags & TFF_TEMPLATE_NAME)
return;

[Bug c++/50828] class template parameter not printed for member function template in candidate list

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2011-10-22 
22:01:12 UTC ---
Changing it would be consistent with the output for non-template member
functions of class templates:

template
  struct A {
void f() { }
  };

int main() {
  A a;
  a.f(0);
}

t.C: In function ‘int main()’:
t.C:8:8: error: no matching function for call to ‘A::f(int)’
t.C:8:8: note: candidate is:
t.C:3:10: note: void A::f() [with T = void]
t.C:3:10: note:   candidate expects 0 arguments, 1 provided

[Bug c++/50830] [c++0x] Variadic template, inner class error

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-10-22 
22:02:30 UTC ---
does the last sentence of [temp.class.spec] apply here?

[Bug libstdc++/50834] New: Documentation about STL thread safety is ambiguous

[bergerp at laposte dot net]

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

 Bug #: 50834
   Summary: Documentation about STL thread safety is ambiguous
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: berg...@laposte.net


The libstdc++ documentation at
http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_concurrency.html states :

"We currently use the SGI STL definition of thread safety."


Then, a few paragraphs later, it also reads :

"All library objects are safe to use in a multithreaded program as long as each
thread carefully locks out access by any other thread while it uses any object
visible to another thread, i.e., treat library objects like any other shared
resource. In general, this requirement includes both read and write access to
objects"


This seems to be contradictory with the SGI STL thread safety definition, which
states that :

"simultaneous read accesses to shared containers are safe"


Regards,
Pierre

[Bug libstdc++/50834] Documentation about STL thread safety is ambiguous

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011-10-22
 AssignedTo|unassigned at gcc dot   |redi at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-10-22 
22:26:56 UTC ---
The first piece you quote continues "unless otherwise documented as safe" and
the SGI definition documents what is safe for concurrent reads.

But I agree it could be improved, the C++11 standard has a better definition,
which we aim to conform to.

[Bug c++/50828] class template parameter not printed for member function template in candidate list

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2011-10-22 
23:39:06 UTC ---
Indeed.

The difference between the two is in flags (primary is true for both of
course): due to the '| TFF_TEMPLATE_NAME' # error.c:1214 in dump_template_decl.
The fact is, toward the end of dump_template_decl there are quite a few of '|
TFF_TEMPLATE_NAME' and before trying removing one we should make sense of the
others.

[Bug c++/50810] c++0x-compat does not warn about narrowing conversions

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #8 from Paolo Carlini  2011-10-23 
00:36:25 UTC ---
I have the patch essentially ready. My only remaining doubt is that currently
-Wc++0x-compat is part of -Wall, and -Wnarrowing would become also part of
-Wall. Are we sure about this?

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call

[manu at gcc dot gnu.org]

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

--- Comment #14 from Manuel López-Ibáñez  2011-10-23 
00:46:15 UTC ---
(In reply to comment #13)
> (In reply to comment #11)
> > I wonder why the detailed overload failure that Nathan implemented does not
> > trigger here. I would expect to give details of why overload failed.
> 
> Name lookup fails due to the ambiguity, so overload resolution never happens. 
> The detailed overload resolution diagnostics won't be printed if overload
> resolution isn't done.

So you are saying that the candidates printed are simply all the matching names
that name lookup is able to find?

If so, I understand that the way g++ implements overload resolution makes not
trivial to give diagnostics, but still as Ivan agrees, it would be nice to be
able to sort viable candidates first, then not viable with details about why
they are not. This would require factoring out code to test overloads and
report diagnostics.

> > g++ could also specify which ones are viable candidates, and which ones are 
> > not
> > even viable, and for the ones not viable, explain why.
> 
> There are no viable candidates, because overload resolution is not performed.
> 
> Why bother performing overload resolution if the result of name lookup is
> ambiguous?  How does it help you resolve the ambiguity?

Yourself explained why above:

"Maybe that's the function you meant to call.  If you call a function with the
wrong number of args you want the compiler to tell you name lookup found
something, but overload resolution failed because the number of arguments
didn't match."

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call

[manu at gcc dot gnu.org]

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

--- Comment #15 from Manuel López-Ibáñez  2011-10-23 
00:47:42 UTC ---
(In reply to comment #12)
> Manual said:
> g++ could also specify which ones are viable candidates, and which ones are 
> not
> even viable, and for the ones not viable, explain why.

http://en.wikipedia.org/wiki/Manual

http://en.wikipedia.org/wiki/Manuel

[Bug bootstrap/49246] bootstrap comparison failure with 174455 on OpenBSD

[jsg at openbsd dot org]

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

--- Comment #3 from Jonathan Gray  2011-10-23 01:08:43 
UTC ---
This seems to be resolved by adding PCH support for OpenBSD.  Without which
builds will fail even if PCH are disabled.

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call

[igodard at pacbell dot net]

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

--- Comment #16 from Ivan Godard  2011-10-23 
01:28:48 UTC ---
(In reply to comment #15)
> (In reply to comment #12)
> > Manual said:
> > g++ could also specify which ones are viable candidates, and which ones are 
> > not
> > even viable, and for the ones not viable, explain why.
> 
> http://en.wikipedia.org/wiki/Manual
> 
> http://en.wikipedia.org/wiki/Manuel

Whoever said it, they were right :-)

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  2011-10-23 
01:54:17 UTC ---
But for this testcase I don't want to be told overload resolution passed or
failed, I want to be told it's ambiguous, because that's the error in the
testcase that prevents it compiling, and the diagnostic should help fix that
problem.

You say clang's output is nicer, I think you should look again.  Notice there
are 6 overloads:
freeListf(), freeListf(U), and freeListf(U,V),
freeListf(), freeListf(U), and freeListf(U,V),

Clang prints 4 errors (which appear to be duplicates, but actually refer to
freeList and freeList but that's not shown).  Why are the other two
overloads not shown?  Why doesn't it mention that the call is ambiguous?
It fails to state the problem, and misleadingly implies overload resolution
failed.

G++ mentions all six and correctly says they're ambiguous.  It would be better
if it said why (name lookup found "newNode" in multiple base classes) as clang
does for this code (which it gets right):

template
struct A {
template
  void f(U);
};
struct C : A, A { };

int main() {
  C c;
  c.f();
}

[Bug c++/42356] improve list of candidates and error recovery for ambiguous call

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  2011-10-23 
02:03:41 UTC ---
(In reply to comment #12)
> Manual said:
> g++ could also specify which ones are viable candidates, and which ones are 
> not
> even viable, and for the ones not viable, explain why.

None of the functions are viable, because 'newNode' is ambiguous.


So your suggestion seems to be:

request for member is ambiguous
Overload 1: not viable, reason: ambiguous.
Overload 2: not viable, reason: ambiguous.
Overload 3: not viable, reason: ambiguous.
Overload 4: not viable, reason: ambiguous.
Overload 5: not viable, reason: ambiguous.
Overload 6: not viable, reason: ambiguous.

rather than what we have now:

request for member is ambiguous
Overload 1
Overload 2
Overload 3
Overload 4
Overload 5
Overload 6
[unhelpful nonsense about expected primary expression]

I think the second one is better (apart from the primary expression part)

Or maybe you could have:

request for member is ambiguous
Overload 1: not viable, reason: ambiguous.
Overload 2: not viable, reason: ambiguous.
Overload 3: not viable, reason: ambiguous, and wrong number of args
Overload 4: not viable, reason: ambiguous, and wrong number of args
Overload 5: not viable, reason: ambiguous, and wrong number of args
Overload 6: not viable, reason: ambiguous, and wrong number of args

I don't think that helps - changing the number of arguments wouldn't make the
testcase compile. Resolving the ambiguous lookup would.

[Bug c++/50810] c++0x-compat does not warn about narrowing conversions

[jason at redhat dot com]

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

--- Comment #9 from Jason Merrill  2011-10-23 02:06:56 
UTC ---
I think that makes sense, yes. People can always specify -Wno-narrowing if they
don't want it.

"paolo.carlini at oracle dot com"  wrote:

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #8 from Paolo Carlini  2011-10-23
00:36:25 UTC ---
I have the patch essentially ready. My only remaining doubt is that currently
-Wc++0x-compat is part of -Wall, and -Wnarrowing would become also part of
-Wall. Are we sure about this?

[Bug c++/50835] New: [4.7 Regression] Lvalue-ness of conditional operator results is incorrect in a function template

[mimomorin at gmail dot com]

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

 Bug #: 50835
   Summary: [4.7 Regression] Lvalue-ness of conditional operator
results is incorrect in a function template
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mimomo...@gmail.com


Created attachment 25578
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25578
Test case (which incorrectly fails to be compiled on gcc-4.7)

Suppose we have the following class

template
struct rvalue_probe
{
explicit rvalue_probe(T &t) : value(t) {}

operator T ()   { return value; }
operator T&() const { return value; }

T& value;
};

Then, 

// std::vector v;
true ? rvalue_probe >(v) : v

should be evaluated to an lvalue. 
But in a function template, this is incorrectly evaluated to an rvalue. 

Tested on gcc-4.7.0 20111022 (in a C++03 mode).

[Bug c++/50810] c++0x-compat does not warn about narrowing conversions

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini  2011-10-23 
02:12:42 UTC ---
Great. I'll post the patch tomorrow.

[Bug rtl-optimization/50827] [4.7 Regression] ICE: RTL check: expected elt 0 type 'e' or 'u', have '0' (rtx entry_value) in loc_cmp, at var-tracking.c:3011

[zsojka at seznam dot cz]

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

--- Comment #1 from Zdenek Sojka  2011-10-23 06:59:24 
UTC ---
Created attachment 25579
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25579
smaller testcase

This testcase needs a bit different flags:
$ gcc -O2 -g -funroll-loops testcase2.c 
testcase2.c: In function 'f':
testcase2.c:13:1: internal compiler error: RTL check: expected elt 0 type 'e'
or 'u', have '0' (rtx entry_value) in loc_cmp, at var-tracking.c:3011
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(gdb) bt
#0  rtl_check_failed_type2 (r=0x7570a1b0, n=0, c1=101, c2=117,
file=0x12af360 "/mnt/svn/gcc-trunk/gcc/var-tracking.c", line=3011, 
func=0x12b0200 "loc_cmp") at /mnt/svn/gcc-trunk/gcc/rtl.c:760
#1  0x00bc4347 in loc_cmp (x=Unhandled dwarf expression opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/var-tracking.c:3011
#2  0x00bc4461 in loc_cmp (x=Unhandled dwarf expression opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/var-tracking.c:3074
#3  0x00bc4e5e in onepart_variable_different_p (var1=0x7570a1b0,
var2=0x0) at /mnt/svn/gcc-trunk/gcc/var-tracking.c:4463
#4  0x00bd957a in variable_merge_over_cur (dst=Unhandled dwarf
expression opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/var-tracking.c:3706
#5  dataflow_set_merge (dst=Unhandled dwarf expression opcode 0xf3
) at /mnt/svn/gcc-trunk/gcc/var-tracking.c:3784
#6  0x00bd9fcf in vt_find_locations () at
/mnt/svn/gcc-trunk/gcc/var-tracking.c:6567
#7  0x00bde265 in variable_tracking_main_1 () at
/mnt/svn/gcc-trunk/gcc/var-tracking.c:9608
#8  variable_tracking_main () at /mnt/svn/gcc-trunk/gcc/var-tracking.c:9653
#9  0x008e5d68 in execute_one_pass (pass=0x17a1ca0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2064
#10 0x008e60d5 in execute_pass_list (pass=0x17a1ca0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2119
#11 0x008e60e7 in execute_pass_list (pass=0x179e840) at
/mnt/svn/gcc-trunk/gcc/passes.c:2120
#12 0x008e60e7 in execute_pass_list (pass=0x179e8a0) at
/mnt/svn/gcc-trunk/gcc/passes.c:2120
#13 0x00a3df6e in tree_rest_of_compilation (fndecl=0x7568a100) at
/mnt/svn/gcc-trunk/gcc/tree-optimize.c:420
#14 0x0069475a in cgraph_expand_function (node=0x755887e0) at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1819
#15 0x006966ac in cgraph_expand_all_functions () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1886
#16 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2197
#17 0x00696baa in cgraph_finalize_compilation_unit () at
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1327
#18 0x0057939b in c_write_global_declarations () at
/mnt/svn/gcc-trunk/gcc/c-decl.c:9940
#19 0x009dbb84 in compile_file (argc=15, argv=0x7fffdad8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:581
#20 do_compile (argc=15, argv=0x7fffdad8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:1930
#21 toplev_main (argc=15, argv=0x7fffdad8) at
/mnt/svn/gcc-trunk/gcc/toplev.c:2006
#22 0x76178d2d in __libc_start_main () from /lib64/libc.so.6
#23 0x0055cf19 in _start ()