Multiple FUNCTION_DECLS for __cxa_begin_catch

[Brendon Costa]

Hi again,

Getting further along with my project, I have come across yet another 
thing that I dont understand. While compiling:


libstdc++-v3/libsupc++/vec.cc

My GCC extension comes across two FUNCTION_DECL nodes that both have 
DECL_ASSEMBLER_NAME of __cxa_begin_catch


After reading some past posts it seems that the standard allows for 
multiple C functions defined extern "C" in different namespaces.


As an example of code which might do this see below:

extern "C"
{
  void Function(void) {}
}
namespace NS
{
  extern "C"
  {
 void Function(void);
  }
}

Is it safe to assume in the C++ front end that two functions declared in 
such a manner will always share the same implementation in which case it 
is kind-of like a "using" statement?


If so, is there any reason why the following code does not emit an error 
in the compiler but only in the assembler?


extern "C"
{
  void Function(void) {}
}
namespace NS
{
  extern "C"
  {
 void Function(void) {}
  }
}


Thanks,
Brendon.

Re: strict aliasing warning

[Silvius Rus]

Joe Buck wrote:


If you first prove that there is no cross-type aliasing, then turn on
-fstrict-aliasing, it seems to me that your alias sets won't change at
all.  The reason is that if there is a change, it means that you
eliminated an aliasing possibility based on the fact that it's not
allowed because of cross-type aliasing, which you said you proved there
is none of.
There have been concerns expressed in the past that if gcc checks for
strict aliasing violations, users will be upset when it misses some
violations but does optimization that breaks an ill-formed program.
I personally am not that worried about that; I think that it will help
train users if they see warning messages about blatant violations, to
the point where they will be less likely to create subtle, hard-to-detect
violations.
  
Yes, using the alias information produced by a complex algorithm may 
lead to errors as false negatives might sneak in.  That is OK when 
warning programmers, but will probably not be accepted as a 
preconditioner.  I was thinking more of a simplified check.  For 
instance, the most conservative and simplest would be verifying that 
there are no conversions to pointers to different types.  That will 
produce many false positives, but no false negatives.  However, if I 
understood you well, in such cases the complex algorithm will end up 
with the same alias sets with or without -fstrict-aliasing, so my 
conclusion is that it is probably not worth doing it.


Thank you,
Silvius

Re: strict aliasing warning

[Silvius Rus]

Joel Sherrill wrote:

Silvius Rus wrote:


I wrote some code (not released yet) that improves the accuracy of 
-Wstrict-aliasing using tree-ssa-alias information.  The primary idea 
was to tell the programmer "go fix the types of variables x and y at 
lines ..." when -fstrict-aliasing breaks their code.



How reliable is this detection and warning?  Is it ready for testers yet?
The first take is almost ready, but will need to pass peer review before 
releasing it (even to testers), so it will be a few days.


I ask because we have found a case where code in RTEMS breaks when 
strict-aliasing is enabled.  We are having
discussions on how to effectively perform an audit on RTEMS for other 
breakages.  Right now, the best idea is
Ralf's to diff the assembly generated for each file compiled with and 
without strict-aliasing.  If there is a difference,
we will have to review it.  This eliminates a lot of the code base but 
it is still generating a lot of cases to examine by

hand.

I'm curious if your patch will ease this process.
The balance (false positives, false negatives) can be controlled by a 
--param option.  You can limit the number of false positives for each 
type pair, originating statement, function, or compilation unit using 
another --param option.



--
Silvius

Re: strict aliasing warning

[Joel Sherrill]

Silvius Rus wrote:


I wrote some code (not released yet) that improves the accuracy of 
-Wstrict-aliasing using tree-ssa-alias information.  The primary idea 
was to tell the programmer "go fix the types of variables x and y at 
lines ..." when -fstrict-aliasing breaks their code.


It occurred to me that part of this code could be used as a 
preconditioner to aggressive optimization that would normally require 
-fstrict-aliasing, so this more aggressive optimization can then be 
performed selectively on individual functions even with 
-fno-strict-aliasing on the command line.  I fear a little though that 
the functions which are provably free of cross-type aliasing might 
also not benefit much from -fstrict-aliasing, but I have very little 
experience with C compilers and GCC.  Is this something worth pursuing?



