Any docs about gcov impl change from 3.3 to 3.4

[Fei, Fei]

Hi, 

I am working on investigating some low level coverage tool, including
gcov. As I find out, the difference of implementation of gcc in gcov
part btw 3.3 and 3.4 is relevant. Can anyone direct me to some document
regarding this change?

Thanks,
Fei

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-06-06 19:23:06 -0400, Robert Dewar wrote:
> Laurent GUERBY wrote:
> 
> >Such algorithm usually require a very detailed control of what's
> >going on at the machine level, given current high level programming
> >languages that means using assembler.
> 
> No, that's not true, you might want to look at some of Jim Demmel's
> work in this area.

Do you have a reference (URL...)?

> >Or that many programs that currently work on many OS
> >will start to work the same under Linux instead of
> >giving strange (and may be wrong) results.
> 
> But many programs that work fine on the x86 now will start breaking.
  ^^^

Linux/x86 only! And probably not many programs, and only programs
specific to x86. Their authors could still change the rounding
precision at the beginning of their programs if need be.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Any docs about gcov impl change from 3.3 to 3.4

[Nathan Sidwell]

Fei, Fei wrote:
Hi, 


I am working on investigating some low level coverage tool, including
gcov. As I find out, the difference of implementation of gcc in gcov
part btw 3.3 and 3.4 is relevant. Can anyone direct me to some document
regarding this change?


I'm not sure what you mean.  The new implementation is documented in gcov.texi 
and the relevant header files.  The old documentation was, er, vague.  The

ChangeLog will describe the changes and the mail archives will contain the 
patches.

nathan

--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Digitize your Records

[[EMAIL PROTECTED]]

Greetings !

 

Are you facing problems in storing growing volume of documents

in the form of – microfilms, microfiche, paper, audio etc ?

 

If so, we have various solutions to digitize them as per your needs.

 

Please feel free to drop us a line for your requirements. 

 

Regards,

Navneet Singhania

[EMAIL PROTECTED]

RE: Any docs about gcov impl change from 3.3 to 3.4

[Fei, Fei]

What I am doing is to apply coverage test for xen project
(http://www.cl.cam.ac.uk/Research/SRG/netos/xen/), exp for hyperviser.
It's like the GCOV/LCOV thing which IBM did for Linux kernel but should
be different in hypervisor case. I will base on GCC 3.4 or above. So I
need to know some low level knowledge gcov.

I have read the OLS document which IBM present on Linux Symposium. But
it seems it only cover GCC 3.3.

Also I want to have some document about format of foo.gcda and for.gcno
files. 

Fei

>-Original Message-
>From: Nathan Sidwell [mailto:[EMAIL PROTECTED]
>Sent: Thursday, June 09, 2005 4:24 PM
>To: Fei, Fei
>Cc: gcc@gcc.gnu.org
>Subject: Re: Any docs about gcov impl change from 3.3 to 3.4
>
>Fei, Fei wrote:
>> Hi,
>>
>> I am working on investigating some low level coverage tool, including
>> gcov. As I find out, the difference of implementation of gcc in gcov
>> part btw 3.3 and 3.4 is relevant. Can anyone direct me to some
document
>> regarding this change?
>
>I'm not sure what you mean.  The new implementation is documented in
>gcov.texi
>and the relevant header files.  The old documentation was, er, vague.
The
>ChangeLog will describe the changes and the mail archives will contain
the
>patches.
>
>nathan
>
>--
>Nathan Sidwell::   http://www.codesourcery.com   ::
CodeSourcery
>LLC
>[EMAIL PROTECTED]::
>http://www.planetfall.pwp.blueyonder.co.uk

Re: Ada front-end depends on signed overflow

[Paul Schlie]

> From: Georg Bauhaus <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>> - How is it necessary or desirable to define that the result is undefined
>>   vs. being target defined?
> 
> What does C say about how a target performs an instruction?
> And why shouldn't GCC take advantage of this?

- In essence I believe the difference is consistency. Where although a
  target implementation defined behavior seems no more clear, it implies
  that the semantics of an operation in question should directly result
  from it's target implementation, and any corresponding compile-time
  constant propagation optimizations should be consistent with their
  otherwise run-time computed counterparts, as otherwise they will be
  needlessly and arguably erroneously inconsistent; which an undefined
  behavior would seem to allow, without providing any tangible benefit.

Digitize your Records

[[EMAIL PROTECTED]]

Greetings !

 

Are you facing problems in storing growing volume of documents

in the form of – microfilms, microfiche, paper, audio etc ?

 

If so, we have various solutions to digitize them as per your needs.

 

Please feel free to drop us a line for your requirements. 

 

Regards,

Navneet Singhania

[EMAIL PROTECTED]

Use of check_vect() in vectorizer testsuite

[Giovanni Bajo]

Hello,

I have some questions about the use of check_vect() in the vectorizer
testsuite:

1) All the ifcvt tests (vect-ifcvt*) seem to require SSE2 capability to be
vectorized but they do not call check_vect(). Is this a bug? They surely fail
on my platform (which does not have SSE2).

2) The same applies for a vect_int test, vect-dv-2.c. I assume also vect_int
tests require SSE2 capability and thus should call check_vect()?

Thanks,
Giovanni Bajo

GCC 4.0.1 RC1 successful build

[William Beebe]

GCC 4.0.1 was successfully built on Fedora Core 3 using 3.4.4 as the
starting compiler.

[EMAIL PROTECTED] opt2]$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/opt2/gcc401
--enable-threads=posix --with-system-zlib -enable-shared
--enable-__cxa_atexit --enable-languages=c,c++,f95,objc
Thread model: posix
gcc version 4.0.1 20050608 (prerelease)

Please note that I did not build java nor ada.

GCC was built with 'make bootstrap'.

The machine in question is an older Athlon XP 2500+ Barton with 512MB
and 1.5GB swap. Swap stays around 192MB on my machine, and did not
grow during compilation.

[EMAIL PROTECTED] opt2]$ cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 10
model name  : AMD Athlon(tm) XP 2500+
...
[EMAIL PROTECTED] opt2]$ cat /proc/version
Linux version 2.6.11.11 ([EMAIL PROTECTED]) (gcc version 3.4.3
20050227 (Red Hat 3.4.3-22.fc3)) #1 Sun May 29 13:35:04 EDT 2005

Build time was approximately 30 minutes. Later this evening I will be
rebuild and boot my kernel for testing and the latest announced
ACE/TAO beta, 5.4.6. This will exercise the C and C++ portions of GCC.

INPUT for broken name-lookup in gcc4.0.0

[Wyss Daniel]

Hello,

i am trying to get running gcc 4.0.0 on a Sun-Blade-1000 sparc host with SunOS 
5.8
for installation path (prefix) /apl/gnu/sol58/gcc/4.0.0.
(Note: i cannot install on /usr/local because its a readonly mount point)

