Re: libgcc-arch.ver details

[Paulo J. Matos]

On Mon, Mar 22, 2010 at 5:48 PM, Ian Lance Taylor  wrote:
> "Paulo J. Matos"  writes:
>
>> After looking into the arm code I am quite confused since even though
>> it uses HF (at least I found references to it in gcc4.5, but not in
>> gcc4.3 or gcc4.4), I can't see how it's importing floatunsihf. In
>> fact, I can't find any reference to a function called floatunsihf
>> anywhere on gccs source code and documentation also doesn't contain
>> any references to it.
>
> See, e.g., LIB2FUNCS_STATIC_EXTRA in config/arm/t-bpabi, and
> config/arm/fp16.c, and the calls to set_conv_libfunc in
> arm_init_libfuncs in config/arm/arm.c.
>
> Ian
>

I have been slowly hammering on this issue to get it to work but the
compiler is still generating a call to floatunsihf and it fails to
link. Now, I am confused as to whether what needs to be done is
hand-code this function for my particular arch or get GCC to
internally convert the float to something else and get that handled
for free.

By looking at the ARM code like you suggested I can see that fp16.c
defines two functions that seems to convert half floats to single
floats and vice versa. These function then get registered in arm.c as
conversion functions. I did the same thing but it doesn't work and I
can't see what should trigger these conversions. Any further help
would be great.

Thanks,

-- 
PMatos

Submitting a patch for an architecture without a maintainer

[Samuel Tardieu]

Hi.

GCC 4.5.0 will ship with support for lm32. This is an IP which can be
configured in several ways (with or without barrel shifter, and with or
without a hardware multiplier).

To be usable in all cases, it has to support multilib. The support is
present but broken: the "MULTILIB_OPTIONS" variable is located in the
wrong file!

I submitted a small patch from a colleague of mine
(http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00307.html) and sent three
PING already. But since there is no listed maintainer for lm32, it seems
that it doesn't draw any attention from anyone who can approve it, so I
cannot check it in.

If we do not apply it, the multilib option for this new target will be
broken in 4.5.0. I know we are late in the development stage, but lm32
is a new target and reading the patch makes it clear that it cannot
break any other platform.

I know you guys are all very busy but I am not able to reach anyone
interested in lm32 on gcc-patches. Could someone with global commit
rights have a look at this patch and approve/reject/delay it?

  http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00307.html

 Sam

PS/ Note that I don't use this architecture myself and I am not
interested in becoming its maintainer -- I just happen to know
someone who uses it and noticed that GCC was broken.
-- 
Samuel Tardieu -- s...@rfc1149.net -- http://www.rfc1149.net/

Re: Submitting a patch for an architecture without a maintainer

[Richard Guenther]

On Tue, Mar 30, 2010 at 10:47 AM, Samuel Tardieu  wrote:
> Hi.
>
> GCC 4.5.0 will ship with support for lm32. This is an IP which can be
> configured in several ways (with or without barrel shifter, and with or
> without a hardware multiplier).
>
> To be usable in all cases, it has to support multilib. The support is
> present but broken: the "MULTILIB_OPTIONS" variable is located in the
> wrong file!
>
> I submitted a small patch from a colleague of mine
> (http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00307.html) and sent three
> PING already. But since there is no listed maintainer for lm32, it seems
> that it doesn't draw any attention from anyone who can approve it, so I
> cannot check it in.
>
> If we do not apply it, the multilib option for this new target will be
> broken in 4.5.0. I know we are late in the development stage, but lm32
> is a new target and reading the patch makes it clear that it cannot
> break any other platform.
>
> I know you guys are all very busy but I am not able to reach anyone
> interested in lm32 on gcc-patches. Could someone with global commit
> rights have a look at this patch and approve/reject/delay it?
>
>  http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00307.html

The patch is ok.

I wonder why we even accepted a new port without a maintainer though.
David?

Thanks,
Richard.

>  Sam
>
> PS/ Note that I don't use this architecture myself and I am not
>    interested in becoming its maintainer -- I just happen to know
>    someone who uses it and noticed that GCC was broken.
> --
> Samuel Tardieu -- s...@rfc1149.net -- http://www.rfc1149.net/
>
>

Re: Submitting a patch for an architecture without a maintainer

[Joel Sherrill]

On 03/30/2010 05:14 AM, Richard Guenther wrote:

On Tue, Mar 30, 2010 at 10:47 AM, Samuel Tardieu  wrote:
   

Hi.

GCC 4.5.0 will ship with support for lm32. This is an IP which can be
configured in several ways (with or without barrel shifter, and with or
without a hardware multiplier).

To be usable in all cases, it has to support multilib. The support is
present but broken: the "MULTILIB_OPTIONS" variable is located in the
wrong file!

I submitted a small patch from a colleague of mine
(http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00307.html) and sent three
PING already. But since there is no listed maintainer for lm32, it seems
that it doesn't draw any attention from anyone who can approve it, so I
cannot check it in.

If we do not apply it, the multilib option for this new target will be
broken in 4.5.0. I know we are late in the development stage, but lm32
is a new target and reading the patch makes it clear that it cannot
break any other platform.

I know you guys are all very busy but I am not able to reach anyone
interested in lm32 on gcc-patches. Could someone with global commit
rights have a look at this patch and approve/reject/delay it?

  http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00307.html
 

The patch is ok.

I wonder why we even accepted a new port without a maintainer though.
David?

   

I thought Jon Beniston was maintainer of this.  He may not
have listed himself.

FWIW I filed a PR for an ICE on this target last week:

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

--joel

Thanks,
Richard.

   

  Sam

PS/ Note that I don't use this architecture myself and I am not
interested in becoming its maintainer -- I just happen to know
someone who uses it and noticed that GCC was broken.
--
Samuel Tardieu -- s...@rfc1149.net -- http://www.rfc1149.net/


 

Re: Submitting a patch for an architecture without a maintainer

[Richard Guenther]

On Tue, Mar 30, 2010 at 12:40 PM, Joel Sherrill
 wrote:
> On 03/30/2010 05:14 AM, Richard Guenther wrote:
>>
>> On Tue, Mar 30, 2010 at 10:47 AM, Samuel Tardieu  wrote:
>>
>>>
>>> Hi.
>>>
>>> GCC 4.5.0 will ship with support for lm32. This is an IP which can be
>>> configured in several ways (with or without barrel shifter, and with or
>>> without a hardware multiplier).
>>>
>>> To be usable in all cases, it has to support multilib. The support is
>>> present but broken: the "MULTILIB_OPTIONS" variable is located in the
>>> wrong file!
>>>
>>> I submitted a small patch from a colleague of mine
>>> (http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00307.html) and sent three
>>> PING already. But since there is no listed maintainer for lm32, it seems
>>> that it doesn't draw any attention from anyone who can approve it, so I
>>> cannot check it in.
>>>
>>> If we do not apply it, the multilib option for this new target will be
>>> broken in 4.5.0. I know we are late in the development stage, but lm32
>>> is a new target and reading the patch makes it clear that it cannot
>>> break any other platform.
>>>
>>> I know you guys are all very busy but I am not able to reach anyone
>>> interested in lm32 on gcc-patches. Could someone with global commit
>>> rights have a look at this patch and approve/reject/delay it?
>>>
>>>  http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00307.html
>>>
>>
>> The patch is ok.
>>
>> I wonder why we even accepted a new port without a maintainer though.
>> David?
>>
>>
>
> I thought Jon Beniston was maintainer of this.  He may not
> have listed himself.

The SC didn't appoint a maintainer for lm32 as far as I can see.

Richard.

Re: gmp 5.0.1 and gcc 4.5?