How reliable is this detection and warning?  Is it ready for testers yet?

I ask because we have found a case where code in RTEMS breaks when 
strict-aliasing is enabled.  We are having
discussions on how to effectively perform an audit on RTEMS for other 
breakages.  Right now, the best idea is
Ralf's to diff the assembly generated for each file compiled with and 
without strict-aliasing.  If there is a difference,
we will have to review it.  This eliminates a lot of the code base but 
it is still generating a lot of cases to examine by

hand.

I'm curious if your patch will ease this process.


Thank you,
Silvius


--joel sherrill
  

Re: strict aliasing warning

[Joe Buck]

On Wed, Nov 29, 2006 at 11:02:51AM -0800, Silvius Rus wrote:
> 
> I wrote some code (not released yet) that improves the accuracy of 
> -Wstrict-aliasing using tree-ssa-alias information.  The primary idea 
> was to tell the programmer "go fix the types of variables x and y at 
> lines ..." when -fstrict-aliasing breaks their code.

Cool.

> It occurred to me that part of this code could be used as a 
> preconditioner to aggressive optimization that would normally require 
> -fstrict-aliasing, so this more aggressive optimization can then be 
> performed selectively on individual functions even with 
> -fno-strict-aliasing on the command line.  I fear a little though that 
> the functions which are provably free of cross-type aliasing might also 
> not benefit much from -fstrict-aliasing, but I have very little 
> experience with C compilers and GCC.  Is this something worth pursuing?

If you first prove that there is no cross-type aliasing, then turn on
-fstrict-aliasing, it seems to me that your alias sets won't change at
all.  The reason is that if there is a change, it means that you
eliminated an aliasing possibility based on the fact that it's not
allowed because of cross-type aliasing, which you said you proved there
is none of.

There have been concerns expressed in the past that if gcc checks for
strict aliasing violations, users will be upset when it misses some
violations but does optimization that breaks an ill-formed program.
I personally am not that worried about that; I think that it will help
train users if they see warning messages about blatant violations, to
the point where they will be less likely to create subtle, hard-to-detect
violations.

strict aliasing warning

[Silvius Rus]

I wrote some code (not released yet) that improves the accuracy of 
-Wstrict-aliasing using tree-ssa-alias information.  The primary idea 
was to tell the programmer "go fix the types of variables x and y at 
lines ..." when -fstrict-aliasing breaks their code.


It occurred to me that part of this code could be used as a 
preconditioner to aggressive optimization that would normally require 
-fstrict-aliasing, so this more aggressive optimization can then be 
performed selectively on individual functions even with 
-fno-strict-aliasing on the command line.  I fear a little though that 
the functions which are provably free of cross-type aliasing might also 
not benefit much from -fstrict-aliasing, but I have very little 
experience with C compilers and GCC.  Is this something worth pursuing?


Thank you,
Silvius

gcc 4.1.1 built on RHEL 4 (Pentium 4)

[Nadathur . Sundar]

Hi,
   I successfully built gcc 4.1.1 on a Red Hat Enterprise Linux 4
(kernel version 2.6.9-5.EL), and then successfully compiled the Linux
kernel 2.6.18 using that.

Config.guess: i686-pc-linux-gnu

Version (gcc -version):
   Using built-in specs.
   Target: i686-pc-linux-gnu
   Configured with: ../gcc-4.1.1/configure --prefix=/opt/gcc4
--enable-languages=c
   Thread model: posix
   gcc version 4.1.1

Languages: C alone 

Linux distribution (from /etc/issue):
   Red Hat Enterprise Linux WS release 4 (Nahant)

Kernel version on which gcc was compiled: 2.6.9-5.EL

Version of glibc (from 'rpm -q glibc'): glibc-2.3.4-2

Version of ld: 2.15.92.0.2 

Version of old gcc used for compiling the new gcc: 3.4.3

 
I also built the Linux kernel 2.6.18.1 using this version of gcc.

Thanks for your contributions.