I am using the following GNU components that allready work fine for 
/apl/gnu/sol58/...


# GNU BUILD COMPONENTS under /appl/gnu/sol58 USED FOR COMPILATION
# ===
#
#   perl5.6.1
#   gnupg   1.2.4
#   patch   2.5.4
#   m4  1.4.3
#   texinfo 4.2
#   sed 4.1.2
#   pkgconfig   0.15.0
#   autoconf2.59
#   automake1.9.5
#   bc  1.06
#   tar 1.15.1
#   gzip1.2.4a
#   bzip2   1.0.3
#   gettext 0.14.1
#   diffutils   2.8.1
#   flex2.5.4a
#   bison   2.0
#   gawk3.1.3
#   grep2.4.2
#   libiconv1.9.1
#   make3.80
#   binutils2.14
#   gcc boot compilation2.95.3 --> 3.4.2 (discarded after 
creating 3.4.2s)
#   sanity compilation  3.4.2  --> 3.4.2s
#
#   gmp 1.4.1 build the GNU MP 32-bit library as follows:
#   ./configure --with-gnu-ld --enable-mpfr 
--prefix=/apl/gnu/sol58/gmp/4.1.4 ABI=32
#


During Compilation i have seen warnings about nonexisting format parameter "q" 
in name-lookup.c

You can find statements like "error("declaration of %q#D", decl)"
  or "cp_error_at (%qD is not a function,", f1 )"
  or "pedwarn ("redeclaration of % as %qT", 
TREE_TYPE (x));"
( the string "%q" can be found with fgrep 50 times in name-lookup.c )


I have browsed the GNU GCC 4.0.0 bug list and found that name-lookup is broken.
The build was not stopped by above mentioned warnings (that could be the reason 
why it didn't get recognized).
Maybe above information can help fixing the problem.


kind regards
  Daniel Wyss

Re: Tracking down source of libgcc_s.so compatibility?

[Daniel Jacobowitz]

On Wed, Jun 08, 2005 at 05:05:58PM -0700, Daniel Kegel wrote:
> Daniel Jacobowitz wrote:
> >Daniel Kegel wrote:
> >>Can somebody suggest a place to start looking for
> >>why the libgcc_s.so built by crosstool's gcc-3.4 can't handle
> >>exceptions from apps built by fc3's gcc-3.4?
> >
> >Try diffing the output of configure from building one and the other.
> >Probably some important linker feature is misdetected.
> 
> OK, good idea.
> 
> One other data point: the crosstool gcc was built against glibc-2.2.2,
> but the fc3 gcc was of course built against glibc-2.3.x.
> How likely is that to cause problems in exception handling?

Very.  The fc3 gcc may assume dl_iterate_phdr.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Tracking down source of libgcc_s.so compatibility?

[Marcin Dalecki]

On 2005-06-09, at 00:57, Daniel Kegel wrote:


Can somebody suggest a place to start looking for
why the libgcc_s.so built by crosstool's gcc-3.4 can't handle
exceptions from apps built by fc3's gcc-3.4?

The C++ program

#include 
void foo() throw (int) {
 std::cout << "In foo()" << std::endl;
 throw 1;
}
int main() {
 try {
   foo();
 } catch (int i) {
   std::cout << "Caught " << i << std::endl;
 }
 std::cout << "Finished" << std::endl;
 return 0;
}

works fine when built by FC3's gcc-3.4.
It also works fine when built by crosstool's gcc-3.4.

But when you add the libgcc_s.so built by crosstool into
ld.so.conf, the results are different; apps built
by fc3's gcc-3.4 die when they try to throw exceptions,
but apps built by crosstool's gcc-3.4 keep working.
Help!


NTPL vers. non NTPL signal handling differences.
The FC3 compiler contains some "backward compatibility" shims at
quite a few places, which are allowing old binaries to execute.
However stuff compiled with the FC3 version of the compiler, which
contains some "features" not seen otherwise will be of course
inconsistent with anything else.

Re: GCC 4.01 RC1 Available

[Ulrich Weigand]

Mark Mitchell wote:

> The GCC 4.0.1 RC1 prerelease is available here:
> 
>ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
> 
> Please test these tarballs, and let me know about showstoppers.

s390(x)-ibm-linux is looking fine:
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00583.html
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00584.html

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  [EMAIL PROTECTED]

Re: Use of check_vect() in vectorizer testsuite

[Devang Patel]

On Jun 9, 2005, at 3:29 AM, Giovanni Bajo wrote:


Hello,

I have some questions about the use of check_vect() in the vectorizer
testsuite:

1) All the ifcvt tests (vect-ifcvt*) seem to require SSE2  
capability to be
vectorized but they do not call check_vect(). Is this a bug? They  
surely fail

on my platform (which does not have SSE2).

2) The same applies for a vect_int test, vect-dv-2.c. I assume also  
vect_int

tests require SSE2 capability and thus should call check_vect()?



check_vect() is used to test whether to run the test or not. Now,  
vect.exp

does the job more efficiently.

 29 # If the target system supports vector instructions, the  
default action
 30 # for a test is 'run', otherwise it's 'compile'.  Save  
current default.
 31 # Executing vector instructions on a system without hardware  
vector support
 32 # is also disabled by a call to check_vect, but disabling  
execution here is

 33 # more efficient.


And dg-require-... should control whether this test should be enabled  
or not.
So depending upon the failure (runtime or compiler not vectorizing  
loops),

you want to update appropriate code block in vect.exp for your platform.

-
Devang

Re: Use of check_vect() in vectorizer testsuite

[Giovanni Bajo]

Devang Patel <[EMAIL PROTECTED]> wrote:

> check_vect() is used to test whether to run the test or not. Now,
> vect.exp does the job more efficiently.
>
>   29 # If the target system supports vector instructions, the
> default action
>   30 # for a test is 'run', otherwise it's 'compile'.  Save
> current default.
>   31 # Executing vector instructions on a system without hardware
> vector support
>   32 # is also disabled by a call to check_vect, but disabling
> execution here is
>   33 # more efficient.
>
>
> And dg-require-... should control whether this test should be enabled
> or not. So depending upon the failure (runtime or compiler not
> vectorizing loops), you want to update appropriate code block in
> vect.exp for your platform.

The point is that my target is i686-pc-linux-gnu, which supports vector
instruction (through -msse2), but whether the instructions can actually be
run or not depends on the given processor (e.g. Pentium 3 vs Pentium 4).
Even if my processor cannot *execute* the vectorized tests, I would still
like to test whether vectorization succeeds or not (that is, at least as
compile-time tests).

So, the point is that you cannot select between compile-time/run-time based
on a target triplet check, at least for this target. What do you suggest?
All the other tests use check_vect() exactly for this reason, as far as I
can see, so it looks to me that the sensible thing to do is to use
check_vect there as well.

