Re: bitwise dataflow

[Paolo Bonzini]

>> 1. Dataflow framework to propagate bitwise register properties.
>>   (Integrated with the current dataflow framework.)
>> 2. Forward bitwise dataflow analysis: constant bit propagation.
>> 3. Backward bitwise dataflow analysis: dead bit propagation.
>> 4. Target applications: improve dce and see.  (Others?)

>>   For each instruction I in the function body
>> For each register R in instruction I
>>   def_constant_bits(I, R) = collect constants from AND/OR/...
>> operations.

There's already nonzero_bits (i.e. maybe nonzero) and
num_sign_bit_copies in rtlanal.c.  You can add to this one_bits and it
should be enough to do the simplifications you want.

You can get initial info from those routines, do the dataflow.  Then
there are rtx_hooks members to get a REG's nonzero bits/# of sign bit
copies (and you can add one for one_bits): just set them to a function
in your pass that returns info from the dataflow.  Then you can walk
through all the functions, recursively simplifying the RHS of each set
(you can look at propagate_rtx in fwprop.c for an example of
"simplifying the RHS").  The code in simplify-rtx.c will take care of
using the nonzero_bits (et al.) information; other optimizations can be
added there.

Do not forget to check the cost of the replacement, otherwise your pass
might end up doing constant propagation (for constants, all zero and one
bits are known!!!).

Paolo

bitwise dataflow analysis

[Kenneth Zadeck]

Silvius,

If you want to persue this, you should go back and look at my patches
for subreg level dataflow and start hacking from there.   It is not a
big step to start from that and modify it for bits.   If you start
from that, it is most likely not much more than a few days work for
the analysis part.  However, hacking combine could be a life long effort!

All of this code got removed because it's only client was the old ra.

Kenny

Handling of extern inline in c99 mode

[Bernd Roesch]

Hi, 

I find this mails here

http://gcc.gnu.org/ml/gcc/2006-11/msg6.html

But i find no answer how i can do same as extern inline and get no problems
in C99 mode and other modes

I use for longer functions this code

extern __inline long func()
{
}

but when a makefile set -std=c99 then get linker error, multiple definition.

what commands gcc have and do same as extern __inline  and this way do not
clash with C99 ?

I can then change the header files.

i know static inline work, but this increase code size a lot.

Bye

Re: The gcc-in-cxx branch now completes bootstrap

[Kaveh R. GHAZI]

On Fri, 6 Mar 2009, Ian Lance Taylor wrote:

> I'm happy to report that the gcc-in-cxx branch can now bootstrap.  That
> is, the code in gcc proper can now be compiled with a C++ compiler.

Great work, thanks!

I'm curious whether there are any detectable differences in the resulting
compiler when built with g++ rather than gcc.  E.g. testsuite regressions,
changes in the speed or size of cc1, etc.  Also, is cc1 linked with
libstdc++.so ?  Stuff like that.

Would you please consider checking this?

Thanks,
--Kaveh
--
Kaveh R. Ghazi  gh...@caip.rutgers.edu

Re: Handling of extern inline in c99 mode

[Dave Korn]

Bernd Roesch wrote:
> Hi, 
> 
> I find this mails here
> 
> http://gcc.gnu.org/ml/gcc/2006-11/msg6.html
> 
> But i find no answer how i can do same as extern inline and get no problems
> in C99 mode and other modes


http://gcc.gnu.org/ml/gcc/2007-03/msg01093.html

cheers,
  DaveK

Re: The gcc-in-cxx branch now completes bootstrap

[Laurent GUERBY]

On Fri, 2009-03-06 at 18:44 -0800, Ian Lance Taylor wrote:
> I'm happy to report that the gcc-in-cxx branch can now bootstrap.  That
> is, the code in gcc proper can now be compiled with a C++ compiler.

Hi, did you test with Ada enabled? There are some C files in the
Ada compiler and RTS.

Laurent

-mfpmath=sse,387 is experimental ?