Cheers,
N. S. Sundar (408-434-6064 x247; INP, Emulex)
I am always ardently against all awkward, affected and artificial
alliteration.

re: why gengtype not a filter for GTY?

[Zack Weinberg]

> However, there is still a question which puzzles me a lot? Why gengtype is
> not a sort of filter or generator (like yacc is) taking a (list of) files on
> input and producing a file on output?

It used to take a list of files on its command line, but the list
was so long we were running into length limits (and not just on
old crufty systems, either).  It doesn't produce a file on stdout
because it produces a whole bunch of files in one run.

I have a patch which makes it read the set of input files from stdin
or a file named on the command line - see
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00197.html (it is tangled
with another change in that message, unfortunately).  I mean to polish that
up and submit it properly in the near future, but that could mean anything
from two weeks to next development cycle.  Feel free to take it over.

(if you're interested in general improvements to gengtype, mail me
off-list, I have other stuff you might like to pick up on)

zw

Re: strict aliasing benefit examples

[Paolo Bonzini]

I guess I can imagine that macro expansion might result in some
cases where strict-aliasing is of benefit. Most people fail to use a
temporary in a macro, probably because __typeof__ is gcc-only.
I can probably fit 20 lines of code on a readable slide. Ideas?


In C++, this:

f (vector  &vec)
{
  vector ::iterator it;
  for (it = vec.begin (); it != vec.end (); it++)
...
}

will expand exactly to

f (vector  *vec)
{
  float *it;
  for (it = vec->data; it != vec->data + vec->size; it++)
...
}

There are no macros involved.  You just need to find whether vec->size 
is invariant.  GCC is nowhere near performing whole program 
optimization, so it has to punt quite often (plus there is the issue 
with "char" aliasing everything, which however can be worked around by 
field-sensitive alias analysis), but you have to start from something.



BTW, there are more normal programming habits that defeat
type-based alias analysis. People pick data types by habit.
Mostly, people will use the same type for nearly everything.


That's a problem with C, not with GCC.  Plus, in the nastiest 
template-metaprogramming-heavy math code this is not necessarily an 
obstacle.  Everything is inlined in the main loop, so there is no need 
for whole program optimization.  You use int or long for counters, float 
or double for data: that's enough for type-based alias analysis to work 
egregiously, coupled with some base/offset alias analysis to 
disambiguate between different data structures used at the same time.


Richard Guenther can provide data for his favorite application (a 
physics simulation) without and with -fstrict-aliasing.  I bet it makes 
a difference (and if not, it's a bug in GCC).


Paolo

Re: strict aliasing benefit examples

[Robert Dewar]

Richard Kenner wrote:

Since humans have to do a bit of alias analysis when maintaining
or writing code, the extra clarity of pulling things into temporary
variables isn't wasted.


Sorry, I don't follow.  Why should we want to do "a bit of alias analysis"
when maintaining or writing code?  It would seem a far better practice to
leave that to the optimizer and use local variables only when necessary
for clarify.


And while we are at it, write code in C, instead of some ill-defined
variant of it!

Re: backporting arm eabi to 4.0

[Rafael Espíndola]

I thought Chris was working on updating LLVM to gcc head.

It will be done, but it is not a priority and I need the ARM bits
sooner. Anyway, he will have 5 or 6 patches less to port :-)


Paul



Best Regards,
Rafael

Re: Finding canonical names of systems

[Michael Eager]

Ulf Magnusson wrote:

On 11/29/06, Michael Eager <[EMAIL PROTECTED]> wrote:

Ulf Magnusson wrote:

> While searching for an answer, I noticed that lots of people seem
> to have had problems with cross-compilation that to me look more
> like problems in the documentation, which I find a bit sad.

Rather than repeatedly complain, the most constructive
contribution would be to contribute to the project.

You can feel sad all you want, but being patronizing is
not going to get much sympathy.



I'm sorry if I came off as patronizing, it's not the way it was meant
to sound. It's just that I've seen a lot of open source software that
has this problem, and I don't like it because I think it hinders the
spread of open source software.