For an example of the failures, see for instance:
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00553.html (which is
Diego's tester).
-- 
Giovanni Bajo

Re: Use of check_vect() in vectorizer testsuite

[Devang Patel]

On Jun 9, 2005, at 8:24 AM, Giovanni Bajo wrote:

So, the point is that you cannot select between compile-time/run- 
time based
on a target triplet check, at least for this target. What do you  
suggest?
All the other tests use check_vect() exactly for this reason, as  
far as I

can see, so it looks to me that the sensible thing to do is to use
check_vect there as well.


hmm.. that means all tests need to use check_vect(). I am going offline
now for the day, however consult with Dorit and/or Janis and feel free
to update these tests appropriately for your platform.

-
Devang

Re: Use of check_vect() in vectorizer testsuite

[Daniel Jacobowitz]

On Thu, Jun 09, 2005 at 05:24:19PM +0200, Giovanni Bajo wrote:
> The point is that my target is i686-pc-linux-gnu, which supports vector
> instruction (through -msse2), but whether the instructions can actually be
> run or not depends on the given processor (e.g. Pentium 3 vs Pentium 4).
> Even if my processor cannot *execute* the vectorized tests, I would still
> like to test whether vectorization succeeds or not (that is, at least as
> compile-time tests).
> 
> So, the point is that you cannot select between compile-time/run-time based
> on a target triplet check, at least for this target. What do you suggest?
> All the other tests use check_vect() exactly for this reason, as far as I
> can see, so it looks to me that the sensible thing to do is to use
> check_vect there as well.

You can still do this in common code in DejaGNU; change the dg-do value
to compile if we can not run the test.  I thought we already did that,
but I appear to be mistaken.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Any docs about gcov impl change from 3.3 to 3.4

[Janis Johnson]

On Thu, Jun 09, 2005 at 05:39:08PM +0800, Fei, Fei wrote:
> Also I want to have some document about format of foo.gcda and for.gcno
> files. 

See the comments in gcc/gcov-io.h.

Janis

Re: Use of check_vect() in vectorizer testsuite

[Janis Johnson]

On Thu, Jun 09, 2005 at 08:29:21AM -0700, Devang Patel wrote:
> 
> On Jun 9, 2005, at 8:24 AM, Giovanni Bajo wrote:
> 
> >So, the point is that you cannot select between compile-time/run- 
> >time based
> >on a target triplet check, at least for this target. What do you  
> >suggest?
> >All the other tests use check_vect() exactly for this reason, as  
> >far as I
> >can see, so it looks to me that the sensible thing to do is to use
> >check_vect there as well.
> 
> hmm.. that means all tests need to use check_vect(). I am going offline
> now for the day, however consult with Dorit and/or Janis and feel free
> to update these tests appropriately for your platform.

The vect tests use 'run' or 'compile' as the dg-do action based on
checks in vect.exp.  For powerpc and alpha this is based on a check
of whether hardware support is available, via check_vmx_hw_available
and check_alpha_max_hw_available.  A few tests use check_vect at
runtime instead because of limitations of the test directives.

It sounds as if there should be a check in target-supports.exp for
SSE2 support that determines whether the default test action is 'run'
or 'compile' for i686 targets.

Janis

Re: Use of check_vect() in vectorizer testsuite

[Giovanni Bajo]

Janis Johnson <[EMAIL PROTECTED]> wrote:

> It sounds as if there should be a check in target-supports.exp for
> SSE2 support that determines whether the default test action is 'run'
> or 'compile' for i686 targets.

I am not able to code TCL/Expect. Instead, I can easily provide a patch to
make the few missing testcases call check_vect(), as the rest of the
testsuite does. This would shut down the bogus regressions, while a more
correct solution is being developed. Would such a patch be ok?
-- 
Giovanni Bajo

Can't bootstrap mainline on powerpc64-linux

[Pat Haugen]

cc1: warnings being treated as errors
/home/pthaugen/work/src/mainline/gcc/gcc/config/rs6000/rs6000.c:12538:
warning: ‘rs6000_invalid_within_doloop’ defined but not used


-Pat

Re: GCC 4.01 RC1 Available

[Jonathan Wakely]

On Wed, Jun 08, 2005 at 09:57:55AM -0700, Mark Mitchell wrote:

> The GCC 4.0.1 RC1 prerelease is available here:
> 
>   ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
> 
> Please test these tarballs, and let me know about showstoppers.

I downloaded the gcc and gcc-g++ tarballs. x86_64 linux (FC3):

$ ../gcc-4.0.1-20050607/configure --enable-languages=c,c++
... configures OK ...
$ make bootstrap
... bootstraps OK ...
$ make check
make[1]: Entering directory
`/home/redi/src/gcc/tmp/build401/fixincludes'
autogen -T ../../gcc-4.0.1-20050607/fixincludes/check.tpl
../../gcc-4.0.1-20050607/fixincludes/inclhack.def
make[1]: autogen: Command not found
make[1]: *** [check] Error 127
make[1]: Leaving directory `/home/redi/src/gcc/tmp/build401/fixincludes'
make: *** [check-fixincludes] Error 2

"make -k check" continues OK (and is still running), but should a release
be looking for autogen like that?

jon

Re: GCC 4.01 RC1 Available

[Andrew Pinski]

On Jun 9, 2005, at 3:54 PM, Jonathan Wakely wrote:


On Wed, Jun 08, 2005 at 09:57:55AM -0700, Mark Mitchell wrote:


The GCC 4.0.1 RC1 prerelease is available here:

  ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/

Please test these tarballs, and let me know about showstoppers.
"make -k check" continues OK (and is still running), but should a 
release

be looking for autogen like that?


fixincludes checking always have needed autogen.  This is not new.

-- Pinski

Re: GCC 4.01 RC1 Available

[Jonathan Wakely]

On Thu, Jun 09, 2005 at 04:12:40PM -0400, Andrew Pinski wrote:

> 
> On Jun 9, 2005, at 3:54 PM, Jonathan Wakely wrote:
> 
> >On Wed, Jun 08, 2005 at 09:57:55AM -0700, Mark Mitchell wrote:
> >
> >>The GCC 4.0.1 RC1 prerelease is available here:
> >>
> >>  ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
> >>
> >>Please test these tarballs, and let me know about showstoppers.
> >"make -k check" continues OK (and is still running), but should a 
> >release
> >be looking for autogen like that?
> 
> fixincludes checking always have needed autogen.  This is not new.

OK, sorry for the silly question then.  Thanks.

jon

obj-c++ on sparc-linux: objc runtime: cannot find class Derived etc...

[Christian Joensson]

When running the obj-c++ testsuite fron gcc trunk, LAST_UPDATED: Thu
Jun  9 09:04:39 UTC 2005, I get a few failures like this:

objc runtime: cannot find class Derived
FAIL: obj-c++.dg/bitfield-2.mm execution test

objc runtime: cannot find class Manip
FAIL: obj-c++.dg/cxx-ivars-1.mm execution test

objc runtime: cannot find class Baz
FAIL: obj-c++.dg/cxx-ivars-2.mm execution test

objc runtime: cannot find class Derived
FAIL: obj-c++.dg/cxx-scope-1.mm execution test

objc runtime: cannot find class A
FAIL: obj-c++.dg/defs.mm execution test

etc...

any ideas?


-- 
Cheers,

/ChJ

A Suggestion for Release Testing

[Scott Robert Ladd]

Given the recent problems with the 4.0.0 release and major packages like
KDE and the kernel, has anyone considered testing releases by completely
compiling a Linux system?

As one of those infamous "Gentoo users", I don't think it would be at
all difficult to build an automated test harness, running in a chroot,
that would rebuild a "standard" Linux install with a pending release of
GCC. The suite of applications would need to be relatively tight; I'd
suggest Linux, Gnome, KDE, their major appliations, and perhaps OpenOffice.

The downside is that the compile would take quite a while; even for my
dual Opteron, full builds take more than a day. On the other hand, this
might catch some problems before release.

I'm willing to implement this, if it's deemed useful.

..Scott

Re: obj-c++ on sparc-linux: objc runtime: cannot find class Derived etc...

[Eric Botcazou]

> When running the obj-c++ testsuite fron gcc trunk, LAST_UPDATED: Thu
> Jun  9 09:04:39 UTC 2005, I get a few failures like this:

Results on x86-64 as of yesterday:

=== obj-c++ tests ===


Running target unix
FAIL: obj-c++.dg/bitfield-1.mm (test for excess errors)
FAIL: obj-c++.dg/bitfield-2.mm execution test
FAIL: obj-c++.dg/bitfield-4.mm (test for excess errors)
FAIL: obj-c++.dg/cxx-ivars-1.mm execution test
FAIL: obj-c++.dg/cxx-ivars-2.mm execution test
FAIL: obj-c++.dg/cxx-scope-1.mm execution test
FAIL: obj-c++.dg/defs.mm execution test
FAIL: obj-c++.dg/encode-3.mm execution test
FAIL: obj-c++.dg/encode-4.mm (test for excess errors)
WARNING: obj-c++.dg/encode-4.mm compilation failed to produce executable
FAIL: obj-c++.dg/encode-5.mm (test for excess errors)
WARNING: obj-c++.dg/encode-5.mm compilation failed to produce executable
FAIL: obj-c++.dg/encode-6.mm (test for excess errors)
WARNING: obj-c++.dg/encode-6.mm compilation failed to produce executable
FAIL: obj-c++.dg/encode-8.mm execution test
FAIL: obj-c++.dg/isa-field-1.mm (test for excess errors)
FAIL: obj-c++.dg/layout-1.mm (test for excess errors)
FAIL: obj-c++.dg/lookup-2.mm (test for excess errors)
WARNING: obj-c++.dg/lookup-2.mm compilation failed to produce executable
FAIL: obj-c++.dg/method-10.mm execution test
FAIL: obj-c++.dg/method-17.mm execution test
FAIL: obj-c++.dg/method-19.mm (test for excess errors)
WARNING: obj-c++.dg/method-19.mm compilation failed to produce executable
FAIL: obj-c++.dg/proto-qual-1.mm execution test
FAIL: obj-c++.dg/qual-types-1.mm execution test
FAIL: obj-c++.dg/template-1.mm execution test
FAIL: obj-c++.dg/template-4.mm execution test
FAIL: obj-c++.dg/try-catch-2.mm (test for excess errors)
WARNING: obj-c++.dg/try-catch-2.mm compilation failed to produce executable
FAIL: obj-c++.dg/try-catch-9.mm (test for excess errors)
WARNING: obj-c++.dg/try-catch-9.mm compilation failed to produce executable
FAIL: obj-c++.dg/va-meth-1.mm execution test

-- 
Eric Botcazou

Floating-Point, Round 2

[Scott Robert Ladd]

Yes, I'm still working on the idea of improving floating-point in GCC.

I've been having a number of offline discussions (for which I'm certain
you're all grateful) with folk who have concerns and suggestions for GCC
floating-point. My plan is to coallate all these thoughts, and present a
simple summary here for discussion.

If anyone has any thoughts on the topic, please e-mail me so I can
consider all viewpoints.

..Scott

Getting started with contributing

[Lee Millward]

I'd like to get started with helping to develop GCC but am seeking
some advice from those of you who are regular contributors on the best
approach to adopt.

I have spent the last few weeks reading the gcc-patches mailing list
and the documentation available on GCC from the Wiki and various other
documents I have found on the Internet to try and get a feel for how
everything works. I also have the latest CVS code and have spent time
reading through the source to become familiar with the coding
conventions in use. I've read through the "beginner" GCC projects on
the website and would like to hear peoples opinion on how useful
submitting patches for some of the these projects would be. Some of
the work being carried out and posted on the gcc-patches mailing list
makes those projects seem insignificant in comparision.

Thanks for your time in reading this, 
Lee.

re: A Suggestion for Release Testing

[Daniel Kegel]

Scott wrote:
> Given the recent problems with the 4.0.0 release and major packages like
> KDE and the kernel, has anyone considered testing releases by completely
> compiling a Linux system?

It's kind of hard to do for a new major release,
since the apps and kernel might not be ported yet,
but 4.0.0's been out long enough that gentoo
or FC4 probably have a good chance of building.

If you have the bandwidth to spare, I'd say go for it!
(But do a baseline for 4.0.0 first, and just report
regressions, of course.)
- Dan

Re: Getting started with contributing

[DJ Delorie]

> Some of the work being carried out and posted on the gcc-patches
> mailing list makes those projects seem insignificant in comparision.

There's a wide range of ability in gcc developers, so there's a wide
range of projects to work on.  They all use the same *process* so
starting with "trivial" projects is a good way to get used to the
process, while helping with "unglamorous" projects.  For example, I'm
working my way through all the warning() calls, changing the default 0
parameter to something useful.  There are thousands.  Want an easy
project?  Pick *one* call to warning() that still passes 0, and make
it pass something useful.  You'll learn a lot about the process that
way.  If you're interested in a particular area of the compiler, pick
a call to warning() in that area.

The beginner projects are listed because the "big" changes going on
are just too difficult for beginners to dive into.  You need something
that seems relatively insignificant because you have to start
*somewhere* and those projects need to be done anyway, so it's a good
fit.  Just pick something that seems easiest to you, and do it.

Fw: Can't bootstrap mainline on powerpc64-linux

[Pat Haugen]

[EMAIL PROTECTED] wrote on 06/09/2005 02:43:37 PM:

> cc1: warnings being treated as errors
> /home/pthaugen/work/src/mainline/gcc/gcc/config/rs6000/rs6000.c:12538:
> warning: ‘rs6000_invalid_within_doloop’ defined but not used


ChangeLog looks odd on this, Adrian changed the name of prototype and then
later Daniel came along and fixed prototype of "old" name.


2005-06-09  Daniel Berlin  <[EMAIL PROTECTED]>

  * config/rs6000/rs6000.c: (rs6000_insn_valid_within_doloop): Fix
  prototype.


...

2005-06-09  Adrian Straetling  <[EMAIL PROTECTED]>

  * target.h (insn_valid_within_doloop): Rename into
  "invalid_within_doloop".  Change return type to "const char *".
  Update Comment.
  * targhooks.h (default_insn_valid_within_doloop): Rename into
  "default_invalid_within_doloop".
  * targhooks.c (default_insn_valid_within_doloop): Likewise.
  Update Comment.
  * target-def.h (TARGET_INSN_VALID_WITHIN_DOLOOP): Rename target hook
  into "TARGET_INVALID_WITHIN_DOLOOP". Default it to
  "default_invalid_within_doloop".
  * hooks.c (hook_constcharptr_rtx_null): New function.
  (hook_bool_rtx_true): Remove.
  * hooks.h (hook_constcharptr_rtx_null): Declare.
  (hook_bool_rtx_true): Remove.
  * loop-doloop.c (doloop_valid_p): Temporarily store return value of
  "invalid_within_doloop" and print error message if non-null.
  Update Comment.
  * doc/tm.texi: Update documentation.
  * config/s390/s390.c: Adjust to new hook name and new default hook.
  * config/rs6000/rs6000.c: (rs6000_insn_valid_within_doloop): Rename
  into "rs6000_invalid_within_doloop".
  (rs6000_invalid_within_doloop): Change return type to "static const
  char *" and replace return values.  Update Comment.

Re: Getting started with contributing

[Eric Botcazou]

> I'd like to get started with helping to develop GCC but am seeking
> some advice from those of you who are regular contributors on the best
> approach to adopt.

I think you should consider trying to fix bugs (Bugzilla has a broad choice of 
these things :-), maybe front-end bugs to start with, say the C and C++ 
front-ends (relatively simple C++, not the fancy stuff), for example related 
to warnings and errors.  That will give you a glimpse of how these beasts 
work.  Then you could gradually migrate to other, "deeper" parts of the 
compiler.

If you choose that approach, do not look at 3.x bugs; the 4.x compilers have 
obsoleted a subtantial amount of 3.x-ish things it would be wasteful to learn 
at this point.

-- 
Eric Botcazou

Re: Fw: Can't bootstrap mainline on powerpc64-linux

[Daniel Berlin]

On Thu, 9 Jun 2005, Pat Haugen wrote:







[EMAIL PROTECTED] wrote on 06/09/2005 02:43:37 PM:


cc1: warnings being treated as errors
/home/pthaugen/work/src/mainline/gcc/gcc/config/rs6000/rs6000.c:12538:
warning: ârs6000_invalid_within_doloopâ defined but not used



ChangeLog looks odd on this, Adrian changed the name of prototype and then
later Daniel came along and fixed prototype of "old" name.


2005-06-09  Daniel Berlin  <[EMAIL PROTECTED]>

 * config/rs6000/rs6000.c: (rs6000_insn_valid_within_doloop): Fix
 prototype.


Before i committed this, we had

"static bool rs6000_invalid_within_doloop

  static const char *
  rs6000_invalid_within_doloop 
"

I had updated rs6000.c repeatedly to make sure i wasn't missing something.

I simply made the prototype at the top match the function as it actually 
exists in the source file.


"Defined but not used" means it exists in the source file but isn't 
actually used, which is a different bug :)




