Re: question about replace_in_call_usage in regmove.c

[Eric Botcazou]

>   In regmove.c there is function "replace_in_call_usage" called in
> fixup_match_1,
> It replaces dst register by src in call_insn, I suspect whether it is
> necessary Since comment of CALL_INSN_FUNCTION_USAGE says that no pseudo
> register can appear in it and seems src is pseudo register.
>
> further more, no replace(dst->src) is done when building bootstrap
> gcc-4.2.4, which confirmed my understanding.

That sounds plausible.  Note that this routine (as well as a few others) has 
been removed in GCC 4.4 because of the new register allocator.

-- 
Eric Botcazou

threading jumps makes niter changed from INTEGER_CST to chrec_dont_know

[Eric Fisher]

Hi,

I found that sometimes -fno-tree-dominator-opts will bring a big speed
promotion. This is because that pass_dominator tries to thread jumps.
But sometimes this will cause that the loop's exit bb does not
dominator its latch bb again. Then pass_complete_unroll is unable to
know the exact number of loop iteration and will not unroll the loop
completely again

Any comments?

Thanks,
Eric.

[Ada] arm-linux port for GCC 4.5

[Eric Botcazou]

I propose that we merge Mickael Pettersson's patch:
  http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00450.html
to have a functional arm-linux port of GNAT in GCC 4.5.

This would yield an Ada compiler with a clean testsuite:
  http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg00419.html

Although it's still an SJLJ port, I don't think we should let the best be the 
enemy of the good here and wait for a hypothetical ZCX port (on which no one 
is working for GCC 4.5 as far as I know).

-- 
Eric Botcazou

Re: GCC aliasing rules: more aggressive than C99?

[Andrew Haley]

On 01/05/2010 01:15 AM, Erik Trulsson wrote:
> On Mon, Jan 04, 2010 at 08:17:00PM +, Joshua Haberman wrote:
>> Andrew Haley  redhat.com> writes:
>>> On 01/03/2010 10:14 PM, Joshua Haberman wrote:
 Andrew Haley  redhat.com> writes:
>>> "6.3.2.3
>>>
>>> "A pointer to an object or incomplete type may be converted to a
>>> pointer to a different object or incomplete type. If the resulting
>>> pointer is not correctly aligned for the pointed-to type, the
>>> behavior is undefined. Otherwise, when converted back again, the
>>> result shall compare equal to the original pointer."
>>>
>>> This is *all* you are allowed to do with the converted pointer.  You
>>> may not dereference it.
>>
>> The text you quoted does not contain any "shall not" language about
>> dereferencing, so this conclusion does not follow.
> 
> It doesn't have to use any "shall not" language.  If the standard does not
> say that any particular action is allowed or otherwise defines what it
> does, then that action implicitly has undefined behaviour.

Exactly.  I think the OP is just being stubborn now.

Andrew.

Re: GCC aliasing rules: more aggressive than C99?

[Andrew Haley]

On 01/05/2010 02:09 AM, Joshua Haberman wrote:
> Erik Trulsson  student.uu.se> writes:
>> On Mon, Jan 04, 2010 at 08:17:00PM +, Joshua Haberman wrote:
>>> The text you quoted does not contain any "shall not" language about
>>> dereferencing, so this conclusion does not follow.
>>
>> It doesn't have to use any "shall not" language.  If the standard does not
>> say that any particular action is allowed or otherwise defines what it
>> does, then that action implicitly has undefined behaviour.
> 
> Section 6.5 does define circumstances under which converted pointers may
> be dereferenced.

No.  It says

"An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:

but

 (union u*)&i

is not a legal lvalue expression because the dereference is undefined
behaviour.  You may only dereference a pointer as permitted by 6.3.2.3.

Andrew.

Re: threading jumps makes niter changed from INTEGER_CST to chrec_dont_know

[Richard Guenther]

On Tue, Jan 5, 2010 at 9:46 AM, Eric Fisher  wrote:
> Hi,
>
> I found that sometimes -fno-tree-dominator-opts will bring a big speed
> promotion. This is because that pass_dominator tries to thread jumps.
> But sometimes this will cause that the loop's exit bb does not
> dominator its latch bb again. Then pass_complete_unroll is unable to
> know the exact number of loop iteration and will not unroll the loop
> completely again
>
> Any comments?

Do you have a testcase for this?  Please file a bugreport then.  Jump threading
should avoid breaking canonical loop forms.

Thanks,
Richard.

> Thanks,
> Eric.
>

Re: Why Thumb-2 only allows very limited access to the PC?

[Richard Earnshaw]

On Tue, 2010-01-05 at 15:42 +0800, Carrot Wei wrote:
> Hi
> 
> In function arm_load_pic_register in file arm.c there are following code:
> 
>   if (TARGET_ARM)
>   {
>   ...
>   }
>   else if (TARGET_THUMB2)
>   {
> /* Thumb-2 only allows very limited access to the PC.  Calculate the
>address in a temporary register.  */
> if (arm_pic_register != INVALID_REGNUM)
>   {
> pic_tmp = gen_rtx_REG (SImode,
>thumb_find_work_register (saved_regs));
>   }
> else
>   {
> gcc_assert (can_create_pseudo_p ());
> pic_tmp = gen_reg_rtx (Pmode);
>   }
> 
> emit_insn (gen_pic_load_addr_thumb2 (pic_reg, pic_rtx));
> emit_insn (gen_pic_load_dot_plus_four (pic_tmp, labelno));
> emit_insn (gen_addsi3 (pic_reg, pic_reg, pic_tmp));
>   }
>   else /* TARGET_THUMB1 */
>   {
>   ...
>   }
> 
> The comment said "Thumb-2 only allows very limited access to the PC.
> Calculate the address in a temporary register.". So the generated code
> is a little more complex than thumb1. Could anybody help to give more
> explanation on the limitation thumb2 has compared to thumb1?
> 
> The generated instructions by this function for thumb1 is listed
> following, both instructions are available under thumb2.
> 
> ldr r3, .L2
> .LPIC0:
> add r3, pc

I didn't write the comment, but I think the limitation is relative to
ARM not thumb1.  Thumb2 code generator is a variation on the ARM code
generator, so the author was most likely thinking of that rather than
Thumb1.

R.

Multilib selection issues

[Joseph S. Myers]

This message describes problems with how GCC presently handles
multilib selection, and proposes changes (at least some hopefully to
be implemented for GCC 4.6) to fix some of those problems; please let
me know any comments on these proposals.

In summary, multilibs are selected using textual matching of options
whose logic is largely independent of that used in the compiler proper
(cc1) to determine what options are enabled when compiling.  If the
options passed when linking are not exactly those used when building a
multilib, but include an option (say a -mcpu option) that implies
other options, or one option on the command line partially overrides
another option, this can lead to inappropriate multilibs being
selected, and existing mechanisms such as MULTILIB_MATCHES are unable
to handle all cases of this reliably and effectively.  For example, if
there is a "-march=armv7-a -mfloat-abi=softfp -mfpu=neon" multilib,
and if the user instead passes the option -mcpu=cortex-a8 (which
logically should imply the above options), the multilib will not be
matched, and MULTILIB_MATCHES can only handle mapping the option to a
single one of the three options it implies and requires duplicating
all the information about such implications.

To fix this, it is proposed to share more option processing logic
between the compiler driver and the compiler proper and to base
multilib selection more closely on the actual features enabled by
options instead of the text of those options.

The present multilib selection logic


A multilib consists of a collection of files (.o files, .a files,
shared libraries and headers) to be used when compiling and linking
with particular options (for example, for 32-bit compilation, or for
big-endian compilation, or for compilation with hardware floating
point).

These files are scattered across the filesystem and may be located by
GCC in several different ways.  GCC has a "multilib directory", shown
when -print-multi-directory is passed to the GCC driver along with
other compilation options, and a "multilib OS directory", shown with
-print-multi-os-directory.  Both of these are relative directory
names, appended to various other directory locations; the OS directory
is intended to be relative to a directory called "lib" and so may have
values such as "../lib64".  In addition to these values, there are the
"sysroot suffix" and "sysroot headers suffix" in sysrooted
toolchains.  The latter does not typically have a different value for
each multilib; in a toolchain with both GLIBC and uClibc multilibs,
the sysroot headers suffix would typically be set so there is one set
of GLIBC headers and one of uClibc headers.

The first two directories are determined by MULTILIB_* settings in the
target makefile fragments t-* when GCC is built; the genmultilib
script converts these settings into a header file used by the GCC
driver.  The second two directories are determined by
SYSROOT_SUFFIX_SPEC and SYSROOT_HEADERS_SUFFIX_SPEC in the target
headers.  Targets may, optionally, use one of three different
print-sysroot-suffix.sh scripts that attempt to reimplement the
genmultilib logic to produce SYSROOT_SUFFIX_SPEC settings replicating
the other multilib directory layouts.

Problems with the present logic
---

The two sorts of multilib selection logic - for GCC multilib
directories and for sysroot suffixes - both work entirely based on the
text of command-line options, as processed by the GCC driver with
logic that is not necessarily the same as that used in cc1 to convert
options to features.  Much the same issue applies to specs used for
other purposes than multilib selection: they are based on textual
processing only with nothing to keep it in sync with how cc1 handles
options.  It is especially complicated to keep them in sync when
various configure options affect the compiler's default settings.

Those problems with multilib selection logic are to an extent
theoretical - in any particular case it might be possible to make
specs reflect cc1's logic accurately, at least as long as options
overriding each other are not present on the command line.  (There is
a limited mechanism for Negative markings in .opt files to allow some
overriding options to be pruned before multilib selection and spec
processing, but it certainly doesn't cover all relevant cases or all
ways in which options can imply or partially override others.)  There
are however cases that cannot effectively be represented.

