Re: Obsolete powerpc*-*-*spe*

[Sebastian Huber]

On 16/03/17 22:16, Andrew Jenner wrote:

On 16/03/2017 21:11, Segher Boessenkool wrote:

The e200z3 upwards have SPE units. None of them have classic FP. So it
would make most sense for the e200/VLE support to be part of the SPE
backend rather than the classic PowerPC backend.


Great to hear!  And all e300 are purely "classic"?


That's one I'm less familiar with (as we don't deliver a multilib for 
it), but yes - my understanding is that this is classic core.


Yes, the e300 is a classic PowerPC. It is a successor of the 603e. The 
name e300 is confusing. It is quite unrelated to the e200 and e500 cores.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Translation breaks IDE

[Frédéric Marchal]

Hi,

I gave my partial French translation a field trial this week and it didn't went 
well. QtCreator can't see error messages any more if they are translated.

QtCreator identifies errors and warnings by parsing gcc output:

file.c:24:5: error: …
file.c:25:3: warning: …

But if "error" and "warning" are translated it becomes impossible to sort out 
the messages.

What can be done to help IDEs with translated messages?

Is it possible to add some --ide-mode flag or some environment variable that 
would prefix every message with untranslated hard coded tags that could be used 
by IDEs? I'm thinking about something along the line:

(E):file.c:24:5: 
(W): for warnings

These two could be put to use immediately because QtCreator already do 
something similar with MSVC. It just lacks something as the above mechanism to 
do it with gcc.

And it might be possibly to add other categories that could be used later such 
as:

(F): for fatal errors
(N): for notifications and informations
(I): included by
(C): candidates for overloaded functions
(H): "called from here" or "in this context"
(!): internal error

This list certainly needs more thinking and IDE folks could give more insight 
but you see were I'm heading.

Thanks,

Frederic

Re: Translation breaks IDE

[Richard Biener]

On Fri, Mar 17, 2017 at 9:48 AM, Frédéric Marchal  wrote:
> Hi,
>
> I gave my partial French translation a field trial this week and it didn't 
> went
> well. QtCreator can't see error messages any more if they are translated.
>
> QtCreator identifies errors and warnings by parsing gcc output:
>
> file.c:24:5: error: …
> file.c:25:3: warning: …
>
> But if "error" and "warning" are translated it becomes impossible to sort out
> the messages.
>
> What can be done to help IDEs with translated messages?
>
> Is it possible to add some --ide-mode flag or some environment variable that
> would prefix every message with untranslated hard coded tags that could be 
> used
> by IDEs? I'm thinking about something along the line:
>
> (E):file.c:24:5: 
> (W): for warnings
>
> These two could be put to use immediately because QtCreator already do
> something similar with MSVC. It just lacks something as the above mechanism to
> do it with gcc.
>
> And it might be possibly to add other categories that could be used later such
> as:
>
> (F): for fatal errors
> (N): for notifications and informations
> (I): included by
> (C): candidates for overloaded functions
> (H): "called from here" or "in this context"
> (!): internal error
>
> This list certainly needs more thinking and IDE folks could give more insight
> but you see were I'm heading.

I think a IDE mode ("machine interface") would be fine.  We already have
-fdiagnostics-parseable-fixits for example, generalizing this to sth like
-fdiagnostics-mi would be nice.

Richard.

> Thanks,
>
> Frederic
>

Re: Translation breaks IDE

[Janne Blomqvist]

On Fri, Mar 17, 2017 at 10:48 AM, Frédéric Marchal  wrote:
> This list certainly needs more thinking and IDE folks could give more insight
> but you see were I'm heading.

Not my area of expertise, but it seems the Glorious Future (TM) in
this area is something called the "language server protocol", see
http://langserver.org/ . Though AFAIK nobody is working on GCC
integration so far.


-- 
Janne Blomqvist

Re: Translation breaks IDE

[Frédéric Marchal]

On Friday 17 March 2017 13:32:17 Janne Blomqvist wrote:
> On Fri, Mar 17, 2017 at 10:48 AM, Frédéric Marchal  
wrote:
> > This list certainly needs more thinking and IDE folks could give more
> > insight but you see were I'm heading.
> 
> Not my area of expertise, but it seems the Glorious Future (TM) in
> this area is something called the "language server protocol", see
> http://langserver.org/ . Though AFAIK nobody is working on GCC
> integration so far.

I was looking for a short term solution. Not something that might possibly be 
available in 20 years :-)

Translations are unusable from within an IDE until gcc offers some solution to 
let the IDE detects errors and warnings irrespective of the selected language.

