Define __NO_MATH_INLINES for x86 -ffast-math?

[Uros Bizjak]

Hello!

I have tripped over a problem, where #defines from libc
(bits/mathinline.h) interfere badly with gcc's intrinsics.

The problem (note the #include):

--cut here--
#include 

double test (double x)
{
  return ceil(x);
}
--cut here--

when compiled with -O2 -ffast-math -msse2 -mfpmath=sse, compiles to
asm that involves x87 insns from mathinline.h. Adding
-D__NO_MATH_INLINES compiles to expected SSE code.

As recent gcc implements all libc math intrinsics as its own builtin
intrinsics, and due to the above interference, I'd like to propose
that gcc defines __NO_MATH_INLINES on x86_32 target for -ffast-math,
for both -mfpmath=sse and -mfpmath=x87.

Uros.

Re: Define __NO_MATH_INLINES for x86 -ffast-math?

[Richard Guenther]

On 9/17/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> Hello!
>
> I have tripped over a problem, where #defines from libc
> (bits/mathinline.h) interfere badly with gcc's intrinsics.
>
> The problem (note the #include):
>
> --cut here--
> #include 
>
> double test (double x)
> {
>   return ceil(x);
> }
> --cut here--
>
> when compiled with -O2 -ffast-math -msse2 -mfpmath=sse, compiles to
> asm that involves x87 insns from mathinline.h. Adding
> -D__NO_MATH_INLINES compiles to expected SSE code.
>
> As recent gcc implements all libc math intrinsics as its own builtin
> intrinsics, and due to the above interference, I'd like to propose
> that gcc defines __NO_MATH_INLINES on x86_32 target for -ffast-math,
> for both -mfpmath=sse and -mfpmath=x87.

This "problem" has come up before and instead of gcc glibc should be fixed.
Do we make glibc aware of the user specifying -mfpmath=sse somehow?

Richard.

Re: Define __NO_MATH_INLINES for x86 -ffast-math?

[Jan Hubicka]

> On 9/17/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> > Hello!
> >
> > I have tripped over a problem, where #defines from libc
> > (bits/mathinline.h) interfere badly with gcc's intrinsics.
> >
> > The problem (note the #include):
> >
> > --cut here--
> > #include 
> >
> > double test (double x)
> > {
> >   return ceil(x);
> > }
> > --cut here--
> >
> > when compiled with -O2 -ffast-math -msse2 -mfpmath=sse, compiles to
> > asm that involves x87 insns from mathinline.h. Adding
> > -D__NO_MATH_INLINES compiles to expected SSE code.
> >
> > As recent gcc implements all libc math intrinsics as its own builtin
> > intrinsics, and due to the above interference, I'd like to propose
> > that gcc defines __NO_MATH_INLINES on x86_32 target for -ffast-math,
> > for both -mfpmath=sse and -mfpmath=x87.
> 
> This "problem" has come up before and instead of gcc glibc should be fixed.
> Do we make glibc aware of the user specifying -mfpmath=sse somehow?

If we really implement all of glibc logic, I think we should just teach
glibc header to disable itself based on GCC version, I don't think this
should be handled on GCC side. 

We already define __SSE_MATH__ and __SSE2_MATH__

Honza
> 
> Richard.

Online Job Representative Staff

[Kimcham Fatu]

Dear Employee,

 We needs a representative in United Kingdom  to act as our Online Staff 
through which our customers can pay outstanding bills owed by them to us in 
your Region 

We are looking only for the Honest and Open – Hearted Individual whosatisfies 
our requirements and glad to offer this job position to you.If our proposals 
interest you, Do get to Our Recruiter Manager on (
 [EMAIL PROTECTED] )  For More Information. 

Thanks for Reading Our Job Offer.

My Regards,
Kimcham Fatu ( Recruiting Manager ) 
Kimcham Fatu for Gallery Art ltd.
B.21/F., Jianjing Building,
1399 Beijing Rd W,
Shanghai Shanghai-200040 China.
TEL: 817-776-5550
FAX: 817-776-5550 

(c) Copyright Reserved 2007

Online Job Representative Staff

[Kimcham Fatu]

Dear Employee,

 We needs a representative in United Kingdom  to act as our Online Staff 
through which our customers can pay outstanding bills owed by them to us in 
your Region 

We are looking only for the Honest and Open – Hearted Individual whosatisfies 
our requirements and glad to offer this job position to you.If our proposals 
interest you, Do get to Our Recruiter Manager on (
 [EMAIL PROTECTED] )  For More Information. 

Thanks for Reading Our Job Offer.

My Regards,
Kimcham Fatu ( Recruiting Manager ) 
Kimcham Fatu for Gallery Art ltd.
B.21/F., Jianjing Building,
1399 Beijing Rd W,
Shanghai Shanghai-200040 China.
TEL: 817-776-5550
FAX: 817-776-5550 

(c) Copyright Reserved 2007

Ada rts fails to build on ppc64?

[Richard Guenther]

On trunk I get

/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/xgcc 
-B/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/ 
-B/usr/powerpc64-suse-linux/bin/ -B/usr/powerpc64-suse-linux/lib/ -isystem 
/usr/powerpc64-suse-linux/include -isystem 
/usr/powerpc64-suse-linux/sys-include -c -g -O2 -fPIC -mno-minimal-toc  
-W -Wall -gnatpg  a-direct.adb -o a-direct.o
 a-direct.adb:661:13: 
warning: types for unchecked conversion have different sizes
make[7]: *** [a-direct.o] Error 1
make[7]: Leaving directory 
`/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/gcc/ada/rts'
make[6]: *** [gnatlib] Error 2
make[6]: Leaving directory 
`/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/gcc/ada'
make[5]: *** [gnatlib-shared-default] Error 2
make[5]: Leaving directory 
`/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/gcc/ada'
make[4]: *** [gnatlib-shared-dual] Error 2
make[4]: Leaving directory 
`/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/gcc/ada'
make[3]: *** [gnatlib-shared] Error 2
make[3]: Leaving directory 
`/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/gcc/ada'
make[2]: *** [gnatlib-shared] Error 2
make[2]: Leaving directory 
`/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/powerpc64-suse-linux/libada'
make[1]: *** [all-target-libada] Error 2

does it now try to build a multilib for libada?

Richard.

Re: Ada rts fails to build on ppc?

[Richard Guenther]

On Mon, 17 Sep 2007, Richard Guenther wrote:

It's actually powerpc configured like

../configure --with-cpu=default32 --build=powerpc64-suse-linux
checking build system type... powerpc64-suse-linux-gnu
checking host system type... powerpc64-suse-linux-gnu
checking target system type... powerpc64-suse-linux-gnu

> On trunk I get
> 
> /usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/xgcc
>  
> -B/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/ 
> -B/usr/powerpc64-suse-linux/bin/ -B/usr/powerpc64-suse-linux/lib/ -isystem 
> /usr/powerpc64-suse-linux/include -isystem 
> /usr/powerpc64-suse-linux/sys-include -c -g -O2 -fPIC -mno-minimal-toc  
> -W -Wall -gnatpg  a-direct.adb -o a-direct.o
>  a-direct.adb:661:13: 
> warning: types for unchecked conversion have different sizes
> make[7]: *** [a-direct.o] Error 1
> make[7]: Leaving directory 
> `/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/gcc/ada/rts'
> make[6]: *** [gnatlib] Error 2
> make[6]: Leaving directory 
> `/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/gcc/ada'
> make[5]: *** [gnatlib-shared-default] Error 2
> make[5]: Leaving directory 
> `/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/gcc/ada'
> make[4]: *** [gnatlib-shared-dual] Error 2
> make[4]: Leaving directory 
> `/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/gcc/ada'
> make[3]: *** [gnatlib-shared] Error 2
> make[3]: Leaving directory 
> `/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/gcc/ada'
> make[2]: *** [gnatlib-shared] Error 2
> make[2]: Leaving directory 
> `/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/powerpc64-suse-linux/libada'
> make[1]: *** [all-target-libada] Error 2
> 
> does it now try to build a multilib for libada?
> 
> Richard.
> 

-- 
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: Coding conventions -- command line option vs command-line option

[Joseph S. Myers]

On Mon, 17 Sep 2007, Gerald Pfeifer wrote:

> And now to the most important issue of all to address before we can
> release GCC 4.3.0. ;-)
> 
> In our current documentation we have both "command-line option" and
> "command line option".  Like other such cases, we should make a choice
> and document this in codingconventions.html.
> 
> I am willing to take care of that, and also adjusting our web pages 
> accordingly.  The question now is: which of the two variants shall we 
> go for?

As an adjective I think it should be "command-line"; I'm sure Sandra will 
correct me if I'm wrong here.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Should -ftrapv check type conversion?

[Joseph S. Myers]

On Mon, 17 Sep 2007, Ken Raeburn wrote:

> I see a few reports in Bugzilla, many marked as duplicates of PR 19020 though
> they cover a few different cases, which have me wondering about what the scope
> of -ftrapv ought to be.

See my message  
for the definition of -ftrapv as I understand it.  I think expanding to 
cover division by 0 and shift counts that are negative or too large would 
make sense, though at some point maybe users will want the option split up 
so they get traps for some operations only.

Potentially trapping operations may need to be marked at tree level as 
having side-effects to avoid them getting optimized away.  This will be 
easier when flags such as -ftrapv are represented as bits on the affected 
operations rather than only as global flag variables.

> (I'm assuming 32-bit int and 16-bit short below, for simplicity.)
> 
> 1) What about conversions to signed types?
> 
>  unsigned int x = 0x8000;
>  int y = x;   /* trap? */
> 
> You get a negative number out of this if you define the conversion as wrapping
> twos-complement style, but I believe the spec says it's undefined.  It's not

It's not undefined, it's implementation-defined, and the implementation 
duly defines it in implement-c.texi.

> 2) Conversions to narrower signed types?
> 
>  signed int x = 0xf;
>  signed short y = x;  /* trap? */
> 
> It seems to me that a trap here would be desirable, though again it's an "out
> of range" issue.  However, a logical extension of this would be to possibly

Again, implementation-defined.

> 3) What about narrower-than-int types?
> 
>  signed short a = 0x7000, b = 0x7000, c = a+b;
> 
> Technically, I believe the addends are widened to signed int before doing the
> addition, so the result of the addition is 0xe000.  If the result is assigned
> to an int variable, there's no undefined behavior.  Converting that to signed
> short would be where the overflow question comes up, so this is actually a
> special case of #2.