GCC has some of the most extensive documentation of any open source
project.  That said, GCC is very complex.  The documentation, despite
its scope, is often difficult to understand because of the complexity
of the underlying project.


I'd be happy to contribute some documentation on this. I just hope I
have a firm enough grip on the issue. Where should I send drafts for
review? Is there some other resource I should be aware of besides
http://gcc.gnu.org/contribute.html?


Sometimes a new person has a different perspective from that of an
expert in an area.  He may not share the history or context that the
expert has, which may reveal areas where the documentation can be
improved.

Look at the internal documentation and the wiki: http://gcc.gnu.org/wiki.
You can post drafts to the mailing list.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: [PATCH] Canonical types (1/3)

[Mark Mitchell]

Doug Gregor wrote:
> This patch introduces canonical types into GCC, which allow us to
> compare two types very efficiently and results in an overall
> compile-time performance improvement. 

Thanks for working on this.  It's the sort of project I used to have
time to do. :-)

I will review these patches in the next couple of days.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: backporting arm eabi to 4.0

[Paul Brook]

On Wednesday 22 November 2006 16:33, Rafael Espíndola wrote:
> I am working on a ARM backend for LLVM. The problemis that llvm-gcc is
> currently based on gcc 4.0 and I would like to use the new EABI.
>
> I have started to back port the ABI from 4.1 to 4.0. The first attempt
> was to just copy the gcc/config/arm directory and try to fix build
> errors. This proved hard because the new files depend on new
> infrastructure.
>
> What I am trying right now is to build a list of patches that are in
> the 4.1 branch but not in the 4.0. Then I will try to selectively move
> then to 4.0.
>
> Does someone has a better idea or some suggestions on how to do this?

I thought Chris was working on updating LLVM to gcc head.

Paul

Re: Finding canonical names of systems

[Ian Lance Taylor]

"Ulf Magnusson" <[EMAIL PROTECTED]> writes:

> I'd be happy to contribute some documentation on this. I just hope I
> have a firm enough grip on the issue. Where should I send drafts for
> review? Is there some other resource I should be aware of besides
> http://gcc.gnu.org/contribute.html?

Thanks for offering.  Patches should be sent to
[EMAIL PROTECTED]  There is nothing special to be aware of for
documentation patches.  You just need to make sure that they pass
texinfo.

Ian

Re: strict aliasing benefit examples

[Richard Kenner]

> Since humans have to do a bit of alias analysis when maintaining
> or writing code, the extra clarity of pulling things into temporary
> variables isn't wasted.

Sorry, I don't follow.  Why should we want to do "a bit of alias analysis"
when maintaining or writing code?  It would seem a far better practice to
leave that to the optimizer and use local variables only when necessary
for clarify.

> BTW, there are more normal programming habits that defeat
> type-based alias analysis. People pick data types by habit.
> Mostly, people will use the same type for nearly everything.

That depends on the language.  What you describe is certainly the norm
for C.  The exact opposite is the norm for Ada.  And Fortran
programmers tend to think more about datatypes than C progammers too.

Re: Finding canonical names of systems

[Ulf Magnusson]

On 11/29/06, Michael Eager <[EMAIL PROTECTED]> wrote:

Ulf Magnusson wrote:

> While searching for an answer, I noticed that lots of people seem
> to have had problems with cross-compilation that to me look more
> like problems in the documentation, which I find a bit sad.

Rather than repeatedly complain, the most constructive
contribution would be to contribute to the project.

You can feel sad all you want, but being patronizing is
not going to get much sympathy.



I'm sorry if I came off as patronizing, it's not the way it was meant
to sound. It's just that I've seen a lot of open source software that
has this problem, and I don't like it because I think it hinders the
spread of open source software.

I'd be happy to contribute some documentation on this. I just hope I
have a firm enough grip on the issue. Where should I send drafts for
review? Is there some other resource I should be aware of besides
http://gcc.gnu.org/contribute.html?

/Ulf Magnusson

Re: strict aliasing benefit examples

[Albert Cahalan]

On 11/29/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:


>> int f(int *a, float *b)
>> {
>>   *a = 1;
>>   *b = 2.0;
>>   return *a == 2;
>> }
>>
>
> Problem: people don't write code that way. (well I hope not)
> People declare a few local variables, load them with data via
> the pointers, do stuff with the local variables, then save back
> the results via the pointers.
>
> So that won't convince many Visual Studio 2005 fans. :-(

Then, the answer is that GCC's stronger aliasing allows you to use one
line of code instead of three.

Consider that most people can only write at most ~50 SLOC/day (including
debugging and documentation), with a stunning independence from the
programming language and programming style.  If you take it with the
necessary grain of salt, this is quite an argument.


It's an argument to favor K+R style over GNU, Allman, and Whitesmith.
This could be holding back gcc development. :-)

Since humans have to do a bit of alias analysis when maintaining
or writing code, the extra clarity of pulling things into temporary
variables isn't wasted.

I guess I can imagine that macro expansion might result in some
cases where strict-aliasing is of benefit. Most people fail to use a
temporary in a macro, probably because __typeof__ is gcc-only.
I can probably fit 20 lines of code on a readable slide. Ideas?

BTW, there are more normal programming habits that defeat
type-based alias analysis. People pick data types by habit.
Mostly, people will use the same type for nearly everything.

Re: strict aliasing benefit examples

[Richard Kenner]

> > > I think there are 3 aliasing possibilities here:
> > > 1. known to alias
> > > 2. known to not alias
> > > 3. may alias
> >
> > Actually there is only 2, it may alias or not.
> 
> Actually, he's right (and both you and Richard are wrong).
> 
> The standard taxonomy of classifications for two memory accesses is:
> 
> Must-alias
> May-Alias
> Don't alias (or some variant name).
> 
> This is what you will find in literature, not "conflicts" or anything else.

I don't see a "right" or "wrong" here.  There's often a terminlogy issue with
GCC development in that it often is using concepts before there's accepted
standard definitions of things in the literature, so quite often the GCC term
has a similar but slightly different meaning.  "alias" is one of those case.
When you use the precise terms (as you did), there's no ambiguity, but when
used in the more generic form in the original question, there is potential
for confusion, which is why I used "conflicts", an even more generic term.

I also wouldn't want to argue for having either two or three states because
that's also a terminology issue: one could easily argue that once you find
that two references are the same, you consider them the same, so that the
"must" state excludes that case.  And many optimization "consumers" of the
information might not care between the remaining "must" case and the "might"
case.

But I think this discussion obscures the point some of use were trying to
make, which I think is something we all agree on.  Let me try to make it
again, going to even more generic terms to avoid getting trapped in
terminology issues:

Given two references, each to a byte, there are exactly three cases:

(1) We know the references are always to the same byte.
(2) We know that the references CANNOT be to the same byte.
(3) We can't prove either (1) or (2).

All non-obvious pairs of references start in state (3).  A major goal of the
compiler is moving as many pairs as possible into states (1) or (2).  Tools
to do this include type-based aliasing information and base+offset tracking.
Neither is completely effective and using the combination of the two is
better than either individually.

> There have been studies on what type of analysis is helpful.
> 
> See, e.g. http://portal.acm.org/citation.cfm?id=378806&coll=portal&dl=ACM

Although I find this a reasonably good methodology for evaluating the various
disambiguation methods, it suffers from the academic bias of assuming that
SPEC is good model of real-world application, though it's indeed probably the
best that can be done in such a setting.  The limitation for just C code is
much more significant an issue, especially since that's no longer the
predominant language nor is the style of those codes the predominant style.

Moreover, as far as the type-based aliasing is concerned, there isn't a large
discussion of that mechanism in terms of number of queries and the results
that are given as very sensitive to available optimization opportunities and
methods: that was work done in 2000 and the growth of additional optimization
techniques will affect the results, but it's unclear in what way.

DW_AT_start_scope

[Rob Quill]

Hi,

I am considering trying to add DW_AT_start_scope attributes to the
debug info emmited by GCC, so it can be used by GDB. I just wanted to
know what people think about this, and how difficult it is likely to
be?

Thanks for your time.

Rob

Re: disabling GCC flags at configure time