[Vincent Lefevre]

Hi,

On 2010-03-29 17:05:09 +, Joseph S. Myers wrote:
> GMP is mainly used via MPFR.  Thus, I'd expect the required version to be 
> bumped if a new MPFR version was required that in turn required newer GMP, 
> but otherwise there would be little use to a bump.  New MPFR would be 
> required if needed for folding some function of use to GCC to fold 
> (erfc_scaled has been mentioned as one it would be useful to the Fortran 
> front end to have MPFR support for, for example, but SVN MPFR doesn't yet 
> support it; if it gains support, that might justify a future increase in 
> the required MPFR version).

FYI, if someone is interested, anyone can contribute:

  http://www.mpfr.org/contrib.html

Otherwise, I fear that the implementation of most functions will not
happen before several years.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

RE: BB reorder forced off for -Os

[Ian Bolton]

> We're not able to enable BB reordering with -Os.  The behaviour is
> hard-coded via this if statement in rest_of_handle_reorder_blocks():
> 
>   if ((flag_reorder_blocks || flag_reorder_blocks_and_partition)
>   /* Don't reorder blocks when optimizing for size because extra
> jump insns may
>be created; also barrier may create extra padding.
> 
>More correctly we should have a block reordering mode that
tried
> to
>minimize the combined size of all the jumps.  This would more
or
> less
>automatically remove extra jumps, but would also try to use
more
> short
>jumps instead of long jumps.  */
>   && optimize_function_for_speed_p (cfun))
> {
>   reorder_basic_blocks ();
> 
> If you comment out the "&& optimize_function_for_speed_p (cfun)" then
> BB reordering takes places as desired (although this isn't a solution
> obviously).
> 
> In a private message Ian indicated that this had a small impact for
the
> ISA he's working with but a significant performance gain.  I tried the
> same thing with the ISA I work on (Ubicom32) and this change typically
> increased code sizes by between 0.1% and 0.3% but improved performance
> by anything from 0.8% to 3% so on balance this is definitely winning
> for most of our users (this for a couple of benchmarks, the Linux
> kernel, busybox and smbd).
> 

It should be noted that commenting out the conditional to do with
optimising for speed will make BB reordering come on for all functions,
even cold ones, so I think whatever gains have come from making this
hacky change could increase further if BB reordering is set to
only come on for hot functions when compiling with -Os.  (Certainly
the code size increases could be minimised, whilst hopefully retaining
the performance gains.)

Note that I am in no way suggesting this should be the default
behaviour for -Os, but that it should be switchable via the
flags just like other optimisations are.  But, once it is switchable,
I expect choosing to turn it on for -Os should not cause universal
enabling of BB reordering for every function (as opposed to the current
universal disabling of BB reordering for every function), but a sensible
half-way point, based on heat, so that you get the performance wins with
minimal code size increases on selected functions.

Cheers,
Ian

Re: GSoC 2010 Project Idea

[Joseph S. Myers]

On Sun, 28 Mar 2010, áÒÔÅÍ ûÉÎËÁÒÏ× wrote:

> It would be much easier for the programmer to use an abstract layer to
> implement a vectorized code. A compiler should deal with the portability 
> issues
> dispatching the code from the abstract layer to the particular architecture. 
> My

The generic vector types (used with the vector_size attribute) could be 
seen as the beginnings of such an abstract layer.

So you might look at what isn't supported readily with such types at 
present.  Note that patches have been submitted but not committed for some 
features (e.g. subscripting vectors like arrays) that would need pushing 
through into GCC.  Then you could look at related extensions in other 
implementations or related languages (e.g. OpenCL) that might be useful 
for GNU C and C++ generic vectors.

What vector instructions are there that cannot be effectively represented 
using generic vectors (supposing that you add the ability to subscript 
them, which helps describe a lot of operations using compound literals)?  
They might need further extensions.  Are there instructions that can be 
effectively represented but where the generic representation in C source 
does not end up generating the right instructions?  If so, you could 
improve the compiler so that given generic C+vectors source, and generic 
RTL patterns for the instruction, it ends up generating that instruction.

One subset of the problem you could look at would be saturating operations 
- both for scalars and for vectors.  For some such operations, built-in 
functions might help.  Some can be written in generic C, but the compiler 
won't detect them and generate saturating instructions.  See a paper of 
Bik, Girkar, Grey and Tian 
 regarding how 
to detect saturating operations.  There are generic RTL codes for some 
saturating operations - but they will only ever be generated from 
target-specific built-in functions at present.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: libgcc-arch.ver details

[Paulo J. Matos]

On Tue, Mar 30, 2010 at 9:33 AM, Paulo J. Matos  wrote:
>
> I have been slowly hammering on this issue to get it to work but the
> compiler is still generating a call to floatunsihf and it fails to
> link. Now, I am confused as to whether what needs to be done is
> hand-code this function for my particular arch or get GCC to
> internally convert the float to something else and get that handled
> for free.
>
> By looking at the ARM code like you suggested I can see that fp16.c
> defines two functions that seems to convert half floats to single
> floats and vice versa. These function then get registered in arm.c as
> conversion functions. I did the same thing but it doesn't work and I
> can't see what should trigger these conversions. Any further help
> would be great.
>

Please do ignore this message. I have found that I were in some
confusion with regards to using fp-bit versus softfp.

Some new questions came up so therefore I will start a new thread.

-- 
PMatos

Software FP Support

[Paulo J. Matos]

Hi,

I am trying to get FP support working in a backend. This raised
several questions which were promptly answered and after digging
deeper I found the culprit.
GCC is generating a call to floatunsihf when it needs to convert an
unsigned integer to a float. And this call is being generated because
I am compiling to a 16bit target, where floats are 32, meaning floats
are HFmode.

Now, I read in http://gcc.gnu.org/wiki/Software_floating_point that
soft-fp doesn't support 16bit targets, but (even if slow) does fp-bit
support 16bit target?
I just need a rudimentary floating point support (speed is not
important) and I am trying to avoid assembler.

Would I be able to get it working with fp-bit or maybe setting the
FLOAT_TYPE_SIZE to something different than 32?

-- 
PMatos

Re: Software FP Support

[Joseph S. Myers]

On Tue, 30 Mar 2010, Paulo J. Matos wrote:

> GCC is generating a call to floatunsihf when it needs to convert an
> unsigned integer to a float. And this call is being generated because
> I am compiling to a 16bit target, where floats are 32, meaning floats
> are HFmode.

No, HFmode only exists if you specifically define it to exist for a 
target.  Unless you really know what you are doing, you should not define 
it until you have ordinary float (SFmode) working.  If HFmode calls are 
generated without having defined it as a target-specific mode, something 
is wrong you need to resolve.

The basic unit for machine modes is QImode, meaning one byte - 
BITS_PER_UNIT bits (8 bits unless you know exactly what you are doing and 
are prepared to fix many broken and bit-rotten cases in 
machine-independent code).  HImode and HFmode are modes of 2*BITS_PER_UNIT 
bits.  SImode and SFmode are modes of 4*BITS_PER_UNIT bits.  So presuming 
BITS_PER_UNIT is 8, a 32-bit float should be SFmode; a 16-bit integer 
value should be HImode (for any target with 8-bit bytes, whatever the word 
size).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Software FP Support

[Paulo J. Matos]

On Tue, Mar 30, 2010 at 2:29 PM, Joseph S. Myers
 wrote:
> On Tue, 30 Mar 2010, Paulo J. Matos wrote:
>
>> GCC is generating a call to floatunsihf when it needs to convert an
>> unsigned integer to a float. And this call is being generated because
>> I am compiling to a 16bit target, where floats are 32, meaning floats
>> are HFmode.
>
> No, HFmode only exists if you specifically define it to exist for a
> target.  Unless you really know what you are doing, you should not define
> it until you have ordinary float (SFmode) working.  If HFmode calls are
> generated without having defined it as a target-specific mode, something
> is wrong you need to resolve.
>

I didn't define the HFmode but gcc still generates this call (reason is below).

> The basic unit for machine modes is QImode, meaning one byte -
> BITS_PER_UNIT bits (8 bits unless you know exactly what you are doing and
> are prepared to fix many broken and bit-rotten cases in
> machine-independent code).  HImode and HFmode are modes of 2*BITS_PER_UNIT
> bits.  SImode and SFmode are modes of 4*BITS_PER_UNIT bits.  So presuming
> BITS_PER_UNIT is 8, a 32-bit float should be SFmode; a 16-bit integer
> value should be HImode (for any target with 8-bit bytes, whatever the word
> size).
>

I have 16 BITS_PER_UNIT for this target, with 1 UNITS_PER_WORD. If I
define FLOAT_TYPE_SIZE to be 32, then a float is an HFmode and it's
not that gcc uses this.
Defining BITS_PER_UNIT to 16 shouldn't generate problems inside the
compiler given that GCC has generic treatment for these situations
(otherwise GCC should state that only BITS_PER_UNIT=8 is supported).
The problem is how to integrate software floating point support for
this target where a float is not SFmode 'as usual'.

> --
> Joseph S. Myers
> jos...@codesourcery.com
>



-- 
PMatos

Re: Software FP Support

[Paulo J. Matos]

On Tue, Mar 30, 2010 at 2:29 PM, Joseph S. Myers
 wrote:
> No, HFmode only exists if you specifically define it to exist for a
> target.  Unless you really know what you are doing, you should not define
> it until you have ordinary float (SFmode) working.  If HFmode calls are
> generated without having defined it as a target-specific mode, something
> is wrong you need to resolve.
>
> The basic unit for machine modes is QImode, meaning one byte -
> BITS_PER_UNIT bits (8 bits unless you know exactly what you are doing and
> are prepared to fix many broken and bit-rotten cases in
> machine-independent code).  HImode and HFmode are modes of 2*BITS_PER_UNIT
> bits.  SImode and SFmode are modes of 4*BITS_PER_UNIT bits.  So presuming
> BITS_PER_UNIT is 8, a 32-bit float should be SFmode; a 16-bit integer
> value should be HImode (for any target with 8-bit bytes, whatever the word
> size).
>

Hello Joseph, let me add something to my last email.
From your email I get the feeling that you can explicitly enable the
HFmode, how can I check if this is being done?

On a surprising note, I decided to try and compile it with
FLOAT_TYPE_SIZE with 64 bits, therefore a float should not be SFmode
and the floatunsihf shouldn't be generated anymore. I was wrong, it is
still generated.

Where are these function calls generated in gcc? (I would expect it to
be during the expand pass but have no idea of where exactly)

-- 
PMatos

Re: Peculiar XPASS of gcc.dg/guality/inline-params.c

[Martin Jambor]

Hi,

On Tue, Mar 30, 2010 at 12:43:39AM +0200, Jan Hubicka wrote:
> > I have run the testcase with the early inliner disabled and noticed
> > that gcc.dg/guality/inline-params.c XPASSes with early inlining and
> > XFAILs without it.  The reason for the (expected) failure is that
> > IPA-CP removes a parameter which is constant (but also unused?).  I
> > reckon this is the reason for the xfail mark and so I guess that early
> > inlining should be disabled in the particular testcase, am I right?
> 
> Well, I guess we should be able to maintain debug info with IPA-CP changes
> (only case where debugging info is difficult to maintain IMO is the case
> of unused argument removal that is explicitely disabled here).  So I guess
> in a way this is correct XFAIL...

I thought so.  The patch below turns at least some of the XPASSes into
XFAILs.  The XPASSes remain with switch combinations when IPA-CP is
not run, I don't know how to get rid of them.  Specifically it turns 

XPASS: gcc.dg/guality/inline-params.c  -O0  execution test
XPASS: gcc.dg/guality/inline-params.c  -O1  execution test
XPASS: gcc.dg/guality/inline-params.c  -O2  execution test
XPASS: gcc.dg/guality/inline-params.c  -O3 -fomit-frame-pointer  execution test
XPASS: gcc.dg/guality/inline-params.c  -O3 -g  execution test
XPASS: gcc.dg/guality/inline-params.c  -Os  execution test
XFAIL: gcc.dg/guality/inline-params.c  -O2 -flto  execution test
XFAIL: gcc.dg/guality/inline-params.c  -O2 -fwhopr  execution test

into

XPASS: gcc.dg/guality/inline-params.c  -O0  execution test
XPASS: gcc.dg/guality/inline-params.c  -O1  execution test
XFAIL: gcc.dg/guality/inline-params.c  -O2  execution test
XFAIL: gcc.dg/guality/inline-params.c  -O3 -fomit-frame-pointer  execution test
XFAIL: gcc.dg/guality/inline-params.c  -O3 -g  execution test
XFAIL: gcc.dg/guality/inline-params.c  -Os  execution test
XFAIL: gcc.dg/guality/inline-params.c  -O2 -flto  execution test
XPASS: gcc.dg/guality/inline-params.c  -O2 -fwhopr  execution test

Only now I have noticed the XFAIL->XPASS in whopr, I wonder what to do
with that (if anything)...

However, given that whopr is still rather experimental, if anybody at
any point actually looks at XFAILs, I guess we probably should apply
the patch, XPASSes in a guality test are confusing and someone might
just remove the xfail mark.  So, OK for trunk?

Thanks (I hope that's the end of various testsuite trivia for now),

Martin


2010-03-30  Martin Jambor  

* inline-params.c: Disable early inlining.

Index: gcc/testsuite/gcc.dg/guality/inline-params.c
===
--- gcc/testsuite/gcc.dg/guality/inline-params.c(revision 157786)
+++ gcc/testsuite/gcc.dg/guality/inline-params.c(working copy)
@@ -1,6 +1,8 @@
 /* { dg-do run { xfail *-*-* } } */
-/* IPA-SRA removes the argumet as dead, so we don't see their values.  */
-/* { dg-options "-g -fno-ipa-sra" } */
+/* IPA-SRA removes the argumet as dead, so we don't see their values, early
+   inlining inlines the functions too early to test the real IPA passes (such
+   as IPA-CP). */
+/* { dg-options "-g -fno-early-inlining -fno-ipa-sra" } */
 #define GUALITY_DONT_FORCE_LIVE_AFTER -1
 
 #ifndef STATIC_INLINE

Re: Software FP Support

[Paulo J. Matos]

On Tue, Mar 30, 2010 at 2:54 PM, Paulo J. Matos  wrote:
>
> On a surprising note, I decided to try and compile it with
> FLOAT_TYPE_SIZE with 64 bits, therefore a float should not be SFmode
> and the floatunsihf shouldn't be generated anymore. I was wrong, it is
> still generated.
>

This is false, I forgot to regenerate the assembler for the file I was
testing on. In this case, it does change the call to a floatunsisf, as
expected. However, this is not practical for my purposes. It still
makes more sense to me to have float as 32bits.


-- 
PMatos

Re: Software FP Support

[Joseph S. Myers]

On Tue, 30 Mar 2010, Paulo J. Matos wrote:

> I have 16 BITS_PER_UNIT for this target, with 1 UNITS_PER_WORD. If I
> define FLOAT_TYPE_SIZE to be 32, then a float is an HFmode and it's
> not that gcc uses this.
> Defining BITS_PER_UNIT to 16 shouldn't generate problems inside the
> compiler given that GCC has generic treatment for these situations

The GCC support for BITS_PER_UNIT values other than 8 is extremely 
bitrotten and parts of it have never worked; there are no such targets in 
the GCC source tree, no patches are tested for such targets and it is easy 
to have hidden dependencies on 8-bit bytes.  It is very inadvisable to 
make your first port one to such an unusual target; substantially more GCC 
experience and expertise is needed for doing a port to a system different 
from all supported systems and that challenges hidden assumptions in the 
GCC code.  There will be a large amount of work finding and fixing issues 
related to non-8-bit bytes that will need doing before you have a working 
integer port, and all that should be done before you look at 
floating-point issues.

If seriously interested in fixing support for non-8-bit bytes, first 
understand exactly what the C semantics are for such systems (including 
how strings are meant to work).  Then read my various past messages to the 
GCC lists discussing aspects of support for such systems in GCC (which you 
should be able to find for yourself in the list archives).  Improving wide 
string support for normal 8-bit-byte systems (so that optimization etc. 
infrastructure can work with both wide and narrow strings) may be a useful 
starting point for making some things work when the characters in narrow 
strings are more than one host byte.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Software FP Support

[Paulo J. Matos]

On Tue, Mar 30, 2010 at 3:29 PM, Joseph S. Myers
 wrote:
> On Tue, 30 Mar 2010, Paulo J. Matos wrote:
>
>> I have 16 BITS_PER_UNIT for this target, with 1 UNITS_PER_WORD. If I
>> define FLOAT_TYPE_SIZE to be 32, then a float is an HFmode and it's
>> not that gcc uses this.
>> Defining BITS_PER_UNIT to 16 shouldn't generate problems inside the
>> compiler given that GCC has generic treatment for these situations
>
> The GCC support for BITS_PER_UNIT values other than 8 is extremely
> bitrotten and parts of it have never worked; there are no such targets in
> the GCC source tree, no patches are tested for such targets and it is easy
> to have hidden dependencies on 8-bit bytes.  It is very inadvisable to
> make your first port one to such an unusual target; substantially more GCC
> experience and expertise is needed for doing a port to a system different
> from all supported systems and that challenges hidden assumptions in the
> GCC code.  There will be a large amount of work finding and fixing issues
> related to non-8-bit bytes that will need doing before you have a working
> integer port, and all that should be done before you look at
> floating-point issues.
>
> If seriously interested in fixing support for non-8-bit bytes, first
> understand exactly what the C semantics are for such systems (including
> how strings are meant to work).  Then read my various past messages to the
> GCC lists discussing aspects of support for such systems in GCC (which you
> should be able to find for yourself in the list archives).  Improving wide
> string support for normal 8-bit-byte systems (so that optimization etc.
> infrastructure can work with both wide and narrow strings) may be a useful
> starting point for making some things work when the characters in narrow
> strings are more than one host byte.

Thank you for all the discussion regarding the GCC support to 16bit
targets. I had noticed already issues with wide-char strings which was
another pending subject. :)
I will be careful with gcc in this respect and make sure I start
fixing issues regarding 'unusual' 16bit targets.


-- 
PMatos

Re: GSoC 2010 Project Idea

[Артем Шинкаров]

> The generic vector types (used with the vector_size attribute) could be
> seen as the beginnings of such an abstract layer.

Yes, this is very likely is going to be a starting point. I'm sorry
that I have not mentioned this in my first email. Maybe there could be
some alternative ideas how it should look like. But this is the most
obvious one.

Basically, general vectors support only a restricted set of
operations: +, -, *, /, &, |, ^, ~

The indexing, as you already said, is not supported. I know about this
patch, but the question is what would be the most efficient way  to
implement it. Do we always want to return a value or a memory address
of the particular vector element, or may be we can optimize the set of
operations using vector-shifting and vector-masking to keep an element
just inside the vector. Sometimes it could be faster.

You cannot compare two vectors, although you have built-in
instructions for that.

You cannot do shifts within a vector and it could be very useful.
Sometimes general vector extension just fails, producing a code that
causes Segmentation fault. For example:

#include 
#define N 1024

typedef short __attribute__((vector_size(16))) v8hi;

short a[N];
v8hi *pa = (v8hi *)a, *pvt;
v8hi va;

int main(int argc, char *argv[]) {
FILE *f;
int i, var;

f = fopen(argv[1], "r");
for (i = 0; i < N; i++) {
fscanf(f, "%i", &var);
a[i] = (short) var;
}

printf("Before the assignment\n");

va  = *((v8hi *)&(a[0]));
pvt =  ((v8hi *)&(a[3]));
*pvt = va;

printf("After the assignment\n");

for (i = 0; i < 20; i++) {
printf("%i ", a[i]);
}
printf("\n");

fclose (f);

}

all the vector assignments are converted in case of intel architecture
into instruction "movdqa" which works only if memory is aligned, which
is not the case in this example. Compiler can't figure it out and
produces a code which causes segmentation fault. Although if you would
compile the same code on an architecture without SIMD support then it
works fine.

It is surely not a very serious bug but it makes hard to use generic
vector support.

Reduction of the operation is not supported, you can't sum over the
vector of elements. Some architectures have a support for this feature
as well.

Permutation of elements within a vector.

Saturated arithmetic. But I'm not an expert in that field. I mean I
don't know what kind o instructions each architecture provides for
saturated arithmetic. But I think it would not be hard to find it out.

And some more.

The question is what should be done at the first stage. It is surely a
very big project, not for one summer. Depending on the taste of the
mentor, different things could be done as at the beginning. Are you
interested in mentoring this project?



--
Artem Shinkarov

accepting a new write-after-approval maintainer (student, Jeremie Salvucci)

[Basile Starynkevitch]

Hello

(sorry for bothering the list, it probably probably is relevant only to 
the persons managing the SSH accounts).



A young French student - Jérémie Salvucci - in CC wants to contribute to 
GCC and has obtained from his university a signed disclaimer, and has 
sent it (probably by scanning a jpeg & emailing it) to [probably] the 
lawyers or copyright at gcc.org...


He apparently did  obtain a positive human answer.

I thought that was enough to get an SSH account (ie write after approval 
SVN acccess). Apparently, I cannot sponsor him, since I have only

"submit-after-approval privileges and do not have the right to sponsor
anyone else for gcc." (he was told by email).

What is the exact procedure to follow?

BTW, that same student candidated for a 3 month internship at my 
employing organization (CEA LIST). In the likely event he is getting the 
necessary security clearance (CEA is a nuclear governmental organization 
in France, ...) what is the procedure to have him (later) authorized to 
submit to GCC (being convered -as any CEA employee- by the same 
copyright agreement than I am 
http://gcc.gnu.org/ml/gcc/2006-12/msg8.html RT306238).


So actually, I have two questions:

1. how to admit as soon as possible (as a a write-after-approval 
maintainer) a student who did get a signed copyright disclaimer from his 
university to get a SVN+ssh write account to GCC


2. later on, how to change temporarily that student to be convered by 
the CEA copyright transfer, if his is accepted as intern. His internship 
at CEA might start on first of june 2010 till 31 of august 2010.


Sorry for bothering the list, but I don't understand all the details.

Regards.

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Peculiar XPASS of gcc.dg/guality/inline-params.c

[Janis Johnson]

On Tue, Mar 30, 2010 at 7:09 AM, Martin Jambor  wrote:
> Hi,
>
> On Tue, Mar 30, 2010 at 12:43:39AM +0200, Jan Hubicka wrote:
>> > I have run the testcase with the early inliner disabled and noticed
>> > that gcc.dg/guality/inline-params.c XPASSes with early inlining and
>> > XFAILs without it.  The reason for the (expected) failure is that
>> > IPA-CP removes a parameter which is constant (but also unused?).  I
>> > reckon this is the reason for the xfail mark and so I guess that early
>> > inlining should be disabled in the particular testcase, am I right?
>>
>> Well, I guess we should be able to maintain debug info with IPA-CP changes
>> (only case where debugging info is difficult to maintain IMO is the case
>> of unused argument removal that is explicitely disabled here).  So I guess
>> in a way this is correct XFAIL...
>
> I thought so.  The patch below turns at least some of the XPASSes into
> XFAILs.  The XPASSes remain with switch combinations when IPA-CP is
> not run, I don't know how to get rid of them.  Specifically it turns
>
> XPASS: gcc.dg/guality/inline-params.c  -O0  execution test
> XPASS: gcc.dg/guality/inline-params.c  -O1  execution test
> XPASS: gcc.dg/guality/inline-params.c  -O2  execution test
> XPASS: gcc.dg/guality/inline-params.c  -O3 -fomit-frame-pointer  execution 
> test
> XPASS: gcc.dg/guality/inline-params.c  -O3 -g  execution test
> XPASS: gcc.dg/guality/inline-params.c  -Os  execution test
> XFAIL: gcc.dg/guality/inline-params.c  -O2 -flto  execution test
> XFAIL: gcc.dg/guality/inline-params.c  -O2 -fwhopr  execution test
>
> into
>
> XPASS: gcc.dg/guality/inline-params.c  -O0  execution test
> XPASS: gcc.dg/guality/inline-params.c  -O1  execution test
> XFAIL: gcc.dg/guality/inline-params.c  -O2  execution test
> XFAIL: gcc.dg/guality/inline-params.c  -O3 -fomit-frame-pointer  execution 
> test
> XFAIL: gcc.dg/guality/inline-params.c  -O3 -g  execution test
> XFAIL: gcc.dg/guality/inline-params.c  -Os  execution test
> XFAIL: gcc.dg/guality/inline-params.c  -O2 -flto  execution test
> XPASS: gcc.dg/guality/inline-params.c  -O2 -fwhopr  execution test
>
> Only now I have noticed the XFAIL->XPASS in whopr, I wonder what to do
> with that (if anything)...

Take a look at the documentation for dg-xfail-run-if in
http://gcc.gnu.org/onlinedocs/gccint/Directives.html#Directives and see if
that helps.

Janis

Re: Peculiar XPASS of gcc.dg/guality/inline-params.c

[Martin Jambor]

Hi,

On Tue, Mar 30, 2010 at 10:14:16AM -0700, Janis Johnson wrote:
> On Tue, Mar 30, 2010 at 7:09 AM, Martin Jambor  wrote:
> > On Tue, Mar 30, 2010 at 12:43:39AM +0200, Jan Hubicka wrote:
> >> > I have run the testcase with the early inliner disabled and noticed
> >> > that gcc.dg/guality/inline-params.c XPASSes with early inlining and
> >> > XFAILs without it.  The reason for the (expected) failure is that
> >> > IPA-CP removes a parameter which is constant (but also unused?).  I
> >> > reckon this is the reason for the xfail mark and so I guess that early
> >> > inlining should be disabled in the particular testcase, am I right?
> >>
> >> Well, I guess we should be able to maintain debug info with IPA-CP changes
> >> (only case where debugging info is difficult to maintain IMO is the case
> >> of unused argument removal that is explicitely disabled here).  So I guess
> >> in a way this is correct XFAIL...
> >
> > I thought so.  The patch below turns at least some of the XPASSes into
> > XFAILs.  The XPASSes remain with switch combinations when IPA-CP is
> > not run, I don't know how to get rid of them.  Specifically it turns
> >
> > XPASS: gcc.dg/guality/inline-params.c  -O0  execution test
> > XPASS: gcc.dg/guality/inline-params.c  -O1  execution test
> > XPASS: gcc.dg/guality/inline-params.c  -O2  execution test
> > XPASS: gcc.dg/guality/inline-params.c  -O3 -fomit-frame-pointer  execution 
> > test
> > XPASS: gcc.dg/guality/inline-params.c  -O3 -g  execution test
> > XPASS: gcc.dg/guality/inline-params.c  -Os  execution test
> > XFAIL: gcc.dg/guality/inline-params.c  -O2 -flto  execution test
> > XFAIL: gcc.dg/guality/inline-params.c  -O2 -fwhopr  execution test
> >
> > into
> >
> > XPASS: gcc.dg/guality/inline-params.c  -O0  execution test
> > XPASS: gcc.dg/guality/inline-params.c  -O1  execution test
> > XFAIL: gcc.dg/guality/inline-params.c  -O2  execution test
> > XFAIL: gcc.dg/guality/inline-params.c  -O3 -fomit-frame-pointer  execution 
> > test
> > XFAIL: gcc.dg/guality/inline-params.c  -O3 -g  execution test
> > XFAIL: gcc.dg/guality/inline-params.c  -Os  execution test
> > XFAIL: gcc.dg/guality/inline-params.c  -O2 -flto  execution test
> > XPASS: gcc.dg/guality/inline-params.c  -O2 -fwhopr  execution test
> >
> > Only now I have noticed the XFAIL->XPASS in whopr, I wonder what to do
> > with that (if anything)...
> 
> Take a look at the documentation for dg-xfail-run-if in
> http://gcc.gnu.org/onlinedocs/gccint/Directives.html#Directives and see if
> that helps.
> 

Thanks!.  The improved patch below turns the output into what it
should be:

PASS: gcc.dg/guality/inline-params.c  -O0  execution test
PASS: gcc.dg/guality/inline-params.c  -O1  execution test
XFAIL: gcc.dg/guality/inline-params.c  -O2  execution test
XFAIL: gcc.dg/guality/inline-params.c  -O3 -fomit-frame-pointer  execution test
XFAIL: gcc.dg/guality/inline-params.c  -O3 -g  execution test
XFAIL: gcc.dg/guality/inline-params.c  -Os  execution test
XFAIL: gcc.dg/guality/inline-params.c  -O2 -flto  execution test
PASS: gcc.dg/guality/inline-params.c  -O2 -fwhopr  execution test

OK for trunk?

Martin


2010-03-30  Martin Jambor  

* inline-params.c: Disable early inlining.  Xfail run only with -O2,
-O3 or -Os and not with -fwhopr.

Index: gcc/testsuite/gcc.dg/guality/inline-params.c
===
--- gcc/testsuite/gcc.dg/guality/inline-params.c(revision 157786)
+++ gcc/testsuite/gcc.dg/guality/inline-params.c(working copy)
@@ -1,6 +1,10 @@
-/* { dg-do run { xfail *-*-* } } */
-/* IPA-SRA removes the argumet as dead, so we don't see their values.  */
-/* { dg-options "-g -fno-ipa-sra" } */
+/* { dg-do run } */
+/* IPA-SRA removes the argumet as dead, so we don't see their values, early
+   inlining inlines the functions too early to test the real IPA passes (such
+   as IPA-CP). */
+/* { dg-options "-g -fno-early-inlining -fno-ipa-sra" } */
+/* { dg-xfail-run-if "" { "*-*-*" } { "-O2" "-O3" "-Os" } { "-fwhopr" } } */
+
 #define GUALITY_DONT_FORCE_LIVE_AFTER -1
 
 #ifndef STATIC_INLINE

Re: accepting a new write-after-approval maintainer (student, Jeremie Salvucci)

[David Edelsohn]

Basile,

Jeremie Salvucci is not listed in the copyrights file.  I don't know
what procedure he followed, but he does not have a copyright
assignment on file.  The FSF does not accept scanned JPEG forms, so I
don't know what you're talking about.  Based on what you have written,
I have no idea what procedure he actually followed for his assignment
and disclaimer.  Did he complete the assignment request form, email it
to the FSF, sign and return the form?  Did he obtain a disclaimer form
from the FSF and return the form signed by his institution?

CEA LIST has a copyright assignment on file.  When Jeremie Salvucci is
employed by CEA, his work will be covered by the existing assignment
for CEA.

Once he has an assignment in place, a number of people can sponsor him
for SVN write access.  I can sponsor him.

David

2010/3/30 Basile Starynkevitch :
> Hello
>
> (sorry for bothering the list, it probably probably is relevant only to the
> persons managing the SSH accounts).
>
>
> A young French student - Jérémie Salvucci - in CC wants to contribute to GCC
> and has obtained from his university a signed disclaimer, and has sent it
> (probably by scanning a jpeg & emailing it) to [probably] the lawyers or
> copyright at gcc.org...
>
> He apparently did  obtain a positive human answer.
>
> I thought that was enough to get an SSH account (ie write after approval SVN
> acccess). Apparently, I cannot sponsor him, since I have only
> "submit-after-approval privileges and do not have the right to sponsor
> anyone else for gcc." (he was told by email).
>
> What is the exact procedure to follow?
>
> BTW, that same student candidated for a 3 month internship at my employing
> organization (CEA LIST). In the likely event he is getting the necessary
> security clearance (CEA is a nuclear governmental organization in France,
> ...) what is the procedure to have him (later) authorized to submit to GCC
> (being convered -as any CEA employee- by the same copyright agreement than I
> am http://gcc.gnu.org/ml/gcc/2006-12/msg8.html RT306238).
>
> So actually, I have two questions:
>
> 1. how to admit as soon as possible (as a a write-after-approval maintainer)
> a student who did get a signed copyright disclaimer from his university to
> get a SVN+ssh write account to GCC
>
> 2. later on, how to change temporarily that student to be convered by the
> CEA copyright transfer, if his is accepted as intern. His internship at CEA
> might start on first of june 2010 till 31 of august 2010.
>
> Sorry for bothering the list, but I don't understand all the details.
>
> Regards.
>
> --
> Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>

Re: GSoC 2010 Project Idea

[Michael Meissner]

On Sun, Mar 28, 2010 at 10:37:07PM +0100, Артем Шинкаров wrote:
> Hi,
> 
> I have a project in mind which I'm going to propose to the GCC in terms of
> Google Summer of Code. My project is not on the list of project ideas
> (http://gcc.gnu.org/wiki/SummerOfCode) that is why it would be very 
> interesting
> for me to hear any opinions and maybe even to find a mentor.
> 
> 
> 1. Project idea
> 
> A brief project idea is to create an abstract layer for vectorized
> computations. This would allow to write a portable vectorized code.
> 
> 
> 2. State of the art
> 
> Nowadays most of processors have a support for SIMD computations. However, the
> problem is that each hardware has a different set of SIMD instructions: Intel
> MMX+SSE+AVX, PowerPC Altivec, ARM iWMMXt, and so on. GCC supports most of
> architecture-specific instructions providing built-in functions. It is
> considerably convenient to use these functions when you want to optimize some
> piece of code. The problem starts when you want to make this code portable.
> It is not a very common task, and of course GCC has a vectorizer.
> Unfortunately, there are many examples which show that it is relatively simple
> for a human to find a right  place in the code and vectorize it, but it is
> extremely hard for the compiler to do the same. As a result we end up with the
> code which is not using the capabilities of the architecture.
> It would be much easier for the programmer to use an abstract layer to
> implement a vectorized code. A compiler should deal with the portability 
> issues
> dispatching the code from the abstract layer to the particular architecture. 
> My
> experience shows that there are no such a library for C/C++ that could solve
> the problem. There are some attempts like: http://libsimd.sourceforge.net/ but
> it is only a small part of the idea, and unfortunately the development is
> suspended. Or maybe I am wrong and everything is already written?

Note, the powerpc and cell compilers have the notion of a vector keyword that
is followed by a type (powerpc needs -maltivec and/or -mvsx to enable it).  So
you can write:

vector float sum (vector float a, vector float b) { return a+b; }

Now, ideally, it would be useful to have sytax so you could change the vector
size, and the compiler would do the conversion to/from hw types to abstract
types.

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meiss...@linux.vnet.ibm.com

Re: Peculiar XPASS of gcc.dg/guality/inline-params.c

[Janis Johnson]

On Tue, Mar 30, 2010 at 10:42 AM, Martin Jambor  wrote:
> Hi,
>
> On Tue, Mar 30, 2010 at 10:14:16AM -0700, Janis Johnson wrote:
>> On Tue, Mar 30, 2010 at 7:09 AM, Martin Jambor  wrote:
>> > On Tue, Mar 30, 2010 at 12:43:39AM +0200, Jan Hubicka wrote:
>> >> > I have run the testcase with the early inliner disabled and noticed
>> >> > that gcc.dg/guality/inline-params.c XPASSes with early inlining and
>> >> > XFAILs without it.  The reason for the (expected) failure is that
>> >> > IPA-CP removes a parameter which is constant (but also unused?).  I
>> >> > reckon this is the reason for the xfail mark and so I guess that early
>> >> > inlining should be disabled in the particular testcase, am I right?
>> >>
>> >> Well, I guess we should be able to maintain debug info with IPA-CP changes
>> >> (only case where debugging info is difficult to maintain IMO is the case
>> >> of unused argument removal that is explicitely disabled here).  So I guess
>> >> in a way this is correct XFAIL...
>> >
>> > I thought so.  The patch below turns at least some of the XPASSes into
>> > XFAILs.  The XPASSes remain with switch combinations when IPA-CP is
>> > not run, I don't know how to get rid of them.  Specifically it turns
>> >
>> > XPASS: gcc.dg/guality/inline-params.c  -O0  execution test
>> > XPASS: gcc.dg/guality/inline-params.c  -O1  execution test
>> > XPASS: gcc.dg/guality/inline-params.c  -O2  execution test
>> > XPASS: gcc.dg/guality/inline-params.c  -O3 -fomit-frame-pointer  execution 
>> > test
>> > XPASS: gcc.dg/guality/inline-params.c  -O3 -g  execution test
>> > XPASS: gcc.dg/guality/inline-params.c  -Os  execution test
>> > XFAIL: gcc.dg/guality/inline-params.c  -O2 -flto  execution test
>> > XFAIL: gcc.dg/guality/inline-params.c  -O2 -fwhopr  execution test
>> >
>> > into
>> >
>> > XPASS: gcc.dg/guality/inline-params.c  -O0  execution test
>> > XPASS: gcc.dg/guality/inline-params.c  -O1  execution test
>> > XFAIL: gcc.dg/guality/inline-params.c  -O2  execution test
>> > XFAIL: gcc.dg/guality/inline-params.c  -O3 -fomit-frame-pointer  execution 
>> > test
>> > XFAIL: gcc.dg/guality/inline-params.c  -O3 -g  execution test
>> > XFAIL: gcc.dg/guality/inline-params.c  -Os  execution test
>> > XFAIL: gcc.dg/guality/inline-params.c  -O2 -flto  execution test
>> > XPASS: gcc.dg/guality/inline-params.c  -O2 -fwhopr  execution test
>> >
>> > Only now I have noticed the XFAIL->XPASS in whopr, I wonder what to do
>> > with that (if anything)...
>>
>> Take a look at the documentation for dg-xfail-run-if in
>> http://gcc.gnu.org/onlinedocs/gccint/Directives.html#Directives and see if
>> that helps.
>>
>
> Thanks!.  The improved patch below turns the output into what it
> should be:
>
> PASS: gcc.dg/guality/inline-params.c  -O0  execution test
> PASS: gcc.dg/guality/inline-params.c  -O1  execution test
> XFAIL: gcc.dg/guality/inline-params.c  -O2  execution test
> XFAIL: gcc.dg/guality/inline-params.c  -O3 -fomit-frame-pointer  execution 
> test
> XFAIL: gcc.dg/guality/inline-params.c  -O3 -g  execution test
> XFAIL: gcc.dg/guality/inline-params.c  -Os  execution test
> XFAIL: gcc.dg/guality/inline-params.c  -O2 -flto  execution test
> PASS: gcc.dg/guality/inline-params.c  -O2 -fwhopr  execution test
>
> OK for trunk?
>
> Martin

OK.

Janis

> 2010-03-30  Martin Jambor  
>
>        * inline-params.c: Disable early inlining.  Xfail run only with -O2,
>        -O3 or -Os and not with -fwhopr.
>
> Index: gcc/testsuite/gcc.dg/guality/inline-params.c
> ===
> --- gcc/testsuite/gcc.dg/guality/inline-params.c        (revision 157786)
> +++ gcc/testsuite/gcc.dg/guality/inline-params.c        (working copy)
> @@ -1,6 +1,10 @@
> -/* { dg-do run { xfail *-*-* } } */
> -/* IPA-SRA removes the argumet as dead, so we don't see their values.  */
> -/* { dg-options "-g -fno-ipa-sra" } */
> +/* { dg-do run } */
> +/* IPA-SRA removes the argumet as dead, so we don't see their values, early
> +   inlining inlines the functions too early to test the real IPA passes (such
> +   as IPA-CP). */
> +/* { dg-options "-g -fno-early-inlining -fno-ipa-sra" } */
> +/* { dg-xfail-run-if "" { "*-*-*" } { "-O2" "-O3" "-Os" } { "-fwhopr" } } */
> +
>  #define GUALITY_DONT_FORCE_LIVE_AFTER -1
>
>  #ifndef STATIC_INLINE
>

Re: Optimizing floating point *(2^c) and /(2^c)

[Jeroen Van Der Bossche]

On 29 March 2010 19:51, Geert Bosch  wrote:
>
> On Mar 29, 2010, at 13:19, Jeroen Van Der Bossche wrote:
>
>> 've recently written a program where taking the average of 2 floating
>> point numbers was a real bottleneck. I've looked into the assembly
>> generated by gcc -O3 and apparently gcc treats multiplication and
>> division by a hard-coded 2 like any other multiplication with a
>> constant. I think, however, that *(2^c) and /(2^c) for floating
>> points, where the c is known at compile-time, should be able to be
>> optimized with the following pseudo-code:
>>
>> e = exponent bits of the number
>> if (e > c && e < (0b111...11)-c) {
>> e += c or e -= c
>> } else {
>> do regular multiplication
>> }
>>
>> Even further optimizations may be possible, such as bitshifting the
>> significand when e=0. However, that would require checking for a lot
>> of special cases and require so many conditional jumps that it's most
>> likely not going to be any faster.
>>
>> I'm not skilled enough with assembly to write this myself and test if
>> this actually performs faster than how it's implemented now. Its
>> performance will most likely also depend on the processor
>> architecture, and I could only test this code on one machine.
>> Therefore I ask to those who are familiar with gcc's optimization
>> routines to give this 2 seconds of thought, as this is probably rather
>> easy to implement and many programs could benefit from this.
>
> For any optimization suggestions, you should start with showing some real, 
> compilable, code with a performance problem that you think the compiler could 
> address. Please include details about compilation options, GCC versions and 
> target hardware, as well as observed performance numbers. How do you see that 
> averaging two floating point numbers is a bottleneck? This should only be a 
> single addition and multiplication, and will execute in a nanosecond or so on 
> a moderately modern system.
>
> Your particular suggestion is flawed. Floating-point multiplication is very 
> fast on most targets. It is hard to see how on any target with floating-point 
> hardware, manual mucking with the representation can be a win. In particular, 
> your sketch doesn't at all address underflow and overflow. Likely a complete 
> implementation would be many times slower than a floating-point multiply.
>
>  -Geert

The program in question was a scientific computation where most of the
main loop was spent doing two floating point operations, one of which
was taking the average of two numbers. Granted, there is no
"performance problem" with the code as it is now, it executes in as
much time as would be expected. However, an optimization need not be a
10% performance gain to be called an optimization, right? If we could
get this multiplication, which you say executes in about a nanosecond,
to execute in half a nanosecond, why not do it?

With all due respect, your statement that "your sketch doesn't at all
address underflow and overflow" is just plain wrong. Did you even look
at the code? The if statement is there exactly to address under- and
overflow and nothing else. It's not because it looks simple that I
didn't think it through. I know exactly how floating point
multiplication works, and this implementation of *(2^c) doesn't
violate under/overflow, denormalisation when e=0, rounding rules or
rules about NaN/infinity.

On my processor (Intel Core2, x86-64), a mulsd instruction takes about
as much time as 5 add instructions, though I have to admit that my
method of determining that are highly unscientific. Nevertheless, if
someone competent with optimizing assembly would be able to write the
entire thing so that the if=true-path uses 4 instructions that takes
as much time as an add instruction, then that would constitute a 20%
gain.

Jeroen

Re: accepting a new write-after-approval maintainer (student, Jeremie Salvucci)

[Joseph S. Myers]

On Tue, 30 Mar 2010, Basile Starynkevitch wrote:

> 1. how to admit as soon as possible (as a a write-after-approval maintainer) a
> student who did get a signed copyright disclaimer from his university to get a
> SVN+ssh write account to GCC

In addition to the paperwork (which needs checking in copyright.list by 
someone with access to fencepost.gnu.org), someone getting 
write-after-approval access should be "known to submit good patches".  
They may well be patches for a development branch rather than trunk, but 
there should be some patch submissions first, then write-after-approval 
access once a few have got to the point of being committed by someone 
else.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: accepting a new write-after-approval maintainer (student, Jeremie Salvucci)

[Basile Starynkevitch]

Joseph S. Myers wrote:

On Tue, 30 Mar 2010, Basile Starynkevitch wrote:


1. how to admit as soon as possible (as a a write-after-approval maintainer) a
student who did get a signed copyright disclaimer from his university to get a
SVN+ssh write account to GCC


In addition to the paperwork (which needs checking in copyright.list by 
someone with access to fencepost.gnu.org), someone getting 
write-after-approval access should be "known to submit good patches".  
They may well be patches for a development branch rather than trunk, but 
there should be some patch submissions first, then write-after-approval 
access once a few have got to the point of being committed by someone 
else.




I hope that either patches to the trunk or to the MELT branch are 
relevant for that purpose.


Cheers

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Peculiar XPASS of gcc.dg/guality/inline-params.c

[Jakub Jelinek]

On Tue, Mar 30, 2010 at 11:13:32AM -0700, Janis Johnson wrote:
> > 2010-03-30  Martin Jambor  
> >
> >        * inline-params.c: Disable early inlining.  Xfail run only with -O2,
> >        -O3 or -Os and not with -fwhopr.
> >
> > Index: gcc/testsuite/gcc.dg/guality/inline-params.c
> > ===
> > --- gcc/testsuite/gcc.dg/guality/inline-params.c        (revision 157786)
> > +++ gcc/testsuite/gcc.dg/guality/inline-params.c        (working copy)
> > @@ -1,6 +1,10 @@
> > -/* { dg-do run { xfail *-*-* } } */
> > -/* IPA-SRA removes the argumet as dead, so we don't see their values.  */
> > -/* { dg-options "-g -fno-ipa-sra" } */
> > +/* { dg-do run } */
> > +/* IPA-SRA removes the argumet as dead, so we don't see their values, early

Can you please s/argumet/argument/ when you are touching it?

> > +   inlining inlines the functions too early to test the real IPA passes 
> > (such
> > +   as IPA-CP). */
> > +/* { dg-options "-g -fno-early-inlining -fno-ipa-sra" } */
> > +/* { dg-xfail-run-if "" { "*-*-*" } { "-O2" "-O3" "-Os" } { "-fwhopr" } } 
> > */
> > +
> >  #define GUALITY_DONT_FORCE_LIVE_AFTER -1
> >
> >  #ifndef STATIC_INLINE
> >

Jakub

Re: accepting a new write-after-approval maintainer (student, Jeremie Salvucci)

[Joseph S. Myers]

On Tue, 30 Mar 2010, Basile Starynkevitch wrote:

> Joseph S. Myers wrote:
> > On Tue, 30 Mar 2010, Basile Starynkevitch wrote:
> > 
> > > 1. how to admit as soon as possible (as a a write-after-approval
> > > maintainer) a
> > > student who did get a signed copyright disclaimer from his university to
> > > get a
> > > SVN+ssh write account to GCC
> > 
> > In addition to the paperwork (which needs checking in copyright.list by
> > someone with access to fencepost.gnu.org), someone getting
> > write-after-approval access should be "known to submit good patches".  They
> > may well be patches for a development branch rather than trunk, but there
> > should be some patch submissions first, then write-after-approval access
> > once a few have got to the point of being committed by someone else.
> > 
> 
> I hope that either patches to the trunk or to the MELT branch are relevant for
> that purpose.

I'd think so, yes - but posted by the patch author to gcc-patches for 
public review (which could be review by you) in any case.

-- 
Joseph S. Myers
jos...@codesourcery.com

Autoconf tests, libtool symlist files, undefined behavior, and LTO

[Ralf Wildenhues]

Hello gcc and libtool lists,

Summary: both Autoconf-generated configure tests as well as some Libtool
construct invoke undefined behavior.  Question is how to deal with it,
and whether GCC, as QoI, may want to define behavior in these cases.


1) Autoconf-generated configure tests often fake the prototype of some
function; e.g., AC_CHECK_FUNC([func]) uses
  char func();

and tries to link that.  Using this is undefined according to C99, if
func has a different actual prototype, and when all system libraries are
LTO'ed, gcc -flto may even detect this kind of inconsistency and could
act accordingly (nasal demons and such).


2) libtool has a feature that makes it extract symbol lists from
objects and turn them into fake declarations and function/object
pointers: fake static preloaded modules.

It currently works by running nm or a similar tool over the object, then
converting the output with a couple of sed script or so
(global_symbol_pipe, global_symbol_to_cdecl, and a couple more) to a
synthesized extra source file that then contains code like this:

extern int func();
extern char variable;

typedef struct {
  const char *name;
  void *address;
} lt_dlsymlist;

extern const lt_dlsymlist
lt__PROGRAM__LTX_preloaded_symbols[];
const lt_dlsymlist
lt__PROGRAM__LTX_preloaded_symbols[] =
{  { "@PROGRAM@", (void *) 0 },
  {"func", (void *) &func},
  {"variable", (void *) &variable},
  {0, (void *) 0}
};

This is invoking undefined behavior in a couple of respects:

a) Pointers to functions are stored in pointer-to-void variables.
This could be fixed with an incompatible API change to using a union of
object and function pointer, I guess.

b) The symbols 'func' and 'variable' likely have the wrong prototypes,
i.e., elsewhere, they might be declared as

  void func(int, double);
  double variable[42];