Yes, implementation-defined.

Out-of-range conversions to signed integer types can be 
implementation-defined to raise an implementation-defined signal as an 
alternative to returning an implementation-defined value.  We could add an 
option to do so, but I think it should be separate from -ftrapv.

> 3) Is Fortran 90 different?

My definition of the option is as language semantics for C and C-family 
languages; I can't judge what may be useful for other supported languages.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Online Job Representative Staff

[Kimcham Fatu]

Dear Employee,

 We needs a representative in United Kingdom  to act as our Online
 Staff through which our customers can pay outstanding bills owed by them to
 us in your Region 

We are looking only for the Honest and Open – Hearted Individual
 whosatisfies our requirements and glad to offer this job position to you.If
 our proposals interest you, Do get to Our Recruiter Manager on (
 [EMAIL PROTECTED] )  For More Information. 

Thanks for Reading Our Job Offer.

My Regards,
Kimcham Fatu ( Recruiting Manager ) 
Kimcham Fatu for Gallery Art ltd.
B.21/F., Jianjing Building,
1399 Beijing Rd W,
Shanghai Shanghai-200040 China.
TEL: 817-776-5550
FAX: 817-776-5550 

(c) Copyright Reserved 2007

Online Job Representative Staff

[Kimcham Fatu]

Dear Employee,

 We needs a representative in United Kingdom  to act as our Online
 Staff through which our customers can pay outstanding bills owed by them to
 us in your Region 