[Richard Sandiford]

Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
>> I am thinking of extending the *.opt machinery (ie the
>> gcc/opt-functions.awk gcc/optc-gen.awk gcc/opth-gen.awk files) to
>> offer some GCC options which can be disabled or enabled by an
>> appropriate configure flag.
>> 
>> More precisely, configure can generate HAVE_* and ENABLE_* flags
>> (usually in the gneerated $GCCBUILD/gcc/auto-host.h). My intent is to
>> hack so that the code corresponding to some flags (eg those marked
>> with CppCondition(HAVE_FOO) in common.opt) is conditionally generated
>> with #if defined(HAVE_FOO) && HAVE_FOO!=0 in files
>> $GCCBUILD/gcc/options.c and $GCCBUILD/gcc/options.h
>
> I am a bit ashamed to not have re-read the documentation.  Perhaps the
> Condition() option syntax might be perhaps used. From
> $GCCTOP/gcc/doc/options.texi (file rev119164 from trunk)
>
>   @item Condition(@var{cond})
>   The option should only be accepted if preprocessor condition
>   @var{cond} is true.  Note that any C declarations associated with the
>   option will be present even if @var{cond} is false; @var{cond} simply
>   controls whether the option is accepted and whether it is printed in
>   the @option{--help} output.

Right.