[Timothy Madden]

Hello

Is -mfpmath=both for i386 and x86-64 still experimental in gcc 4.3, as
the in the online manual page ?

`sse,387'`sse+387'`both'Attempt to utilize both instruction sets at
once. This effectively double the amount of available registers and on
chips with separate execution units for 387 and SSE the execution
resources too. Use this option with care, as it is still experimental,
because the GCC register allocator does not model separate functional
units well resulting in instable performance.

Thank you,
Timothy Madden

Re: The gcc-in-cxx branch now completes bootstrap

[Gabriel Dos Reis]

On Fri, Mar 6, 2009 at 8:44 PM, Ian Lance Taylor  wrote:
> I'm happy to report that the gcc-in-cxx branch can now bootstrap.  That
> is, the code in gcc proper can now be compiled with a C++ compiler.
>
> My plan going forward is as follows (when we are back in stage 1):
>
> * For each difference between trunk and gcc-in-cxx:
>  + Try to implement a -Wc++-compat warning which detects the change.
>    - If it is possible, implement the warning, and make the changes to
>      let gcc bootstrap with the warning.
>    - If a warning is not possible for some reason, I will simply
>      propose the change by itself.  I expect this will be a small
>      subset of the changes, mostly related to the build system and to
>      low-level configuration like ansidecl.h.
>  + This process will eventually eliminate all differences between trunk
>    and gcc-in-cxx, at which point gcc-in-cxx can be retired.
>
> * Implement a configure option, --enable-c++-build or something like
>  that, which builds gcc with a C++ compiler.
>  + Start running regular builds with that option, to avoid any
>    regressions in C++ buildability for cases for which there is no
>    -Wc++-compat warning.
>
> * Begin the lobbying process for changing the default value of the
>  configure option.
>
> I certainly welcome help on any of these steps.
>
> Ian
>

Hi Ian,

  This is a really fantastic job you've done.
Please send copies of your messages to my address at TAMU for
patches to implement the need -Wc++-compat so that I can review
as quickly as possible.

-- Gaby

Re: C++ constant expressions in __attribute__

[Gabriel Dos Reis]

On Wed, Mar 4, 2009 at 9:37 AM, Joseph S. Myers  wrote:
> On Wed, 4 Mar 2009, Piotr Wyderski wrote:
>
>> Hello,
>>
>> Is it possible to allow C++ constant expressions (currently static const,
>> and C++0x constexpr in the future) to be used as __attribute__ parameters
>> in the upcomming version of GCC? In my code I have the following 
>> construction:
>
> What does C++0x say about this, if any C++0x [[]] attributes have integer
> parameters?

The current draft says no name lookup is done.  I don't think that
is very useful, and the French national body submitted a defect
(in the last CD ballot) to that effect.  I do not know yet whether the
comment was processed
by the C++ CWG group or what the decisions are at this point.

I also believe there is a bugzilla PR filled about this some time ago.

>
> (Not that I am impressed with the incompatibilities of C++0x attributes
> with existing practice or their ignoring all the hard issues with
> attributes that have actually come up in GCC implementation experience -
> along with the proposals having long lists of people they were discussed
> with, none of whom have been involved in any of the discussions of these
> issues with attributes in GCC.)

I may be wrong but I believe Jason Merrill had had input or participated
in the attribute discussions in the C++ CWG.

-- Gaby

Re: C++ constant expressions in __attribute__

[Joseph S. Myers]

On Sat, 7 Mar 2009, Gabriel Dos Reis wrote:

> > (Not that I am impressed with the incompatibilities of C++0x attributes
> > with existing practice or their ignoring all the hard issues with
> > attributes that have actually come up in GCC implementation experience -
> > along with the proposals having long lists of people they were discussed
> > with, none of whom have been involved in any of the discussions of these
> > issues with attributes in GCC.)
> 
> I may be wrong but I believe Jason Merrill had had input or participated
> in the attribute discussions in the C++ CWG.

