headers
gccadmin | 1 Jul 2004 01:09
Picon
Favicon

gcc-ss-3.3-20040630 is now available

gcc-ss-3.3-20040630 is now available on 
  ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20040630/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20040630 

You'll find:

  gcc-3.3-20040630.tar.bz2              The full GCC snapshot, including all
                                        languages and runtime libraries.

  gcc-core-3.3-20040630.tar.bz2         Just the C front end and core compiler.

  gcc-testsuite-3.3-20040630.tar.bz2    The GCC testsuite.

  gcc-ada-3.3-20040630.tar.bz2          The Ada language and runtime.

  gcc-g++-3.3-20040630.tar.bz2          The C++ front end and runtime.

  gcc-g77-3.3-20040630.tar.bz2          The F77 front end and runtime.

  gcc-fortran-3.3-20040630.tar.gz       The Fortran front end and runtime.

  gcc-objc-3.3-20040630.tar.bz2         The Objective-C front end and runtime.

  gcc-java-3.3-20040630.tar.bz2         The Java front end and runtime.

Diffs from 3.3-20040623 are available in the diffs/ subdirectory.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joe Buck | 1 Jul 2004 01:15

Re: bootstrap of 3.4.1 RC1 failed on powerpc-ibm-aix4.3.3.0

On Wed, Jun 30, 2004 at 10:42:04PM +0200, Jakub Jelinek wrote:
> On Wed, Jun 30, 2004 at 03:32:46PM -0700, Joe Buck wrote:
> > > I'm not going to consider that a showstopper, since it didn't work in 
> > > 3.4.0 and since David's comments indicate that this might not be 
> > > tractable to fix without modifications to binutils.
> > 
> > Another possible fix would be to re-order the assembly language output
> > so that the thunks don't need forward references.  A third possibility
> > would be to use gas, if it can be made to work.
> > 
> > In any case, this is now PR 16304.
> 
> Or you can override TARGET_USE_LOCAL_THUNK_ALIAS_P definition for
> AIX with the assembler which doesn't handle forward references.

Could you explain in more detail?
Permalink | Reply | 0 comments |
headers
Janis Johnson | 1 Jul 2004 01:16
Picon
Favicon

Re: altivec questions

On Wed, Jun 30, 2004 at 03:45:59PM -0700, Ziemowit Laski wrote:
> 
> On 29 Jun 2004, at 13.58, Janis Johnson wrote:
> 
> >Some AltiVec observations and questions:
> >
> >1. vector bool
> >
> >   The documentation says "The bool type is deprecated and will be
> >   discontinued in future revisions.  Use vector signed instead."
> 
> That's a bug in the documentation.  'vector bool ...' types are 
> first-class
> citizens which _must_ be kept distinct from 'vector signed ...' or
> 'vector unsigned ...'.

That's how it was originally documented, but now they are first-class
citizens and ought to be documented as such.

> >   Recently, though, Zem added lots of support for vector bool and
> >   except for some apparent oversights it appears to be fully supported
> >   now, along with vector pixel.
> 
> Indeed.  What are the oversights? :-)  I wouldn't mind fixing them, 
> unless
> you have done so in the work you mention below.

Yeah, I've done the work; it's coming as soon as I figure out how to
break up the one massive patch into smaller ones, and finish testing.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Wilson | 1 Jul 2004 02:28

Re: crosstool-0.28-rc26: 118 ugly toolchains and 74 pretty ones

Dan Kegel wrote:
 >                 A       B       C       D       E       F       G 
    > H
> ia64            FAIL    FAIL    FAIL    FAIL    pass    FAIL    FAIL    
> pass

The IA-64 port was started after the gcc-2.95 release, so there is no 
hope of getting A or B to work.

I doubt that there is IA-64 support in gclib-2.1.x, which means A, C, 
and F can't work.  I don't have a copy to verify.

I doubt that there is IA-64 support in binutils-2.11, which means B 
can't work.  I don't have a copy to verify.

I don't recall the linux history, but 2.4.3 is probably way too early 
for IA-64 support, which is another reason why B can't work.

The IA-64 port wasn't finished until sometime during the gcc-3.0.x 
release process.  There was a major change to the startup files that was 
needed near the end.   This change required a corresponding glibc 
change.  The result is that gcc-3.x works only with glibc-2.3.x, and 
gcc-2.96 works only with glibc-2.2.x.  Thus D and G can't work.

That leaves only E and H, both of which passed, so there are no IA-64 
problems that need to be fixed.

Some of the other targets probably have similar issues.  i686 works for 
all combinations because it is one of the oldest and most stable 
targets.  The other targets likely all have limitations that prevent
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Wilson | 1 Jul 2004 02:37

