Re: C++ PATCH for c++/70353 (core issue 1962)

[Dominique d'Humières]

> Le 28 mars 2016 à 15:11, Jason Merrill  a écrit :
> 
> On 03/28/2016 09:02 AM, Dominique d'Humières wrote:
>> 
>>> Le 28 mars 2016 à 14:55, Jason Merrill  a écrit :
>>> 
>>> OK, thanks.
>>> 
>>> Jason
>> 
>> Does it mean that I should commit the patch?
> 
> Please.

Revision 234504.

Dominique

> Jason
> 

Re: C++ PATCH for c++/70353 (core issue 1962)

[Jason Merrill]

On 03/28/2016 09:02 AM, Dominique d'Humières wrote:



Le 28 mars 2016 à 14:55, Jason Merrill  a écrit :

OK, thanks.

Jason


Does it mean that I should commit the patch?


Please.

Jason

Re: C++ PATCH for c++/70353 (core issue 1962)

[Dominique d'Humières]

> Le 28 mars 2016 à 14:55, Jason Merrill  a écrit :
> 
> OK, thanks.
> 
> Jason

Does it mean that I should commit the patch?

Dominique

Re: C++ PATCH for c++/70353 (core issue 1962)

[Jason Merrill]

OK, thanks.

Jason

Re: C++ PATCH for c++/70353 (core issue 1962)

[Segher Boessenkool]

On Fri, Mar 25, 2016 at 05:29:26PM -0400, Jason Merrill wrote:
> 70353 is a problem with the function-local static declaration of 
> __func__.  Normally constexpr functions can't have local statics, so 
> this is only an issue with __func__.  Meanwhile, core issue 1962 looks 
> like it's going to be resolved by changing __func__ et al to be prvalue 
> constants of type const char * rather than static local array variables, 
> so implementing that proposed resolution also resolves this issue, as 
> well as 62466 which complains about the strings not being merged between 
> translation units.  This patch proceeds from Martin's work last year.
> 
> Tested x86_64-pc-linux-gnu, applying to trunk.

This patch caused PR70422, a bootstrap comparison failure on aarch64,
ia64, and powerpc64.


Segher

Re: C++ PATCH for c++/70353 (core issue 1962)

[Markus Trippelsdorf]

On 2016.03.25 at 17:29 -0400, Jason Merrill wrote:
> 70353 is a problem with the function-local static declaration of __func__.
> Normally constexpr functions can't have local statics, so this is only an
> issue with __func__.  Meanwhile, core issue 1962 looks like it's going to be
> resolved by changing __func__ et al to be prvalue constants of type const
> char * rather than static local array variables, so implementing that
> proposed resolution also resolves this issue, as well as 62466 which
> complains about the strings not being merged between translation units.
> This patch proceeds from Martin's work last year.
> 
> Tested x86_64-pc-linux-gnu, applying to trunk.

It breaks building Firefox:

trippels@gcc2-power8 places % cat nsNavHistory.ii
struct A {
  template  A(const char (&)[N]);
};
void fn1() { A(__func__); }


trippels@gcc2-power8 places % c++  -c nsNavHistory.ii
nsNavHistory.ii: In function ‘void fn1()’:
nsNavHistory.ii:4:24: error: no matching function for call to ‘A::A(const 
char*&)’
 void fn1() { A(__func__); }
^
nsNavHistory.ii:2:20: note: candidate: template A::A(const char (&)[N])
   template  A(const char (&)[N]);
^
nsNavHistory.ii:2:20: note:   template argument deduction/substitution failed:
nsNavHistory.ii:4:24: note:   mismatched types ‘const char [N]’ and ‘const 
char*’
 void fn1() { A(__func__); }
^
nsNavHistory.ii:1:8: note: candidate: constexpr A::A(const A&)
 struct A {
^
nsNavHistory.ii:1:8: note:   no known conversion for argument 1 from ‘const 
char*’ to ‘const A&’
nsNavHistory.ii:1:8: note: candidate: constexpr A::A(A&&)
nsNavHistory.ii:1:8: note:   no known conversion for argument 1 from ‘const 
char*’ to ‘A&&’

So I'm not sure if your patch is really appropriate at this time.
Maybe waiting until next stage 1 would be better?

-- 
Markus

Re: C++ PATCH for c++/70353 (core issue 1962)

[Dominique d'Humières]

Hi Jason,

The following tests for g++.dg/ext/fnname5.C fail on darwin

FAIL: g++.dg/ext/fnname5.C  -std=c++11  scan-assembler .string\\t"foo"
FAIL: g++.dg/ext/fnname5.C  -std=c++11  scan-assembler .string\\t"void 
A::foo(int)"
FAIL: g++.dg/ext/fnname5.C  -std=c++14  scan-assembler .string\\t"foo"
FAIL: g++.dg/ext/fnname5.C  -std=c++14  scan-assembler .string\\t"void 
A::foo(int)"
FAIL: g++.dg/ext/fnname5.C  -std=c++98  scan-assembler .string\\t"foo"
FAIL: g++.dg/ext/fnname5.C  -std=c++98  scan-assembler .string\\t"void 
A::foo(int) »

AFAICT the corresponding patterns are

.ascii "foo\0"
.ascii "void A::foo(int)\0 »

This is fixed by the following patch

--- ../_clean/gcc/testsuite/g++.dg/ext/fnname5.C2016-03-25 
22:46:32.0 +0100
+++ gcc/testsuite/g++.dg/ext/fnname5.C  2016-03-26 09:04:51.0 +0100
@@ -29,5 +29,5 @@ main ()
 /* { dg-final { scan-assembler-not "_ZZN1A3fooEvE12__FUNCTION__" } } */
 /* { dg-final { scan-assembler-not "_ZZN1A3fooEiE12__FUNCTION__" } } */
 /* { dg-final { scan-assembler-not "_ZZN1A3fooEiE19__PRETTY_FUNCTION__" } } */
-/* { dg-final { scan-assembler ".string\"void A::foo\\(int\\)\"" } } */
-/* { dg-final { scan-assembler ".string\"foo\"" } } */
+/* { dg-final { scan-assembler ".(string|ascii) \"void A::foo\\(int\\)(.0)?\"" 
} } */
+/* { dg-final { scan-assembler ".(string|ascii) \"foo(.0)?\"" } } */

TIA

Dominique