Currently, every single translated gcc*.po file is affected (Spanish and 
Indonesian users would still see errors as "error" apparently translates to 
"error" in those languages).

Frederic

Re: Translation breaks IDE

[Jonathan Wakely]

On 17 March 2017 at 12:17, Frédéric Marchal wrote:
> On Friday 17 March 2017 13:32:17 Janne Blomqvist wrote:
>> Not my area of expertise, but it seems the Glorious Future (TM) in
>> this area is something called the "language server protocol", see
>> http://langserver.org/ . Though AFAIK nobody is working on GCC
>> integration so far.
>
> I was looking for a short term solution. Not something that might possibly be
> available in 20 years :-)

Changing GCC's output and getting IDEs to support it isn't exactly
short term either (and the suggested (E) additions look ugly IMHO).

> Translations are unusable from within an IDE until gcc offers some solution to
> let the IDE detects errors and warnings irrespective of the selected language.
>
> Currently, every single translated gcc*.po file is affected (Spanish and
> Indonesian users would still see errors as "error" apparently translates to
> "error" in those languages).

Or the translators decided not to translate those words, maybe for this reason.

Re: Translation breaks IDE

[David Malcolm]

On Fri, 2017-03-17 at 12:20 +0100, Richard Biener wrote:
> On Fri, Mar 17, 2017 at 9:48 AM, Frédéric Marchal 
> wrote:
> > Hi,
> > 
> > I gave my partial French translation a field trial this week and it
> > didn't went
> > well. QtCreator can't see error messages any more if they are
> > translated.
> > 
> > QtCreator identifies errors and warnings by parsing gcc output:
> > 
> > file.c:24:5: error: …
> > file.c:25:3: warning: …
> > 
> > But if "error" and "warning" are translated it becomes impossible
> > to sort out
> > the messages.
> > 
> > What can be done to help IDEs with translated messages?
> > 
> > Is it possible to add some --ide-mode flag or some environment
> > variable that
> > would prefix every message with untranslated hard coded tags that
> > could be used
> > by IDEs? I'm thinking about something along the line:
> > 
> > (E):file.c:24:5: 
> > (W): for warnings
> > 
> > These two could be put to use immediately because QtCreator already
> > do
> > something similar with MSVC. It just lacks something as the above
> > mechanism to
> > do it with gcc.
> > 
> > And it might be possibly to add other categories that could be used
> > later such
> > as:
> > 
> > (F): for fatal errors
> > (N): for notifications and informations
> > (I): included by
> > (C): candidates for overloaded functions
> > (H): "called from here" or "in this context"
> > (!): internal error
> > 
> > This list certainly needs more thinking and IDE folks could give
> > more insight
> > but you see were I'm heading.
> 
> I think a IDE mode ("machine interface") would be fine.  We already
> have
> -fdiagnostics-parseable-fixits for example, generalizing this to sth
> like
> -fdiagnostics-mi would be nice.

This all sounds a lot like:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79423

Paraphrasing myself from that RFE: given that many IDEs can already
parse LANG=C output, presumably you'd want a command-line flag that
suppresses just the translation of "error" and "warning" etc, so that
instead of output of the form:

[with LANG=ja_JP.utf-8]

/tmp/test.cc: 関数 ‘int x2()’ 内:
/tmp/test.cc:3:4: エラー: some translated message here
 x0 x3 = x3.
^~
/tmp/test.cc:1:7: 備考: some other translated message here
 class x0;
   ^~

you get:

/tmp/test.cc: In function ‘int x2()’:
/tmp/test.cc:3:4: error: the same *translated* message here
 x0 x3 = x3.
^~
/tmp/test.cc:1:7: note: again, the message is still translated here
 class x0;
   ^~

i.e. that the content of the messages themselves should still be
translated, even when in some kind of IDE mode; it's just the
"error"/"warning" etc boilerplate that shouldn't be.

I can implement this for gcc 8.

What should the diagnostic be called?

  -fdiagnostics-output-format=VALUE
  -fdiagnostics-mi
  -fide

etc

Dave

Re: [Aarch64] Vector Function Application Binary Interface Specification for OpenMP

[James Greenhalgh]