We are looking only for the Honest and Open – Hearted Individual
 whosatisfies our requirements and glad to offer this job position to you.If
 our proposals interest you, Do get to Our Recruiter Manager on (
 [EMAIL PROTECTED] )  For More Information. 

Thanks for Reading Our Job Offer.

My Regards,
Kimcham Fatu ( Recruiting Manager ) 
Kimcham Fatu for Gallery Art ltd.
B.21/F., Jianjing Building,
1399 Beijing Rd W,
Shanghai Shanghai-200040 China.
TEL: 817-776-5550
FAX: 817-776-5550 

(c) Copyright Reserved 2007

Re: Coding conventions -- command line option vs command-line option

[Sandra Loosemore]

Joseph S. Myers wrote:

On Mon, 17 Sep 2007, Gerald Pfeifer wrote:


And now to the most important issue of all to address before we can
release GCC 4.3.0. ;-)

In our current documentation we have both "command-line option" and
"command line option".  Like other such cases, we should make a choice
and document this in codingconventions.html.

I am willing to take care of that, and also adjusting our web pages 
accordingly.  The question now is: which of the two variants shall we 
go for?


As an adjective I think it should be "command-line"; I'm sure Sandra will 
correct me if I'm wrong here.


As an adjective immediately preceding the noun it modifies, yes, it 
should be hyphenated:  "command-line option".  But if you use "command 
line" as a noun, use the unhyphenated form; e.g., "use the -foo option 
on the command line".


-Sandra

Re: Ada rts fails to build on ppc?

[Eric Botcazou]

> It's actually powerpc configured like
>
> ../configure --with-cpu=default32 --build=powerpc64-suse-linux
> checking build system type... powerpc64-suse-linux-gnu
> checking host system type... powerpc64-suse-linux-gnu
> checking target system type... powerpc64-suse-linux-gnu

Looks like

2007-08-31  Ben Elliston  <[EMAIL PROTECTED]>

* Makefile.in (LIBGNAT_TARGET_PAIRS): Use system-linux-ppc64.ads
when compiling for powerpc64-*-linux.
* system-linux-ppc64.ads: New file.

needs to be refined.

-- 
Eric Botcazou

Re: ICE on valid code, cse related

[Rask Ingemann Lambertsen]

On Fri, Aug 17, 2007 at 06:02:06PM +0200, Rask Ingemann Lambertsen wrote:
>What happened to the experiments you described at
> http://gcc.gnu.org/ml/gcc/2004-06/msg01178.html>? Emitting a no-op move
> of the (set (reg) (reg)) form won't work, but maybe something like
> 
> (insn (use (reg) (expr_list:REG_EQUAL ...)))
> 
> would work?

   And if not, the required no-op move pattern could look like this:

(define_insn "*no-op-move"
  [(set (match_operand 0 "register_operand")
(match_dup 0))]
  "REG_P (operands[0])
   && !reload_completed"
{
  gcc_abort ();
}

   Reload will delete such an insn even at -O0.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Ada rts fails to build on ppc64?

[Andreas Schwab]

Richard Guenther <[EMAIL PROTECTED]> writes:

> On trunk I get
>
> /usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/xgcc
>  
> -B/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/ 
> -B/usr/powerpc64-suse-linux/bin/ -B/usr/powerpc64-suse-linux/lib/ -isystem 
> /usr/powerpc64-suse-linux/include -isystem 
> /usr/powerpc64-suse-linux/sys-include -c -g -O2 -fPIC -mno-minimal-toc  
> -W -Wall -gnatpg  a-direct.adb -o a-direct.o
>  a-direct.adb:661:13: 
> warning: types for unchecked conversion have different sizes

See PR33454.  Revert r127960 for a workaround.

> does it now try to build a multilib for libada?

libada still does not support multilib.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bootstrap failure on ppc64-linux: ICE in set_variable_part

[Janis Johnson]

Bootstrap of powerpc64-linux fails building libgfortran with:

/home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function 
'set_integer':
/home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c:81: internal compiler 
error: in set_variable_part, at var-tracking.c:2381
Please submit a full bug report, with preprocessed source if appropriate.
See  for instructions.

My last successful build was revision 128522; earliest known break
was 128536, still breaks with 128551.

Re: Ada rts fails to build on ppc64?

[Laurent GUERBY]

On Mon, 2007-09-17 at 17:55 +0200, Andreas Schwab wrote:
> Richard Guenther <[EMAIL PROTECTED]> writes:
> 
> > On trunk I get
> >
> > /usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/xgcc
> >  
> > -B/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/
> >  
> > -B/usr/powerpc64-suse-linux/bin/ -B/usr/powerpc64-suse-linux/lib/ -isystem 
> > /usr/powerpc64-suse-linux/include -isystem 
> > /usr/powerpc64-suse-linux/sys-include -c -g -O2 -fPIC -mno-minimal-toc  
> > -W -Wall -gnatpg  a-direct.adb -o a-direct.o
> >  a-direct.adb:661:13: 
> > warning: types for unchecked conversion have different sizes
> 
> See PR33454.  Revert r127960 for a workaround.
> 
> > does it now try to build a multilib for libada?
> 
> libada still does not support multilib.

Joel Sherrill tried something on Ada multilib support, if multilib
experts want to help here is the thread:

http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01869.html

Laurent

Re: bootstrap failure on ppc64-linux: ICE in set_variable_part

[Jakub Jelinek]

On Mon, Sep 17, 2007 at 10:50:17AM -0700, Janis Johnson wrote:
> Bootstrap of powerpc64-linux fails building libgfortran with:
> 
> /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function 
> 'set_integer':
> /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c:81: internal compiler 
> error: in set_variable_part, at var-tracking.c:2381
> Please submit a full bug report, with preprocessed source if appropriate.
> See  for instructions.
> 
> My last successful build was revision 128522; earliest known break
> was 128536, still breaks with 128551.

My guess is that this is a long standing latent bug with var-tracking
on big endian machines, we saw it a few times with gcc-4.1.x-RH as well.
The problem is that after optimizing some subregs we can have negative
offsets in MEM_OFFSET of some REG vars (e.g. when a QImode user decl
is held in the least significant bits of SImode or DImode register)
and var-tracking is very upset about that.  Haven't had time to
try to fix this though.
First of all it should be clear whether those negative MEM_OFFSETs
are ok or not in RTL.

Jakub

Re: bootstrap failure on ppc64-linux: ICE in set_variable_part

[Andrew Pinski]

On 9/17/07, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> My guess is that this is a long standing latent bug with var-tracking
> on big endian machines, we saw it a few times with gcc-4.1.x-RH as well.
> The problem is that after optimizing some subregs we can have negative
> offsets in MEM_OFFSET of some REG vars (e.g. when a QImode user decl
> is held in the least significant bits of SImode or DImode register)
> and var-tracking is very upset about that.  Haven't had time to
> try to fix this though.

I thought we fixed that issue with:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29558

Thanks,
Andrew Pinski

Re: Ada rts fails to build on ppc64?

[Joel Sherrill]

Laurent GUERBY wrote:

On Mon, 2007-09-17 at 17:55 +0200, Andreas Schwab wrote:
  

Richard Guenther <[EMAIL PROTECTED]> writes:



On trunk I get

/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/xgcc 
-B/usr/src/packages/BUILD/gcc-4.3.0-20070917/obj-powerpc64-suse-linux/./gcc/ 
-B/usr/powerpc64-suse-linux/bin/ -B/usr/powerpc64-suse-linux/lib/ -isystem 
/usr/powerpc64-suse-linux/include -isystem 
/usr/powerpc64-suse-linux/sys-include -c -g -O2 -fPIC -mno-minimal-toc  
-W -Wall -gnatpg  a-direct.adb -o a-direct.o
 a-direct.adb:661:13: 
warning: types for unchecked conversion have different sizes
  

See PR33454.  Revert r127960 for a workaround.



does it now try to build a multilib for libada?
  

libada still does not support multilib.



Joel Sherrill tried something on Ada multilib support, if multilib
experts want to help here is the thread:

http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01869.html
  

I have a somewhat better version of that code now.  It is enough to
correct create the subdirectories and cd into each of them but it
doesn't build anything yet.  I would really like to see Ada multilib'ed
but Igot distracted from it. 


I will clean up my patch and post it.

Laurent

  

Re: Ada rts fails to build on ppc64?

[Laurent GUERBY]

This is for Joel :). 