In the present system, an option either is or is not an option
affecting multilib selection.  If it affects multilib selection, it
may be one of the options directly involved in multilib selection, or
it may be mapped to such an option with MULTILIB_MATCHES.
MULTILIB_MATCHES only allows for one option being treated as an exact
alias of another for multilib selection purposes.  This suffices for
the use in config/rs6000/t-fprules to map certain -mcpu options to
-

Re: GCC aliasing rules: more aggressive than C99?

[Robert Dewar]

This discussion prompts me to relate something from
experience in exegesis of the Ada RM.

In Robert's rules of order, there is an overriding
rule that says "none of the other rules in this book
can be used to obfuscate" [don't have my copy here,
so not an exact quote].

Following that line of thinking,
I proposed for the Ada standard that we consider
(but perhaps not include explicitly) that the standard
has an overarching rule

"none of the other rules in this standard can be used
to derive obviously incorrect conclusions".

The work of interpreting a standard is always one of
interpreting intention. Most of the time, we expect
that the language clearly indicates that intention,
but when it doesn't, we don't blindly follow some
misprint or thinko in the standard, we figure out
what was intended and makes sense.

Of course we still may need to do careful exegesis
to see if the standard needs fixing or clarification.

My own thoughts in this case, not being a real
expert in the C standard, is that the standard
seems pretty clear and supports the gcc interpretation.

In any case the gcc interpretation is clearly what's
intended in my view, so if it can be argued that the
standard is inconsistent with this interpretation (I
am unconvinced that this burden has been met), then
the conclusion is to add a clarification to the
standard, not to modify the gcc behavior.

Yes, this behavior may surprise, but there are a
number of practices in C that are clearly outside
the language. Even with the original K&R definition,
there were lots of things clearly specified to lead
to undefined behavior that people got used to using
because they happen to work.

Any time you let the actual behavior of a particular
be your language tutor, you are in trouble. There is
no substitute for knowing the language accurately.

Re: Multilib selection issues

[Richard Kenner]

> In summary, multilibs are selected using textual matching of options
> whose logic is largely independent of that used in the compiler proper
> (cc1) to determine what options are enabled when compiling.  

This has been an annoyance I've had with multilib processing for a long
time, so I'm very pleased to see this being addressed.

adding -fnoalias ... would a patch be accepted ?

[torbenh]

hi...

i am new to this list. 

i am trying to something like:

struct Ramp
{
float phase;
inline float process() { return phase++; }
} ramp;

