Re: [ARM] Is TARGET_UNIFIED_ASM still needed?

[Richard Earnshaw]

On 22/07/14 16:23, Ramana Radhakrishnan wrote:
> 
> 
> On 22/07/14 14:14, Kyrill Tkachov wrote:
>> Hi all,
>>
>> In the arm backend we've got this TARGET_UNIFIED_ASM macro that is
>> currently on for TARGET_THUMB2 with a comment that says:
>> /* We could use unified syntax for arm mode, but for now we just use it
>>  for Thumb-2.  */
>>
>> I've been doing some work converting the pre-UAL floating point
>> mnemonics to unified syntax and it seems if we were to strictly adhere
>> to this TARGET_UNIFIED_ASM I would have to guard those changes, which
>> would be somewhat ugly.
> 
> I would just change vfp.md to UAL and expect it to work because GAS 
> accepts unified syntax for the floating point instructions even without 
> .syntax unified.
> 
> We need T_U_A until the point of time that the Thumb1 port is converted 
> to UAL, GAS validated against Thumb1 and the rest of the "arm" port is 
> converted to UAL and verified with GAS.
> 
> Additionally if someone were to do the full transition, remember that 
> users need to have a way of mixing non-unified syntax in inline 
> assembler with unified syntax in the rest of the C code.
> 
> 
> regards
> Ramana
> 
>>
>> Is it perhaps time to just drop this and assume unified asm everywhere?
>>
>>
>> Kyrill
>>
>>
> 
> 
> 

We also need to be able to support User's inline assembly that is not in
unified syntax.  Though that might be a different issue to the one
you're trying to address here.

R.

Re: [ARM] Is TARGET_UNIFIED_ASM still needed?

[Kyrill Tkachov]

On 23/07/14 09:55, Richard Earnshaw wrote:

On 22/07/14 16:23, Ramana Radhakrishnan wrote:


On 22/07/14 14:14, Kyrill Tkachov wrote:

Hi all,

In the arm backend we've got this TARGET_UNIFIED_ASM macro that is
currently on for TARGET_THUMB2 with a comment that says:
/* We could use unified syntax for arm mode, but for now we just use it
  for Thumb-2.  */

I've been doing some work converting the pre-UAL floating point
mnemonics to unified syntax and it seems if we were to strictly adhere
to this TARGET_UNIFIED_ASM I would have to guard those changes, which
would be somewhat ugly.

I would just change vfp.md to UAL and expect it to work because GAS
accepts unified syntax for the floating point instructions even without
.syntax unified.

We need T_U_A until the point of time that the Thumb1 port is converted
to UAL, GAS validated against Thumb1 and the rest of the "arm" port is
converted to UAL and verified with GAS.

Additionally if someone were to do the full transition, remember that
users need to have a way of mixing non-unified syntax in inline
assembler with unified syntax in the rest of the C code.


regards
Ramana


Is it perhaps time to just drop this and assume unified asm everywhere?


Kyrill






We also need to be able to support User's inline assembly that is not in
unified syntax.  Though that might be a different issue to the one
you're trying to address here.


Thanks for the responses,
I was just thinking that the TARGET_UNIFIED_ASM macro is not honored 
right now anyway (due to the pre-UAL mnemonics in vfp.md) so we might 
want to get rid of it. I don't think this would be a user-visible 
change, now would it reject pre-UAL inline assembly from what I can see 
in its uses.


Kyrill



R.

Re: [ARM] Is TARGET_UNIFIED_ASM still needed?

[Kyrill Tkachov]

On 23/07/14 09:59, Kyrill Tkachov wrote:

On 23/07/14 09:55, Richard Earnshaw wrote:

On 22/07/14 16:23, Ramana Radhakrishnan wrote:

On 22/07/14 14:14, Kyrill Tkachov wrote:

Hi all,

In the arm backend we've got this TARGET_UNIFIED_ASM macro that is
currently on for TARGET_THUMB2 with a comment that says:
/* We could use unified syntax for arm mode, but for now we just use it
   for Thumb-2.  */