I know nothing about autoconf, near to nothing about Makefile
and I don't even know what multilib are for (I never found any
documentation about them :).

Laurent

On Mon, 2007-09-17 at 16:20 -0400, Jack Howarth wrote:
> Laurent,
> I would suggest you start over using the libgfortran as your
> example. Geoffrey Keating created the config/multi.m4 file which
> dramatically simplified how the multilib could be implemented.
> If I recall correctly from when I helped clean up some of
> the residual multilib problems (so they used multi.m4), you
> just need in configure.ac...
> 
> AM_ENABLE_MULTILIB(, ..)
> 
> ...and for the 'Calculate toolexeclibdir' section...
> 
> toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)'
> 
> ...and...
> 
> if test ${multilib} = yes; then
>   multilib_arg="--enable-multilib"
> else
>   multilib_arg=
> fi
> 
> ...before you write your Makefile in configure.ac. You might also
> need the lines for multi_os_directory as well. When you regenerate
> the aclocal.m4 or configure don't forget to use '-I ../config' for
> autoconf so that it can find the multi.m4 in the top level config
> directory.
>  Jack
> 
> 

Re: bootstrap failure on ppc64-linux: ICE in set_variable_part

[Andreas Schwab]

Janis Johnson <[EMAIL PROTECTED]> writes:

> Bootstrap of powerpc64-linux fails building libgfortran with:
>
> /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function 
> 'set_integer':
> /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c:81: internal compiler 
> error: in set_variable_part, at var-tracking.c:2381
> Please submit a full bug report, with preprocessed source if appropriate.
> See  for instructions.
>
> My last successful build was revision 128522; earliest known break
> was 128536, still breaks with 128551.

Bisection has identified this change:

2007-09-16  Richard Sandiford  <[EMAIL PROTECTED]>

* dse.c (find_shift_sequence): Allow word as well as subword shifts.
Do the tentative shift expansion with the DF_NO_INSN_RESCAN flag set.
Fix the call to insn_rtx_cost.  Skip access sizes that require a
real truncation of the store register.  Use convert_move instead
of gen_lowpart when narrowing the result.
(replace_read): Use convert_move instead of gen_lowpart when
narrowing the store rhs.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC 4.3.0 Status Report (2007-09-04)

[Mark Mitchell]

Kai Tietz wrote:

>> I'm sorry -- that doesn't really answer the question I was trying to
>> ask.  To be clear, if we're calling through a function pointer, we still
>> need to be able to do the right thing, and in that case we don't have a
>> FUNCTION_DECL.  So, I don't understand how you can have a macro to
>> control the calling convention that accepts a FUNCTION_DECL; I would
>> think it would have to accept a FUNCTION_TYPE.
> 
> Sorry, I think I missed your question. To make the macro 
> OUTGOING_REG_PARM_STACK_SPACE accepting a FUNCTION_DECL, there is no 
> special reason for it. I deceided this to make it accepting a 
> FUNCTION_DECL to avoid the fndecl to fntype conversion in middle-backend. 

> If this is a serious
> problem, of course I can move this to a FUNCTION_TYPE. Are there some 
> special needs to have here FUNCTION_TYPE ?

Yes, I think this -- and any other macros/hooks that affect calling
convention -- must be based on FUNCTION_TYPEs, not FUNCTION_DECLs.
Otherwise, we cannot properly support calling through a function pointer.

>From (one) type-theoretic perspective, types tell you what set of
operations you can perform.  You can't perform the operation "call this
function, putting its parameters in the usual place" if the function
doesn't want its parameters there; ergo, this must be a property of the
type.

Furthermore, I would argue that the attributes here should be recorded
*only* on the type, in order to avoid duplication.  That's not strictly
speaking necessary, but calling conventions are certainly properly
thought of as a property of types, not of declarations.

Thanks,

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

Re: Ada rts fails to build on ppc64?

[Jack Howarth]