void fill_buffer( float *buf, size_t nframes )
{
for( size_t i=0; i

Re: adding -fnoalias ... would a patch be accepted ?

[Richard Guenther]

On Tue, Jan 5, 2010 at 2:40 PM, torbenh  wrote:
>
> hi...
>
> i am new to this list.
>
> i am trying to something like:
>
> struct Ramp
> {
>    float phase;
>    inline float process() { return phase++; }
> } ramp;
>
> void fill_buffer( float *buf, size_t nframes )
> {
>        for( size_t i=0; i                buf[i] = ramp.process()
> }
>
> the goal is to chain several of such Ramp structs together via
> templates. so that i can model dsp graphs, but have it all inlined into
> the loop.
>
> however the stores to phase cant be moved out of the loop due to
> aliasing. but that is one of the points to do this whole exercise.
>
> this simple case can be optimized when i use -fargument-noalias-anything
> and:
>
> void fill_buffer( float *buf, size_t nframes )
> {
>        for( size_t i=0; i                *(buf++) = ramp.process()
> }
>
> but things start to break again, when i add:
>
> struct Sample
> {
>        unsigned int pos;
>        float *sample;
>        inline float process() { return sample[pos++]; }
> }
>
>
> __restrict__ is of no help here. which leads me to the question whats
> the point of a restricted this pointer ? members of structs arent
> unaliased by a __restrict__ pointer to the struct.
>
> my favourite solution would be __noalias__ ... msvc has that.
> but -fnoalias would make me happy too.
>
> i havent read much of the gcc code yet, so i am not sure what i need to
> patch.
>
> refs_may_alias_p_1() is my current bet though.

The -fno-alias-X things do not make much sense for user code (they
have been historically used from Frontends).  If restrict doesn't work
for you (do you have a testcase that can reproduce your issue?)
then you probably need to wait for IPA pointer analysis to be
fixed in GCC 4.6.

Richard.

> --
> torben Hohn
>

Laeuft es im Bett) nicht so gut

[Iris Heinrich]

Kaufen sie direkt und ver-gessen sie Ihre Entaeuschungen und alle Aengste
die Sie haben.

 - Lieferung kostenfrei
 - ohne Zollprobleme
 - sicher online shoppen.
 - Wirkstoffe rein pflanzlich
 - diskret verpackt

Nicht mehr zufrueh im Bett abspritzen und das Maedchen enttaeuschen!

Oder andere Maenner-Produkte einkaufen auf

http://bit.ly/7ZxCAO 

-

Mit angenehmen Grussen
Prof. Dr. Iris Heinrich


Apostle I Notre Adonay, island justifiably expletives so Officers. 

Re: adding -fnoalias ... would a patch be accepted ?

[torbenh]

On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
> On Tue, Jan 5, 2010 at 2:40 PM, torbenh  wrote:
> > __restrict__ is of no help here. which leads me to the question whats
> > the point of a restricted this pointer ? members of structs arent
> > unaliased by a __restrict__ pointer to the struct.
> >
> > my favourite solution would be __noalias__ ... msvc has that.
> > but -fnoalias would make me happy too.
> >
> > i havent read much of the gcc code yet, so i am not sure what i need to
> > patch.
> >
> > refs_may_alias_p_1() is my current bet though.
> 
> The -fno-alias-X things do not make much sense for user code (they
> have been historically used from Frontends).  If restrict doesn't work
> for you (do you have a testcase that can reproduce your issue?)
> then you probably need to wait for IPA pointer analysis to be
> fixed in GCC 4.6.

can you please explain, why you reject the idea of -fnoalias ? 
msvc has declspec(noalias) icc has -fnoalias 


ramp.cc attached.
compiling it with gcc -S -O3 ramp.cc on x86_64 yields:


_Z11fill_bufferPfm:
.LFB1:
testq   %rsi, %rsi
je  .L1
xorl%eax, %eax
movss   .LC0(%rip), %xmm2
.align 16
.L3:
movss   ramp(%rip), %xmm0
movaps  %xmm0, %xmm1
addss   %xmm2, %xmm1
movss   %xmm1, ramp(%rip)
movss   %xmm0, (%rdi,%rax,4)
addq$1, %rax
cmpq%rax, %rsi
ja  .L3
.L1:
rep
ret
---


-- 
torben Hohn

Re: adding -fnoalias ... would a patch be accepted ?

[torbenh]

On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
> On Tue, Jan 5, 2010 at 2:40 PM, torbenh  wrote:
> 
> The -fno-alias-X things do not make much sense for user code (they
> have been historically used from Frontends).  If restrict doesn't work
> for you (do you have a testcase that can reproduce your issue?)
> then you probably need to wait for IPA pointer analysis to be
> fixed in GCC 4.6.

sorry... forget the attachment :S


-- 
torben Hohn

#include "stddef.h"

struct Ramp {
float phase;
inline float process() { return phase++; }
} ramp;

void fill_buffer( float *buf, size_t nframes )
{
for( size_t i=0; i

Re: entry point of gimplification

[Diego Novillo]

On 1/4/10 14:57 , sandeep soni wrote:

> I want to know what is the entry point to the gimplification pass? and
> given a function body which are the functions in the gcc source that
> convert the body into equivalent gimple statements?

This is controlled from the callgraph manager.  You need to start
looking at cgraphunit.c:cgraph_analyze_functions.  It traverses the
cgraph queue converting each node into gimple (the call to
cgraph_analyze_function).

> Also is there a way in which i can selectively step through the
> execution of the source related to this?

Yes.  You need to debug cc1/cc1plus and set a breakpoint in
cgraph_analyze_functions.  The function debug_cgraph() will show you the
callgraph at that point.


Diego.

Re: GCC aliasing rules: more aggressive than C99?

[Vincent Lefevre]

On 2010-01-05 10:31:13 +, Andrew Haley wrote:
> "An object shall have its stored value accessed only by an lvalue
> expression that has one of the following types:
> 
> but
> 
>  (union u*)&i
> 
> is not a legal lvalue expression because the dereference is undefined
> behaviour.  You may only dereference a pointer as permitted by 6.3.2.3.

For the same reason, (char *) &i could not be dereferenced, and this
would break a lot of code!

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

Re: adding -fnoalias ... would a patch be accepted ?

[Richard Guenther]

On Tue, Jan 5, 2010 at 4:03 PM, torbenh  wrote:
> On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
>> On Tue, Jan 5, 2010 at 2:40 PM, torbenh  wrote:
>>
>> The -fno-alias-X things do not make much sense for user code (they
>> have been historically used from Frontends).  If restrict doesn't work
>> for you (do you have a testcase that can reproduce your issue?)
>> then you probably need to wait for IPA pointer analysis to be
>> fixed in GCC 4.6.
>
> sorry... forget the attachment :S

Yes, in this case you can fix it by making ramp static.  Otherwise its
address may be takein in another translation unit.  For Fortran we
have the DECL_RESTRICTED_P which we could expose to other
languages via an attribute.  It tells that a decl is not aliased by
restrict qualified pointers, so

struct Ramp {
float phase;
inline float process() { return phase++; }
} ramp __attribute__((restrict));

void fill_buffer( float * __restrict buf, size_t nframes )
{
for( size_t i=0; i

Re: GCC aliasing rules: more aggressive than C99?

[Andrew Haley]

On 01/05/2010 03:23 PM, Vincent Lefevre wrote:
> On 2010-01-05 10:31:13 +, Andrew Haley wrote:
>> "An object shall have its stored value accessed only by an lvalue
>> expression that has one of the following types:
>>
>> but
>>
>>  (union u*)&i
>>
>> is not a legal lvalue expression because the dereference is undefined
>> behaviour.  You may only dereference a pointer as permitted by 6.3.2.3.
> 
> For the same reason, (char *) &i could not be dereferenced, and this
> would break a lot of code!

Try reading it.  This is Clause 7.

Andrew.

Re: GCC aliasing rules: more aggressive than C99?

[Joseph S. Myers]

On Tue, 5 Jan 2010, Vincent Lefevre wrote:

> On 2010-01-05 10:31:13 +, Andrew Haley wrote:
> > "An object shall have its stored value accessed only by an lvalue
> > expression that has one of the following types:
> > 
> > but
> > 
> >  (union u*)&i
> > 
> > is not a legal lvalue expression because the dereference is undefined
> > behaviour.  You may only dereference a pointer as permitted by 6.3.2.3.
> 
> For the same reason, (char *) &i could not be dereferenced, and this
> would break a lot of code!

No, read 6.3.2.3 again.  Specifically, where it says "When a pointer to an 
object is converted to a pointer to a character type, the result points to 
the lowest addressed byte of the object. Successive increments of the 
result, up to the size of the object, yield pointers to the remaining 
bytes of the object.".

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

Re: GCC aliasing rules: more aggressive than C99?

[Vincent Lefevre]

On 2010-01-05 15:30:11 +, Joseph S. Myers wrote:
> On Tue, 5 Jan 2010, Vincent Lefevre wrote:
> 
> > On 2010-01-05 10:31:13 +, Andrew Haley wrote:
> > > "An object shall have its stored value accessed only by an lvalue
> > > expression that has one of the following types:
> > > 
> > > but
> > > 
> > >  (union u*)&i
> > > 
> > > is not a legal lvalue expression because the dereference is undefined
> > > behaviour.  You may only dereference a pointer as permitted by 6.3.2.3.
  ^^
> > For the same reason, (char *) &i could not be dereferenced, and this
> > would break a lot of code!
> 
> No, read 6.3.2.3 again.  Specifically, where it says "When a pointer to an 
> object is converted to a pointer to a character type, the result points to 
> the lowest addressed byte of the object. Successive increments of the 
> result, up to the size of the object, yield pointers to the remaining 
> bytes of the object.".

6.3.2.3 says that one can *convert* the pointer, but not that one can
*dereference* it.

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

Re: GCC aliasing rules: more aggressive than C99?

[Vincent Lefevre]

On 2010-01-05 15:29:25 +, Andrew Haley wrote:
> On 01/05/2010 03:23 PM, Vincent Lefevre wrote:
> > On 2010-01-05 10:31:13 +, Andrew Haley wrote:
> >> "An object shall have its stored value accessed only by an lvalue
> >> expression that has one of the following types:
> >>
> >> but
> >>
> >>  (union u*)&i
> >>
> >> is not a legal lvalue expression because the dereference is undefined
> >> behaviour.  You may only dereference a pointer as permitted by 6.3.2.3.
> > 
> > For the same reason, (char *) &i could not be dereferenced, and this
> > would break a lot of code!
> 
> Try reading it.  This is Clause 7.

Clause 7 is about pointer conversion, not about pointer dereferencing.
I recall what you said above:

  You may only dereference a pointer as permitted by 6.3.2.3.
   ^^^

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

Re: GCC aliasing rules: more aggressive than C99?

[Joseph S. Myers]

On Tue, 5 Jan 2010, Vincent Lefevre wrote:

> On 2010-01-05 15:30:11 +, Joseph S. Myers wrote:
> > On Tue, 5 Jan 2010, Vincent Lefevre wrote:
> > 
> > > On 2010-01-05 10:31:13 +, Andrew Haley wrote:
> > > > "An object shall have its stored value accessed only by an lvalue
> > > > expression that has one of the following types:
> > > > 
> > > > but
> > > > 
> > > >  (union u*)&i
> > > > 
> > > > is not a legal lvalue expression because the dereference is undefined
> > > > behaviour.  You may only dereference a pointer as permitted by 6.3.2.3.
>   ^^
> > > For the same reason, (char *) &i could not be dereferenced, and this
> > > would break a lot of code!
> > 
> > No, read 6.3.2.3 again.  Specifically, where it says "When a pointer to an 
> > object is converted to a pointer to a character type, the result points to 
> > the lowest addressed byte of the object. Successive increments of the 
> > result, up to the size of the object, yield pointers to the remaining 
> > bytes of the object.".
> 
> 6.3.2.3 says that one can *convert* the pointer, but not that one can
> *dereference* it.

You can dereference it if it is defined where (to what object of the 
relevant type) it points, and no other rule prohibits the dereference.

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

Re: [gcc-as-cxx] enum conversion to int

[NightStrike]

On Mon, Jan 4, 2010 at 7:40 PM, Matt  wrote:
> Hi,
>
> I'm trying to fix some errors/warnings to make sure that gcc-as-cxx doesn't
> bitrot too much.

Wasn't that branch already merged to trunk?

Re: adding -fnoalias ... would a patch be accepted ?

[torbenh]

On Tue, Jan 05, 2010 at 04:27:33PM +0100, Richard Guenther wrote:
> On Tue, Jan 5, 2010 at 4:03 PM, torbenh  wrote:
> > On Tue, Jan 05, 2010 at 02:46:30PM +0100, Richard Guenther wrote:
> >> On Tue, Jan 5, 2010 at 2:40 PM, torbenh  wrote:
> >>
> >> The -fno-alias-X things do not make much sense for user code (they
> >> have been historically used from Frontends).  If restrict doesn't work
> >> for you (do you have a testcase that can reproduce your issue?)
> >> then you probably need to wait for IPA pointer analysis to be
> >> fixed in GCC 4.6.
> >
> > sorry... forget the attachment :S
> 
> Yes, in this case you can fix it by making ramp static.  Otherwise its
> address may be takein in another translation unit.  For Fortran we
> have the DECL_RESTRICTED_P which we could expose to other
> languages via an attribute.  It tells that a decl is not aliased by
> restrict qualified pointers, so
> 
> struct Ramp {
> float phase;
> inline float process() { return phase++; }
> } ramp __attribute__((restrict));
> 
> void fill_buffer( float * __restrict buf, size_t nframes )
> {
> for( size_t i=0; i buf[i] = ramp.process();
> }

would that also work with this stuff:


template
class Mixer;

template
class Mixer : public Block
{
private:
T1 t1 __attribute__((restrict));
Mixer t2;
public:
inline float process() {
return t1.process() + t2.process();
}
};

template
class Mixer : public Block
{
private:
T1 t1 __attribute__((restrict));
T2 t2 __attribute__((restrict));
public:
inline float process() {
return t1.process() + t2.process();
}
};

Mixer mix __attribute__((restrict))

?

i still dont understand whats the problem with -fnolias,
as in attached patch.

> 
> would then be optimized as well.  Can you file an enhancement
> bugreport according to this?
> 
> Thanks,
> Richard.

-- 
torben Hohn
diff --git a/gcc/common.opt b/gcc/common.opt
index 77967f8..21eebb2 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -834,6 +834,10 @@ freschedule-modulo-scheduled-loops
 Common Report Var(flag_resched_modulo_sched) Optimization
 Enable/Disable the traditional scheduling in loops that already passed modulo scheduling
 
+fnoalias
+Common Report Var(flag_noalias) Optimization
+Assume no aliasing is happening
+
 fnon-call-exceptions
 Common Report Var(flag_non_call_exceptions) Optimization
 Support synchronous non-call exceptions
diff --git a/gcc/opts.c b/gcc/opts.c
index 5407527..9b8639e 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2053,6 +2053,10 @@ common_handle_option (size_t scode, const char *arg, int value,
   flag_ipa_cp_clone_set = true;
   break;
 
+case OPT_fnoalias:
+  flag_noalias = true;
+  break;
+
 case OPT_fpredictive_commoning:
   flag_predictive_commoning_set = true;
   break;
diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index cbb43b5..0b66577 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -662,6 +662,9 @@ indirect_ref_may_alias_decl_p (tree ref1, tree ptr1,
   if (!ptr_deref_may_alias_decl_p (ptr1, base2))
 return false;
 
+  if (flag_noalias)
+return false;
+
   /* Disambiguations that rely on strict aliasing rules follow.  */
   if (!flag_strict_aliasing)
 return true;

Re: adding -fnoalias ... would a patch be accepted ?

[Tim Prince]

torbenh wrote:

can you please explain, why you reject the idea of -fnoalias ? 
msvc has declspec(noalias) icc has -fnoalias 

msvc needs it because it doesn't implement restrict and supports 
violation of typed aliasing rules as a default.  ICL needs it for msvc 
compatibility, but has better alternatives. gcc can't copy the worst 
features of msvc.

Re: target hooks / plugins

[Joern Rennecke]

Quoting "Joseph S. Myers" :


On Wed, 23 Dec 2009, Joern Rennecke wrote:


I've attached what I have so far.


If you want to have documentation extracted from source files, you need to
engage with the SC and FSF at an early stage to get suitable license
exception wording to permit the relevant text to be used in the manuals as
well as the main (GPL) sources.


I suppose I'm reaching the steering commitee by posting to g...@gcc.gnu.org.
What email address should I use to engage the FSF?

I want to move the hook descriptions from tm.texi into target.def .
gentarget.c includes target.def, and gentarget (re-)generates
$(srcdir)/doc/targhooks.texi (the makefile dependency would be keyed on
--enable-maintainer-mode) ; targhooks.texi would then include the hook
descriptions from target.def .

As the person who regenerates targhooks.texi is in possession of target.def ,
I think the (s)he can use the license on target.def to generate a GFDL
(terms according to gcc.texi) targhooks.texi which includes pieces of  
target.def, without requiring the gentarget executable to have a special

license; the executable is only a means to create a (documentation) work
based on target.def .

I've looked at the bison skeleton for inspiration on the license blurb
for target.def .
This is what I have come up with:

/* Target hook definitions.
   Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
   Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify it
   under the terms of the GNU General Public License as published by the
   Free Software Foundation; either version 3, or (at your option) any
   later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; see the file COPYING3.  If not see
   .

   In other words, you are welcome to use, share and improve this program.
   You are forbidden to forbid anyone else to use, share and improve
   what you give them.   Help stamp out software-hoarding!  */

/* As a special exception, you may create documentation that contains
   part or all of this target hooks definitions file and distribute that
   work under the copying terms outlined in doc/gcc.texi .
   Alternatively, if you modify or redistribute this target hooks
   definitions file itself, you may (at your option) remove this special
   exception, which will cause the target hooks definitions file (and any
   program output which incorporates parts of this file) to be licensed
   under the GNU General Public License without this special exception.  */



Of course, the ordering and (especially)
section divisions in the internals manual are human-designed not arbitrary
so you need to retain the ability to put the documentation of each hook in
an appropriate position in an appropriate section of the manual.


Yes, I plan to allow any number of explicit placements of hooks descriptions
in the resulting documentation, and any hooks that are not explicitly placed
will appear as successor of their predecessor in target.def .

Re: threading jumps makes niter changed from INTEGER_CST to chrec_dont_know

[Jeff Law]

On 01/05/10 01:46, Eric Fisher wrote:

Hi,

I found that sometimes -fno-tree-dominator-opts will bring a big speed
promotion. This is because that pass_dominator tries to thread jumps.
But sometimes this will cause that the loop's exit bb does not
dominator its latch bb again. Then pass_complete_unroll is unable to
know the exact number of loop iteration and will not unroll the loop
completely again
   
Please file a bug report with a complete testcase so that we can see 
what's happening rather than trying to speculate.


jeff

Re: [gcc-as-cxx] enum conversion to int

[Ian Lance Taylor]

Matt  writes:

> I'm trying to fix some errors/warnings to make sure that gcc-as-cxx
> doesn't bitrot too much. I ran into this issue, and an unsure how to
> fix it without really ugly casting:
>
> enum df_changeable_flags
> df_set_flags (enum df_changeable_flags changeable_flags)
> {
>   enum df_changeable_flags old_flags = df->changeable_flags;
>   df->changeable_flags |= changeable_flags;
>   return old_flags;
> }

On trunk df_set_flags looks like this:

int
df_set_flags (int changeable_flags)

The gcc-in-cxx branch is no longer active.  All the work was merged to
trunk, where it is available via --enable-build-with-cxx.  If you want
to work on the gcc-in-cxx branch, start by merging from trunk.

Ian

Re: [gcc-as-cxx] enum conversion to int

[NightStrike]

On Tue, Jan 5, 2010 at 1:40 PM, Ian Lance Taylor  wrote:
> The gcc-in-cxx branch is no longer active.  All the work was merged to
> trunk, where it is available via --enable-build-with-cxx.

Is that option regularly tested?

Will it ever become the default?

Re: [gcc-as-cxx] enum conversion to int

[Ian Lance Taylor]

NightStrike  writes:

> On Tue, Jan 5, 2010 at 1:40 PM, Ian Lance Taylor  wrote:
>> The gcc-in-cxx branch is no longer active.  All the work was merged to
>> trunk, where it is available via --enable-build-with-cxx.
>
> Is that option regularly tested?

Probably not.

> Will it ever become the default?

I hope so, but there is opposition.

Ian

Microblaze branch updated to gcc-4.5

[Michael Eager]

I've updated the Microblaze branch to gcc-4.5.
It has passed gcc regression tests reasonably well.

I still have some minor cleanup to do -- updating
copyright notices, checking indents, and so forth.

What's the best process for merging this into head?
Should I submit a patch?


--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[Ian Lance Taylor]

"H.J. Lu"  writes:

> On Tue, Nov 3, 2009 at 3:23 PM, Roland McGrath  wrote:
>> --with is wrong for this.  It's not about the ambient system built against.
>> It's a feature selection for how you build binutils, which means --enable.
>>
>
> Here is the updated patch.

I'm still not entirely convinced that this is the way to go.  It seems
to me that ideally one wants to be able to select the linker at
runtime.  I don't see how this patch supports that.  What am I
missing?

This patch would be easier to review if you omitted the generated
files.

Do any of the binutils maintainers have any comments on the best
approach here?


> diff --git a/configure.ac b/configure.ac
> index 407ab59..b349633 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -311,10 +311,11 @@ esac
>  # Handle --enable-gold.
>  
>  AC_ARG_ENABLE(gold,
> -[  --enable-gold   use gold instead of ld],
> +[  --enable-gold[[=ARG]] build gold [[ARG={yes,both}]]],
>  ENABLE_GOLD=$enableval,
>  ENABLE_GOLD=no)
> -if test "${ENABLE_GOLD}" = "yes"; then
> +case "${ENABLE_GOLD}" in 
> +yes|both)
># Check for ELF target.
>is_elf=no
>case "${target}" in
> @@ -334,11 +335,17 @@ if test "${ENABLE_GOLD}" = "yes"; then
>  # Check for target supported by gold.
>  case "${target}" in
>i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-*)
> -configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
> +if test "${ENABLE_GOLD}" = both; then
> +  configdirs="$configdirs gold"
> + else
> +  configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
> + fi
>  ;;
>  esac
>fi
> -fi
> +  ENABLE_GOLD=yes
> +  ;;
> +esac

You should have an error case here to ensure that --enable-gold only
has the values "yes", "both", or "no".  --enable-gold=foo should give
an error.

This patch uses two configure options: one to build both gold and ld,
and one to select which linker is the default.  Why not use just one
configure option?  Perhaps something like:
--enable-gold  Build only gold, gold is default
--disable-gold [default]   Build only GNU ld, GNU ld is default
--enable-gold=no   Same
--enable-gold=both Build both gold and GNU ld, gold is default
--enable-gold=both/goldSame
--enable-gold=both/bfd Build both gold and GNU ld, GNU ld is default

But of course this approach is conditional on whether there should be
some way to select the linker to use at runtime.



> diff --git a/gold/Makefile.am b/gold/Makefile.am
> index 8d8b617..85b103b 100644
> --- a/gold/Makefile.am
> +++ b/gold/Makefile.am
> @@ -163,12 +163,20 @@ check: libgold.a
>  
>  install-exec-local: ld-new$(EXEEXT)
>   $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(tooldir)/bin
> - n=`echo ld | sed '$(transform)'`; \
> + n=`echo @installed_linker@ | sed '$(transform)'`; \
>   $(INSTALL_PROGRAM) ld-new$(EXEEXT) $(DESTDIR)$(bindir)/$${n}$(EXEEXT); \
> - if test "$(bindir)" != "$(tooldir)/bin"; then \
> -   rm -f $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
> -   ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) 
> $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT) >/dev/null 2>/dev/null \
> + if test "@linker@" = "ld.gold"; then \
> +   if test "@installed_linker@" != "ld"; then \
> + ld=`echo ld | sed '$(transform)'`; \
> + rm -f $(DESTDIR)$(bindir)/$${ld}$(EXEEXT); \
> + ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) 
> $(DESTDIR)$(bindir)/$${ld}$(EXEEXT) >/dev/null 2>/dev/null \
> + || $(INSTALL_PROGRAM) ld-new$(EXEEXT) 
> $(DESTDIR)$(bindir)/$${ld}$(EXEEXT); \
> +   fi; \
> +   if test "$(bindir)" != "$(tooldir)/bin"; then \
> + rm -f $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
> + ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) 
> $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT) >/dev/null 2>/dev/null \
>   || $(INSTALL_PROGRAM) ld-new$(EXEEXT) 
> $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
> +   fi; \
>   fi

In Makefile.am you don't need to use @@ quoting in rules.  You can
just use $(installed_linker) and $(linker).



> diff --git a/gold/configure.ac b/gold/configure.ac
> index 85e23f9..10389a9 100644
> --- a/gold/configure.ac
> +++ b/gold/configure.ac
> @@ -38,6 +38,29 @@ AC_DEFINE_UNQUOTED(TARGET_SYSTEM_ROOT, "$sysroot",
>  AC_DEFINE_UNQUOTED(TARGET_SYSTEM_ROOT_RELOCATABLE, $sysroot_relocatable,
>[Whether the system root can be relocated])
>  
> +AC_ARG_ENABLE(gold,
> +[  --enable-gold[[=ARG]] build gold [[ARG={yes,both}]]],
> +[if test "${enableval}" = "both"; then
> +   bfd_linker=ld.bfd
> +   installed_linker=ld.gold
> + else
> +   bfd_linker=ld.gold
> +   installed_linker=ld
> + fi],
> +[bfd_linker=ld.bfd
> + installed_linker=ld])
> +AC_SUBST(installed_linker)

It seems rather weird to set a variable named bfd_linker to be
ld.gold.  What does that mean?


> +AC_ARG_ENABLE(linker,
> +[  --enable-linker=[[ARG]]   specify the default linker [[ARG={bfd,gold}]]],
> +[if test "${enable

Re: GCC aliasing rules: more aggressive than C99?

[Joshua Haberman]

Robert Dewar  adacore.com> writes:
> In any case the gcc interpretation is clearly what's
> intended in my view, so if it can be argued that the
> standard is inconsistent with this interpretation (I
> am unconvinced that this burden has been met), then
> the conclusion is to add a clarification to the
> standard, not to modify the gcc behavior.

I agree with you completely on this point.  My position throughout this
thread has been that GCC should keep its existing type-based aliasing
behavior.  I think the GCC policy represents a good trade-off between a
policy that is not aggressive enough and a policy that is too hard to
follow.

In my view the C99 standard quite clearly specifies a policy that is
less aggressive than what GCC implements.  I think it's hard to come to
any other conclusion; section 6.5 paragraph 7 contains a footnote
explicitly stating that the intention is to specify conditions under
which values may be aliased, and one of the rules allows for an aliasing
condition that GCC does not respect.  I have not heard any credible 
rebuttal to this point, or any explanation of what 6.5 paragraph 7 
*does* mean, if it is not intended to specify aliasing rules.

I am guessing that the committee didn't have enough practical experience
with aliasing policies to come to Richard's conclusion that the
standard's policy "removes nearly all advantages of type-based aliasing
that you have when dealing with disambiguating a pointer dereference vs.
an object reference."  In this sense I think this is a bug in the 
standard, and I hope the committee will take it up in C1x.

Josh

Re: [gcc-as-cxx] enum conversion to int

[Matt]

On Tue, 5 Jan 2010, Ian Lance Taylor wrote:


Matt  writes:


I'm trying to fix some errors/warnings to make sure that gcc-as-cxx
doesn't bitrot too much. I ran into this issue, and an unsure how to
fix it without really ugly casting:

enum df_changeable_flags
df_set_flags (enum df_changeable_flags changeable_flags)
{
  enum df_changeable_flags old_flags = df->changeable_flags;
  df->changeable_flags |= changeable_flags;
  return old_flags;
}


On trunk df_set_flags looks like this:

int
df_set_flags (int changeable_flags)


Yes, was I pasted was a local change. I was trying to eliminate the 
implicit cast to int from the enum type, which was causing my 
--enable-werror build to fail. At this point, I think the better 
option would be to break up the enum values into indivdual #defines and do 
a typedef df_changeable_flags int;



The gcc-in-cxx branch is no longer active.  All the work was merged to
trunk, where it is available via --enable-build-with-cxx.  If you want
to work on the gcc-in-cxx branch, start by merging from trunk.


Sorry, I didn't mean to imply I was working on the now-dead branch. I'm 
doing this work in trunk. I want the build-as-cxx option to work decently 
so that my profiledbootstrap exercises the C++ front-end more, since that 
is what we compile all our code with here. As such, I'm building trunk to 
eliminate some of the cxx failures, and will submit a patch once it either 
builds completely or I've hit a brick wall. This should (hopefully) make 
for less work when the more invasive changes are started once trunk is 
open again.


PS: of course, it would be even better if profiledbootstrap allowed me to 
point at our build's makefile to generate the runtime profile.

--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt

Re: GCC aliasing rules: more aggressive than C99?

[Joshua Haberman]

Andrew Haley  redhat.com> writes:
> but
>
>  (union u*)&i
>
> is not a legal lvalue expression because the dereference is undefined
> behaviour.

Your example does not contain a dereference.

> You may only dereference a pointer as permitted by 6.3.2.3.

6.3.2.3 does not mention dereferencing at all; it only addresses pointer
conversion.  Dereferencing is defined in 6.5.3.2.

But let me ask you this.  What do you think 6.5 paragraph 7 means?  For
example, are you also of the opinion that this is illegal?

  int i;
  unsigned int *pui = (unsigned int*)&i;
  unsigned int ui = *pui;

I believe that GCC allows this (Richard can correct me if I am wrong),
but under your interpretation this would be illegal because "int" and
"unsigned int" are not compatible types.  The only thing that makes this
legal is 6.5 paragraph 7, where one of the allowed aliasing scenarios
is:

  a type that is the signed or unsigned type corresponding to the
  effective type of the object

Josh

Re: GCC aliasing rules: more aggressive than C99?

[Andrew Haley]

On 01/05/2010 07:58 PM, Joshua Haberman wrote:
> Andrew Haley  redhat.com> writes:
>> but
>>
>>  (union u*)&i
>>
>> is not a legal lvalue expression because the dereference is undefined
>> behaviour.
> 
> Your example does not contain a dereference.
> 
>> You may only dereference a pointer as permitted by 6.3.2.3.
> 
> 6.3.2.3 does not mention dereferencing at all; it only addresses pointer
> conversion.  Dereferencing is defined in 6.5.3.2.
> 
> But let me ask you this.  What do you think 6.5 paragraph 7 means?  For
> example, are you also of the opinion that this is illegal?
> 
>   int i;
>   unsigned int *pui = (unsigned int*)&i;
>   unsigned int ui = *pui;

That's covered by 6.3.2.3 Para 2.

Andrew.

Re: GCC aliasing rules: more aggressive than C99?

[Vincent Lefevre]

On 2010-01-05 16:16:52 +, Joseph S. Myers wrote:
> On Tue, 5 Jan 2010, Vincent Lefevre wrote:
> > 6.3.2.3 says that one can *convert* the pointer, but not that one can
> > *dereference* it.
> 
> You can dereference it if it is defined where (to what object of the 
> relevant type) it points, and no other rule prohibits the dereference.

But this is the same for (union u*)&i. I don't see how 6.3.2.3 could
make a difference between (char *)&i and (union u*)&i as long as the
pointer is correctly aligned.

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

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[Roland McGrath]

> I'm still not entirely convinced that this is the way to go.  It seems
> to me that ideally one wants to be able to select the linker at
> runtime.  I don't see how this patch supports that.  What am I
> missing?

It covers the first step by letting you run "ld.bfd" or "ld.gold" to
choose.  Having the two binaries installed by those names is a good start
and seems likely to be part of how any fancier plan would work, so why not
start there?

This setup is compatible with using "alternatives" to switch a $(bindir)/ld
symlink.  Using "alternatives" is outside the scope of what 'make install'
should do, so having it install a plain symlink makes sense.  Packagers
will drop the ld symlink and do their own thing.  (This is exactly what we
are doing now in Fedora >= 13.)

Another obvious approach is to add a wrapper script for $(bindir)/ld that
groks an argument like --gold or --bfd to choose which real ld to run.
That could be used by hand and by gcc -Wl,--gold, etc.  That is also fine
by me.  But it requires inventing some new plan for where the system-wide
default is configured.  IMHO it seems better just to leave that sort of
thing to packagers.


Thanks,
Roland

Re: [gcc-as-cxx] enum conversion to int

[Ian Lance Taylor]

Matt  writes:

> Yes, was I pasted was a local change. I was trying to eliminate the
> implicit cast to int from the enum type, which was causing my
> --enable-werror build to fail. At this point, I think the better
> option would be to break up the enum values into indivdual #defines
> and do a typedef df_changeable_flags int;

Don't use #defines.  Enums give better debug info by default.  typedef
df_changeable_flags int is fine if that seems necessary.  Right now
the code simply doesn't use the df_changeable_flags type any time
there is more than one flag.

Ian

Re: GCC aliasing rules: more aggressive than C99?

[Vincent Lefevre]

On 2010-01-05 20:50:38 +, Andrew Haley wrote:
> On 01/05/2010 07:58 PM, Joshua Haberman wrote:
> > Andrew Haley  redhat.com> writes:
> >> but
> >>
> >>  (union u*)&i
> >>
> >> is not a legal lvalue expression because the dereference is undefined
> >> behaviour.
> > 
> > Your example does not contain a dereference.
> > 
> >> You may only dereference a pointer as permitted by 6.3.2.3.
> > 
> > 6.3.2.3 does not mention dereferencing at all; it only addresses pointer
> > conversion.  Dereferencing is defined in 6.5.3.2.

and I'd say that it is also covered by 6.2.6.1 (together with 6.5p7).

> > But let me ask you this.  What do you think 6.5 paragraph 7 means?  For
> > example, are you also of the opinion that this is illegal?
> > 
> >   int i;
> >   unsigned int *pui = (unsigned int*)&i;
> >   unsigned int ui = *pui;
> 
> That's covered by 6.3.2.3 Para 2.

This paragraph is about pointer conversion, not dereferencing.

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

Re: GCC aliasing rules: more aggressive than C99?

[Andrew Haley]

On 01/05/2010 07:38 PM, Joshua Haberman wrote:
> Robert Dewar  adacore.com> writes:
>> In any case the gcc interpretation is clearly what's
>> intended in my view, so if it can be argued that the
>> standard is inconsistent with this interpretation (I
>> am unconvinced that this burden has been met), then
>> the conclusion is to add a clarification to the
>> standard, not to modify the gcc behavior.
> 
> I agree with you completely on this point.  My position throughout this
> thread has been that GCC should keep its existing type-based aliasing
> behavior.  I think the GCC policy represents a good trade-off between a
> policy that is not aggressive enough and a policy that is too hard to
> follow.
> 
> In my view the C99 standard quite clearly specifies a policy that is
> less aggressive than what GCC implements.  I think it's hard to come to
> any other conclusion; section 6.5 paragraph 7 contains a footnote
> explicitly stating that the intention is to specify conditions under
> which values may be aliased, and one of the rules allows for an aliasing
> condition that GCC does not respect.  I have not heard any credible 
> rebuttal to this point, 

On the contrary, you haven't even addressed the core issue.  6.3.2.3
limits the pointer conversions that you may do without undefined
behaviour.  The conversion in your example displays undefined
behaviour, since it is not permitted by 6.3.2.3.  Therefore, your
example is not legal C.  Once you have a single example of undefined
beaviour, the rest of the program is irrelevant.

> or any explanation of what 6.5 paragraph 7 *does* mean, if it is not
> intended to specify aliasing rules.

It means, for example, that if you have something like

struct s1
{
  float a;
  float b;
};

void foo(struct s *a, int *b)
{
  ...

an access to *a shall not access the value of *b.  However, an access
to a struct type that includes a member of a type compatible with int
may access the value of *b.  This is a rule that gcc uses to do its
alias analysis.

However, this rule should not be read as extending the range of legal
pointer conversions: it only limits the types that may alias.

Andrew.

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[Ian Lance Taylor]

Roland McGrath  writes:

>> I'm still not entirely convinced that this is the way to go.  It seems
>> to me that ideally one wants to be able to select the linker at
>> runtime.  I don't see how this patch supports that.  What am I
>> missing?
>
> It covers the first step by letting you run "ld.bfd" or "ld.gold" to
> choose.  Having the two binaries installed by those names is a good start
> and seems likely to be part of how any fancier plan would work, so why not
> start there?

Mainly because an alternative is to install them in subdirectories
with the name ld.  Then gcc can run them directly using a -B option.
I don't know which approach is best.

Ian

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[H.J. Lu]

On Tue, Jan 5, 2010 at 1:35 PM, Ian Lance Taylor  wrote:
> Roland McGrath  writes:
>
>>> I'm still not entirely convinced that this is the way to go.  It seems
>>> to me that ideally one wants to be able to select the linker at
>>> runtime.  I don't see how this patch supports that.  What am I
>>> missing?
>>
>> It covers the first step by letting you run "ld.bfd" or "ld.gold" to
>> choose.  Having the two binaries installed by those names is a good start
>> and seems likely to be part of how any fancier plan would work, so why not
>> start there?
>
> Mainly because an alternative is to install them in subdirectories
> with the name ld.  Then gcc can run them directly using a -B option.
> I don't know which approach is best.
>

Plugin only works with gold. So I configured my gcc with

-with-plugin-ld=ld.gold

If both linkers have the same name, it will be harder to
use ld by default and use gold only for plugin.

-- 
H.J.

Re: [gcc-as-cxx] enum conversion to int

[Matt]

On Tue, 5 Jan 2010, Ian Lance Taylor wrote:


Matt  writes:


Yes, was I pasted was a local change. I was trying to eliminate the
implicit cast to int from the enum type, which was causing my
--enable-werror build to fail. At this point, I think the better
option would be to break up the enum values into indivdual #defines
and do a typedef df_changeable_flags int;


Don't use #defines.  Enums give better debug info by default.  typedef
df_changeable_flags int is fine if that seems necessary.  Right now
the code simply doesn't use the df_changeable_flags type any time
there is more than one flag.


Okay, good to know about the better debuggability of enums. If the flags 
are supposed to be mutually exclusive, then the code in my other email 
where two flags are added together seems contrary.


Regardless, does this mean  that the bit-wise operations for set_flags and 
clear_flags could be changed to simple assignments? That would indeed fix 
this issue in a nice way.


--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt

Thanks for your help!

[Fleaser Team]

Hello,
we are a small team and would need  your help,just click and you've already 
helped.We thanks in advance.

Look at our  website:
http://www.fleaser.com

Follow us on Twitter
http://twitter.com/fleaser



Send this message  to your friends and help us.

Thanks for your help!

Greetings
Fleaser Team

Re: GCC aliasing rules: more aggressive than C99?

[Vincent Lefevre]

On 2010-01-05 21:29:22 +, Andrew Haley wrote:
> On the contrary, you haven't even addressed the core issue.  6.3.2.3
> limits the pointer conversions that you may do without undefined
> behaviour.  The conversion in your example displays undefined
> behaviour, since it is not permitted by 6.3.2.3.  Therefore, your
> example is not legal C.  Once you have a single example of undefined
> beaviour, the rest of the program is irrelevant.

I disagree. The conversion in Joshua's example has a defined behavior
if the pointer is correctly aligned.

Then the question is whether Joshua's example is a simplification of
a more complex code that ensures that, or whether this is implied by
the architecture (ABI) and compiler options he used.

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

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[Ian Lance Taylor]

"H.J. Lu"  writes:

> On Tue, Jan 5, 2010 at 1:35 PM, Ian Lance Taylor  wrote:
>> Roland McGrath  writes:
>>
 I'm still not entirely convinced that this is the way to go.  It seems
 to me that ideally one wants to be able to select the linker at
 runtime.  I don't see how this patch supports that.  What am I
 missing?
>>>
>>> It covers the first step by letting you run "ld.bfd" or "ld.gold" to
>>> choose.  Having the two binaries installed by those names is a good start
>>> and seems likely to be part of how any fancier plan would work, so why not
>>> start there?
>>
>> Mainly because an alternative is to install them in subdirectories
>> with the name ld.  Then gcc can run them directly using a -B option.
>> I don't know which approach is best.
>>
>
> Plugin only works with gold. So I configured my gcc with
>
> -with-plugin-ld=ld.gold
>
> If both linkers have the same name, it will be harder to
> use ld by default and use gold only for plugin.

The issue can be addressed with symlinks.

Of course, if we have a way to tell gcc the linker to use, by name, at
runtime, that will also work.

Ian

Re: [gcc-as-cxx] enum conversion to int

[Ian Lance Taylor]

Matt  writes:

> On Tue, 5 Jan 2010, Ian Lance Taylor wrote:
>
>> Matt  writes:
>>
>>> Yes, was I pasted was a local change. I was trying to eliminate the
>>> implicit cast to int from the enum type, which was causing my
>>> --enable-werror build to fail. At this point, I think the better
>>> option would be to break up the enum values into indivdual #defines
>>> and do a typedef df_changeable_flags int;
>>
>> Don't use #defines.  Enums give better debug info by default.  typedef
>> df_changeable_flags int is fine if that seems necessary.  Right now
>> the code simply doesn't use the df_changeable_flags type any time
>> there is more than one flag.
>
> Okay, good to know about the better debuggability of enums. If the
> flags are supposed to be mutually exclusive, then the code in my other
> email where two flags are added together seems contrary.

The flags are not mutually exclusive.  They are bit values which may
be combined.  This is a pattern which is used in various places in
gcc.

> Regardless, does this mean  that the bit-wise operations for set_flags
> and clear_flags could be changed to simple assignments? That would
> indeed fix this issue in a nice way.

No, that won't work.

What is the actual problem that you are encountering?

Ian

gcc-4.4-20100105 is now available

[gccadmin]

Snapshot gcc-4.4-20100105 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100105/
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 155662

You'll find:

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

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

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

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

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

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

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

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

Diffs from 4.4-20091229 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: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[Roland McGrath]

> Mainly because an alternative is to install them in subdirectories
> with the name ld.  Then gcc can run them directly using a -B option.
> I don't know which approach is best.

I think it keeps things simplest for humans to understand if the actual
binaries are available as ld.bfd and ld.gold.  If you then want some
obscure directory names containing an "ld" for gcc's use, then make those
symlinks.  Personally, I think -Wl,--gold (via $(bindir)/ld being a wrapper
script) is nicer than -B/usr/libexec/binutils/gold/ or whatnot.


Thanks,
Roland

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[Matthias Klose]

On 05.01.2010 23:29, Ian Lance Taylor wrote:

"H.J. Lu"  writes:


On Tue, Jan 5, 2010 at 1:35 PM, Ian Lance Taylor  wrote:

Roland McGrath  writes:


I'm still not entirely convinced that this is the way to go.  It seems
to me that ideally one wants to be able to select the linker at
runtime.  I don't see how this patch supports that.  What am I
missing?


It covers the first step by letting you run "ld.bfd" or "ld.gold" to
choose.  Having the two binaries installed by those names is a good start
and seems likely to be part of how any fancier plan would work, so why not
start there?


Mainly because an alternative is to install them in subdirectories
with the name ld.  Then gcc can run them directly using a -B option.
I don't know which approach is best.



Plugin only works with gold. So I configured my gcc with

-with-plugin-ld=ld.gold

If both linkers have the same name, it will be harder to
use ld by default and use gold only for plugin.


The issue can be addressed with symlinks.

Of course, if we have a way to tell gcc the linker to use, by name, at
runtime, that will also work.


symlinks are only a solution for a globally configured default. when building a 
package which requires a specific linker, you'll have to work with explicit 
build-depends/build-conflicts which need package installation/removal for 
building a single package. this might be feasible for a machine used by a single 
developer, but not for a machine where you don't have root access, and you still 
want to be able to use both ld versions. For this kind of setup an option 
interpreted by the gcc driver like --ld= would be useful. even managing this 
symlink with alternatives or diversions gives you the flexibility.


  Matthias

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[Matthias Klose]

On 05.01.2010 23:59, Roland McGrath wrote:
>> I'm still not entirely convinced that this is the way to go.  It seems
>> to me that ideally one wants to be able to select the linker at
>> runtime.  I don't see how this patch supports that.  What am I
>> missing?
>
> It covers the first step by letting you run "ld.bfd" or "ld.gold" to
> choose.  Having the two binaries installed by those names is a good start
> and seems likely to be part of how any fancier plan would work, so why not
> start there?

agreed on this.


Mainly because an alternative is to install them in subdirectories
with the name ld.  Then gcc can run them directly using a -B option.
I don't know which approach is best.


I think it keeps things simplest for humans to understand if the actual
binaries are available as ld.bfd and ld.gold.  If you then want some
obscure directory names containing an "ld" for gcc's use, then make those
symlinks.  Personally, I think -Wl,--gold (via $(bindir)/ld being a wrapper
script) is nicer than -B/usr/libexec/binutils/gold/ or whatnot.


why not make this more explicit by adding an option --ld which is directly 
understood by the gcc driver?


  Matthias

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[Ian Lance Taylor]

Roland McGrath  writes:

>> Mainly because an alternative is to install them in subdirectories
>> with the name ld.  Then gcc can run them directly using a -B option.
>> I don't know which approach is best.
>
> I think it keeps things simplest for humans to understand if the actual
> binaries are available as ld.bfd and ld.gold.  If you then want some
> obscure directory names containing an "ld" for gcc's use, then make those
> symlinks.  Personally, I think -Wl,--gold (via $(bindir)/ld being a wrapper
> script) is nicer than -B/usr/libexec/binutils/gold/ or whatnot.

OK, HJ's approach is OK with me.

I would still like another binutils maintainer to take a look at the
patch, once he updates it for my comments.

Ian

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[Roland McGrath]

> why not make this more explicit by adding an option --ld which is
> directly understood by the gcc driver?

Feel free to send some gcc patches.  I see no point in this.
We have -Wl.

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[Daniel Jacobowitz]

On Tue, Jan 05, 2010 at 05:01:24PM -0800, Roland McGrath wrote:
> > why not make this more explicit by adding an option --ld which is
> > directly understood by the gcc driver?
> 
> Feel free to send some gcc patches.  I see no point in this.
> We have -Wl.

I deal with a lot of host systems where shell scripts aren't a viable
option for ld.  Why make everyone write the wrapper script?  Makes
sense to me to have gcc decide.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GCC aliasing rules: more aggressive than C99?

[Erik Trulsson]

On Sun, Jan 03, 2010 at 05:46:48AM +, Joshua Haberman wrote:
> The aliasing policies that GCC implements seem to be more strict than
> what is in the C99 standard.  I am wondering if this is true or whether
> I am mistaken (I am not an expert on the standard, so the latter is
> definitely possible).
> 
> The relevant text is:
> 
>   An object shall have its stored value accessed only by an lvalue
>   expression that has one of the following types:
> 
>   * a type compatible with the effective type of the object,
>   [...]
>   * an aggregate or union type that includes one of the aforementioned
> types among its members (including, recursively, a member of a
> subaggregate or contained union), or
> 
> To me this allows the following:
> 
>   int i;
>   union u { int x; } *pu = (union u*)&i;
>   printf("%d\n", pu->x);
> 
> In this example, the object "i", which is of type "int", is having its
> stored value accessed by an lvalue expression of type "union u", which
> includes the type "int" among its members.

Even with your interpretation of the C99 standard that example would be
allowed only if  '*pu' is a valid lvalue of type  'union u'.  (Since pu->x
is equivalent to (*pu).x)

First of all the conversion  (union u*)&i is valid only if the alignment
of 'i' is suitable for an object of type 'union u'.  Lets assume that is the
case. (Otherwise just making that conversion would result in undefined
behaviour.)  (See 6.3.2.3 clause 7.)

There is however no guarantee that the conversion yields a valid "pointer to
union u".  If not then dereferencing it (with the expression '*pu') has
undefined behaviour. (See 6.5.3.2 clause 4)

So your example contains undefined behaviour even without considering the
parts of 6.5 clause 7 that you quoted.




Moreover I think you are misinterpreting 6.5 clause 7 (which I concede is
fairly easy since it is not quite as unambiguous as one could wish).
I believe that paragraph should not be interpreted as automatically allowing
all accesses that correspond to one of the sorts listed.  Rather it should
be interpreted as saying that if an access is not included in that list then
it is not allowed, but even if it is included in that list there could be
other reasons why it is not allowed.  (I.e.  just as the attached footnote
suggests it is a list of what types of aliasing are allowed, not of which
pointers may be dereferenced.)


As for the purpose of the part you quoted above (about aggregate and union
types) I believe it is intended for the following situation:

 struct S1 {
 int x;
 int y;
 double z;
 };

 struct S2 {
 float f1;
 float f2;
 };

 void foo(struct S1 *p1, int *a)
{

 ...

}

 void bar(struct S2 *p2, int *b)
{

 ...


}



Here 6.5 clause 7 says that (inside the functions depicted) it is possible
that accessing the object '*p1' also accesses the object '*a' while it is
guaranteed that accessing '*p2' will not access '*b', since '*p1' is an
aggregate type containing a member of the same type as '*b', while '*p2' is
an aggregate type not containing a member of the same type as '*b'.

Moreover accessing (*p1).x) or (*p1).y might also access '*a' (since the type
of '(*p1).x' is compatible with the type of '*a'), but an access to
'(*p1).z' will not access '*a'.

(The obvious situation where accessing *p1 would also access *a is if foo() is
called as follows:

 struct S1 A;

 foo(&A, &(A.x));

)

-- 

Erik Trulsson
ertr1...@student.uu.se

Re: GCC aliasing rules: more aggressive than C99?

[Joshua Haberman]

Erik Trulsson  student.uu.se> writes:
> On Sun, Jan 03, 2010 at 05:46:48AM +, Joshua Haberman wrote:
> > The aliasing policies that GCC implements seem to be more strict than
> > what is in the C99 standard.  I am wondering if this is true or whether
> > I am mistaken (I am not an expert on the standard, so the latter is
> > definitely possible).
> >-
> > The relevant text is:
> >-
> >   An object shall have its stored value accessed only by an lvalue
> >   expression that has one of the following types:
> >-
> >   * a type compatible with the effective type of the object,
> >   [...]
> >   * an aggregate or union type that includes one of the aforementioned
> > types among its members (including, recursively, a member of a
> > subaggregate or contained union), or
> >-
> > To me this allows the following:
> >-
> >   int i;
> >   union u { int x; } *pu = (union u*)&i;
> >   printf("%d\n", pu->x);
> >-
> > In this example, the object "i", which is of type "int", is having its
> > stored value accessed by an lvalue expression of type "union u", which
> > includes the type "int" among its members.
>-
> Even with your interpretation of the C99 standard that example would be
> allowed only if  '*pu' is a valid lvalue of type  'union u'.  (Since pu->x
> is equivalent to (*pu).x)
>-
> First of all the conversion  (union u*)&i is valid only if the alignment
> of 'i' is suitable for an object of type 'union u'.  Lets assume that is the
> case. (Otherwise just making that conversion would result in undefined
> behaviour.)  (See 6.3.2.3 clause 7.)

This is true.  You could get around this particular point by saying:

  int *i = malloc(sizeof(*i));
  *i = 5;
  union u { int x; } *pu = (union u*)i;
  printf("%d\n", pu->x);

...since the return from malloc() is guaranteed to be suitably aligned for
any object (7.20.3).  But your point is taken.

> There is however no guarantee that the conversion yields a valid "pointer to
> union u".  If not then dereferencing it (with the expression '*pu') has
> undefined behaviour. (See 6.5.3.2 clause 4)

I think this is a bit of a stretch.  It is true that 6.5.3.2 says that
dereferencing invalid values has undefined behavior.  But if you are
saying that the standard has to explicitly say that a pointer conversion
will not result in an invalid value (even when suitably aligned), then
the following is also undefined:

  int i;
  unsigned int *pui = (unsigned int*)&i;
  unsigned int ui = *pui;

Andrew cited 6.3.2.3p2 as support for why this is defined, but that
paragraph deals with qualifiers (const, volatile, and restrict).
"unsigned" is not a qualifier.  There is no part of the standard that
guarantees that a pointer conversion from "int*" to "unsigned int*" will
not result in an invalid value.

> So your example contains undefined behaviour even without considering the
> parts of 6.5 clause 7 that you quoted.
>-
> Moreover I think you are misinterpreting 6.5 clause 7 (which I concede is
> fairly easy since it is not quite as unambiguous as one could wish).
> I believe that paragraph should not be interpreted as automatically allowing
> all accesses that correspond to one of the sorts listed.  Rather it should
> be interpreted as saying that if an access is not included in that list then
> it is not allowed, but even if it is included in that list there could be
> other reasons why it is not allowed.  (I.e.  just as the attached footnote
> suggests it is a list of what types of aliasing are allowed, not of which
> pointers may be dereferenced.)

Interesting.  I think it is plausible that this is what the committee
intended.  It like the committee wanted to give a heads-up to
implementations that pointers to primitive types can alias pointers to
those same types within unions and aggregates, just as a result of
taking the address of a member.

In any case I definitely agree that this could be clarified, and I hope the
standards committee will take this up for C1x.

Thank you for your thoughtful analysis.

Josh

Re: PATCH: Support --enable-gold=both --with-linker=[bfd|gold]

[H.J. Lu]

On Tue, Jan 5, 2010 at 11:08 AM, Ian Lance Taylor  wrote:
> "H.J. Lu"  writes:

>
>> diff --git a/configure.ac b/configure.ac
>> index 407ab59..b349633 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -311,10 +311,11 @@ esac
>>  # Handle --enable-gold.
>>
>>  AC_ARG_ENABLE(gold,
>> -[  --enable-gold           use gold instead of ld],
>> +[  --enable-gold[[=ARG]]     build gold [[ARG={yes,both}]]],
>>  ENABLE_GOLD=$enableval,
>>  ENABLE_GOLD=no)
>> -if test "${ENABLE_GOLD}" = "yes"; then
>> +case "${ENABLE_GOLD}" in
>> +yes|both)
>>    # Check for ELF target.
>>    is_elf=no
>>    case "${target}" in
>> @@ -334,11 +335,17 @@ if test "${ENABLE_GOLD}" = "yes"; then
>>      # Check for target supported by gold.
>>      case "${target}" in
>>        i?86-*-* | x86_64-*-* | sparc*-*-* | powerpc*-*-* | arm*-*-*)
>> -        configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
>> +        if test "${ENABLE_GOLD}" = both; then
>> +          configdirs="$configdirs gold"
>> +     else
>> +          configdirs="`echo " ${configdirs} " | sed -e 's/ ld / gold /'`"
>> +     fi
>>          ;;
>>      esac
>>    fi
>> -fi
>> +  ENABLE_GOLD=yes
>> +  ;;
>> +esac
>
> You should have an error case here to ensure that --enable-gold only
> has the values "yes", "both", or "no".  --enable-gold=foo should give
> an error.
>
> This patch uses two configure options: one to build both gold and ld,
> and one to select which linker is the default.  Why not use just one
> configure option?  Perhaps something like:
>    --enable-gold              Build only gold, gold is default
>    --disable-gold [default]   Build only GNU ld, GNU ld is default
>    --enable-gold=no           Same
>    --enable-gold=both         Build both gold and GNU ld, gold is default
>    --enable-gold=both/gold    Same
>    --enable-gold=both/bfd     Build both gold and GNU ld, GNU ld is default

Done.

> But of course this approach is conditional on whether there should be
> some way to select the linker to use at runtime.
>
>
>
>> diff --git a/gold/Makefile.am b/gold/Makefile.am
>> index 8d8b617..85b103b 100644
>> --- a/gold/Makefile.am
>> +++ b/gold/Makefile.am
>> @@ -163,12 +163,20 @@ check: libgold.a
>>
>>  install-exec-local: ld-new$(EXEEXT)
>>       $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(tooldir)/bin
>> -     n=`echo ld | sed '$(transform)'`; \
>> +     n=`echo @installed_linker@ | sed '$(transform)'`; \
>>       $(INSTALL_PROGRAM) ld-new$(EXEEXT) $(DESTDIR)$(bindir)/$${n}$(EXEEXT); 
>> \
>> -     if test "$(bindir)" != "$(tooldir)/bin"; then \
>> -       rm -f $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
>> -       ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) 
>> $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT) >/dev/null 2>/dev/null \
>> +     if test "@linker@" = "ld.gold"; then \
>> +       if test "@installed_linker@" != "ld"; then \
>> +         ld=`echo ld | sed '$(transform)'`; \
>> +         rm -f $(DESTDIR)$(bindir)/$${ld}$(EXEEXT); \
>> +         ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) 
>> $(DESTDIR)$(bindir)/$${ld}$(EXEEXT) >/dev/null 2>/dev/null \
>> +         || $(INSTALL_PROGRAM) ld-new$(EXEEXT) 
>> $(DESTDIR)$(bindir)/$${ld}$(EXEEXT); \
>> +       fi; \
>> +       if test "$(bindir)" != "$(tooldir)/bin"; then \
>> +         rm -f $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
>> +         ln $(DESTDIR)$(bindir)/$${n}$(EXEEXT) 
>> $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT) >/dev/null 2>/dev/null \
>>           || $(INSTALL_PROGRAM) ld-new$(EXEEXT) 
>> $(DESTDIR)$(tooldir)/bin/ld$(EXEEXT); \
>> +       fi; \
>>       fi
>
> In Makefile.am you don't need to use @@ quoting in rules.  You can
> just use $(installed_linker) and $(linker).
>