On Wed, Mar 15, 2017 at 09:50:18AM +, Sekhar, Ashwin wrote:
> Hi GCC Team, Aarch64 Maintainers,
> 
> 
> The rules in Vector Function Application Binary Interface Specification  for
> OpenMP
> (https://sourceware.org/glibc/wiki/libmvec?action=AttachFile&do=view&target=VectorABI.txt)
> is used in x86 for generating the simd clones of a function.
> 
> Is there a similar one defined for Aarch64?
> 
> If not, would like to start a discussion on the same for Aarch64. To  kick
> start the same, a draft proposal for Aarch64 (on the same lines as  x86 ABI)
> is included below. The only change from x86 ABI is in the  function name
> mangling. Here the letter 'b' is used for indicating the  ASIMD isa.

Hi Ashwin,

Thanks for the question. ARM has defined a vector function ABI, based
on the Vector Function ABI Specification you linked below, which
is designed to be suitable for both the Advanced SIMD and Scalable
Vector Extensions. There has not yet been a release of this document
which I can point you at, nor can I give you an estimate of when the
document will be published.

However, Francesco Petrogalli has recently made a proposal to the
LLVM mailing list ( https://reviews.llvm.org/D30739 ) which I would
note conflicts with your proposal in one way. You choose 'b' for name
mangling for a vector function using Advanced SIMD, while Francesco
uses 'n', which is the agreed character in the Vector Function ABI
Specification we have been working on.

I'd encourage you to wait for formal publication of the ARM Vector
Function ABI to prevent any unexpected divergence between
implementations.

Thanks,
James

Re: Translation breaks IDE

[Frédéric Marchal]

On Friday 17 March 2017 09:30:40 David Malcolm wrote:
> This all sounds a lot like:
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79423

That's exactly the problem I'm faced with. Thanks for pointing it out to me.

 
> Paraphrasing myself from that RFE: given that many IDEs can already
> parse LANG=C output, presumably you'd want a command-line flag that
> suppresses just the translation of "error" and "warning" etc, so that
> instead of output of the form:
> 
> [with LANG=ja_JP.utf-8]
> 
> /tmp/test.cc: 関数 ‘int x2()’ 内:
> /tmp/test.cc:3:4: エラー: some translated message here
>  x0 x3 = x3.
> ^~
> /tmp/test.cc:1:7: 備考: some other translated message here
>  class x0;
>^~
> 
> you get:
> 
> /tmp/test.cc: In function ‘int x2()’:
> /tmp/test.cc:3:4: error: the same *translated* message here
>  x0 x3 = x3.
> ^~
> /tmp/test.cc:1:7: note: again, the message is still translated here
>  class x0;
>^~
> 
> i.e. that the content of the messages themselves should still be
> translated, even when in some kind of IDE mode; it's just the
> "error"/"warning" etc boilerplate that shouldn't be.

Right. We don't want to disable translation completely because the message is 
displayed to the user and it must be displayed in the correct language.

Your solution is much better than the tag I proposed. With your solution, IDEs 
don't have to change anything. The user can add the new command line option 
and get the translation working again. That's great!


> I can implement this for gcc 8.

Debian Jessie is still using gcc 4.9, Debian Squeeze will use version 6. 
QtCreator ships with version 5. Therefore, I expect it will take a long time 
before gcc 8 is used in production. In the meantime, I'll mark the 
translations for "error: " and "warning: " as fuzzy in the French po file along 
with a comment explaining why.


> What should the diagnostic be called?
> 
>   -fdiagnostics-output-format=VALUE
>   -fdiagnostics-mi
>   -fide

If users are expected to add it manually to their IDE's environment, let's 
keep it as simple and to the point as possible. Does it have to start with -f? 
Can't it just be -ide? Or --ide-output-format?

At the very least, the name should be explicit enough. -fdiagnostics-mi 
doesn't talk to me. I fail to see how it relates to a problem with IDEs 
parsing messages…

Frederic

Re: Translation breaks IDE

[Frédéric Marchal]

On Friday 17 March 2017 12:28:48 Jonathan Wakely wrote:
> On 17 March 2017 at 12:17, Frédéric Marchal wrote:
> > On Friday 17 March 2017 13:32:17 Janne Blomqvist wrote:
> >> Not my area of expertise, but it seems the Glorious Future (TM) in
> >> this area is something called the "language server protocol", see
> >> http://langserver.org/ . Though AFAIK nobody is working on GCC
> >> integration so far.
> > 
> > I was looking for a short term solution. Not something that might possibly
> > be available in 20 years :-)
> 
> Changing GCC's output and getting IDEs to support it isn't exactly
> short term either (and the suggested (E) additions look ugly IMHO).

The (E) and (W) tags would only be visible to the IDE. An IDE aware of that 
tag can easily strip it before displaying the message to the user. But, you 
are right and, beside, the solution proposed by David in his reply to this 
thread is much much better! IDEs don't have to change.

By short term, I mean within one year or two. Linux distributions are very 
slow at adopting newer compiler major versions. I don't expect to see gcc 8 in 
production any time soon.


> > Translations are unusable from within an IDE until gcc offers some
> > solution to let the IDE detects errors and warnings irrespective of the
> > selected language.
> > 
> > Currently, every single translated gcc*.po file is affected (Spanish and
> > Indonesian users would still see errors as "error" apparently translates
> > to
> > "error" in those languages).
> 
> Or the translators decided not to translate those words, maybe for this
> reason.

That's possible, but then, they both forgot to leave the translation unchanged 
for "warning: ".

That's the solution I'll apply with the French translation until the IDE 
compatibility option is available.

Frederic

Re: Translation breaks IDE

[Gabriel Paubert]

On Fri, Mar 17, 2017 at 12:28:48PM +, Jonathan Wakely wrote:
> On 17 March 2017 at 12:17, Frédéric Marchal wrote:
> > On Friday 17 March 2017 13:32:17 Janne Blomqvist wrote:
> >> Not my area of expertise, but it seems the Glorious Future (TM) in
> >> this area is something called the "language server protocol", see
> >> http://langserver.org/ . Though AFAIK nobody is working on GCC
> >> integration so far.
> >
> > I was looking for a short term solution. Not something that might possibly 
> > be
> > available in 20 years :-)
> 
> Changing GCC's output and getting IDEs to support it isn't exactly
> short term either (and the suggested (E) additions look ugly IMHO).
> 
> > Translations are unusable from within an IDE until gcc offers some solution 
> > to
> > let the IDE detects errors and warnings irrespective of the selected 
> > language.
> >
> > Currently, every single translated gcc*.po file is affected (Spanish and
> > Indonesian users would still see errors as "error" apparently translates to
> > "error" in those languages).
> 
> Or the translators decided not to translate those words, maybe for this 
> reason.