instead.  I haven't come across any actual issues with this yet, except
now LTO may rightfully complain about it.


Question is, what can we do about this?  We could ensure to never pass
-flto or -fwhopr to the compilation of the libtool symfile object, and
remove it from some or all link tests done in configure.  That's ugly.
Would that even be sufficient though?  Conversely, would GCC developers
be willing to agree that, when GCC detects such inconsistencies, it
wouldn't take adverse advantage of it (e.g., by turning off LTO in this
case, or similar)?

Other possibilities for Autoconf would be to work toward a new set of
checking macros (or extensions of current one) where the configure.ac
author passes a full prototype for each function to check (Autoconf
could keep a list of known prototypes for often-checked functions).
I'm not sure how to fix the libtool symfile in a C99-conforming way.

Thanks for reading this far.

Cheers,
Ralf

-enable-tls and emulated tls

[Jack Howarth]

   What exactly is the expected behavior from invoking
-enable-tls in configure on a target that only has
emulated tls? In libgcc, we end up building tls support
in the compiler via emulated tls and I am wondering if
using -enable-tls would do the same across the whole
compiler.
Jack

gcc-4.4-20100330 is now available

[gccadmin]

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

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

You'll find:

gcc-4.4-20100330.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20100330.tar.bz2 C front end and core compiler