Done.

>
>> diff --git a/gold/configure.ac b/gold/configure.ac
>> index 85e23f9..10389a9 100644
>> --- a/gold/configure.ac
>> +++ b/gold/configure.ac
>> @@ -38,6 +38,29 @@ AC_DEFINE_UNQUOTED(TARGET_SYSTEM_ROOT, "$sysroot",
>>  AC_DEFINE_UNQUOTED(TARGET_SYSTEM_ROOT_RELOCATABLE, $sysroot_relocatable,
>>    [Whether the system root can be relocated])
>>
>> +AC_ARG_ENABLE(gold,
>> +[  --enable-gold[[=ARG]]     build gold [[ARG={yes,both}]]],
>> +[if test "${enableval}" = "both"; then
>> +   bfd_linker=ld.bfd
>> +   installed_linker=ld.gold
>> + else
>> +   bfd_linker=ld.gold
>> +   installed_linker=ld
>> + fi],
>> +[bfd_linker=ld.bfd
>> + installed_linker=ld])
>> +AC_SUBST(installed_linker)
>
> It seems rather weird to set a variable named bfd_linker to be
> ld.gold.  What does that mean?

Rewritten.

>
>> +AC_ARG_ENABLE(linker,
>> +[  --enable-linker=[[ARG]]   specify the default linker [[ARG={bfd,gold}]]],
>> +[if test "${enableval}" = "gold"; then
>> +   linker=ld.gold
>> + else
>> +   linker=$bfd_linker
>> + fi],
>> +[linker=$bfd_linker])
>> +AC_SUBST(linker)
>
> You should give an error if --enable-linker is used with an
> unrecognized value.

Done.

>
>> --- a/ld/Makefile.am
>> +++ b/ld/Makefile.am
>> @@ -95,7 +95,7 @@ CXX_FOR_TARGET = ` \
>>      fi; \
>>    fi`
>>
>> -transform = s/^ld-new$$/ld/;@program_transfor

Re: GCC aliasing rules: more aggressive than C99?

[Patrick Horgan]

Erik Trulsson wrote:

Moreover I think you are misinterpreting 6.5 clause 7 (which I concede is
fairly easy since it is not quite as unambiguous as one could wish).
I believe that paragraph should not be interpreted as automatically allowing
all accesses that correspond to one of the sorts listed.  Rather it should
be interpreted as saying that if an access is not included in that list then
it is not allowed, but even if it is included in that list there could be
other reasons why it is not allowed.  (I.e.  just as the attached footnote
suggests it is a list of what types of aliasing are allowed, not of which
pointers may be dereferenced.)
  
Good point, they're saying that something other than this list is 
undefined for sure.


While the C Standard says in this section:

7 An object shall have its stored value accessed only by an lvalue 
expression that has one of the following types:78)

