headers
DJ Delorie | 1 Aug 2008 01:50
Picon
Favicon

Re: Inconsistent use of allocator wrapper macros in libiberty


> Is there some reason for the inconsistency,

Not really.  Patches welcome.
Permalink | Reply | 0 comments |
headers
Grigori Fursin | 1 Aug 2008 01:50
Picon
Picon
Favicon

RE: Help with identifing all cost models in GCC to make it adaptable ?..

Thanks, David!

That's a good start. I will need to find places in GCC where these
parameters are used to monitor the behavior of transformations 
based on these parameters and be able to change the compiler decisions 
through ICI to learn how to tune those costs based on program execution 
time/code size...

Also, I would prefer to concentrate on only most critical/important 
costs right now (for example, within register allocation, scheduling, etc) 
since this research is very time consuming ...

Cheers,
Grigori

========================================
Grigori Fursin, PhD
Research Scientist, INRIA, France
http://fursin.net/research
  

> -----Original Message-----
> From: David Edelsohn [mailto:dje <at> watson.ibm.com]
> Sent: Thursday, July 31, 2008 9:44 PM
> To: Grigori Fursin
> Cc: 'gcc'
> Subject: Re: Help with identifing all cost models in GCC to make it adaptable ?..
> 
> Grigori,
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Denys Vlasenko | 1 Aug 2008 01:52

Re: gcc will become the best optimizing x86 compiler

On Thursday 31 July 2008 11:36, Dave Korn wrote:
> Agner Fog wrote on 31 July 2008 07:14:
> 
> > Denys Vlasenko wrote:
> >> I tend to doubt that odd-byte aligned large memcpys are anywhere
> >> near typical. malloc and mmap both return well-aligned buffers
> >> (say, 8 byte aligned). Static and on-stack objects are also
> >> at least word-aligned 99% of the time.
> >> 
> >> memcpy can just use "relatively simple" code for copies in which
> >> either src or dst is not word aligned. This cuts possibilities down from
> >> 16 to 4 (or even 2?). 
> >> 
> > The XMM code is still more than 3 times faster than rep movsl when data
> > are aligned by 4 or 8, but not by 16.
> > Even if odd addresses are rare, they must be supported, but we can put
> > the most common cases first.
> 
>   In the real world, unaligned memcpys are anything but rare.  Everything's
> networked these days, remember?  Stuff gets misaligned real quick when you
> start adding and removing various network layer headers and trailers to
> unpredictably-sized packets.

Headers are usually at least rounded to 16-bit multiple.
Trailers do not matter to alignment.

This happens in kernel space. In kernel space, there are many differences.
* memcpy are rarely bigger than a page - this negates any gains from
  non-temporal MOVs