gcc-ada-4.4-20100330.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20100330.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20100330.tar.bz2  C++ front end and runtime

gcc-java-4.4-20100330.tar.bz2 Java front end and runtime

gcc-objc-4.4-20100330.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20100330.tar.bz2The GCC testsuite

Diffs from 4.4-20100323 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
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.

Re: Optimizing floating point *(2^c) and /(2^c)

[Vincent Lefevre]

On 2010-03-30 20:36:04 +0200, Jeroen Van Der Bossche wrote:
> The if statement is there exactly to address under- and overflow and
> nothing else. It's not because it looks simple that I didn't think
> it through. I know exactly how floating point multiplication works,
> and this implementation of *(2^c) doesn't violate under/overflow,
> denormalisation when e=0, rounding rules or rules about
> NaN/infinity.

However, extracting the exponent, and putting the new exponent back
to the floating-point number probably takes significant time (not
even mentioning the tests on the exponent) compared to what is done
entirely in hardware. I think that before anyone looks at this, you
should post benchmarks.

Also, the pipeline can stall due to the "if". Perhaps not in your
case. But a compiler cannot know that (the other branch is taken
when the value is 0, and this should not be regarded as rare).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

List for discussion in French on GCC MELT = gcc-melt-fre...@googlegroups.com

[Basile Starynkevitch]

Hello All,

For your information, since there are several native French speaking 
persons interested by GCC MELT (that is by the MELT branch & plugin of 
GCC), I just created the gcc-melt-fre...@googlegroups.com list.


Its archives are public, and the discussion language on that list is French.

I would suppose that english messages about GCC MELT can go on the 
gcc@gcc.gnu.org list.


In case you never heard of MELT, it is a plugin & a GCC branch 
(following quite closely the trunk) which provides a higher-level domain 
specific language to code GCC extensions in. MELT has a Lispy syntax, 
and provides several features (pattern matching, notably on Gimple, 
functional & object programming, generational copying garbage collection 
above Ggc, ...) useful to code GCC passes (that is, you can code in MELT 
your specific GCC passes).


I am blind-copying this message to gcc-melt-fre...@googlegroups.com but 
messages there should be in French.


Les messages sur gcc-melt-fre...@googlegroups.com doivent être en français

Cheers

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***