Re: ASM_OUTPUT_WEAK_ALIAS documentation

Aaron W. LaFramboise wrote:
> I don't understand what ASM_OUTPUT_DEF has to do with anything.  Does it
> mean ASM_WEAKEN_DECL instead?

A weak alias is something that is both weak and an alias. 
ASM_OUTPUT_DEF is used for aliases.  ASM_WEAKEN_LABEL is used for weak. 
  If you have both of these, then there is no need to define 
ASM_OTPUT_WEAK_ALIAS.

However, some targets have a special directive that needs to be used in 
this case, e.g. the ECOFF .weakext directive.  These targets have to 
define ASM_OUTPUT_WEAK_ALIAS.
--

-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Permalink | Reply | 0 comments |
headers
Jim Wilson | 1 Jul 2004 02:56

Re: Solaris installation notes

Dimitri Papadopoulos-Orfanos wrote:
>     [...] proceed as described in the build instructions,
>     where we strongly recommend using GNU make and specifying
>     an absolute path to invoke srcdir/configure.

The Solaris instructions are giving additional recommendations over the 
default instructions.  The additions are use of GNU make and using an 
absolute path to srcdir/configure.  The GNU make recommendation is 
obsolete, as gcc now requireds GNU make for all targets.  I don't know 
of any reason why an absolute path to srcdir/configure is required.  I 
use relative paths all of the time.  Perhaps there is something about 
Solaris that requires an absolute path, in which case it makes sense to 
put this in the Solaris section.
--

-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Permalink | Reply | 17 comments |
headers
Jim Wilson | 1 Jul 2004 03:28

Re: Status of for Argonaut ARC port?

Steven Bosscher wrote:
> There is no listed maintainer currently, but apparently Rich D'Addio
> offered to take that job (though I couldn't actually find a mail
> saying so)

Rich D'Addio didn't have FSF paperwork on file when he volunteered.  It 
took some time to get the paperwork and GCC SC approval, and when this 
stuff was all done he didn't respond to mail telling him he could start 
maintaining the port.  Maybe he lost interest in ARC in the meantime?

I think it would be reasonable to deprecate this in the next release.  I 
don't think we should go straight to removal.  We should always have one 
release with the target deprecated before we delete it.

To deprecate a target, search for enable_obsolete in gcc/config.gcc, and 
add the target tuple there.
--

-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Permalink | Reply | 7 comments |
headers
Jim Wilson | 1 Jul 2004 03:57

Re: Help in Load Store Instrumentation

Rajkishore Barik wrote:
> I am a newbie to GCC development community. Can
> someone help me in instrumenting loads/stores in GCC?

There are many places that loads/stores can be emitted, so this may not 
be very easy.  emit_move_insn is a good place to start though.  Also, a 
typical program has many loads/stores, so trying to instrument them is 
likely to add a lot of overheard.

You might try looking at some solutions implemented by other people. 
Current sources have mudflap which does some load/store instrumentation 
to detect programming errors.

There were the gcc patches for Checker.  I don't know if there is a 
current maintained version of these patches, but if you grab a copy of 
gcc-2.8.1 from the old-releases directory on our web site, and grep for 
flag_check_memory_usage you can see what these patches did.

 > want to get the runtime values back into the GCC
 > component in the next run. Any help will be highly

Maybe you want to look at the value profiling support in the current gcc 
sources then.  See the gcc/value-prof.c file.  See the options 
-fprofile-values and -fpvt (profile value transformations).  See also 
-fprofile-generate and -fprofile-use which turn these options on.
--

-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Permalink | Reply | 0 comments |
headers
Mark Mitchell | 1 Jul 2004 04:06

Re: named warnings & individual warning control

> If we keep track of the input_location info with the warning control
> state, we can get around this problem.  Then we'd also not need the
> API for obtaining the warning state and keeping track of it.

That's a good idea.

> Summary:

I think this is a good plan, and not controversial.

Thanks for working it out.

--

-- 
Mark Mitchell
CodeSourcery, LLC
mark <at> codesourcery.com
Permalink | Reply | 0 comments |
headers
Mark Mitchell | 1 Jul 2004 04:14

Re: GCC 3.4.1 RC1 available

H. J. Lu wrote:

> I opened a C++ bug:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276
> 
> In some cases, gcc puts a local definition in a linkonce section. I
> don't think it is correct. It should be either local or linkonce,
> not both.

Given that the compiler has done this for ages, I don't see this as a 
showstopper.

Thanks,

--

-- 
Mark Mitchell
CodeSourcery, LLC
mark <at> codesourcery.com
Permalink | Reply | 0 comments |

Gmane