I've been doing some work converting the pre-UAL floating point
mnemonics to unified syntax and it seems if we were to strictly adhere
to this TARGET_UNIFIED_ASM I would have to guard those changes, which
would be somewhat ugly.

I would just change vfp.md to UAL and expect it to work because GAS
accepts unified syntax for the floating point instructions even without
.syntax unified.

We need T_U_A until the point of time that the Thumb1 port is converted
to UAL, GAS validated against Thumb1 and the rest of the "arm" port is
converted to UAL and verified with GAS.

Additionally if someone were to do the full transition, remember that
users need to have a way of mixing non-unified syntax in inline
assembler with unified syntax in the rest of the C code.


regards
Ramana


Is it perhaps time to just drop this and assume unified asm everywhere?


Kyrill





We also need to be able to support User's inline assembly that is not in
unified syntax.  Though that might be a different issue to the one
you're trying to address here.

Thanks for the responses,
I was just thinking that the TARGET_UNIFIED_ASM macro is not honored
right now anyway (due to the pre-UAL mnemonics in vfp.md) so we might
want to get rid of it. I don't think this would be a user-visible
change, now would it reject pre-UAL inline assembly from what I can see
in its uses.


s/now would it/nor would it/



Kyrill


R.

Re: GCC version bikeshedding

[Richard Biener]

On Wed, Jul 23, 2014 at 4:27 AM, Segher Boessenkool
 wrote:
> On Tue, Jul 22, 2014 at 08:44:41AM +0100, Richard Sandiford wrote:
>> So why
>> not just stick to the current scheme and have 5.0.0, 5.0.1, 5.0.2 etc.?
>
> Yes, why would we use a different numbering scheme now?  There is no change
> in development / release planning, unless I missed something.  Is this just
> to have bigger number than the "competition"?  Or is it change for change's
> sake?  Are there no more important things to be done?

It's to avoid the need to decide whether to bump the major version.
For example for the next release I don't see a particularly good reason
to bump from 4.9 to 5.0 - not a reason that wasn't present when going
from 4.8 to 4.9.  And going from 4.9 to 5.0 suggests that 5.0 is
not as stable as 4.9 while in reality our "major" version doesn't carry
any useful information.

Thus, as 4.10.0 is as bad for existing scripts as 5.0.0 take the opportunity
to get rid of that no-information-carrying "major" number (by making
the patchlevel version unused).

And yes, it also looks nicer marketing-wise - but that's not the reason
to change it.

Richard.

>
> Segher

Re: GCC version bikeshedding

[Jason Merrill]

On 07/20/2014 06:01 PM, Jakub Jelinek wrote:

On Sun, Jul 20, 2014 at 05:59:08PM +0100, Richard Biener wrote:

I understood we agreed on 5.0 and further 5.1, 5.2 releases from the
branch and 6.0 a year later.  With unspecified uses for the patch level
number (so leave it at zero).


Ian/Jason, is that your understanding too?


I didn't think that we had come to a decision, but I don't mind going 
ahead with this pattern.


Jason

Re: [Copyright transfer] What to do for copyright transfer to FSF for contracted changes?

[Andre Vehreschild]

Hi,

thanks for all your help. I have contact ass...@gnu.org now. Still waiting for
a reply though.

- Andre
-- 
Andre Vehreschild

C as intermediate language, signed integer overflow and -ftrapv

[Thomas Mertes]

C is popular as intermediate language. This means that some compilers
generate C and use a C compiler as backend. Wikipedia lists several
languages, which use C as intermediate language:
Eiffel, Sather, Esterel, some dialects of Lisp (Lush, Gambit),
Haskell (Glasgow Haskell Compiler), Squeak's Smalltalk-subset Slang,
Cython, Seed7 and Vala.

When C is used as backend the features needed from a C compiler are
different from the features that a human programmer of C needs.

