Re: 4.1rc1 cross Ada build issue

[Paolo Bonzini]

Joel Sherrill wrote:


Hi,

I think/thought this has been dealt with
but am not sure.  I started with a fresh install
directory, built and installed a native GNU/Linux
C, C++, and Ada toolset.  Then proceeded to
try to build cross Ada for *-rtems.  All targets
are failing because they are not finding newlib's
.h files in the source tree while building.

Hasn't this been fixed before?  Is there a missing
fix to merge onto the branch?


Yes, http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00342.html was not 
applied on the branch.  It only affects Ada so it shuld be safe.


Paolo

bug with -O2 in g++ Debian 4.0.2-9 ?

[Jerome Robert]

Here is the faulty program (this kind of code is generated by
http://www.swig.org):

/// Start ///
#include 

int main(void)
{
long long a = 0xL;
long long b = 0;
void ** aa=(void **)(void *)&a;
void ** ab=(void **)(void *)&b;
*ab = *aa;
printf("in: %llX, out: %llX\n", a, b);
return 0;
}
/// End ///

The output for the following version is:
(Debian 1:3.3.6-12) g++ in: , out: 
(Debian 1:3.3.6-12) g++ -O1 in: , out: 
(Debian 1:3.3.6-12) g++ -O2 in: , out: 
(Debian 4.0.2-9) g++in: , out: 
(Debian 4.0.2-9) g++ -O1in: , out: 
(Debian 4.0.2-9) g++ -O2in: , out: 0

So there is something wrong with g++ -O2 (Debian 4.0.2-9). Is this program wrong
or is this a bug ?

Regards,

Jerome

Re: bug with -O2 in g++ Debian 4.0.2-9 ?

[Digvijoy Chatterjee]

#include

using namespace std;
class Rational
{

  int numerator;
  int denominator;
public:
  int GetNum ()
  {
return numerator;
  }
  int GetDen ()
  {
return denominator;
  }
  void setNum (int numer)
  {
numerator = numer;
  }

  void setDen (int den)
  {
denominator = den;
  }

  int gcd (int i1, int i2) 
  {
if (i2 == 0)
  return i1;
else
  return gcd (i2, i1 % i2);
  }
public :
  Rational (float f)
  {
int denom = 1;
while (((int) f  -  f)!= 0) 
  {
f *= 10;
denom *= 10;
  }
int Gcd = gcd (int (f), denom); 
numerator = f / Gcd;
cout < Here is the faulty program (this kind of code is generated by
> http://www.swig.org):
> 
> /// Start ///
> #include 
> 
> int main(void)
> {
> long long a = 0xL;
> long long b = 0;
> void ** aa=(void **)(void *)&a;
> void ** ab=(void **)(void *)&b;
> *ab = *aa;
> printf("in: %llX, out: %llX\n", a, b);
> return 0;
> }
> /// End ///
> 
> The output for the following version is:
> (Debian 1:3.3.6-12) g++ in: , out: 
> (Debian 1:3.3.6-12) g++ -O1 in: , out: 
> (Debian 1:3.3.6-12) g++ -O2 in: , out: 
> (Debian 4.0.2-9) g++in: , out: 
> (Debian 4.0.2-9) g++ -O1in: , out: 
> (Debian 4.0.2-9) g++ -O2in: , out: 0
> 
> So there is something wrong with g++ -O2 (Debian 4.0.2-9). Is this program 
> wrong
> or is this a bug ?
> 
> Regards,
> 
> Jerome
-- 
Thanks and Regards
Digvijoy Chatterjee

Please Visit http://indra/LiMS and start your Linux Journey


 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not to copy, disclose, or distribute this e-mail or its contents to any other 
person and any such actions are unlawful. This e-mail may contain viruses. 
Infosys has taken every reasonable precaution to minimize this risk, but is not 
liable for any damage you may sustain as a result of any virus in this e-mail. 
You should carry out your own virus checks before opening the e-mail or 
attachment. Infosys reserves the right to monitor and review the content of all 
messages sent to or from this e-mail address. Messages sent to or from this 
e-mail address may be stored on the Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

Re: bug with -O2 in g++ Debian 4.0.2-9 ?

[Andrew Haley]

Jerome Robert writes:
 >  Is this program wrong

Yes.

See ISO C9899:199 Section 6.3.2.3.  

These lines are particularly bogus:

void ** aa=(void **)(void *)&a;
void ** ab=(void **)(void *)&b;

All the cast to (void *) does is suppress a useful warning.

-fno-strict-aliasing may help.

Andrew.

Re: bug with -O2 in g++ Debian 4.0.2-9 ?

[Digvijoy Chatterjee]

I am using g++ 4.0.2 on Suse-10
On Thu, 2006-02-23 at 15:50 +0530, Digvijoy Chatterjee wrote:
> #include
> 
> using namespace std;
> class Rational
> {
> 
>   int numerator;
>   int denominator;
> public:
>   int GetNum ()
>   {
> return numerator;
>   }
>   int GetDen ()
>   {
> return denominator;
>   }
>   void setNum (int numer)
>   {
> numerator = numer;
>   }
> 
>   void setDen (int den)
>   {
> denominator = den;
>   }
> 
>   int gcd (int i1, int i2) 
>   {
> if (i2 == 0)
>   return i1;
> else
>   return gcd (i2, i1 % i2);
>   }
> public :
>   Rational (float f)
>   {
> int denom = 1;
> while (((int) f  -  f)!= 0) 
>   {
> f *= 10;
> denom *= 10;
>   }
> int Gcd = gcd (int (f), denom); 
> numerator = f / Gcd;
> cout < denominator = denom / Gcd;
> cout<<"-"< cout <   }
>  
> };
> 
> int
> main (int argc, char **argv)
> {
>   Rational r1 = Rational (.4537f);
> }
> 
> 
> -
> This runs successfully with:
> g++ without any optimization  ,
> but with -O or -02 or -03  the executable just hangs forever
> 
> 
> On Thu, 2006-02-23 at 10:56 +0100, Jerome Robert wrote:
> > Here is the faulty program (this kind of code is generated by
> > http://www.swig.org):
> > 
> > /// Start ///
> > #include 
> > 
> > int main(void)
> > {
> > long long a = 0xL;
> > long long b = 0;
> > void ** aa=(void **)(void *)&a;
> > void ** ab=(void **)(void *)&b;
> > *ab = *aa;
> > printf("in: %llX, out: %llX\n", a, b);
> > return 0;
> > }
> > /// End ///
> > 
> > The output for the following version is:
> > (Debian 1:3.3.6-12) g++ in: , out: 
> > (Debian 1:3.3.6-12) g++ -O1 in: , out: 
> > (Debian 1:3.3.6-12) g++ -O2 in: , out: 
> > (Debian 4.0.2-9) g++in: , out: 
> > (Debian 4.0.2-9) g++ -O1in: , out: 
> > (Debian 4.0.2-9) g++ -O2in: , out: 0
> > 
> > So there is something wrong with g++ -O2 (Debian 4.0.2-9). Is this program 
> > wrong
> > or is this a bug ?
> > 
> > Regards,
> > 
> > Jerome
-- 
Thanks and Regards
Digvijoy Chatterjee

Please Visit http://indra/LiMS and start your Linux Journey


 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not to copy, disclose, or distribute this e-mail or its contents to any other 
person and any such actions are unlawful. This e-mail may contain viruses. 
Infosys has taken every reasonable precaution to minimize this risk, but is not 
liable for any damage you may sustain as a result of any virus in this e-mail. 
You should carry out your own virus checks before opening the e-mail or 
attachment. Infosys reserves the right to monitor and review the content of all 
messages sent to or from this e-mail address. Messages sent to or from this 
e-mail address may be stored on the Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

Re: bug with -O2 in g++ Debian 4.0.2-9 ?

[Richard Guenther]

> This runs successfully with:
> g++ without any optimization  ,
> but with -O or -02 or -03  the executable just hangs forever

See PR323 - this is expected behavior.

Richard.

Re: bug with -O2 in g++ Debian 4.0.2-9 ?

[Digvijoy Chatterjee]

On Thu, 2006-02-23 at 13:54 +0100, Richard Guenther wrote:
> > This runs successfully with:
> > g++ without any optimization  ,
> > but with -O or -02 or -03  the executable just hangs forever
> 
> See PR323 - this is expected behavior.
> 
> Richard.
> 
What is PR323 ,is it some page in the manual /or gcc info ?  Please
articulate
-- 
Thanks and Regards
Digvijoy Chatterjee

Please Visit http://indra/LiMS and start your Linux Journey


 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not to copy, disclose, or distribute this e-mail or its contents to any other 
person and any such actions are unlawful. This e-mail may contain viruses. 
Infosys has taken every reasonable precaution to minimize this risk, but is not 
liable for any damage you may sustain as a result of any virus in this e-mail. 
You should carry out your own virus checks before opening the e-mail or 
attachment. Infosys reserves the right to monitor and review the content of all 
messages sent to or from this e-mail address. Messages sent to or from this 
e-mail address may be stored on the Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

Re: bug with -O2 in g++ Debian 4.0.2-9 ?

[Andrew Haley]

Digvijoy Chatterjee writes:
 > 
 > On Thu, 2006-02-23 at 13:54 +0100, Richard Guenther wrote:
 > > > This runs successfully with:
 > > > g++ without any optimization  ,
 > > > but with -O or -02 or -03  the executable just hangs forever
 > > 
 > > See PR323 - this is expected behavior.
 > > 
 > > Richard.
 > > 
 > What is PR323 ,is it some page in the manual /or gcc info ?  Please
 > articulate

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

acats testsuite, "enum_check.ads" compilation error

[Rainer Emrich]

Looking into the acats.log I discovered the following:

Compiling support files...splitting spprt13s.adt into:
   spprt13.ads
gnatmake
--GCC="/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-3.4.5/gcc-3.4.5/gcc/xgcc
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-3.4.5/gcc-3.4.5/gcc/"
-gnatws -c -gnato -gnatE defs.ads enum_check.ads f340a000.ads f340a001.ads
f341a00_0.ads f341a00_1.ads f341a00_2.ads f390a00.ads f392a00.ads f392c00_1.ads
f392d00.ads f393a00_0.ads f393a00_1.ads f393a00_2.ads f393a00_3.ads
f393a00_4.ads f393b00.ads f3a2a00.ads f460a00.ads f730a000.ads f730a001.ads
f731a00.ads f940a00.ads f954a00.ads fa11a00.ads fa11b00.ads
fa11c00_0-fa11c00_1-fa11c00_2.ads fa11c00_0-fa11c00_1.ads fa11c00_0.ads
fa11d00.ads fa13a00_0.ads fa13a00_1-fa13a00_2.ads fa13a00_1-fa13a00_3.ads
fa13a00_1.ads fa13b00_0.ads fa21a00.ads fb20a00.ads fb40a00.ads fc50a00.ads
fc51a00.ads fc51b00.ads fc51c00.ads fc51d00.ads fc54a00.ads fc70a00.ads
fc70b00.ads fc70c00_0.ads fc70c00_1.ads fcndecl.ads fd72a00.ads fdb0a00.ads
fdd2a00.ads fxa5a00.ads fxaca00.ads fxacb00.ads fxacc00.ads fxc6a00.ads
fxe2a00_0.ads fxe2a00_1.ads fxe2a00_2.ads fxe2a00_4.ads fxf2a00.ads fxf3a00.ads
getsubs.ads impdef-annex_d.ads impdef-annex_e.ads impdef-annex_g.ads
impdef-annex_h.ads impdef.ads length_check.ads parsemac.ads report.ads
spprt13.ads tctouch.ads -largs
--GCC="/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-3.4.5/gcc-3.4.5/gcc/xgcc
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-3.4.5/gcc-3.4.5/gcc/"
/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-3.4.5/gcc-3.4.5/gcc/xgcc -c
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-3.4.5/gcc-3.4.5/gcc/
-gnatws -gnato -gnatE defs.ads
/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-3.4.5/gcc-3.4.5/gcc/xgcc -c
-B/SCRATCH/gcc-build/HP-UX/hppa2.0w-hp-hpux11.00/gcc-3.4.5/gcc-3.4.5/gcc/
-gnatws -gnato -gnatE enum_check.ads
cannot generate code for file enum_check.ads (package spec)
to check package spec for errors, use -gnatc
gnatmake: "enum_check.ads" compilation error

I see this on all branches and all targets I have. Which are i686-pc-linux-gnu,
ia64-unknown-linux-gnu, x86_64-unknown-linux-gnu, hppa2.0w-hp-hpux11.00 and
mips-sgi-irix6.5.

I'm wondering if this affects the testsuite in any way.

Any idea?

Rainer

-- 
Rainer Emrich
TECOSIM GmbH
Im Eichsfeld 3
65428 Rüsselsheim

Phone: +49(0)6142/8272 12
Mobile: +49(0)163/56 949 20
Fax.:   +49(0)6142/8272 49
Web: www.tecosim.com

gcc 4.0.2 - Nortel VPN client - Suse 10.0

[Jens-Olaf Beismann]

Dear all,

I used to work with the Nortel Contivity VPN client (3.3) under Suse9.0 
for quite some time. The client had been built using the standard gcc 
included in that Suse distribution (3.3.6?).


Recently I've changed to Suse10.0 which now has gcc 4.0.2, and I'm not 
able to compile my VPN client anymore:


make all
cd src && make all
make[1]: Entering directory `/usr/local/cvc_linux-suse-gcc3-3.3/src'
cd k2.6 && make
make[2]: Entering directory `/usr/local/cvc_linux-suse-gcc3-3.3/src/k2.6'
make -C /lib/modules/2.6.13-15.7-default/build 
SUBDIRS=/usr/local/cvc_linux-suse-gcc3-3.3/src/k2.6 modules

make[3]: Entering directory `/usr/src/linux-2.6.13-15.7-obj/i386/default'
make -C ../../../linux-2.6.13-15.7 
O=../linux-2.6.13-15.7-obj/i386/default modules

CC [M] /usr/local/cvc_linux-suse-gcc3-3.3/src/k2.6/linux_wrapper.o
/usr/local/cvc_linux-suse-gcc3-3.3/src/k2.6/linux_wrapper.c: In Funktion 
»register_nl_netfilter«:
/usr/local/cvc_linux-suse-gcc3-3.3/src/k2.6/linux_wrapper.c:194: error: 
implicit declaration of function `nl_nf_register_hook'
/usr/local/cvc_linux-suse-gcc3-3.3/src/k2.6/linux_wrapper.c: In Funktion 
»nl_skb_dup«:
/usr/local/cvc_linux-suse-gcc3-3.3/src/k2.6/linux_wrapper.c:527: error: 
structure has no member named `security'
/usr/local/cvc_linux-suse-gcc3-3.3/src/k2.6/linux_wrapper.c:527: error: 
structure has no member named `security'
/usr/local/cvc_linux-suse-gcc3-3.3/src/k2.6/linux_wrapper.c: In Funktion 
»nlshim_init«:
/usr/local/cvc_linux-suse-gcc3-3.3/src/k2.6/linux_wrapper.c:662: error: 
implicit declaration of function `mishim_init'
/usr/local/cvc_linux-suse-gcc3-3.3/src/k2.6/linux_wrapper.c: In Funktion 
»nlshim_exit«:
/usr/local/cvc_linux-suse-gcc3-3.3/src/k2.6/linux_wrapper.c:667: error: 
implicit declaration of function `mishim_uninit'


I've tried it also with a re-installed gcc 3.3.6, but the error messages 
remain the same. I'd very much appreciate any hint to solve this problem.


Thank you very much & best regards,

Re: acats testsuite, "enum_check.ads" compilation error

[Arnaud Charlet]

> I'm wondering if this affects the testsuite in any way.

No, that's expected. The script is simply compiling all .ads and then all
.adb files without worrying whether .ads files should actually be compiled
or not.

Arno

Re: question about pic and relocation

[Daniel Jacobowitz]

On Thu, Feb 23, 2006 at 01:51:08PM +0800, Eric Fisher wrote:
> But flag '-shared' and '-fpic' are used to create shared object,
> aren't they? When I use objdump to see the codes, I find that the
> program address doesn't start from 0. Such as,

On MIPS, it happens that shared libraries are linked as 0x5ffe
or thereabouts.  It's historical.

> Why? And the symble 'b' is of absolute type(*A*)?

I don't know; not enough information.


-- 
Daniel Jacobowitz
CodeSourcery

Re: gcc 4.0.2 - Nortel VPN client - Suse 10.0

[Richard Guenther]

On 2/23/06, Jens-Olaf Beismann <[EMAIL PROTECTED]> wrote:
> Dear all,
>
> I used to work with the Nortel Contivity VPN client (3.3) under Suse9.0
> for quite some time. The client had been built using the standard gcc
> included in that Suse distribution (3.3.6?).
>
> Recently I've changed to Suse10.0 which now has gcc 4.0.2, and I'm not
> able to compile my VPN client anymore:

This looks more like a kernel issue.  Try getting flames from
linux-kernel@vger.kernel.org instead.

Richard.

Re: GCC 4.1.0 RC1

[Rainer Emrich]

Jim Wilson schrieb:
> Rainer Emrich wrote:
>> /SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin/ld:
>> unrecognized
>> option '-Wl,-rpath'
> 
> This looks like PR 21206.  See my explanation at the end.  I see this on
> some of our FreeBSD machines, but I've never seen it on an IA-64 linux
> machine.

The config.log in libjava has two entries for libiconv:
LIBICONV
which is
LIBICONV='/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib/libiconv.so
-Wl,-rpath -Wl,/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib'
in my case.

The second is
LTLIBICONV
which is
LTLIBICONV='-L/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib -liconv
-R/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib'
in my case.

I changed the libgcj.spec file manually to the second. That seems to work.
So, my conclusion is to change the libgcj.spec.in.
The following line:
*lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@
%(libgcc) %(liborig)
 should be changed to
*lib: -lgcj -lm @LTLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@
%(libgcc) %(liborig)

Any comments?

Rainer

P.S.: In the mean time I try to do a complete bootstrap and testsuite run

-- 
Rainer Emrich
TECOSIM GmbH
Im Eichsfeld 3
65428 Rüsselsheim

Phone: +49(0)6142/8272 12
Mobile: +49(0)163/56 949 20
Fax.:   +49(0)6142/8272 49
Web: www.tecosim.com

Re: question about pic and relocation

[Richard Sandiford]

"Eric Fisher" <[EMAIL PROTECTED]> writes:
> $ mips-elf-gcc -shared -fpic fun.c -o fun.so -save-temps
>
> We can see this below from fun.s,
> lw  $2,%gp_rel(b)($28)
>
> I think symble 'b' should be of GOT relocation.
> But it isn't.

What platform are you targetting?

mips-elf does not support shared libraries out of the box.
You can compile individual PIC objects using "mips-elf-gcc -mabicalls"
(which implies "-fpic", you don't need to add "-fpic" as well).  However,
the libraries built by mips-elf configurations, such as libgcc, are not
PIC, so you won't be able to link PIC code against them.  You should
really use a target that creates PIC by default, in the same way as
mips-linux-gnu and mips-sgi-irix* do.

Richard

Re: [Bug target/21206] gcj seems not to pass the option to ld correctly

[Rainer Emrich]

Andrew Haley schrieb:
> Rainer Emrich writes:
>  > -BEGIN PGP SIGNED MESSAGE-
>  > Hash: SHA1
>  > 
>  > Andrew Haley schrieb:
>  > > Rainer Emrich writes:
>  > >  > The config.log in libjava has two entries for libiconv:
>  > >  > LIBICONV
>  > >  > which is
>  > >  > 
> LIBICONV='/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib/libiconv.so
>  > >  > -Wl,-rpath -Wl,/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib'
>  > >  > in my case.
>  > >  > 
>  > >  > The second is
>  > >  > LTLIBICONV
>  > >  > which is
>  > >  > LTLIBICONV='-L/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib 
> -liconv
>  > >  > -R/appl/shared/gnu/Linux/ia64-unknown-linux-gnu/lib'
>  > >  > in my case.
>  > >  > 
>  > >  > I changed the libgcj.spec file manually to the second. That seems to 
> work.
>  > >  > So, my conclusion is to change the libgcj.spec.in.
>  > >  > The following line:
>  > >  > *lib: -lgcj -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ 
> @SYSTEMSPEC@
>  > >  > %(libgcc) %(liborig)
>  > >  >  should be changed to
>  > >  > *lib: -lgcj -lm @LTLIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ 
> @SYSTEMSPEC@
>  > >  > %(libgcc) %(liborig)
>  > >  > 
>  > >  > Any comments?
>  > > 
>  > > Looks right to me.  BTW, what failure caused you to find this?
> 
>  > See the following messages:
>  > 
>  > http://gcc.gnu.org/ml/gcc/2006-02/msg00415.html
>  > http://gcc.gnu.org/ml/gcc/2006-02/msg00482.html
> 
> Yes, I agree with your reasoning.  AFAIK Mark Mitchell has to approve
> this as it's for the release, but it's OK by me if it passes
> bootstrap.
> 
> I don't see this problem on my system because LIBICONV and LTLIBICONV
> are both null.  AFAIK that's because iconv is in libc.
> 
> Andrew.

Bootstrap passed at my site for ia64-unknown-linux-gnu.
Testsuite run for libjaava gives:

=== libjava Summary ===

# of expected passes4009
# of unexpected failures1
# of expected failures  10
# of untested testcases 8

Rainer

-- 
Rainer Emrich
TECOSIM GmbH
Im Eichsfeld 3
65428 Rüsselsheim

Phone: +49(0)6142/8272 12
Mobile: +49(0)163/56 949 20
Fax.:   +49(0)6142/8272 49
Web: www.tecosim.com

x86 -ffast-math problem on SPEC CPU 2K

[H. J. Lu]

When I use -O2 -mtune=pentium4 -ffast-math on SPEC CPU 2K on Linux/x86
with gcc 4.2, I get

*** Miscompare of 200.s, see
/export/spec/src/2000/spec/benchspec/CINT2000/176.gcc/run/0004/200.s.mis
*** Miscompare of scilab.s, see
/export/spec/src/2000/spec/benchspec/CINT2000/176.gcc/run/0004/scilab.s.mis

Is that a known issue?


H.J.

Re: GCC 4.1.0 RC1

[Bob Wilson]

I ran the testsuite for an xtensa-elf target and it looks OK:

http://gcc.gnu.org/ml/gcc-testresults/2006-02/msg01243.html

There are a few failures but they are not regressions.

--Bob

BIT_FIELD_REF considered harmful

[Ian Lance Taylor]

Currently, when we see code that compares a bitfield to a constant, in
some cases we will turn the bitfield from a COMPONENT_REF into a
BIT_FIELD_REF.  For example, this test case is based on PR 22563:

struct s
{
  int a : 3;
};

struct s g;

int
foo ()
{
  g.a = 2;
  return g.a != 2;
}

In .003t.original, this looks like this:

{
  g.a = 2;
  return (BIT_FIELD_REF  & 7) != 2;
}

In other workds, the comparison in the second line becomes a
BIT_FIELD_REF rather than a COMPONENT_REF.  This happens in
fold_binary, at the very start of the compilation process.  Because it
is a BIT_FIELD_REF, the tree optimizers never notice that the code is
looking at the value that was just set.  And the RTL optimizers never
notice either.  And so we wind up generating this (-O2
-momit-leaf-frame-pointer):

foo:
movlg, %eax
andl$-8, %eax
orl $2, %eax
movl%eax, g
movzbl  g, %eax
andl$7, %eax
cmpb$2, %al
setne   %al
movzbl  %al, %eax
ret

With a trivial patch to make optimize_bit_field_compare do nothing, we
get this:

.003t.original:

{
  g.a = 2;
  return g.a != 2;
}

foo:
movlg, %eax
andl$-8, %eax
orl $2, %eax
movl%eax, g
xorl%eax, %eax
ret

Now, this is obviously a contrived example.  But, in general, we do
not optimize BIT_FIELD_REF in the tree optimizers.  Whereas we do
optimize COMPONENT_REF.  The only advantage I can see of generating
BIT_FIELD_REF early is that we will pick it up in PRE.  But of course
we also have RTL level CSE/PRE.

I think it is likely to be appropriate to move the optimizations in
fold-const.c which generate BIT_FIELD_REF to occur just before we
convert to RTL, rather than applying them at the start.

Any thoughts on whether this is a good idea?

Ian

Re: BIT_FIELD_REF considered harmful

[Diego Novillo]

Ian Lance Taylor wrote:

> Any thoughts on whether this is a good idea?
> 
I agree.  Long ago I had a similar situation with CCP not being able to
do some trivial propagation because a variable of an enum type was being
accessed with BIT_FIELD_REFs hiding the real values.  I will try to find
my message.

Anything that hides things from the optimizers is inherently bad.

Re: x86 -ffast-math problem on SPEC CPU 2K

[Dale Johannesen]

On Feb 23, 2006, at 8:54 AM, H. J. Lu wrote:


When I use -O2 -mtune=pentium4 -ffast-math on SPEC CPU 2K on Linux/x86
with gcc 4.2, I get

*** Miscompare of 200.s, see
/export/spec/src/2000/spec/benchspec/CINT2000/176.gcc/run/0004/ 
200.s.mis

*** Miscompare of scilab.s, see
/export/spec/src/2000/spec/benchspec/CINT2000/176.gcc/run/0004/ 
scilab.s.mis


Is that a known issue?


This is what you get if the benchmark source thinks the host is of the  
wrong endianness.

Do you have -DHOST_WORDS_BIG_ENDIAN in your config file perhaps?

Re: x86 -ffast-math problem on SPEC CPU 2K

[H. J. Lu]

On Thu, Feb 23, 2006 at 11:00:33AM -0800, Dale Johannesen wrote:
> 
> On Feb 23, 2006, at 8:54 AM, H. J. Lu wrote:
> 
> >When I use -O2 -mtune=pentium4 -ffast-math on SPEC CPU 2K on Linux/x86
> >with gcc 4.2, I get
> >
> >*** Miscompare of 200.s, see
> >/export/spec/src/2000/spec/benchspec/CINT2000/176.gcc/run/0004/ 
> >200.s.mis
> >*** Miscompare of scilab.s, see
> >/export/spec/src/2000/spec/benchspec/CINT2000/176.gcc/run/0004/ 
> >scilab.s.mis
> >
> >Is that a known issue?
> 
> This is what you get if the benchmark source thinks the host is of the  
> wrong endianness.
> Do you have -DHOST_WORDS_BIG_ENDIAN in your config file perhaps?

No.

BTW, "-O2 -mtune=pentium4" generates correct results for SPEC CPU 2K.
The only difference is -ffast-math.


H.J.

Re: bug with -O2 in g++ Debian 4.0.2-9 ?

[Mike Stump]

On Feb 23, 2006, at 5:46 AM, Digvijoy Chatterjee wrote:

What is PR323 ,is it some page in the manual /or gcc info ?


http://gcc.gnu.org/PR323

Re: Bootstrap failure on trunk: x86_64-linux-gnu

[Richard Henderson]

On Wed, Feb 22, 2006 at 10:06:25AM -0700, Jeffrey A Law wrote:
> > > This does highlight one of the issues that keeps nagging at me.
> > > For an enumeration type, presumably we have TYPE_PRECISION set to
> > > the minimum precision necessary to hold all the values in the enum.
> > > What are TYPE_MIN_VAL/TYPE_MAX_VAL?Does TYPE_MAX_VALUE include
> > > values outside the enum, but which are included by the TYPE_PRECISION?
> > 
> > In C++, there are no such values.  In C++, the range of the type gets
> > rounded up to a power of two, so for:
> Great.  That's what I expected to hear.  Hopefully the C 
> front end does something similar.

The C front end correctly copies the min, max, and precision
from the base type.

The C90 language doesn't have the clauses that C++ does that
allows for the narrowed precision.  I think one can construe
that in C99, with extended integral types, but there's not so
much to be gained that it's worth being incompatible with C90.


r~

Re: borken link !

[Gerald Pfeifer]

On Tue, 21 Feb 2006, Boris Pereira wrote:
> this link to
> http://gcc.gnu.org/install/build.html
> 
> in page
> http://gcc.gnu.org/install/

Thanks for the report, this has been fixed now.  (Thanks, Joseph et al!)

Gerald

gcc-4.0-20060223 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch 
revision 111398

You'll find:

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

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

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

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

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

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

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

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

Diffs from 4.0-20060216 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.

GCC 4.1 Status Report (2006-02-23)

[Mark Mitchell]

Thus far, the feedback for GCC 4.1 RC1 seems very positive.  There have
been very few problems reported, and none that look to me to be fatal flaws.

I plan to make a pass over the open regressions, looking for
showstoppers.  At this point, my inclination is to apply a very limited
number of already submitted changes, spin RC2, and declare that
all-but-final.  However, I am not fully committed to this plan; I might
still decide that RC1 is good enough.

Therefore, if you have any strong feelings on this topic, now would be a
good time to speak up!

Thanks,

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

Re: Ada subtypes and base types

[Jeffrey A Law]

On Wed, 2006-02-22 at 13:25 -0500, Richard Kenner wrote:
>  When I speak about doing arithmetic in a type, I'm referring to the
>  type of the expression & its input operands in a gimplified
>  expression.  At that point I do not care about base types or anything
>  like that.  All that should matter is TREE_TYPE (expr), nothing more,
>  nothing less.  How the inputs are converted or how the output is later
>  converted is not a concern -- all that matters is TREE_TYPE (expr) in
>  a gimplified tree.
> 
>  Can we agree on that?
> 
> Yes.
> 
> The base type reference is that I'm *also* saying "If you see an arithmetic
> node where TREE_TYPE is *not* a base type, there's a bug someplace that
> has to be fixed". (Well, with the exception of such things as sizetypes
> or subtypes that don't actually change anything.)
Just to make sure I've dotted the i's and crossed the t's, this
is not what's happening when we hang in VRP when compiling a-textio.

We convert the incoming object from natural___XDLU_0___2147483647
into its base type, perform the addition in the base type, then
convert back to XDLU_0_2147483647.

Jeff

Solaris/x86 namespace bug?

[Frank Cusack]

I found this when building doxygen.  Found a simple test case on the web:


$ cat ll.cc
#include 
int CS;
$ g++ ll.cc
ll.cc:2: error: expected unqualified-id before numeric constant

It works correctly on Solaris/sparc.  My system is amd64, using the
Sun gcc.  /usr/include/sys/regset.h #define's CS on x86/amd64 only ...
hence the brokenness.  A comment there says "The names and offsets
defined here are specified by i386 ABI suppl.".  So my question is,
should these be in a namespace, or is code that uses these various
register names as symbols broken.

I couldn't find any mentions of this kind of error on non-Solaris
machines, but I don't think that points to an answer either way.

thanks
-frank

confused by mips target

[Eric Fisher]

Hi,
I'm really confused by mips targets, such as mips-elf, mips-linux,
mips-elf-linux, mips-elf-linux-gnu. I will appreciate if anyone can
tell me the difference between them.

Thanks.
Eric.

Re: confused by mips target

[Eric Christopher]

On Feb 23, 2006, at 5:27 PM, Eric Fisher wrote:


Hi,
I'm really confused by mips targets, such as mips-elf, mips-linux,
mips-elf-linux, mips-elf-linux-gnu. I will appreciate if anyone can
tell me the difference between them.


The last two don't exist.

The first one is to target an elf-based embedded system. The second  
is for a mips-linux (mips-linux-gnu) box.


-eric

Re: IVOPTS vs Ada subtypes and base types

[Jeffrey A Law]

On Wed, 2006-02-22 at 13:25 -0500, Richard Kenner wrote:
>  When I speak about doing arithmetic in a type, I'm referring to the
>  type of the expression & its input operands in a gimplified
>  expression.  At that point I do not care about base types or anything
>  like that.  All that should matter is TREE_TYPE (expr), nothing more,
>  nothing less.  How the inputs are converted or how the output is later
>  converted is not a concern -- all that matters is TREE_TYPE (expr) in
>  a gimplified tree.
> 
>  Can we agree on that?
> 
> Yes.
> 
> The base type reference is that I'm *also* saying "If you see an arithmetic
> node where TREE_TYPE is *not* a base type, there's a bug someplace that
> has to be fixed". (Well, with the exception of such things as sizetypes
> or subtypes that don't actually change anything.)
Scratch my last message (February *really* isn't my month).

A day away and I had forgotten that there are two hunks of code
which effectively do the same thing (due to early jump threading)
I was looking at the first hunk when I came to the conclusion
that we were doing all the arithmetic in the base type.

It turns out that IVOPTS mucks up the second hunk of code and
removes all the conversions into the base type!  GR

Before IVOPTS we have:

  # BLOCK 5 freq:8574
  # PRED: 8 [95.0%]  (false,exec)
:;
  last.70_35 = (integer) last_22;
  D.2061_36 = last.70_35 + 1;
  last_37 = (natural___XDLU_0__2147483647) D.2061_36;
  last.70_40 = (integer) last_37;
  last.71_41 = () last.70_40;
  D.2065_42 = (character) D.2066_44;
  #   TMT.422_55 = V_MAY_DEF ;
  VIEW_CONVERT_EXPR(*item
$P_ARRAY_1)[last.71_41]{lb: D.2041_6 sz: 1} = D.2065_42;
  if (D.2043_9 == last.70_40) goto ; else goto ;
  # SUCC: 6 [5.0%]  (loop_exit,true,exec) 7 [95.0%]
(dfs_back,false,exec)


Which looks like exactly what we want.  We convert last_22 into the
base type and store the result in last.70_35.  We then perform our
arithmetic storing the result into D.2061_36.  Then we convert the
result back into the original type, storing the result in last_37.

After IVOPTS we have:

  # BLOCK 5 freq:8574
  # PRED: 8 [95.0%]  (false,exec)
:;
  last_32 = last_22 + 1;
  last_37 = last_32;
  D.2065_42 = (character) D.2066_44;
  D.2988_38 = (character *) ivtmp.449_5;
  #   TMT.422_55 = V_MAY_DEF ;
  MEM[base: D.2988_38, offset:
1B]{VIEW_CONVERT_EXPR(*item
$P_ARRAY)[last.71]{lb: D.2041 sz: 1}} = D.2065_42;
  ivtmp.449_46 = ivtmp.449_5 + 1B;
  D.2989_43 = (natural___XDLU_0__2147483647) D.2041_6;
  D.2990_45 = (unsigned int) D.2043_9;
  D.2991_33 = (unsigned int) D.2041_6;
  D.2992_18 = D.2990_45 - D.2991_33;
  D.2993_17 = (natural___XDLU_0__2147483647) D.2992_18;
  D.2994_16 = D.2989_43 + D.2993_17;
  if (last_37 == D.2994_16) goto ; else goto ;
  # SUCC: 6 [5.0%]  (loop_exit,true,exec) 7 [95.0%]
(dfs_back,false,exec)

Note how the conversions have been lost.

Unfortuantely IVOPTS is a black box to me.

Zdenek, can you help here?

Jeff

Re: 4.1rc1 cross Ada build issue

[Mark Mitchell]

Paolo Bonzini wrote:

> Yes, http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00342.html was not
> applied on the branch.  It only affects Ada so it shuld be safe.

Yes.  Do you have a revision number handy?

Thanks,

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

GCC 4.1 RC2

[Mark Mitchell]

I will spin GCC 4.1 RC2 tonight.

The only patch I plan to apply, relative to current sources, is Paolo
Bonzini's Ada patch.

GCC 4.1 RC2 will become the final GCC 4.1.0 release within a few days,
unless disaster occurs.

Thanks,

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

Re: Solaris/x86 namespace bug?

[Mike Stump]

On Feb 23, 2006, at 5:03 PM, Frank Cusack wrote:

#include 
int CS;
$ g++ ll.cc
ll.cc:2: error: expected unqualified-id before numeric constant

It works correctly on Solaris/sparc.  My system is amd64, using the
Sun gcc.  /usr/include/sys/regset.h #define's CS on x86/amd64 only ...
hence the brokenness.


Sounds like generic namespace pollution.  Anyway, this isn't a gcc  
issue, but a doxygen/Solaris issue, well, unless we want to  
fixincludes it, which I don't think we can.

canon_modify_mem_list in gcse.c

[Daniel Berlin]

(steven, you spent a fair amount of time in gcse.c, which is why i've
copied you to see if you knew what was up)

In record_mem_last_set_info, we have

if (CALL_P (insn))
{
  /* Note that traversals of this loop (other than for free-ing)
 will break after encountering a CALL_INSN.  So, there's no
 need to insert a pair of items, as canon_list_insert does.  */
  canon_modify_mem_list[bb] =
alloc_INSN_LIST (insn, canon_modify_mem_list[bb]);
  bitmap_set_bit (blocks_with_calls, bb);
}




The *only* traversal of canon_modify_mem_list that isn't freeing now
looks like this:

  /* First handle all the blocks with calls.  We don't need to
 do any list walking for them.  */
  EXECUTE_IF_SET_IN_BITMAP (blocks_with_calls, 0, bb_index, bi)
{
  if (set_p)
SET_BIT (bmap[bb_index], indx);
  else
RESET_BIT (bmap[bb_index], indx);
}

/* Now iterate over the blocks which have memory
modifications
   but which do not have any calls.  */
EXECUTE_IF_AND_COMPL_IN_BITMAP (modify_mem_list_set,
blocks_with_calls,
0, bb_index, bi)
  {
rtx list_entry = canon_modify_mem_list[bb_index];


Note that it won't iterate over any blocks that have calls anymore.



1. Why are we bothering to allocate anything in the lists for basic
blocks with calls in them, at all, if we aren't going to ever walk them?

Seems like a waste of time and space

The second we see a call, we could just blow away the
canon_modify_mem_list for that block, mark the block as having a call,
and go about our way, instead of continuing to put both calls, and
memory instructions on the list.

2. ISTM we could probably handle blocks with pure and const calls, if we
really wanted to.

Re: do -fprofile-arcs and -fbranch-probabilities help to set bb->count?

[Liu Haibin]

I did a testing on a normal PC and it worked. Thanks.

However, I'm using gcc nios2 port. The executable file is downloaded
to a board, which is attached to my PC. So while the executable file
is running on the board, it doesn't produce any gcda file.

According to Altera nios2 people, I can do some configuration, so that
the executable will be able to output to Host PC through normal fputs
or fwrite.

So is it feasible that I can make executable to output gcda file to my
Host PC via fputs or fwrite?


Regards,
Haibin



On 2/21/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
> Liu Haibin wrote:
> > Hi,
> >
> > I wanted to use bb->count, so I expected that -fprofile-arcs and
> > -fbranch-probabilities would help. I added printf just before
> > peephole2 optimization and ran the following.
> >
> > $gcc -O3 -fprofile-arcs test.c -o test
> > $./test (which produced test.gcno only, but no test.gcda)
> > $gcc -O3 -fprofile-arcs -fbranch-probabilities test.c -o test
>
> Easier to use -fprofile-generate and -fprofile-use:
>
> gcc -O3 -fprofile-generate test.c -o test (produces test.gcno)
> ./test (now should have as well test.gcda)
> gcc -O3 -fprofile-use test.c -o test
>
> Paolo
>

Disabling pch checking?

[Dan Kegel]

gcc-4.1-rc1 seems nice so far - it's the first version of gcc
that can beat gcc-2.95.3 on one particular app -
but it seems to be slow at preprocessing C++ source.
This matters quite a bit when running distcc.
In fact, it seems to take three times as long to
build large C++ apps as gcc-2.95.3 did.
(Your milage may vary.)

The app I measured this on has a rather large number of -I
options, so there are lots and lots of stat calls
looking for .h files, and lots and lots of stat calls looking
for precompiled headers.   We plan to get rid of most of
the -I flags, but in the meantime, it'd be nice to be able to
disable the stat for the pch (since we know we aren't using pch at all).
Is there an option to do that?  I couldn't see one in a quick scan.
- Dan


--
Wine for Windows ISVs: http://kegel.com/wine/isv

Re: do -fprofile-arcs and -fbranch-probabilities help to set bb->count?

[Ben Elliston]

> So is it feasible that I can make executable to output gcda file to
> my Host PC via fputs or fwrite?

Yes, but this requires a suitable board support package that can
divert I/O on your target board back to the host.

Ben

Re: GCC 4.1 RC2

[Paolo Bonzini]

Mark Mitchell wrote:

I will spin GCC 4.1 RC2 tonight.

The only patch I plan to apply, relative to current sources, is Paolo
Bonzini's Ada patch.


... which is revision 108058.  I gather that you want to apply it yourself?

r108058 | bonzini | 2005-12-05 15:40:27 +0100 (Mon, 05 Dec 2005)

libada:
2005-12-05  Paolo Bonzini  <[EMAIL PROTECTED]>

* Makefile.in (FLAGS_TO_PASS): Add GCC_FOR_TARGET.

gcc/ada:
2005-12-05  Paolo Bonzini  <[EMAIL PROTECTED]>

* Makefile.in (gnatlib): Fix regex, using \. instead of . when
a period is meant.

Paolo

Re: do -fprofile-arcs and -fbranch-probabilities help to set bb->count?

[Paolo Bonzini]

So is it feasible that I can make executable to output gcda file to my
Host PC via fputs or fwrite?


Sure.  The easiest way is to run the program under a functional 
simulator of the nios2, that can map system calls from the C library to 
I/O on the target board.  The Altera people probably know best.


Paolo