with footnote 78 saying:
78) The intent of this list is to specify those circumstances in which 
an object may or may not be aliased.


The same section of the C++ standard says:
15 If a program attempts to access the stored value of an object through 
an lvalue of other than one of the following types the behavior is 
undefined:49)

with footnote 49 saying:
49) The intent of this list is to specify those circumstances in which 
an object may or may not be aliased.


The content of the section is almost identical, and both say identically 
word for word:
— an aggregate or union type that includes one of the aforementioned 
types among its members (including, recursively, a member of a 
subaggregate or contained union),


and I think that the intent of the C version is the same as the C++ 
clearly states. This is a list of all the ways to access a stored value 
through an lvalue. Anything else is undefined behavior. So constructing 
code to bypass the pointer issues, gcc does allow accessing an int value 
through a lvalue that is a union that contains an int like this:


int i;
union u{ int x; };
printf("%d\n",(*((union u*)&i)).x);

although it's perverse, it doesn't seem to break any aliasing rules and 
neither gcc (nor g++ with an equivalent std::cout line), complain about 
it with maximum aliasing bitching turned on. And indeed, the problems 
with aliasing are more like the cool part about the structs I elided 
above. -fstrict-aliasing is a promise to the compiler that you aren't 
going to do weird things like:


void foo(int, float);