One such feature is the detection of signed integer overflow. It is
not hard, to detect signed integer overflow with a generated C
program, but the performance is certainly not optimal. Signed integer
overflow is undefined behavior in C and the access to some overflow
flag of the CPU is machine dependent. So the generated C code must
recogize overflow before it happens or use unsigned computations and
recognize the overflow afterwards. I have doubts that this leads to
optimal performance.

The C compiler is much better suited to do signed integer overflow
checks. The C compiler can do low level tricks, that would be
undefined behavior in C, and the C compiler also knows about overflow
flags and other details of the CPU. Maybe the CPU can be switched to
a mode where it traps signed integer overflow for free.

The gcc compiler option -ftrapv promises to do exactly that, but it
seems broken. At least my test suite shows that both gcc version
4.6.3 and 4.8.1 fail to detect integer overflow with -ftrapv. The
detection fails even for addition and subtraction. I know that 4.6.3
and 4.8.1 are old, but I found nothing in the internet that tells
me that the situation is better now. So for gcc as C compiler backend
-ftrapv cannot be used and overflow checking in the generated C code
is necessary.

Clang supports -ftrapv reliably. Signed integer overflow raises the
signal SIGILL, which can be catched. Btw. SIGILL seems to be a better
choice, because under windows (7) SIGABRT causes some text to be
written to the console. Is it possible to choose a -ftrapv signal?

A sanitizer such as ubsan is good as tool to find errors in C
programs. But I don't think that ubsan is well suited to do overflow
detection with maximum performance. Is just not the goal of this
tool.

The argumantation that nobody uses -ftrapv is self-fulfilling
prophecy. How can someone expect that a buggy feature is used.
The counterexample is clang, where -ftrapv works and is also used
(E.g. by the integer overflow detection of Seed7).

Conclusion:
Signed integer overflow detection with -ftrapv is NOT something that
nobody uses. It is an important feature. Especially when C is used as
intermediate language. When it works it results in a significant
speed up of signed overflow detection. A sanitizer has a different
purpose and cannot be used as replacement.

I can offer some help with this issue:
I have test programs for cases with integer overflow and for cases
where the result is as big or as small as possible without causing an
overflow. The test programs are not written in C, but are licensed
with the GPL, and it would be possible to convert them to C with
reasonable effort. Maybe this is not necessary, because clang must
have some test suites for -ftrapv.

Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Re: GCC version bikeshedding

[Ian Lance Taylor]

On Wed, Jul 23, 2014 at 3:28 AM, Jason Merrill  wrote:
> On 07/20/2014 06:01 PM, Jakub Jelinek wrote:
>>
>> On Sun, Jul 20, 2014 at 05:59:08PM +0100, Richard Biener wrote:
>>>
>>> I understood we agreed on 5.0 and further 5.1, 5.2 releases from the
>>> branch and 6.0 a year later.  With unspecified uses for the patch level
>>> number (so leave it at zero).
>>
>>
>> Ian/Jason, is that your understanding too?
>
>
> I didn't think that we had come to a decision, but I don't mind going ahead
> with this pattern.

I am also fine with it.

I think that if anybody has strong objections, now is the time to make
them.  Otherwise I think we should go with this plan.

To me, the basic summary of the idea is that there is no clear reason
to ever change the GCC major version number.  There were real
objections to changing it when we went from 3 to 4.  There will be
real objections for any future change from 4 to 5.  At the same time,
we face the fact that going from 4.9 to 4.10 will break some people's
existing scripts, as is also true of any other decision we can make.

Given that there is no clear reason to ever change the major version
number, making that change will not convey any useful information to
our users.  So let's just drop the major version number.  Once we've
made that decision, then the next release (in 2015) naturally becomes
5.0, the release after that (in 2016) becomes 6.0, etc.

Ian

Re: GCC version bikeshedding

[Andreas Schwab]

Ian Lance Taylor  writes:

> At the same time, we face the fact that going from 4.9 to 4.10 will
> break some people's existing scripts, as is also true of any other
> decision we can make.