Laurent,
I would suggest you start over using the libgfortran as your
example. Geoffrey Keating created the config/multi.m4 file which
dramatically simplified how the multilib could be implemented.
If I recall correctly from when I helped clean up some of
the residual multilib problems (so they used multi.m4), you
just need in configure.ac...

AM_ENABLE_MULTILIB(, ..)

...and for the 'Calculate toolexeclibdir' section...

toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)'

...and...

if test ${multilib} = yes; then
  multilib_arg="--enable-multilib"
else
  multilib_arg=
fi

...before you write your Makefile in configure.ac. You might also
need the lines for multi_os_directory as well. When you regenerate
the aclocal.m4 or configure don't forget to use '-I ../config' for
autoconf so that it can find the multi.m4 in the top level config
directory.
 Jack

Re: bootstrap failure on ppc64-linux: ICE in set_variable_part

[Janis Johnson]

On Mon, 2007-09-17 at 23:41 +0200, Andreas Schwab wrote:
> Janis Johnson <[EMAIL PROTECTED]> writes:
> 
> > Bootstrap of powerpc64-linux fails building libgfortran with:
> >
> > /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function 
> > 'set_integer':
> > /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c:81: internal 
> > compiler error: in set_variable_part, at var-tracking.c:2381
> > Please submit a full bug report, with preprocessed source if appropriate.
> > See  for instructions.
> >
> > My last successful build was revision 128522; earliest known break
> > was 128536, still breaks with 128551.
> 
> Bisection has identified this change:
> 
> 2007-09-16  Richard Sandiford  <[EMAIL PROTECTED]>
> 
>   * dse.c (find_shift_sequence): Allow word as well as subword shifts.
>   Do the tentative shift expansion with the DF_NO_INSN_RESCAN flag set.
>   Fix the call to insn_rtx_cost.  Skip access sizes that require a
>   real truncation of the store register.  Use convert_move instead
>   of gen_lowpart when narrowing the result.
>   (replace_read): Use convert_move instead of gen_lowpart when
>   narrowing the store rhs.

My hunt just found the same patch  Here's a small test that fails
with cc1 for powerpc64-linux with "-O2 -g -m64 -mstrict-align":
-
extern void *memcpy (void *, const void *, signed long);

void
set_integer (void *dest, __int128_t value, int length)
{
  switch (length)
{
case 16:
  {
 __int128_t tmp = value;
 memcpy (dest, (void *) &tmp, length);
  }
  break;
case 1:
  {
signed char tmp = value;
memcpy (dest, (void *) &tmp, length);
  }
  break;
}
}
---
Janis

gcc-4.1-20070917 is now available

[gccadmin]

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

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

You'll find:

gcc-4.1-20070917.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20070917.tar.bz2 C front end and core compiler

gcc-ada-4.1-20070917.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20070917.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20070917.tar.bz2  C++ front end and runtime

gcc-java-4.1-20070917.tar.bz2 Java front end and runtime

gcc-objc-4.1-20070917.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20070917.tar.bz2The GCC testsuite

Diffs from 4.1-20070910 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
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: bootstrap failure on ppc64-linux: ICE in set_variable_part

[Richard Sandiford]

Janis Johnson <[EMAIL PROTECTED]> writes:
> On Mon, 2007-09-17 at 23:41 +0200, Andreas Schwab wrote:
>> Janis Johnson <[EMAIL PROTECTED]> writes:
>> 
>> > Bootstrap of powerpc64-linux fails building libgfortran with:
>> >
>> > /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function 
>> > 'set_integer':
>> > /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c:81: internal 
>> > compiler error: in set_variable_part, at var-tracking.c:2381
>> > Please submit a full bug report, with preprocessed source if appropriate.
>> > See  for instructions.
>> >
>> > My last successful build was revision 128522; earliest known break
>> > was 128536, still breaks with 128551.
>> 
>> Bisection has identified this change:
>> 
>> 2007-09-16  Richard Sandiford  <[EMAIL PROTECTED]>
>> 
>>  * dse.c (find_shift_sequence): Allow word as well as subword shifts.
>>  Do the tentative shift expansion with the DF_NO_INSN_RESCAN flag set.
>>  Fix the call to insn_rtx_cost.  Skip access sizes that require a
>>  real truncation of the store register.  Use convert_move instead
>>  of gen_lowpart when narrowing the result.
>>  (replace_read): Use convert_move instead of gen_lowpart when
>>  narrowing the store rhs.
>
> My hunt just found the same patch  Here's a small test that fails
> with cc1 for powerpc64-linux with "-O2 -g -m64 -mstrict-align":
> -
> extern void *memcpy (void *, const void *, signed long);
>
> void
> set_integer (void *dest, __int128_t value, int length)
> {
>   switch (length)
> {
> case 16:
>   {
>  __int128_t tmp = value;
>  memcpy (dest, (void *) &tmp, length);
>   }
>   break;
> case 1:
>   {
> signed char tmp = value;
> memcpy (dest, (void *) &tmp, length);
>   }
>   break;
> }
> }
> ---
> Janis