> However, I grepped the source and did not found any use of this in any
> gcc/*.opt file. Does anyone have an idea why this Condition is still
> there?

You need to check the target files too (in gcc/config and subdirectories).
Condition() was added for the SH port.

> And my initial proposal (which I called CppCondition) is slightly
> different (and more general, perhaps safer) If the preprocessor
> condition is false, the C variable for the flag should be not even
> generated. (hence any reference to it will fail at Gcc build time).

We generally want to move away from having preprcoessor conditions
guard code.

Richard

Re: insn field INSN_CODE

[Richard Kenner]

> In the "GCC Internals manual" it is said that the INSN_CODE(i) is printed in
> the debugging output as a small integer followed by a symbolic
> representation that locates the pattern in the md file as a small positive
> or negative offset from the named pattern. Now, I'm a bit confused. The
> following example (a part of an annotated assembler file) says that the
> pattern is muldf3, but what stands the offset 77 for?
> 
> ;#(insn 16 543 689 ../../gcc-4.1.0/gcc/libgcc2.c:1624 (set (reg:DF 25 L9 )
> ;#(mult:DF (reg:DF 25 L9 )
> ;#(reg/v:DF 20 L4  [orig:67 c ] [67]))) 77 {muldf3}
> (insn_list:REG_DEP_TRUE 543 (nil))
> ;#(nil))

That's the integer value for the INSN_CODE.  If it were, say, 78 and that
pattern had no name, it would be displayed as "78 {muldf3+1}".

insn field INSN_CODE

[Andrija Radicevic]

Hi,

In the "GCC Internals manual" it is said that the INSN_CODE(i) is printed in
the debugging output as a small integer followed by a symbolic
representation that locates the pattern in the md file as a small positive
or negative offset from the named pattern. Now, I'm a bit confused. The
following example (a part of an annotated assembler file) says that the
pattern is muldf3, but what stands the offset 77 for?

;#(insn 16 543 689 ../../gcc-4.1.0/gcc/libgcc2.c:1624 (set (reg:DF 25 L9 )
;#(mult:DF (reg:DF 25 L9 )
;#(reg/v:DF 20 L4  [orig:67 c ] [67]))) 77 {muldf3}
(insn_list:REG_DEP_TRUE 543 (nil))
;#(nil))


Best regards

Andrija Radicevic

voli low cost

[fede]

per i voli low cost è il top


www.fluupe.com


se non è chiaro il perche guarda nelle search tips.

ciao

fede

voli low cost

[fede]

per i voli low cost è il top


www.fluupe.com


se non è chiaro il perche guarda nelle search tips.

ciao

fede

fluupe

[fede]

ciao,

guarda questo sito 

www.fluupe.com


per i voli low cost  è fighissimo


fede

Re: Aliasing: reliable code or not?

[Jakub Jelinek]

On Tue, Nov 28, 2006 at 11:36:19PM -0800, Ian Lance Taylor wrote:
> Or you can use constructor expressions to make this slightly more
> elegant, though I retain the assumptions about type sizes:
> 
> char *foo1(char* buf){
>   memcpy(buf, (char[]) { 42 }, 1);
>   buf += 1;
>   memcpy(buf, (short[]) { 0xfeed }, 2);
>   buf += 2;
>   memcpy(buf, (int[]) { 0x12345678 }, 4);
>   buf += 4;
>   memcpy(buf, (int[]) { 0x12345678 }, 4);
>   buf += 4;
>   return buf;
> }

Or even use mempcpy to make it even more compact:

char *
foo1 (char *buf)
{
  buf = mempcpy (buf, (char[]) { 42 }, 1);
  buf = mempcpy (buf, (short[]) { 0xfeed }, 2);
  buf = mempcpy (buf, (int[]) { 0x12345678 }, 4);
  buf = mempcpy (buf, (int[]) { 0x12345678 }, 4);
  return buf;
}

Jakub

Re: Build problem on hpxw 4300 running fc6 x86_64

[Vincent Lefevre]

Hi,

On 2006-11-28 10:39:20 -0800, George R Goffe wrote:
> I'm trying to build the latest svn version of gcc on my hp xw 4300
> system running fedora core 6 and am seeing a problem with mpfr. I
> got the latest mpfr and applied their patch before attempting this
> build. I have a complete build log available if anyone wants to see
> it.

These "undefined reference to `mpfr_xxx'" errors mean that the MPFR
library can't be found. Perhaps you forgot to add the corresponding
directory to LD_LIBRARY_PATH (and/or LIBRARY_PATH). BTW, the INSTALL
file of MPFR 2.2.1 (which has just been released) contains more
information about that.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Announce: MPFR 2.2.1 is released

[Vincent Lefevre]

MPFR 2.2.1 is now available for download from the MPFR web site:

  http://www.mpfr.org/mpfr-2.2.1/

Thanks very much to those who tested the release candidates.

The MD5's:
40bf06f8081461d8db7d6f4ad5b9f6bd  mpfr-2.2.1.tar.bz2
662bc38c75c9857ebbbc34e3280053cd  mpfr-2.2.1.tar.gz
93a2bf9dc66f81caa57c7649a6da8e46  mpfr-2.2.1.zip

Changes from version 2.2.0 to version 2.2.1:
- Many bug fixes: .
- Updated mpfr-longlong.h from the GMP 4.2 longlong.h file.
- Moved some internal declarations from mpfr.h to mpfr-impl.h.
- Use -search_paths_first on Darwin (Mac OS X) to fix linking behavior.
- Improved "make check": much more complete generic tests.
- Improved INSTALL file and MPFR manual.

Regards,

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Finding canonical names of systems

[Michael Eager]

Ulf Magnusson wrote:


While searching for an answer, I noticed that lots of people seem
to have had problems with cross-compilation that to me look more
like problems in the documentation, which I find a bit sad.


Rather than repeatedly complain, the most constructive
contribution would be to contribute to the project.

You can feel sad all you want, but being patronizing is
not going to get much sympathy.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: strict aliasing benefit examples

[Robert Dewar]

Paolo Bonzini wrote:

for(i = 0;i<*t;i++)
  *f += 1.0;


This one is pretty realistic, especially if you consider C++ and inlining:


Don't you think that a convincing argument here has to be based
on actual timings with and without strict aliasing. It would
be interesting to see cases where that simple-to-understand
argument can be made!

Re: error in 02g.gch

[Bobby McNulty]

Bobby McNulty wrote:

I received the following error in libstdc++-   v3
i686-pc-cygwin and trunk.



   /home/Owner/gcc/o/./gcc/xgcc -shared-libgcc 
-B/home/Owner/gcc/o/./gcc -n
ostdinc++ -L/home/Owner/gcc/o/i686-pc-cygwin/libstdc++-v3/src 
-L/home/Owner/gcc/
o/i686-pc-cygwin/libstdc++-v3/src/.libs 
-B/usr/local/i686-pc-cygwin/bin/ -B/usr/
local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include 
-isystem /u
sr/local/i686-pc-cygwin/sys-include -Winvalid-pch -Wno-deprecated -x 
c++-header
-g -O2  
-I/home/Owner/gcc/o/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin -
I/home/Owner/gcc/o/i686-pc-cygwin/libstdc++-v3/include 
-I/home/Owner/gcc/gcc/lib
stdc++-v3/libsupc++ -O2 -g 
/home/Owner/gcc/gcc/libstdc++-v3/include/precompiled/

stdc++.h -o i686-pc-cygwin/bits/stdc++.h.gch/O2g.gch
In file included from 
/home/Owner/gcc/gcc/libstdc++-v3/include/precompiled/stdc+

+.h:81:
/home/Owner/gcc/o/i686-pc-cygwin/libstdc++-v3/include/valarray: In 
function 'voi

d __static_initialization_and_destruction_0(int, int)':
/home/Owner/gcc/o/i686-pc-cygwin/libstdc++-v3/include/valarray:1024: 
internal co

mpiler error: in loop_optimizer_init, at loop-init.c:54
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [i686-pc-cygwin/bits/stdc++.h.gch/O2g.gch] Error 1
make[4]: Leaving directory 
`/home/Owner/gcc/o/i686-pc-cygwin/libstdc++-v3/includ

e'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory 
`/home/Owner/gcc/o/i686-pc-cygwin/libstdc++-v3'

make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/home/Owner/gcc/o/i686-pc-cygwin/libstdc++-v3'

make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/home/Owner/gcc/o'
make: *** [all] Error 2

[EMAIL PROTECTED] ~/gcc/o
$



False alarm. I ran make clean and it is working now.

Re: Finding canonical names of systems

[Ulf Magnusson]

On 11/29/06, Michael Eager <[EMAIL PROTECTED]> wrote:

Ulf Magnusson wrote:
> How are you supposed to find the canonical name of a system (of known
> type) in CPU-Vendor-OS form in the general case? If you have access to
> a system of that particular type, you can run config.guess to find
> out, but you might not have, and that approach won't work for many
> systems anyway. The canonical name needs to be known e.g. when
> cross-compiling and building cross-compilers.
>
> The only way I could find to get a list of canonical CPU, Vendor and
> OS strings was to dig through /usr/share/gnuconfig/config.sub on my
> GNU/Linux systems, which needless to say is about as bad as it gets
> from a documentation perspective. Is there any other way to get a list
> mapping CPU's, Vendors and OS's to their canonical strings? If there
> isn't, I think it's making things much more complicated than they
> should be.

Strictly speaking, there isn't anything that is a canonical name
for a particular configuration, if you mean a single correct name.
GCC uses the vendor name to simplify figuring out the desired target
architecture.

For most cross-compilations, the vendor name is ignored.  There may
be a multitude of vendors, for example.  (How many MIPS vendors can
you name?)



It would be helpful if the documentation said this. I believe I'm not the only
one who immediately went hunting in the docs for some kind of list with
different CPU's, vendors and OS's, or at least some guide on how to find
a string for your configuration.


Take a look at configure and config.gcc.   Find the architecture you
are interested in.  Look at the names defined for the architecture and
pick the best one.

For example, in configure you will find
   powerpc-*-eabi)
 noconfigdirs="$noconfigdirs ${libgcj}"
 ;;

This says that powerpc--eabi is a valid configuration.

This is further refined in config.gcc, where you will find
that powerpc-*-eabi is a bit different from powerpc-*-eabisim.



This should also be in the doc, if it is the way you have to do it.
Right now, I believe it pretty much glosses over the issue of how
to find a suitable string for the configuration you want to
represent.


If you are looking for a comprehensive list of all possible
configurations, rather than just trying to find the correct
one for your particular application, you will find that there
are an infinite number of configurations.



I understand this now, but the docs could be more helpful
in explaining how to find the string to use for your configuration.

While searching for an answer, I noticed that lots of people seem
to have had problems with cross-compilation that to me look more
like problems in the documentation, which I find a bit sad.

/Ulf Magnusson