Looking forward to gcc 10.0. :-)

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: GCC version bikeshedding

[pinskia]

> On Jul 23, 2014, at 9:51 AM, Andreas Schwab  wrote:
> 
> Ian Lance Taylor  writes:
> 
>> At the same time, we face the fact that going from 4.9 to 4.10 will
>> break some people's existing scripts, as is also true of any other
>> decision we can make.
> 
> Looking forward to gcc 10.0. :-)

So are following what sun did?

> 
> 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: C as intermediate language, signed integer overflow and -ftrapv

[David Wohlferd]

I believe that sometimes gcc is promoting the ints to long longs when 
doing the overflow testing.  If I try to overflow a long long, I get the 
trap as expected.


See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020

dw

On 7/23/2014 7:56 AM, Thomas Mertes wrote:

C is popular as intermediate language. This means that some compilers
generate C and use a C compiler as backend. Wikipedia lists several
languages, which use C as intermediate language:
Eiffel, Sather, Esterel, some dialects of Lisp (Lush, Gambit),
Haskell (Glasgow Haskell Compiler), Squeak's Smalltalk-subset Slang,
Cython, Seed7 and Vala.

When C is used as backend the features needed from a C compiler are
different from the features that a human programmer of C needs.

One such feature is the detection of signed integer overflow. It is
not hard, to detect signed integer overflow with a generated C
program, but the performance is certainly not optimal. Signed integer
overflow is undefined behavior in C and the access to some overflow
flag of the CPU is machine dependent. So the generated C code must
recogize overflow before it happens or use unsigned computations and
recognize the overflow afterwards. I have doubts that this leads to
optimal performance.

The C compiler is much better suited to do signed integer overflow
checks. The C compiler can do low level tricks, that would be
undefined behavior in C, and the C compiler also knows about overflow
flags and other details of the CPU. Maybe the CPU can be switched to
a mode where it traps signed integer overflow for free.

The gcc compiler option -ftrapv promises to do exactly that, but it
seems broken. At least my test suite shows that both gcc version
4.6.3 and 4.8.1 fail to detect integer overflow with -ftrapv. The
detection fails even for addition and subtraction. I know that 4.6.3
and 4.8.1 are old, but I found nothing in the internet that tells
me that the situation is better now. So for gcc as C compiler backend
-ftrapv cannot be used and overflow checking in the generated C code
is necessary.

Clang supports -ftrapv reliably. Signed integer overflow raises the
signal SIGILL, which can be catched. Btw. SIGILL seems to be a better
choice, because under windows (7) SIGABRT causes some text to be
written to the console. Is it possible to choose a -ftrapv signal?

A sanitizer such as ubsan is good as tool to find errors in C
programs. But I don't think that ubsan is well suited to do overflow
detection with maximum performance. Is just not the goal of this
tool.

The argumantation that nobody uses -ftrapv is self-fulfilling
prophecy. How can someone expect that a buggy feature is used.
The counterexample is clang, where -ftrapv works and is also used
(E.g. by the integer overflow detection of Seed7).

Conclusion:
Signed integer overflow detection with -ftrapv is NOT something that
nobody uses. It is an important feature. Especially when C is used as
intermediate language. When it works it results in a significant
speed up of signed overflow detection. A sanitizer has a different
purpose and cannot be used as replacement.

I can offer some help with this issue:
I have test programs for cases with integer overflow and for cases
where the result is as big or as small as possible without causing an
overflow. The test programs are not written in C, but are licensed
with the GPL, and it would be possible to convert them to C with
reasonable effort. Maybe this is not necessary, because clang must
have some test suites for -ftrapv.

Greetings Thomas Mertes

--
Seed7 Homepage:  http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

Re: GCC version bikeshedding

[Jakub Jelinek]

On Wed, Jul 23, 2014 at 09:20:23AM -0700, Ian Lance Taylor wrote:
> I think that if anybody has strong objections, now is the time to make
> them.  Otherwise I think we should go with this plan.