The last paper I can find before attributes support was integrated in the 
C++0x document is N2761.  It has a long list of people acknowledged, with 
Jason Merrill not mentioned by name.  It retains the mistake of following 
a speculative future direction that used to be in the GCC manual that I 
removed in September 2007 as no longer a good idea after I found it had 
been picked up in previous draft proposals without talking to GCC people 
about whether it really made sense (see my WG14 paper N1259).  It does not 
seem to address the important question of classifying attributes as 
semantic or non-semantic (see 
), or even reference that 
discussion.

By making noreturn apply to functions not to their types, it is both 
incompatible with existing practice (whether they apply to functions or 
types is certainly visible with GNU typeof, and I suppose may also be 
visible through C++0x features without needing GNU extensions), and 
ignores rather than thinking about how to address the issues of how those 
attributes interact with the type system that I raised in 
.  (It also 
chooses in this instance to ignore a long-intended future direction that 
noreturn attributes should fully apply to types rather than declarations, 
albeit a direction that needs type system issues to be resolved before it 
can be brought into effect.  So it picks up bad future directions and 
ignores good ones.)

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

Re: C++ constant expressions in __attribute__

[Gabriel Dos Reis]

May I forward your message to the CCC++ CWG?

-- Gaby

Re: C++ constant expressions in __attribute__

[Joseph S. Myers]

On Sat, 7 Mar 2009, Gabriel Dos Reis wrote:

> May I forward your message to the CCC++ CWG?

Certainly, it is a public message, as are all the previous discussions it 
references.  I have not tried to engage with the C++ committee directly 
since I am not a C++ expert and keeping up with C development and pointing 
out (on the reflector and as needed in WG14 papers) when mistakes appear 
to be being made there is quite enough.

(Also, the points I make are influenced by the general acceptance in WG14 
that a major mistake C99 made was inventing new features and standardising 
existing ones in ways that were *similar but different* to existing 
implementations, through lack of understanding of the existing features, 
so causing very slow adoption of C99 and compatibility problems down the 
line, e.g. C99 versus GNU inline.  This was accepted in writing the C1x 
charter, but C++ may have different views on invention and compatibility.  
The choice of [[]] syntax does at least mean that __attribute__ can do one 
thing compatible with GNU practice and [[]] can do another thing as 
described in C++0x, but such a difference is bound to be confusing to 
users compared to making sure that attributes placed in the common subset 
of positions in the syntax have standard semantics that accord with 
existing practice.)

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

Re: C++ constant expressions in __attribute__

[Gabriel Dos Reis]

On Sat, Mar 7, 2009 at 4:45 PM, Joseph S. Myers  wrote:
> On Sat, 7 Mar 2009, Gabriel Dos Reis wrote:
>
>> May I forward your message to the CCC++ CWG?
>
> Certainly, it is a public message, as are all the previous discussions it
> references.  I have not tried to engage with the C++ committee directly
> since I am not a C++ expert and keeping up with C development and pointing
> out (on the reflector and as needed in WG14 papers) when mistakes appear
> to be being made there is quite enough.
>
> (Also, the points I make are influenced by the general acceptance in WG14
> that a major mistake C99 made was inventing new features and standardising
> existing ones in ways that were *similar but different* to existing
> implementations, through lack of understanding of the existing features,
> so causing very slow adoption of C99 and compatibility problems down the
> line, e.g. C99 versus GNU inline.  This was accepted in writing the C1x
> charter, but C++ may have different views on invention and compatibility.
> The choice of [[]] syntax does at least mean that __attribute__ can do one
> thing compatible with GNU practice and [[]] can do another thing as
> described in C++0x, but such a difference is bound to be confusing to
> users compared to making sure that attributes placed in the common subset
> of positions in the syntax have standard semantics that accord with
> existing practice.)

OK.  I believe semantics differences matter a lot.
My understanding is that the __attribute__ is found yucky
for some people, hence the [[]] syntax.

-- Gaby