--Dan

Re: Can't bootstrap mainline on powerpc64-linux

[Dale Johannesen]

On Jun 9, 2005, at 12:43 PM, Pat Haugen wrote:

cc1: warnings being treated as errors
/home/pthaugen/work/src/mainline/gcc/gcc/config/rs6000/rs6000.c:12538:
warning: ‘rs6000_invalid_within_doloop’ defined but not used


Problem is Adrian changed TARGET_INSN_VALID_WITHIN_DOLOOP to
TARGET_INVALID_WITHIN_DOLOOP most places, but not in rs6000.c.
I'll commit the following as obvious after bootstrap succeeds.

Index: rs6000.c
===
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
retrieving revision 1.838
diff -u -b -r1.838 rs6000.c
--- rs6000.c9 Jun 2005 14:23:28 -   1.838
+++ rs6000.c9 Jun 2005 22:46:02 -
@@ -906,8 +906,8 @@
 #undef TARGET_FUNCTION_OK_FOR_SIBCALL
 #define TARGET_FUNCTION_OK_FOR_SIBCALL rs6000_function_ok_for_sibcall
 
-#undef TARGET_INSN_VALID_WITHIN_DOLOOP
-#define TARGET_INSN_VALID_WITHIN_DOLOOP rs6000_invalid_within_doloop
+#undef TARGET_INVALID_WITHIN_DOLOOP
+#define TARGET_INVALID_WITHIN_DOLOOP rs6000_invalid_within_doloop
 
 #undef TARGET_RTX_COSTS
 #define TARGET_RTX_COSTS rs6000_rtx_costs