My preference was to keep the current versioning scheme, after all, even
right now it is IMHO worthwhile to tell users about to significant user
visible change with libstdc++ ABI.
But not a strong objection from me.

Jakub

Re: Question for ARM person re asm_fprintf

[Hans-Peter Nilsson]

On Mon, 21 Jul 2014, David Wohlferd wrote:

> I have been looking at asm_fprintf in final.c, and I think there's a design
> flaw.  But since the change affects ARM and since I have no access to an ARM
> system, I need a second opinion.

There's this thing called cross-compilation, which happens for
more than 99% (my guess) of the compiled ARM code distributed in
the world - and I believe what most people here do ARM-wise.
(Your target system doesn't have to match your host system!)

> It would be helpful if someone could confirm that it still
> compiles without error under ARM after applying this patch.  I'm reluctant to
> post this to gcc-patches when it has never been run.

Not that the following would constitute the actual testing
usually required for a patch, but:

/path/to/toplevel/configure --target=arm-eabi && make all-gcc
# Yay, the compiler-proper for a "bare iron" ARM compiler.

./gcc/xgcc -B./gcc -S test.c

Woot, compiled your first ARM program. :)  Just emitting text
assembly code, and #include's won't work, but a missing-case
leading-to-abort would be prominently noticed as an internal
compiler error.

The page  is
unfortunately out of date (e.g. binutils+sim now lives in the
same git repo) but it gives you the idea.

Happy hacking.
brgds, H-P

gcc-4.9-20140723 is now available

[gccadmin]

Snapshot gcc-4.9-20140723 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140723/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch 
revision 212964

You'll find:

 gcc-4.9-20140723.tar.bz2 Complete GCC

  MD5=152f446c240e7cb2856ef2b256722b26
  SHA1=2b6fb3a12733a12fb1a95acbdb116301127753bb

Diffs from 4.9-20140716 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Slides from Cauldron talks

[David Malcolm]

I didn't see a place to post slides for Cauldron talks, so am posting
links to them here.


"Just-In-Time compilation using GCC (libgccjit.so)"
===
HTML slides:
http://dmalcolm.fedorapeople.org/presentations/cauldron-2014/jit/

Source code used for generating the HTML slides:
https://github.com/davidmalcolm/2014-cauldron-jit-talk/blob/master/source/index.rst


"A proposal for typesafe RTL"
=
HTML slides:
http://dmalcolm.fedorapeople.org/presentations/cauldron-2014/rtl

Source code used for generating the HTML slides:
https://github.com/davidmalcolm/2014-cauldron-rtl-talk/blob/master/source/index.rst


(both talks built using Sphinx, using the hieroglyph.io extension, which
adds an HTML slides backend.  Sphinx is superb)


Does anyone know if any Cauldron talks were recorded?

Thanks
Dave

Re: Question for ARM person re asm_fprintf

[David Wohlferd]

Not that the following would constitute the actual testing
usually required for a patch, but:

/path/to/toplevel/configure --target=arm-eabi && make all-gcc
# Yay, the compiler-proper for a "bare iron" ARM compiler.

./gcc/xgcc -B./gcc -S test.c

Woot, compiled your first ARM program. :)  Just emitting text
assembly code, and #include's won't work, but a missing-case
leading-to-abort would be prominently noticed as an internal
compiler error.


I just tried this and I did get it to build and run.  And it's true that 
invalid formats do cause an error, even just using -S.  But I'm still 
glad that kyrill tried it too.


So I've sent this to gcc-patches.  Now comes the hard part: Patience...

dw

Re: Slides from Cauldron talks

[Tobias Burnus]

David Malcolm wrote:

I didn't see a place to post slides for Cauldron talks, so am posting
links to them here.


I have added the links to
https://gcc.gnu.org/wiki/cauldron2014#Slides_and_Notes


Does anyone know if any Cauldron talks were recorded?


At least the ones in Lecture Theatre One were. However, I don't know 
when the organizers will upload the videos.


Tobias