I think this is a latent bug in var-tracking.c.  It's getting confused
by the negative offsets in:

(insn:HI 17 47 19 4 /tmp/foo.c:11 (set (reg:DI 26 26 [orig:124 tmp+-7 ] [124])
(lshiftrt:DI (reg:DI 31 31 [orig:141 value ] [141])
(const_int 56 [0x38]))) 292 {*lshrdi3_internal1} (nil))

(insn:HI 19 17 21 4 /tmp/foo.c:11 (set (reg:DI 27 27 [orig:125 tmp+-6 ] [125])
(lshiftrt:DI (reg:DI 31 31 [orig:141 value ] [141])
(const_int 48 [0x30]))) 292 {*lshrdi3_internal1} (nil))

where the registers have come from paradoxical subregs of QImode registers.
(DSE itself didn't create those; combine did.  DSE just created DImode
shift instructions.)

FWIW, the part of the patch that exposed the bug as the change from
"access_bytes < UNITS_PER_WORD" to "access_bytes <= UNITS_PER_WORD".
Your testcase passes if we change that back.

>From my POV of view, feel free to commit that change until the underlying
var-tracking bug is fixed.  Alternatively, I think it'd be OK to revert
the whole of my patch _and_ revert Kenny's patch.  (Please don't just
revert mine, as it would reintroduce a bootstrap failure on MIPS targets.)

I'm afraid I won't have time to work on this myself.  Hopefully Kenny
will.  (At the end of the day, I was only trying to fix MIPS breakage
in the original DSE patch, rather than asking Kenny to it for me. ;))

Richard

Re: bootstrap failure on ppc64-linux: ICE in set_variable_part

[Kenneth Zadeck]

Richard Sandiford wrote:
> Janis Johnson <[EMAIL PROTECTED]> writes:
>   
>> On Mon, 2007-09-17 at 23:41 +0200, Andreas Schwab wrote:
>> 
>>> Janis Johnson <[EMAIL PROTECTED]> writes:
>>>
>>>   
 Bootstrap of powerpc64-linux fails building libgfortran with:

 /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function 
 'set_integer':
 /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c:81: internal 
 compiler error: in set_variable_part, at var-tracking.c:2381
 Please submit a full bug report, with preprocessed source if appropriate.
 See  for instructions.

 My last successful build was revision 128522; earliest known break
 was 128536, still breaks with 128551.
 
>>> Bisection has identified this change:
>>>
>>> 2007-09-16  Richard Sandiford  <[EMAIL PROTECTED]>
>>>
>>> * dse.c (find_shift_sequence): Allow word as well as subword shifts.
>>> Do the tentative shift expansion with the DF_NO_INSN_RESCAN flag set.
>>> Fix the call to insn_rtx_cost.  Skip access sizes that require a
>>> real truncation of the store register.  Use convert_move instead
>>> of gen_lowpart when narrowing the result.
>>> (replace_read): Use convert_move instead of gen_lowpart when
>>> narrowing the store rhs.
>>>   
>> My hunt just found the same patch  Here's a small test that fails
>> with cc1 for powerpc64-linux with "-O2 -g -m64 -mstrict-align":
>> -
>> extern void *memcpy (void *, const void *, signed long);
>>
>> void
>> set_integer (void *dest, __int128_t value, int length)
>> {
>>   switch (length)
>> {
>> case 16:
>>   {
>>  __int128_t tmp = value;
>>  memcpy (dest, (void *) &tmp, length);
>>   }
>>   break;
>> case 1:
>>   {
>> signed char tmp = value;
>> memcpy (dest, (void *) &tmp, length);
>>   }
>>   break;
>> }
>> }
>> ---
>> Janis
>> 
>
> I think this is a latent bug in var-tracking.c.  It's getting confused
> by the negative offsets in:
>
> (insn:HI 17 47 19 4 /tmp/foo.c:11 (set (reg:DI 26 26 [orig:124 tmp+-7 ] [124])
> (lshiftrt:DI (reg:DI 31 31 [orig:141 value ] [141])
> (const_int 56 [0x38]))) 292 {*lshrdi3_internal1} (nil))
>
> (insn:HI 19 17 21 4 /tmp/foo.c:11 (set (reg:DI 27 27 [orig:125 tmp+-6 ] [125])
> (lshiftrt:DI (reg:DI 31 31 [orig:141 value ] [141])
> (const_int 48 [0x30]))) 292 {*lshrdi3_internal1} (nil))
>
> where the registers have come from paradoxical subregs of QImode registers.
> (DSE itself didn't create those; combine did.  DSE just created DImode
> shift instructions.)
>
> FWIW, the part of the patch that exposed the bug as the change from
> "access_bytes < UNITS_PER_WORD" to "access_bytes <= UNITS_PER_WORD".
> Your testcase passes if we change that back.
>
>   
i would prefer that the above change be reverted and the rest of the
patch left in.
kenny
> From my POV of view, feel free to commit that change until the underlying
> var-tracking bug is fixed.  Alternatively, I think it'd be OK to revert
> the whole of my patch _and_ revert Kenny's patch.  (Please don't just
> revert mine, as it would reintroduce a bootstrap failure on MIPS targets.)
>
> I'm afraid I won't have time to work on this myself.  Hopefully Kenny
> will.  (At the end of the day, I was only trying to fix MIPS breakage
> in the original DSE patch, rather than asking Kenny to it for me. ;))
>
> Richard
>   