union u{
int a;
float b;
}

foo(u.a, u.b);

so that it can do some types of optimizations it couldn't otherwise do. 
-Wstrict-aliasing tries to warn you if you break the promise, although 
if the definition and call are in different compilation units gcc won't 
know.


A funnier example of something that seems not to break the above 
aliasing rules, (really equivalent to the printf above), the following 
when compiled with -fstrict-aliasing -Wstrict-aliasing=3 doesn't get 
complained about by 4.4.1 or 4.5.0 at least.


#include 
union u { int x; };

void
foo(union u theu)
{
printf("%d\n",theu.x);
}

int main()
{
int i=7;
foo(*((union u*)&i));
return 0;
}

Patrick

Re: entry point of gimplification

[sandeep soni]

On Tue, Jan 5, 2010 at 8:44 PM, Diego Novillo  wrote:
> On 1/4/10 14:57 , sandeep soni wrote:
>
>> I want to know what is the entry point to the gimplification pass? and
>> given a function body which are the functions in the gcc source that
>> convert the body into equivalent gimple statements?
>
> This is controlled from the callgraph manager.  You need to start
> looking at cgraphunit.c:cgraph_analyze_functions.  It traverses the
> cgraph queue converting each node into gimple (the call to
> cgraph_analyze_function).
>
>> Also is there a way in which i can selectively step through the
>> execution of the source related to this?
>
> Yes.  You need to debug cc1/cc1plus and set a breakpoint in
> cgraph_analyze_functions.  The function debug_cgraph() will show you the
> callgraph at that point.
>
>
> Diego.
>

Hi,

I recently read in the internal documentation of gcc that the main
entry point to the gimplification pass is the function defined in
gimplify.c: gimplify_function_tree function.Is there something which I
m missing?

plus can someone point to me to of any way in which I can achieve my
aim of speculatively parallelizing the code at runtime?
chiefly I wanna know if gcc supports it ?
(If not) would it be possible to do?

-- 
cheers
sandy