For Spanish at least, "error" is the correct translation, although the
pronunciation is vastly different.

Gabriel

FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

[Pinski, Andrew]

One of the following revision caused a bootstrap comparison failure on 
aarch64-linux-gnu:
r246225 
r246226
r246227

Thanks,
Andrew Pinski

Ignore the URLs in the log file below, this is a Jenkins to Cavium.

-Original Message-
From: jenk...@cavium.com [mailto:jenk...@cavium.com] 
Sent: Friday, March 17, 2017 11:00 AM
To: Pinski, Andrew 
Subject: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

--
rm -f stage_current
make[3]: Leaving directory 
'
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/lto/lto.o differs
libcpp/line-map.o differs
Makefile:24072: recipe for target 'compare' failed
make[2]: *** [compare] Error 1
make[2]: Leaving directory 
'
Makefile:24051: recipe for target 'stage3-bubble' failed
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory 
'
Makefile:931: recipe for target 'all' failed
make: *** [all] Error 2
Build step 'Execute shell' marked build as failure
[WARNINGS] Skipping publisher since build result is FAILURE
Archiving artifacts

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

[Bernd Schmidt]

On 03/17/2017 07:38 PM, Pinski, Andrew wrote:

One of the following revision caused a bootstrap comparison failure on 
aarch64-linux-gnu:
r246225
r246226
r246227


Can you help narrow that down?


Bernd

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

[Jeff Law]

On 03/17/2017 12:47 PM, Bernd Schmidt wrote:

On 03/17/2017 07:38 PM, Pinski, Andrew wrote:

One of the following revision caused a bootstrap comparison failure on
aarch64-linux-gnu:
r246225
r246226
r246227


Can you help narrow that down?

I'm provisioning an aarch64 system now.

jeff

Re: Translation breaks IDE

[Andreas Schwab]

On Mär 17 2017, Frédéric Marchal  wrote:

> On Friday 17 March 2017 09:30:40 David Malcolm wrote:
>> What should the diagnostic be called?
>> 
>>   -fdiagnostics-output-format=VALUE
>>   -fdiagnostics-mi
>>   -fide
>
> If users are expected to add it manually to their IDE's environment, let's 
> keep it as simple and to the point as possible. Does it have to start with 
> -f? 

You can write --ide or --diagnostics-mi if you like.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

[Andrew Pinski]