* memcpy cannot use XMM registers (otherwise lazy FPU saving doesn't work)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bo Yang | 1 Aug 2008 05:24
Picon

Re: gcc emit wrong symbols in multiple inheritance case

On Thu, Jul 31, 2008 at 11:00 PM, Brian Dessent <brian <at> dessent.net> wrote:
> Bo Yang wrote:
>
>> When we produce an exe from a single c++ file, there is no linking
>> need, so there is no problem. But when we separate the definition and
>
> That's not how it works, the linker is always required to produce an
> executable.

I am wrong. But how the linker find the __attribute__((__stdcall__))
bottom::fun1() when there is a single source file? There is no such
definition in the object file.

>> And Obviously, this is not a linker error, it is the problem gcc
>> generate a " U __ZThn4_N6bottom4fun1Ev <at> 4" for indeed existing
>> definition of "__attribute__((__stdcall__)) bottom:fun1()" .
>
> The "U" lines are correct and aren't the problem; those are call sites
> to the properly mangled symbol name.  What's incorrect is that gcc emits
> the function definitions (the 'T' lines) without the proper stdcall name
> mangling.  If gcc used the proper mangling for the definitions then the
> undefined call sites would no longer be undefined and would not show up
> in the objdump output any more.

So, are you sure this bug is identical to PR27067 or not?

Regards!
Bo
(Continue reading)

Permalink | Reply | 0 comments |
headers
梁 | 1 Aug 2008 05:32
Picon

Is there some mistakes in comments of passes.c?

The comments in passes.c at the beginning are identical to toplev.c.

--
Permalink | Reply | 0 comments |
headers
Arnaud Charlet | 1 Aug 2008 09:07
Favicon

Re: GNAT build failure on cross

> Any suggestions?

I would double check that you are indeed using the freshly built
corresponding native. Maybe your native installation didn't work as
expected and your building from an older compiler. That's the
most likely explanation.

Alternatively, there have been changes recently in the libada and ada
Makefiles by Paolo Bonzini that might be related.

Arno
Permalink | Reply | 2 comments |
headers
Alexandre Oliva | 1 Aug 2008 09:34
Picon
Favicon

[vta] created 4.3 branch, merged 4.3 and trunk <at> 138264

I forked the vta branch into a var-tracking-assignments-4_3-branch,
created and merged from gcc-4_3-branch on Wednesday, and I've just
finished merging the trunk onto the var-tracking-assignments-branch.
Both merges were mostly trivial, although the trunk merge required the
tuplification of debug stmts.

I didn't expect difficulties here, but it turned out to be much easier
than I'd anticipated.  I added GIMPLE_DEBUG, with VAR_DEBUG_VALUE as a
subcode, and then, after a few tweaks here and there, it all built.  I
haven't assessed the quality of debug information yet (err, guality),
though.

No patches, but the diffs between the baselines and the post-merge
state can be obtained with commands such as:

# svn diff svn://gcc.gnu.org/svn/gcc/tags/var-tracking-assignments-4_3-merge-138264-{4_3,after}

# svn diff svn://gcc.gnu.org/svn/gcc/tags/var-tracking-assignments-merge-138264-{trunk,after}

The 4.3 branch won't bootstrap without a couple of patches I'm post
and install momentarily; the trunk builds at least all the way to the
end of stage2.  That's all the testing I've done.

The previous state of the branch can be obtained with

svn checkout svn://gcc.gnu.org/svn/gcc/tags/var-tracking-assignments-merge-138264-before

--

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist  oliva <at> {lsd.ic.unicamp.br, gnu.org}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paolo Bonzini | 1 Aug 2008 10:22
Picon
Gravatar

Re: GNAT build failure on cross

Arnaud Charlet wrote:
>> Any suggestions?
> 
> I would double check that you are indeed using the freshly built
> corresponding native. Maybe your native installation didn't work as
> expected and your building from an older compiler. That's the
> most likely explanation.
> 
> Alternatively, there have been changes recently in the libada and ada
> Makefiles by Paolo Bonzini that might be related.

I agree with Arnaud that the most likely explanation is 
not-recent-enough native tools.  But you can try reverting to r138299 to 
see if my patches are at fault.

Paolo
Permalink | Reply | 1 comment |
headers
Jay | 1 Aug 2008 10:26
Picon
Favicon

insn-attrtab.c long time to compile..


4.2.3 insn-attrtab.c takes "a long time" to 
compile on djgpp (build=host=target=i586-pc-msdosdjgpp, bootstrapping
from 4.2.3) with the default -g -O2.

I let it go, walked away for a few days, laptop
power was pulled in the meantime (moved to another laptop),
so it ran till the battery ran out. Presumably at least 30 minutes.

Perhaps this can at least be split up into 
  insn-attrtab-1.c
  insn-attrtab-2.c 
  insn-attrtab-3.c  
  insn-attrtab-4.c 

with a quarter of the functions in each file?

  It seems either switch takes a long time.  
  Omitting both compiles in just a few seconds.  

  I'll see about collecting accurate times for all four combinations,  
  testing with 4.3.1, see if breaking it up into multiple files helps, etc.  
  (could be just one particular function causes it, even if isolated in one source file).  

#pragma optimize would probably good and easy, but looks like that's not available in these versions.

 Thanks, 
  - Jay
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rainer Orth | 1 Aug 2008 14:36
Picon
Picon

Mainline Ada bootstrap broken

Eric,

this patch of yours

2008-08-01  Eric Botcazou  <ebotcazou <at> adacore.com>

        * gcc-interface/utils.c (convert_vms_descriptor): Add gnu_expr_alt_type
        parameter.
        Convert the expression to it instead of changing its type in place.
        (build_function_stub): Adjust call to above function.

broke mainline Ada bootstrap everywhere.  It uses DECL_PARM_ALT_TYPE, which
is not defined anywhere, so e.g. gnat1 fails to link:

Undefined                       first referenced
 symbol                             in file
DECL_PARM_ALT_TYPE                  ada/utils.o
ld: fatal: Symbol referencing errors. No output written to gnat1
collect2: ld returned 1 exit status
make[3]: *** [gnat1] Error 1

Please fix.

	Rainer

-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University
Permalink | Reply | 4 comments |

Gmane