extern const and all that

[Gabriel Dos Reis]

Hi,

In the message
 
http://gcc.gnu.org/ml/gcc/2005-05/msg01265.html

you said

  > Fifth, there is a slight difference between "const" in C and in  C++.
  > In C++, a const variable implicitly has an internal linkage; so a
  > C++ compiler tends to optimize it out when its address is not taken
  > (so no storage is wasted).  This is an issue for the objects
  > automatically generated by the gengtype support machinery.  The are
  > supposed to have external linkage, so we need to explicitly say
  > "extern" in their definitions. 

  Presumably such constants are declared in some header file, with
  external linkage.  It would be better to make that declaration visible
  at the point of definition, rather than marking up the declarations with
  'extern'.

However, if you try to compile the souces (augmented with attched
patch) with g++, you should hit an "undefined reference to symbol"
linker error similar to:

g++   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros 
-Wold-style-definition -fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE -o 
build/genmddeps \
 build/genmddeps.o build/gensupport.o build/dummy-conditions.o build/rtl.o 
build/read-rtl.o build/ggc-none.o build/min-insn-modes.o \
 build/errors.o ../build-i686-pc-linux-gnu/libiberty/libiberty.a
build/gensupport.o(.text+0xc27): In function `maybe_eval_c_test(char const*)':
/home/gdr/redhat/egcs/gcc/gensupport.c:1122: undefined reference to 
`insn_elision_unavailable'
build/gensupport.o(.text+0x105d): In function `init_md_reader_args_cb(int, 
char**, bool (*)(char const*))':
/home/gdr/redhat/egcs/gcc/gensupport.c:975: undefined reference to 
`n_insn_conditions'
build/gensupport.o(.text+0x108d):/home/gdr/redhat/egcs/gcc/gensupport.c:977: 
undefined reference to `insn_conditions'
collect2: ld returned 1 exit status


This is an instance of the situations I reported earlier.  
Of course, your suggestion is the natural choice, if we did not have
addiional constraint.  Indeed, the file (for MD gen-support machinery)
that defines those variables is dummy-conditions.c, with the following
comment: 

/* In order to avoid dragging in all the headers that are needed to
   declare things that gensupport.h uses, we duplicate the declaration
   of struct c_test here.  (In particular we do not want to have to
   include tm.h nor rtl.h in this file.)  */
 
Given that constraint, it appears to me that putting "extern" in the
definition is the minimal, viable solution.  

Thoughts?

-- Gaby

Index: ChangeLog
===
RCS file: /cvs/gcc/gcc/gcc/ChangeLog,v
retrieving revision 2.9112
diff -p -r2.9112 ChangeLog
*** ChangeLog   9 Jun 2005 22:27:41 -   2.9112
--- ChangeLog   9 Jun 2005 22:57:51 -
***
*** 1,3 
--- 1,9 
+ 2005-06-09  Gabriel Dos Reis  <[EMAIL PROTECTED]>
+ 
+   * gensupport.c (lookup_predicate): Add explicit cast to
+   htab_find() value.
+   (init_predicate_table): Use XCNEW.
+ 

Index: gensupport.c
===
RCS file: /cvs/gcc/gcc/gcc/gensupport.c,v
retrieving revision 1.62
diff -p -r1.62 gensupport.c
*** gensupport.c26 Apr 2005 00:23:54 -  1.62
--- gensupport.c9 Jun 2005 22:57:51 -
*** lookup_predicate (const char *name)
*** 1200,1206 
  {
struct pred_data key;
key.name = name;
!   return htab_find (predicate_table, &key);
  }
  
  void
--- 1200,1206 
  {
struct pred_data key;
key.name = name;
!   return (pred_data *) htab_find (predicate_table, &key);
  }
  
  void
*** init_predicate_table (void)
*** 1289,1295 
  
for (i = 0; i < NUM_KNOWN_OLD_PREDS; i++)
  {
!   pred = xcalloc (sizeof (struct pred_data), 1);
pred->name = old_preds[i].name;
  
for (j = 0; old_preds[i].codes[j] != 0; j++)
--- 1289,1295 
  
for (i = 0; i < NUM_KNOWN_OLD_PREDS; i++)
  {
!   pred = XCNEW (struct pred_data);
pred->name = old_preds[i].name;
  
for (j = 0; old_preds[i].codes[j] != 0; j++)

Re: Getting started with contributing

[chris jefferson]

Lee Millward wrote:


I'd like to get started with helping to develop GCC but am seeking
some advice from those of you who are regular contributors on the best
approach to adopt.

I have spent the last few weeks reading the gcc-patches mailing list
and the documentation available on GCC from the Wiki and various other
documents I have found on the Internet to try and get a feel for how
everything works. I also have the latest CVS code and have spent time
reading through the source to become familiar with the coding
conventions in use. I've read through the "beginner" GCC projects on
the website and would like to hear peoples opinion on how useful
submitting patches for some of the these projects would be. Some of
the work being carried out and posted on the gcc-patches mailing list
makes those projects seem insignificant in comparision.

Thanks for your time in reading this, 
Lee.
 

Speaking as someone who started contributing the gcc (actually 
libstdc++-v3) quite recently, I wouldn't worry too much that anything 
you think you can do seems inconsequental. If you wander around bugzilla 
and try to fix bugs, and also look at bits of code related to things you 
look at, it won't take very long to find some minor annoying bugs that 
have been hanging around but no-one has got around to fixing, or some 
code that looks a little crusty and hacked which could do with a spot of 
cleaning.


Also there are quite a few bits of code which aren't ever tested in the 
testsuite, and really all code should be. Writing testcases isn't the 
most exciting job in the world, but it's an easy way to get some code 
written, and I'm fairly sure no-one will reject new test cases which 
stress untested pieces of code. Also, you are in the useful position of 
looking at code with a new eye, take the opportunity to convince 
yourself algorithms actually work correctly in all cases, and don't have 
any random unnessasary overheads. While it's not as exciting as writing 
a new uber-super-SRA-loop-floating point-tree-SSE3 optimisation pass, a 
spot of cleaning up old corners and clearing out old dusty cobwebs I'm 
sure will be useful, and provides a method to get deeper into gcc.


Chris

Re: Getting started with contributing

[Giovanni Bajo]

Lee Millward <[EMAIL PROTECTED]> wrote:

> I have spent the last few weeks reading the gcc-patches mailing list
> and the documentation available on GCC from the Wiki and various other
> documents I have found on the Internet to try and get a feel for how
> everything works. I also have the latest CVS code and have spent time
> reading through the source to become familiar with the coding
> conventions in use. I've read through the "beginner" GCC projects on
> the website and would like to hear peoples opinion on how useful
> submitting patches for some of the these projects would be. Some of
> the work being carried out and posted on the gcc-patches mailing list
> makes those projects seem insignificant in comparision.

There are a couple of ongoing transitions that might be carried out by
beginners. For instance, we are in the process of converting all calls to
"abort()" to calls to gcc_assert()/gcc_unreachable(). Or we are trying to
convert all the VARRAY data structures into VEC data structures. You might have
seen some of these patches in gcc-patches. I think those are a good fit for a
beginner.

Also, remember to file papers for copyright assignment to the FSF, which is a
prerequisite for accepting any patch.

Giovanni Bajo

Re: A Suggestion for Release Testing

[Joe Buck]

On Thu, Jun 09, 2005 at 04:42:33PM -0400, Scott Robert Ladd wrote:
> Given the recent problems with the 4.0.0 release and major packages like
> KDE and the kernel, has anyone considered testing releases by completely
> compiling a Linux system?

With 4.0.0, compiling a complete GNU/Linux distribution reveals bugs in
GCC, but even more bugs in C++ software that is not valid C++.  Assuming
we can get the distros to fix the latter set of problems, it would
certainly be good for release testing if we built complete distros, or
significant chunks thereof.  It would be even better if this could be
coordinated with the people producing all that software; I think that (for
example) GCC and KDE could both do better about trying each others' early
code sooner than we do, and communicate any problems found.

gcc-4.0-20050609 is now available

[gccadmin]

Snapshot gcc-4.0-20050609 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050609/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050609 

You'll find:

gcc-4.0-20050609.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.0-20050609.tar.bz2 C front end and core compiler

gcc-ada-4.0-20050609.tar.bz2  Ada front end and runtime

gcc-fortran-4.0-20050609.tar.bz2  Fortran front end and runtime

gcc-g++-4.0-20050609.tar.bz2  C++ front end and runtime

gcc-java-4.0-20050609.tar.bz2 Java front end and runtime

gcc-objc-4.0-20050609.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.0-20050609.tar.bz2The GCC testsuite

Diffs from 4.0-20050602 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.0
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: A Suggestion for Release Testing

[Arthur Nascimento]

2005/6/9, Scott Robert Ladd <[EMAIL PROTECTED]>:
> Given the recent problems with the 4.0.0 release and major packages like
> KDE and the kernel, has anyone considered testing releases by completely
> compiling a Linux system?

Yes, people do it all the time. Check Sourcemage, LFS and DIY:

http://www.sourcemage.org/
http://www.linuxfromscratch.org/
http://www.diy-linux.org/

position of section() attribute question

[DJ Delorie]

Consider:

int __attribute__((section("foo"))) *var1;
int * __attribute__((section("foo"))) var2;

var2 is itself in section foo, and points to an int.

Isn't var1 a pointer to something in section foo, and not itself in
foo?  GCC instead treats var1 like var2.

I couldn't figure out a suitable search string to see if this has been
discussed before, please feel free to just point me at an old email
somewhere.

Re: Getting started with contributing

[Bernardo Innocenti]

Giovanni Bajo wrote:

> Also, remember to file papers for copyright assignment to the FSF, which is a
> prerequisite for accepting any patch.

Filing papers is a prerequisite for legally significant changes only:

  http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant


And, btw, it may take about a month for the paperwork to
do the round trip from the FSF copyright clerk and back.

When you file your request, be sure to mention a few ancillary
or related projects such as libstdc++, autoconf, binutils, GDB,
and maybe others... Just to make sure this is a one-time hassle.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: position of section() attribute question

[Joseph S. Myers]

On Thu, 9 Jun 2005, DJ Delorie wrote:

> 
> Consider:
> 
> int __attribute__((section("foo"))) *var1;
> int * __attribute__((section("foo"))) var2;
> 
> var2 is itself in section foo, and points to an int.
> 
> Isn't var1 a pointer to something in section foo, and not itself in
> foo?  GCC instead treats var1 like var2.
> 
> I couldn't figure out a suitable search string to see if this has been
> discussed before, please feel free to just point me at an old email
> somewhere.

The interpretation of attribute specifiers is explained in "Attribute 
Syntax" in the manual.  If the attribute specifier is part of the 
declaration specifiers, it applies to the declaration; see vector_size for 
how to write handlers for attributes which should apply to the type given 
in the declaration specifiers instead.  "section" attributes are presently 
storage-class-like (similar to "static") and only work on declarations.

If you want something like section attributes but affecting types then 
TR18037 (or perhaps the updated version in WG14 N1120) named address 
spaces would indicate the appropriate semantics.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: position of section() attribute question

[DJ Delorie]

> "section" attributes are presently storage-class-like (similar to
> "static") and only work on declarations.

Ok, I see that we set the "apply to decl" bit for "section".  I guess
the question is - why?  Would it be more consistent to keep track of
where it is given, and complain if it is applied to the type instead
of the decl?

Or is it as simple as "because the programmer expects it this way" ? ;-)

Re: position of section() attribute question

[Joseph S. Myers]

On Thu, 9 Jun 2005, DJ Delorie wrote:

> 
> > "section" attributes are presently storage-class-like (similar to
> > "static") and only work on declarations.
> 
> Ok, I see that we set the "apply to decl" bit for "section".  I guess
> the question is - why?  Would it be more consistent to keep track of
> where it is given, and complain if it is applied to the type instead
> of the decl?
> 
> Or is it as simple as "because the programmer expects it this way" ? ;-)

The various exceptions of the form "if an attribute is applied to the type 
of a decl which can only apply to a decl, then apply it to the decl" are 
there because they represent forms used by existing code.

In principle I'd prefer storage class attributes to be in the declaration 
specifiers (and nowhere else), and attributes on types to be after "*" or 
"(" in nested declarators (and nowhere else), and attributes on 
struct/union/enum definitions to be after the struct/union/enum keyword, 
and attributes on labels not to be there at all.  But though these 
positions are syntactically cleaner and less ambiguous, most code and GCC 
documentation uses the less clear do-what-I-mean positions instead.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: position of section() attribute question

[DJ Delorie]

> most code and GCC documentation uses the less clear do-what-I-mean
> positions instead.

Ok, that's kinda what I figured.  Thanks!

Re: A Suggestion for Release Testing

[Scott Robert Ladd]

Arthur Nascimento wrote:
>>Given the recent problems with the 4.0.0 release and major packages like
>>KDE and the kernel, has anyone considered testing releases by completely
>>compiling a Linux system?

> Yes, people do it all the time. Check Sourcemage, LFS and DIY:
> 
> http://www.sourcemage.org/
> http://www.linuxfromscratch.org/
> http://www.diy-linux.org/

Of course there are several source-based distributions, but that's not
what I'm talking about. While they may do individual testing when a new
GCC release appears, I'm talking about a formal testing process, where
GCC would be regularly tested during development to ensure that nothing
unexpected is broken. Breaking KDE or the kernel demonstrates a serious
problem in a release, for example.

The test suite can check individual tests, but what may be needed is a
comprehensive test across several applications that comprise a whole.
Certainly GCC would be the better for being able to effectively compile
Linux, KDE, Gnome, Apache, and other "core" programs.

..Scott

Re: A Suggestion for Release Testing

[Scott Robert Ladd]

Joe Buck wrote:
> With 4.0.0, compiling a complete GNU/Linux distribution reveals bugs
> in GCC, but even more bugs in C++ software that is not valid C++.
> Assuming we can get the distros to fix the latter set of problems...

I don't have a good solution for this problem, other than education.

> ...it would certainly be good for release testing if we built
> complete distros, or significant chunks thereof.  It would be even
> better if this could be coordinated with the people producing all
> that software; I think that (for example) GCC and KDE could both do
> better about trying each others' early code sooner than we do, and
> communicate any problems found.

I'm hoping that creating a formal "core software" test might foster some
of that communication. We have to start somewhere.

..Scott

Re: extern const and all that

[Gabriel Dos Reis]

Gabriel Dos Reis <[EMAIL PROTECTED]> writes:

[...]

| /* In order to avoid dragging in all the headers that are needed to
|declare things that gensupport.h uses, we duplicate the declaration
|of struct c_test here.  (In particular we do not want to have to
|include tm.h nor rtl.h in this file.)  */
|  
| Given that constraint, it appears to me that putting "extern" in the
| definition is the minimal, viable solution.  

An alternative is just this:

Index: dummy-conditions.c
===
RCS file: /cvs/gcc/gcc/gcc/dummy-conditions.c,v
retrieving revision 1.4
diff -p -r1.4 dummy-conditions.c
*** dummy-conditions.c  12 Aug 2004 07:48:51 -  1.4
--- dummy-conditions.c  10 Jun 2005 04:52:27 -
***
*** 27,33 
  /* In order to avoid dragging in all the headers that are needed to
 declare things that gensupport.h uses, we duplicate the declaration
 of struct c_test here.  (In particular we do not want to have to
!include tm.h nor rtl.h in this file.)  */
  struct c_test
  {
const char *expr;
--- 27,38 
  /* In order to avoid dragging in all the headers that are needed to
 declare things that gensupport.h uses, we duplicate the declaration
 of struct c_test here.  (In particular we do not want to have to
!include tm.h nor rtl.h in this file.)  For the same reasons, we
!repeat the "extern" declarations for the const variable here.  We
!could have used the "extern" specifier directly in their definitions,
!but then gcc would produce a warning which will cause a failure.  The
!"extern" specifier is necessary for preserving the same meaning in
!C++ (which assumes internal linkage by default for const objects.)  */
  struct c_test
  {
const char *expr;
*** struct c_test
*** 35,42 
--- 40,51 
  };
  
  /* Empty conditions table to prevent link errors.  */
+ extern const struct c_test insn_conditions[];
+ extern const size_t n_insn_conditions;
+ 
  const struct c_test insn_conditions[1] = { { 0, 0 } };
  const size_t n_insn_conditions = 0;
  
  /* Disable insn elision, since it is currently impossible.  */
+ extern const int insn_elision_unavailable;
  const int insn_elision_unavailable = 1;

Re: obj-c++ on sparc-linux: objc runtime: cannot find class Derived etc...

[Ziemowit Laski]

Eric,

What do objc.log and obj-c++.log say?  I'm still seeing mysterious FC3 
(a fresh install thereof, no less) failures that no one else seems to 
be able to reproduce...


Thanks,

--Zem



On 9 Jun 2005, at 13.45, Eric Botcazou wrote:


When running the obj-c++ testsuite fron gcc trunk, LAST_UPDATED: Thu
Jun  9 09:04:39 UTC 2005, I get a few failures like this:


Results on x86-64 as of yesterday:

=== obj-c++ tests ===


Running target unix
FAIL: obj-c++.dg/bitfield-1.mm (test for excess errors)
FAIL: obj-c++.dg/bitfield-2.mm execution test
FAIL: obj-c++.dg/bitfield-4.mm (test for excess errors)
FAIL: obj-c++.dg/cxx-ivars-1.mm execution test
FAIL: obj-c++.dg/cxx-ivars-2.mm execution test
FAIL: obj-c++.dg/cxx-scope-1.mm execution test
FAIL: obj-c++.dg/defs.mm execution test
FAIL: obj-c++.dg/encode-3.mm execution test
FAIL: obj-c++.dg/encode-4.mm (test for excess errors)
WARNING: obj-c++.dg/encode-4.mm compilation failed to produce 
executable

FAIL: obj-c++.dg/encode-5.mm (test for excess errors)
WARNING: obj-c++.dg/encode-5.mm compilation failed to produce 
executable

FAIL: obj-c++.dg/encode-6.mm (test for excess errors)
WARNING: obj-c++.dg/encode-6.mm compilation failed to produce 
executable

FAIL: obj-c++.dg/encode-8.mm execution test
FAIL: obj-c++.dg/isa-field-1.mm (test for excess errors)
FAIL: obj-c++.dg/layout-1.mm (test for excess errors)
FAIL: obj-c++.dg/lookup-2.mm (test for excess errors)
WARNING: obj-c++.dg/lookup-2.mm compilation failed to produce 
executable

FAIL: obj-c++.dg/method-10.mm execution test
FAIL: obj-c++.dg/method-17.mm execution test
FAIL: obj-c++.dg/method-19.mm (test for excess errors)
WARNING: obj-c++.dg/method-19.mm compilation failed to produce 
executable

FAIL: obj-c++.dg/proto-qual-1.mm execution test
FAIL: obj-c++.dg/qual-types-1.mm execution test
FAIL: obj-c++.dg/template-1.mm execution test
FAIL: obj-c++.dg/template-4.mm execution test
FAIL: obj-c++.dg/try-catch-2.mm (test for excess errors)
WARNING: obj-c++.dg/try-catch-2.mm compilation failed to produce 
executable

FAIL: obj-c++.dg/try-catch-9.mm (test for excess errors)
WARNING: obj-c++.dg/try-catch-9.mm compilation failed to produce 
executable

FAIL: obj-c++.dg/va-meth-1.mm execution test

--
Eric Botcazou



--
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler GroupCupertino, CA USA  95014-2083
Apple Computer, Inc.   +1.408.974.6229  Fax .5477

Re: A Suggestion for Release Testing

[R Hill]

Scott Robert Ladd wrote:

Joe Buck wrote:

With 4.0.0, compiling a complete GNU/Linux distribution reveals bugs
in GCC, but even more bugs in C++ software that is not valid C++.
Assuming we can get the distros to fix the latter set of problems...


I don't have a good solution for this problem, other than education.


The more the better. ;)  Actually, by the time 4.0.0 was released most 
of the packages in Gentoo that had issues with the new compiler had 
already been patched and tested.  There are some great gcc porting devs 
on board and a small independent group of users that use the weekly 
snapshots attempting to build a clean system in a chroot and patching up 
what we run into.



...it would certainly be good for release testing if we built
complete distros, or significant chunks thereof.  It would be even
better if this could be coordinated with the people producing all
that software; I think that (for example) GCC and KDE could both do
better about trying each others' early code sooner than we do, and
communicate any problems found.


I'm hoping that creating a formal "core software" test might foster some
of that communication. We have to start somewhere.


I use Gentoo's "system" target plus a few of the essentials like the 
kernel, xorg, Firefox ;), etc. as my smoketest.  Others use whatever 
they want or need.  Between all of us we end up covering a lot of the 
distro.  LFS and DIYL could be good models to look at as well.


While some of the Gentoo userbase isn't exactly helpful as far as 
development goes ;) there's still a lot of good work being done that's 
really not being used by anyone but us.  Patches go upstream of course, 
but we're in a good position to give an overall view of just how ready a 
particular release is to be let loose in public. Opening some lines of 
communication between GCC, the producers, and the users might be an 
asset to everybody.


--de. (currently working the hell out of RC1)

Re: obj-c++ on sparc-linux: objc runtime: cannot find class Derived etc...

[Eric Botcazou]

> What do objc.log and obj-c++.log say?  I'm still seeing mysterious FC3
> (a fresh install thereof, no less) failures that no one else seems to
> be able to reproduce...

objc.log is clean, obj-c++.log is attached.  This is on SuSE 9.2 Professional.

-- 
Eric Botcazou


obj-c++.log.gz
Description: GNU Zip compressed data