On Fri, Mar 17, 2017 at 11:47 AM, Bernd Schmidt  wrote:
> On 03/17/2017 07:38 PM, Pinski, Andrew wrote:
>>
>> One of the following revision caused a bootstrap comparison failure on
>> aarch64-linux-gnu:
>> r246225
>> r246226
>> r246227
>
>
> Can you help narrow that down?

I can though I don't want to duplicate work since Jeff was going to
provision an aarch64 system.  My automated testing is approximately
every hour or so; these commits were within an hour window even.
I did not look into the revisions when I write the email but I suspect
r246227 did NOT cause it since aarch64 does not use reload anymore.

Thanks,
Andrew

>
>
> Bernd
>

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

[Jeff Law]

On 03/17/2017 03:31 PM, Andrew Pinski wrote:

On Fri, Mar 17, 2017 at 11:47 AM, Bernd Schmidt  wrote:

On 03/17/2017 07:38 PM, Pinski, Andrew wrote:


One of the following revision caused a bootstrap comparison failure on
aarch64-linux-gnu:
r246225
r246226
r246227



Can you help narrow that down?


I can though I don't want to duplicate work since Jeff was going to
provision an aarch64 system.  My automated testing is approximately
every hour or so; these commits were within an hour window even.
I did not look into the revisions when I write the email but I suspect
r246227 did NOT cause it since aarch64 does not use reload anymore.
My the box I got isn't terribly fast, but regardless I'll be walking 
through each commit to see if I can trigger the failure.


246224 tested OK (as it should).

246225 is in progress.

jeff

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

[Jim Wilson]

On 03/17/2017 03:28 PM, Jeff Law wrote:

On 03/17/2017 03:31 PM, Andrew Pinski wrote:

On Fri, Mar 17, 2017 at 11:47 AM, Bernd Schmidt 
wrote:

On 03/17/2017 07:38 PM, Pinski, Andrew wrote:


One of the following revision caused a bootstrap comparison failure on
aarch64-linux-gnu:
r246225
r246226
r246227



Can you help narrow that down?


I can though I don't want to duplicate work since Jeff was going to
provision an aarch64 system.  My automated testing is approximately
every hour or so; these commits were within an hour window even.
I did not look into the revisions when I write the email but I suspect
r246227 did NOT cause it since aarch64 does not use reload anymore.

My the box I got isn't terribly fast, but regardless I'll be walking
through each commit to see if I can trigger the failure.

246224 tested OK (as it should).

246225 is in progress.


I have access to a fast box that isn't otherwise in use at the moment so 
I'm taking a look.  r246225 builds OK.  r246226 does not.  So it is 
Bernd's combine patch.  A little experimenting shows that the compare 
difference is triggered by the use of -gtoggle in stage2, which is not 
used in stage3.  Otherwise stage2 and stage3 generate identical code. 
The bug is apparently due to a problem with handling debug insns in the 
combine patch.


Jim

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

[Jim Wilson]

On 03/17/2017 04:12 PM, Jim Wilson wrote:

I have access to a fast box that isn't otherwise in use at the moment so
I'm taking a look.  r246225 builds OK.  r246226 does not.  So it is
Bernd's combine patch.  A little experimenting shows that the compare
difference is triggered by the use of -gtoggle in stage2, which is not
used in stage3.  Otherwise stage2 and stage3 generate identical code.
The bug is apparently due to a problem with handling debug insns in the
combine patch.


Changing a new prev_nonnote_insn call to a prev_nonnote_nondebug_insn 
call appears to solve the problem.  I will have to do a bootstrap and 
make check from scratch to verify.  I also noticed that there is a 
redundant i1 check in the patch which should be fixed also.


Jim

Re: FW: Build failed in Jenkins: BuildThunderX_native_gcc_upstream #1267

[Jeff Law]

On 03/17/2017 05:51 PM, Jim Wilson wrote:

On 03/17/2017 04:12 PM, Jim Wilson wrote:

I have access to a fast box that isn't otherwise in use at the moment so
I'm taking a look.  r246225 builds OK.  r246226 does not.  So it is
Bernd's combine patch.  A little experimenting shows that the compare
difference is triggered by the use of -gtoggle in stage2, which is not
used in stage3.  Otherwise stage2 and stage3 generate identical code.
The bug is apparently due to a problem with handling debug insns in the
combine patch.


Changing a new prev_nonnote_insn call to a prev_nonnote_nondebug_insn
call appears to solve the problem.  I will have to do a bootstrap and
make check from scratch to verify.  I also noticed that there is a
redundant i1 check in the patch which should be fixed also.

Thanks Jim.  My 246226 was just spinning up.

Consider your fixes pre-approved.

jeff