Re: bootstrap failure on ppc64-linux: ICE in set_variable_part

[Kenneth Zadeck]

Kenneth Zadeck wrote:
> Richard Sandiford wrote:
>   
>> Janis Johnson <[EMAIL PROTECTED]> writes:
>>   
>> 
>>> On Mon, 2007-09-17 at 23:41 +0200, Andreas Schwab wrote:
>>> 
>>>   
 Janis Johnson <[EMAIL PROTECTED]> writes:

   
 
> Bootstrap of powerpc64-linux fails building libgfortran with:
>
> /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c: In function 
> 'set_integer':
> /home/janis/gcc_trunk_anonsvn/gcc/libgfortran/io/read.c:81: internal 
> compiler error: in set_variable_part, at var-tracking.c:2381
> Please submit a full bug report, with preprocessed source if appropriate.
> See  for instructions.
>
> My last successful build was revision 128522; earliest known break
> was 128536, still breaks with 128551.
> 
>   
 Bisection has identified this change:

 2007-09-16  Richard Sandiford  <[EMAIL PROTECTED]>

* dse.c (find_shift_sequence): Allow word as well as subword shifts.
Do the tentative shift expansion with the DF_NO_INSN_RESCAN flag set.
Fix the call to insn_rtx_cost.  Skip access sizes that require a
real truncation of the store register.  Use convert_move instead
of gen_lowpart when narrowing the result.
(replace_read): Use convert_move instead of gen_lowpart when
narrowing the store rhs.
   
 
>>> My hunt just found the same patch  Here's a small test that fails
>>> with cc1 for powerpc64-linux with "-O2 -g -m64 -mstrict-align":
>>> -
>>> extern void *memcpy (void *, const void *, signed long);
>>>
>>> void
>>> set_integer (void *dest, __int128_t value, int length)
>>> {
>>>   switch (length)
>>> {
>>> case 16:
>>>   {
>>>  __int128_t tmp = value;
>>>  memcpy (dest, (void *) &tmp, length);
>>>   }
>>>   break;
>>> case 1:
>>>   {
>>> signed char tmp = value;
>>> memcpy (dest, (void *) &tmp, length);
>>>   }
>>>   break;
>>> }
>>> }
>>> ---
>>> Janis
>>> 
>>>   
>> I think this is a latent bug in var-tracking.c.  It's getting confused
>> by the negative offsets in:
>>
>> (insn:HI 17 47 19 4 /tmp/foo.c:11 (set (reg:DI 26 26 [orig:124 tmp+-7 ] 
>> [124])
>> (lshiftrt:DI (reg:DI 31 31 [orig:141 value ] [141])
>> (const_int 56 [0x38]))) 292 {*lshrdi3_internal1} (nil))
>>
>> (insn:HI 19 17 21 4 /tmp/foo.c:11 (set (reg:DI 27 27 [orig:125 tmp+-6 ] 
>> [125])
>> (lshiftrt:DI (reg:DI 31 31 [orig:141 value ] [141])
>> (const_int 48 [0x30]))) 292 {*lshrdi3_internal1} (nil))
>>
>> where the registers have come from paradoxical subregs of QImode registers.
>> (DSE itself didn't create those; combine did.  DSE just created DImode
>> shift instructions.)
>>
>> FWIW, the part of the patch that exposed the bug as the change from
>> "access_bytes < UNITS_PER_WORD" to "access_bytes <= UNITS_PER_WORD".
>> Your testcase passes if we change that back.
>>
>>   
>> 
> i would prefer that the above change be reverted and the rest of the
> patch left in.
> kenny
>   
>> From my POV of view, feel free to commit that change until the underlying
>> var-tracking bug is fixed.  Alternatively, I think it'd be OK to revert
>> the whole of my patch _and_ revert Kenny's patch.  (Please don't just
>> revert mine, as it would reintroduce a bootstrap failure on MIPS targets.)
>>
>> I'm afraid I won't have time to work on this myself.  Hopefully Kenny
>> will.  (At the end of the day, I was only trying to fix MIPS breakage
>> in the original DSE patch, rather than asking Kenny to it for me. ;))
>>
>> Richard
>>   
>> 
>
>   
I should also point out that i am at a conference this week in romania
and cannot really test anything, especially on the ppc.  So someone else
needs to revert this regression.

Kenny