4.3 target deprecation patch part 1: c4x removal, whole-target deprecations

[Pompapathi V Gadad]

Hello All,
Please donot deprecate crx-*-* target. We have a active team for 
maintaining both crx and cr16 targets. CR16 target has been submitted 
for the inclusion into the 4.3. I had volunteered for maintaining the 
crx port earlier since the original maintainer was not with the company 
anymore. However, things did not move and I am still waiting to be get 
the maintainer ship. I agree, we have not posted the test results of crx 
in recent past, however, now that we have active team to maintain, we 
will post the results as soon as possible.

Thanks,
Pompa

[Fwd: Re: GCC 4.3 target deprecation proposals]

[M R Swami Reddy]

 --- Begin Message ---

Hi Joseph,

> The following target architectures have seen no test results posted in
> the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11,
> score, stormy16, vax.

Please do not deprecate the "crx" target. We are actively working on to update 
this target and post test results soon.



Thanks,
Swami

--- End Message ---

Some help with fold_convert() on RECORD_TYPEs

[FX]

Hi all,

I'm going forward on my patch to remove the multiple decls emitted by
the Fortran front-end for a single function. The problem is that doing
so yields quite a few type mismatch issues that were hidden by it.
Some of them can be corrected in the front-end, and for some of them I
just don't know. Today's example is an error when we try to
fold_convert() a RECORD_TYPE into a different, but similar
RECORD_TYPE. Namely, the right hand side is:

(gdb) p debug_tree(rse->expr)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x2b8710158000
fields 
SI file a2.f90 line 3 col 0 size  unit size 
align 32 offset_align 128
offset 
bit offset  context >
chain >
[...]

and the left hand side is:

(gdb) p debug_tree(lse->expr)
 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x2b8710158480
fields 
SI file a2.f90 line 11 col 0 size  unit size 
align 32 offset_align 128
offset 
bit offset  context >
chain >
[...]

The two record types are equivalent in Fortran rules: in Fortran, you
can assign between two different type (defined in different places, or
with different names) as long as they have the same list of
components, in the same order, with the same attributes. However, the
middle-end doesn't like that, and fold_convert'ing rse->expr into a
TREE_TYPE(lse->expr) yields to failure. My questions are:

  1. Is this limitation in the middle-end likely to be lifted if we
ask nicely? I mean, if I understand correctly, the current behaviour
is implemented here because it's the right thing to do to support C,
but GCC is more than C, so maybe it could be considered to change this
assumption? Or would that be more work than I imagine?

  2. Could a Fortran maintainer who knows copy_dt_decls_ifequal()
advise me on how likely it is that we can resolve this directly in the
front-end? For example, I imagine we could, before building a new type
node, go through all the other derived types nodes and see if there's
one that fits... but is that a reasonable thing to do? Or would it
break other stuff that I don't think off?

Thanks,
FX

-- 
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: Some help with fold_convert() on RECORD_TYPEs

[Richard Guenther]

On Fri, Feb 29, 2008 at 1:01 PM, FX <[EMAIL PROTECTED]> wrote:
> Hi all,
>
>  I'm going forward on my patch to remove the multiple decls emitted by
>  the Fortran front-end for a single function. The problem is that doing
>  so yields quite a few type mismatch issues that were hidden by it.
>  Some of them can be corrected in the front-end, and for some of them I
>  just don't know. Today's example is an error when we try to
>  fold_convert() a RECORD_TYPE into a different, but similar
>  RECORD_TYPE. Namely, the right hand side is:
>
>  (gdb) p debug_tree(rse->expr)
>type  size 
> unit size 
> align 32 symtab 0 alias set -1 canonical type 0x2b8710158000
> fields   0x2b87100c7540 integer(kind=4)>
> SI file a2.f90 line 3 col 0 size   0x2b87100baa50 32> unit size 
> align 32 offset_align 128
> offset 
> bit offset   0> context >
> chain >
> [...]
>
>  and the left hand side is:
>
>  (gdb) p debug_tree(lse->expr)
>type  size 
> unit size 
> align 32 symtab 0 alias set -1 canonical type 0x2b8710158480
> fields   0x2b87100c7540 integer(kind=4)>
> SI file a2.f90 line 11 col 0 size   0x2b87100baa50 32> unit size 
> align 32 offset_align 128
> offset 
> bit offset   0> context >
> chain >
> [...]
>
>  The two record types are equivalent in Fortran rules: in Fortran, you
>  can assign between two different type (defined in different places, or
>  with different names) as long as they have the same list of
>  components, in the same order, with the same attributes. However, the
>  middle-end doesn't like that, and fold_convert'ing rse->expr into a
>  TREE_TYPE(lse->expr) yields to failure. My questions are:
>
>   1. Is this limitation in the middle-end likely to be lifted if we
>  ask nicely? I mean, if I understand correctly, the current behaviour
>  is implemented here because it's the right thing to do to support C,
>  but GCC is more than C, so maybe it could be considered to change this
>  assumption? Or would that be more work than I imagine?

Sort of.  The frontend is supposed to note this compatibility via
the TYPE_MAIN_VARIANT or the TYPE_CANONICAL mechanism
(note that fold_convert doesn't listen to TYPE_CANONICAL at all
at the moment, but this eventually needs to change anyway).

>   2. Could a Fortran maintainer who knows copy_dt_decls_ifequal()
>  advise me on how likely it is that we can resolve this directly in the
>  front-end? For example, I imagine we could, before building a new type
>  node, go through all the other derived types nodes and see if there's
>  one that fits... but is that a reasonable thing to do? Or would it
>  break other stuff that I don't think off?

Another workaround is to use a VIEW_CONVERT_EXPR in case
fold_convertible_p () returns false but you still think you are ok.

Richard.

Re: 4.3 target deprecation patch part 1: c4x removal, whole-target deprecations

[Joseph S. Myers]

The question of maintainership will need to be decided by the Steering 
Committee, but before you can become the maintainer you should have 
established a record of submitting good patches to the port that conform 
to the GNU Coding Standards etc.; depending on the status of any corporate 
assignment, you may also need to have personal copyright assignment papers 
on file at the FSF.

When you have patches to the port ready that make any changes necessary to 
get it in good working order, you can include the change to config.gcc to 
remove the deprecation along with those patches, and post the test results 
for the patched compiler to gcc-testresults (indicating in the test 
results posting what patches are applied).  If any changes required are 
confined to the crx port or otherwise clearly safe for other targets, you 
may also be able to remove the deprecation on 4.3 branch.

You should plan on getting the patches in - including doing any necessary 
paperwork and pinging patches needing review as necessary - within the 
next couple of months; deprecated ports are likely to be removed at that 
point unless they have seen sufficient activity to revive them.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: 4.3 target deprecation patch part 1: c4x removal, whole-target deprecations

[Pompapathi V Gadad]

Hello Joseph S. Myers,
Thanks for reply. My individual assignment process with the FSF is 
complete. I have submitted patches for another target CR16 and it has 
been reviewed. However, it has not be committed to trunk yet.


OK. We will make necessary changes in the patches to include the removal 
of deprecation and post the results as soon as possible.


Thanks a lot,
Pompa

Joseph S. Myers wrote:
The question of maintainership will need to be decided by the Steering 
Committee, but before you can become the maintainer you should have 
established a record of submitting good patches to the port that conform 
to the GNU Coding Standards etc.; depending on the status of any corporate 
assignment, you may also need to have personal copyright assignment papers 
on file at the FSF.


When you have patches to the port ready that make any changes necessary to 
get it in good working order, you can include the change to config.gcc to 
remove the deprecation along with those patches, and post the test results 
for the patched compiler to gcc-testresults (indicating in the test 
results posting what patches are applied).  If any changes required are 
confined to the crx port or otherwise clearly safe for other targets, you 
may also be able to remove the deprecation on 4.3 branch.


You should plan on getting the patches in - including doing any necessary 
paperwork and pinging patches needing review as necessary - within the 
next couple of months; deprecated ports are likely to be removed at that 
point unless they have seen sufficient activity to revive them.


  

Re: 4.3 target deprecation patch part 1: c4x removal, whole-target deprecations

[Joseph S. Myers]

On Fri, 29 Feb 2008, Pompapathi V Gadad wrote:

> Hello Joseph S. Myers,
> Thanks for reply. My individual assignment process with the FSF is complete. I
> have submitted patches for another target CR16 and it has been reviewed.
> However, it has not be committed to trunk yet.

If a patch reviewer approves a patch without committing it, they are 
assuming that the submitter has commit access.  If you don't, you need to 
say so when it's approved and ask them to commit it (and possibly to 
sponsor you for commit access so you can commit future patches yourself).

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Some help with fold_convert() on RECORD_TYPEs

[FX]

>  Another workaround is to use a VIEW_CONVERT_EXPR in case
>  fold_convertible_p () returns false but you still think you are ok.

I'm trying that, but fold_convertible_p () return true and it still
ICEs in in fold_convert, at fold-const.c:2643!  Basically,
fold_convert() can't handle RECORD_TYPEs, but in fold_convertible_p()
it falls into the default case and returns TRUE, in my case. Is it
considered a middle-end bug?

FX

-- 
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: 4.3 target deprecation patch part 1: c4x removal, whole-target deprecations

[Pompapathi V Gadad]

Yes. I donot have commit access. I will make a fresh request to commit 
the changes on my behalf.

Thanks,
Pompa

Joseph S. Myers wrote:

On Fri, 29 Feb 2008, Pompapathi V Gadad wrote:

  

Hello Joseph S. Myers,
Thanks for reply. My individual assignment process with the FSF is complete. I
have submitted patches for another target CR16 and it has been reviewed.
However, it has not be committed to trunk yet.



If a patch reviewer approves a patch without committing it, they are 
assuming that the submitter has commit access.  If you don't, you need to 
say so when it's approved and ask them to commit it (and possibly to 
sponsor you for commit access so you can commit future patches yourself).


  

Re: Some help with fold_convert() on RECORD_TYPEs

[Richard Guenther]

On Fri, Feb 29, 2008 at 2:48 PM, FX <[EMAIL PROTECTED]> wrote:
> >  Another workaround is to use a VIEW_CONVERT_EXPR in case
>  >  fold_convertible_p () returns false but you still think you are ok.
>
>  I'm trying that, but fold_convertible_p () return true and it still
>  ICEs in in fold_convert, at fold-const.c:2643!  Basically,
>  fold_convert() can't handle RECORD_TYPEs, but in fold_convertible_p()
>  it falls into the default case and returns TRUE, in my case. Is it
>  considered a middle-end bug?

Yeah, it should return false for some classes of types, RECORD_TYPE, UNION_TYPE,
ARRAY_TYPE come to my mind here.  Patch welcome ;)

Richard.

PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

[Jack Howarth]

   Current gcc 4.3 branch incorrectly links all of its
shared libraries against the system libgcc instead of
the copy it builds and installs (PR35401). It appears
that the fix applied for PR30572 may have been
disturbed since it is no longer working.
   Shouldn't PR35401 be escalated to a release blocker
for gcc 4.3.0?
   Jack

Re: 4.3 target deprecation patch part 1: c4x removal, whole-target deprecations

[Manuel López-Ibáñez]

On 29/02/2008, Pompapathi V Gadad <[EMAIL PROTECTED]> wrote:
> Yes. I donot have commit access. I will make a fresh request to commit
>  the changes on my behalf.
>  Thanks,
>  Pompa

Hey Pompa,

if you have your legal papers in order, you are planning to keep
contributing and your patch is not extremely urgent, perhaps it would
be better to just ask for commit access and wait for it. See
http://gcc.gnu.org/svnwrite.html

It should take no more than a few days and you won't have to depend on
anyone to commit your patches for you.

Cheers,

Manuel.

Re: Some help with fold_convert() on RECORD_TYPEs

[Richard Guenther]

On Fri, Feb 29, 2008 at 3:07 PM, FX <[EMAIL PROTECTED]> wrote:
> >  Yeah, it should return false for some classes of types, RECORD_TYPE, 
> > UNION_TYPE,
>  >  ARRAY_TYPE come to my mind here.  Patch welcome ;)
>
>  I'd suggest:

Works for me.  Ok if that passes bootstrap / regtest and with a proper
changelog entry.

Richard.

>  Index: fold-const.c
>  ===
>  --- fold-const.c(revision 131974)
>  +++ fold-const.c(working copy)
>  @@ -2476,8 +2476,15 @@ fold_convertible_p (const_tree type, con
>return (TREE_CODE (orig) == VECTOR_TYPE
>   && tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig)));
>
>  -default:
>  +case REAL_TYPE:
>  +case FIXED_POINT_TYPE:
>  +case COMPLEX_TYPE:
>  +case VECTOR_TYPE:
>  +case VOID_TYPE:
>return TREE_CODE (type) == TREE_CODE (orig);
>  +
>  +default:
>  +  return false;
>
>
>  }
>   }
>
>
>
>
>  --
>  FX Coudert
>  http://www.homepages.ucl.ac.uk/~uccafco/
>

Re: Some help with fold_convert() on RECORD_TYPEs

[FX]

>  Yeah, it should return false for some classes of types, RECORD_TYPE, 
> UNION_TYPE,
>  ARRAY_TYPE come to my mind here.  Patch welcome ;)

I'd suggest:

Index: fold-const.c
===
--- fold-const.c(revision 131974)
+++ fold-const.c(working copy)
@@ -2476,8 +2476,15 @@ fold_convertible_p (const_tree type, con
   return (TREE_CODE (orig) == VECTOR_TYPE
  && tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig)));

-default:
+case REAL_TYPE:
+case FIXED_POINT_TYPE:
+case COMPLEX_TYPE:
+case VECTOR_TYPE:
+case VOID_TYPE:
   return TREE_CODE (type) == TREE_CODE (orig);
+
+default:
+  return false;
 }
 }




-- 
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

[Richard Guenther]

On Fri, Feb 29, 2008 at 3:14 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
>Current gcc 4.3 branch incorrectly links all of its
>  shared libraries against the system libgcc instead of
>  the copy it builds and installs (PR35401). It appears
>  that the fix applied for PR30572 may have been
>  disturbed since it is no longer working.
>Shouldn't PR35401 be escalated to a release blocker
>  for gcc 4.3.0?

As this only seems to affect darwin, no.

Richard.

Re: GCC loop optimizations

[Zdenek Dvorak]

Hi,

> I'd like to know your experiences with the gcc loop optimizations.
> 
> What loop optimizations (in your opinion) can be applied to a large
> number of programs and yield a (significant) improvement of the
> program run-time?

in general, I would say invariant motion, load/store motion, strength
reduction and loop unrolling.  Most of the other loop optimizations tend
to apply only in special situations.  Note however that the usefulness
also heavily depends on the type of the compiled code; e.g., wide class
of programs (simulations, optimization) spend most of the time doing
simple calculations on large arrays, and other optimizations (loop
interchange/reordering/..., prefetching) become important.

> I've tested the gcc compiler optimization "loop unswitching" 
> (introduced in gcc 3.4) but going through a large number of different
> benchmarks I could find very few cases where the optimization could be
> applied. Do you share my experience?

yes, the situations where loop unswitching can be applied are not
very common.

Zdenek

Benchmarks: 7z, bzip2 & gzip.

[J.C. Pizarro]

Here are the results of benchmarks of 3 compressors: 7z, bzip2 and gzip, and
GCCs 3.4.6, 4.1.3-20080225, 4.2.4-20080227, 4.3.0-20080228 & 4.4.0-20080222.

--
# User's time is taken, machine is Ath64 3200+ 2.0 GHz x1, 64+64K L1, 512K L2.
# Every GCC-4 compilers were compiled so
mkdir build ; cd build
../configure --prefix=/opt/gcc? --disable-shared \
--disable-threads --disable-checking --enable-__cxa_atexit \
--enable-languages=c,c++,fortran --enable-bootstrap
time make "CFLAGS=-O3 -fomit-frame-pointer -march=i686 -pipe \
-mno-sse3 -msse2 -msse -mno-mmx -mno-3dnow \
-funroll-loops -finline-functions -fpeel-loops" bootstrap
make install
--
1. gcc-3.4.6 (the default of the distro)
--
2. gcc-4.1.3-20080225 ( built in 40 minutes, 110 MiB /opt/gcc41320080225 )
export PATH=/opt/gcc41320080225/bin:$PATH
export LD_LIBRARY_PATH=/opt/gcc41320080225//lib
--
3. gcc-4.2.4-20080227 ( built in 65 minutes, 150 MiB /opt/gcc42420080227 )
export PATH=/opt/gcc42420080227/bin:$PATH
export LD_LIBRARY_PATH=/opt/gcc42420080227/lib
--
4. gcc-4.3.0-20080228 ( built in 85 minutes, 114 MiB /opt/gcc43020080228 )
export PATH=/opt/gcc43020080228/bin:$PATH
export LD_LIBRARY_PATH=/opt/gcc43020080228/lib
--
5. gcc-4.4.0-20080222 ( built in 79 minutes, 112 MiB /opt/gcc44020080222 )
export PATH=/opt/gcc44020080222/bin:$PATH
export LD_LIBRARY_PATH=/opt/gcc44020080222/lib
--
  p7zip-4.57
  --
1. tar -jxf p7zip_4.57_src_all.tar.bz2
2. Edit CPP/7zip/Bundles/Alone/makefile adding
LOCAL_FLAGS+= below ...
3. time make ; strip --strip-all bin/7za ; ls -l bin/7za ; size bin/7za
4. linux-2.4.36.2.tar.gz ( 38'720'979 bytes, 175'237'120 bytes .tar,
   24'471'728 bytes .tar.7z )
   time gzip -cd ../linux-2.4.36.2.tar.gz | ./bin/7za a -t7z -m0=lzma -mx=9 \
   -mfb=273 -md=48m -ms=on -si trash.7z  ; ls -l *7z
--
LOCAL_FLAGS+=-O3 -fomit-frame-pointer -march=i686 \
 -mno-sse3 -msse2 -msse -mno-mmx -mno-3dnow \
 -funroll-loops -finline-functions -fpeel-loops

1. 1m50s compile, 1630164 file, 1618639 text, 6120 data, 27168 bss, 5m50s run.
2. 1m53s compile, 1665952 file, 1649829 text, 4668 data, 29160 bss, 6m04s run.
3. 2m08s compile, 1629088 file, 1613313 text, 4672 data, 29160 bss, 5m54s run.
4. 2m36s compile, 2063216 file, 2047420 text, 4380 data, 29160 bss, 6m14s run.
5. 2m30s compile, 1976228 file, 1960164 text, 4380 data, 29160 bss, 6m12s run.
--
LOCAL_FLAGS+=-Os -fomit-frame-pointer -march=i686 \
 -mno-sse3 -mno-sse2 -mno-sse -mno-mmx -mno-3dnow

1. 1m21s compile, 1123476 file, 971 text, 6120 data, 27168 bss, 6m11s run.
2. 1m01s compile,  723872 file,  707806 text, 4672 data, 29224 bss, 6m39s run.
3. 1m11s compile,  720264 file,  705082 text, 4220 data, 29004 bss, 6m15s run.
4. 1m01s compile,  721688 file,  706557 text, 3928 data, 28908 bss, 6m12s run.
5. 1m01s compile,  700612 file,  685009 text, 3928 data, 28940 bss, 6m12s run.
--
LOCAL_FLAGS+=-Os -fomit-frame-pointer -march=i686 \
 -mno-sse3 -mno-sse2 -mno-sse -mno-mmx -mno-3dnow \
 -funroll-loops -finline-functions -fpeel-loops

3. 1m20s compile,  908496 file,  893314 text, 4220 data, 29004 bss, 6m38s run.
5. 1m14s compile,  969228 file,  953629 text, 3928 data, 28940 bss, 6m18s run.
--
  bzip2-1.0.4
  ---
1. tar -zxf bzip2-1.0.4.tar.gz
2. time make "CFLAGS=-Wall -Winline -D_FILE_OFFSET_BITS=64 ...below... " \
   ; strip --strip-all bzip2 ; ls -l bzip2 ; size bzip2
3. linux-2.4.36.2.tar.gz ( 38'720'979 bytes, 175'237'120 bytes .tar,
   24'471'728 .tar.7z, 31'095'864 bytes .tar.bz2 )
   time gzip -cd ../linux-2.4.36.2.tar.gz | ./bzip2 -9 > /dev/null
--
-O3 -fomit-frame-pointer -march=i686 \
-mno-sse3 -msse2 -msse -mno-mmx -mno-3dnow \
-funroll-loops -finline-functions -fpeel-loops

1.  7.0s compile,  111660 file,  104530 text, 3644 data,  4400 bss, 1m15s run.
2.  7.3s compile,  107664 file,  100538 text, 3524 data,  4400 bss, 1m1

A few questions on XFmode for x86

[H.J. Lu]

i386-modes.def has

---
/* In ILP32 mode, XFmode has size 12 and alignment 4.
   In LP64 mode, XFmode has size and alignment 16.  */
ADJUST_FLOAT_FORMAT (XF, (TARGET_128BIT_LONG_DOUBLE
  ? &ieee_extended_intel_128_format
  : TARGET_96_ROUND_53_LONG_DOUBLE
  ? &ieee_extended_intel_96_round_53_format
  : &ieee_extended_intel_96_format));
ADJUST_BYTESIZE  (XF, TARGET_128BIT_LONG_DOUBLE ? 16 : 12);
ADJUST_ALIGNMENT (XF, TARGET_128BIT_LONG_DOUBLE ? 16 : 4);
---

The comment don't match the code.  XFmode is independent of ILP32
and LP64.  However, in i386.h, there is

/* Decide whether a variable of mode MODE should be 128 bit aligned.  */
#define ALIGN_MODE_128(MODE) \
 ((MODE) == XFmode || SSE_REG_MODE_P (MODE))

What is the real alignment of XFmode in ILP32 mode?

According to i386 and x86-64 psABIs,  in LP32 mode, XFmode has
size 12 and alignment 4 and in LP64 mode, XFmode has size and
alignment 16. It doesn't make senses to have XFmode of size 12
and alignment 16 in ILP32 mode since it doesn't work with array
of XFmode.


H.J.

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

[Jack Howarth]

Richard,
This problem appears to be caused by...

Author: rsandifo
Date: Thu Dec 27 11:26:06 2007
New Revision: 131198

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131198
Log:
libgcc/
* Makefile.in (all): Use install-leaf rather than install.
(install): Split most of the rule into...
(install-leaf): ...this new one.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/Makefile.in

...regressing that patch for my existing build and rebuilding the
gcc shared libraries eliminates the problem...

otool -L libgfortran.3.dylib
libgfortran.3.dylib:
/sw/lib/gcc4.3/lib/libgfortran.3.dylib (compatibility version 4.0.0,
current version 4.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 111.0.0)
/sw/lib/gcc4.3/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)

I am repeating a complete bootstrap with that patch regressed as
an additional confirmation.
 Jack


On Fri, Feb 29, 2008 at 05:04:53PM +0100, Richard Guenther wrote:
> On Fri, Feb 29, 2008 at 3:14 PM, Jack Howarth <[EMAIL PROTECTED]> wrote:
> >Current gcc 4.3 branch incorrectly links all of its
> >  shared libraries against the system libgcc instead of
> >  the copy it builds and installs (PR35401). It appears
> >  that the fix applied for PR30572 may have been
> >  disturbed since it is no longer working.
> >Shouldn't PR35401 be escalated to a release blocker
> >  for gcc 4.3.0?
> 
> As this only seems to affect darwin, no.
> 
> Richard.

Re: Draft SH uClinux FDPIC ABI

[Joseph S. Myers]

On Thu, 28 Feb 2008, Alexandre Oliva wrote:

> It was the need for using the atomic 64-bit load/store instructions
> that motivated us to use 64-bit alignment for function descriptors on
> FR-V.  Since SH doesn't have 64-bit load/store instructions, there's
> no need for function descriptors to be aligned to 64-bit boundaries.

I've removed one reference to alignment.

> > This arrangement will not make processes that the debugger attaches to
> > after they are mapped in look like they have independent sets of
> > breakpoints; they may just crash instead of they reach a breakpoint
> > instruction set with ptrace for another process.
> 
> Typo (carried over from the original): instead of => instead, if

Thanks - there were lots more typos in the original (spell-checking it 
might be a good idea).

> I've just fixed it in FR-V FDPIC 1.0b.

Is there a more recent location to reference than 
, which still seems to 
have 1.0a?

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

[Ralf Wildenhues]

* dju wrote on Fri, Feb 29, 2008 at 03:19:45AM CET:
> platform : microsoft windowsXP(32) sp2 intel core duo
>
> i managed to build gcc-4.2.3 using MinGW-5.1.3 candidate with gcc 3.4.5
and binutils-2.17.50 in MSYS-1.0.10
[...]
>
> only one change in gcc-4.2.3 source :
>  in /work/src/gcc-4.2.3/libada/Makefile.in line 30
>  [EMAIL PROTECTED]@
>  by
>  LN_S=cp

Why was that change necessary?  Can you post the error that you got
without it?

Thanks,
Ralf

Re: A few questions on XFmode for x86

[Jan Hubicka]

> i386-modes.def has
> 
> ---
> /* In ILP32 mode, XFmode has size 12 and alignment 4.
>In LP64 mode, XFmode has size and alignment 16.  */
> ADJUST_FLOAT_FORMAT (XF, (TARGET_128BIT_LONG_DOUBLE
>   ? &ieee_extended_intel_128_format
>   : TARGET_96_ROUND_53_LONG_DOUBLE
>   ? &ieee_extended_intel_96_round_53_format
>   : &ieee_extended_intel_96_format));
> ADJUST_BYTESIZE  (XF, TARGET_128BIT_LONG_DOUBLE ? 16 : 12);
> ADJUST_ALIGNMENT (XF, TARGET_128BIT_LONG_DOUBLE ? 16 : 4);
> ---
> 
> The comment don't match the code.  XFmode is independent of ILP32
> and LP64.  However, in i386.h, there is

TARGET_128BIT_LONG_DOUBLE is default in 64bit mode and disabled in
32bit, see unix.h. So transitively the comment is correct but it
probably should comment that in 32bit mode 128bit alignment is possible.
> 
> /* Decide whether a variable of mode MODE should be 128 bit aligned.  */
> #define ALIGN_MODE_128(MODE) \
>  ((MODE) == XFmode || SSE_REG_MODE_P (MODE))
> 
> What is the real alignment of XFmode in ILP32 mode?

It is 4 byte with size of 12 per i386 psABI. We however take care to
increase the alginment whenever possible in non-ABI breaking way. 16
byte aligned long double is faster. So as simple local or static
variables and spill slots should be 16byte aligned, in arrays and
fileds, it should be 4 byte aligned.
> 
> According to i386 and x86-64 psABIs,  in LP32 mode, XFmode has
> size 12 and alignment 4 and in LP64 mode, XFmode has size and
> alignment 16. It doesn't make senses to have XFmode of size 12
> and alignment 16 in ILP32 mode since it doesn't work with array
> of XFmode.
> 
> 
> H.J.

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

[Mark Mitchell]

Jack Howarth wrote:

Richard,
This problem appears to be caused by...

Author: rsandifo
Date: Thu Dec 27 11:26:06 2007
New Revision: 131198

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131198
Log:
libgcc/
* Makefile.in (all): Use install-leaf rather than install.
(install): Split most of the rule into...
(install-leaf): ...this new one.


It's certainly desirable to fix this before the release, but Darwin bugs 
are not release blockers for 4.3.0.


The GCC SC has been discussing the Darwin situation.  There are two 
basic criteria for being a primary platform: (1) utility to users of the 
FSF GCC releases, and (2) active maintenance.  There hasn't been enough 
in the way of active maintenance for Darwin to make it possible to 
maintain Primary Platform status for Darwin for 4.3.0.


That statement doesn't imply anything about what status Darwin might 
have in the future; if there's active maintenance -- as, it looks like, 
there may very well be, given that we have a volunteer for the position 
-- then that might well reactivate Darwin, even for later 4.3.x releases.


Thanks,

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

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

[Jack Howarth]

Mark,
   I can understand the FSF gcc developers' frustration at
the lack of participation by the darwin developers. However
I still think it merits at least understanding why r131198
is breaking the linkage on darwin. It may well be that darwin
to exposing a latent bug in the use of install-leaf.
Jack

On Fri, Feb 29, 2008 at 11:04:24AM -0800, Mark Mitchell wrote:
> Jack Howarth wrote:
>> Richard,
>> This problem appears to be caused by...
>>
>> Author: rsandifo
>> Date: Thu Dec 27 11:26:06 2007
>> New Revision: 131198
>>
>> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131198
>> Log:
>> libgcc/
>> * Makefile.in (all): Use install-leaf rather than install.
>> (install): Split most of the rule into...
>> (install-leaf): ...this new one.
>
> It's certainly desirable to fix this before the release, but Darwin bugs 
> are not release blockers for 4.3.0.
>
> The GCC SC has been discussing the Darwin situation.  There are two basic 
> criteria for being a primary platform: (1) utility to users of the FSF GCC 
> releases, and (2) active maintenance.  There hasn't been enough in the way 
> of active maintenance for Darwin to make it possible to maintain Primary 
> Platform status for Darwin for 4.3.0.
>
> That statement doesn't imply anything about what status Darwin might have 
> in the future; if there's active maintenance -- as, it looks like, there 
> may very well be, given that we have a volunteer for the position -- then 
> that might well reactivate Darwin, even for later 4.3.x releases.
>
> Thanks,
>
> -- 
> Mark Mitchell
> CodeSourcery
> [EMAIL PROTECTED]
> (650) 331-3385 x713

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

[Mark Mitchell]

Jack Howarth wrote:

Mark,
   I can understand the FSF gcc developers' frustration at
the lack of participation by the darwin developers. However
I still think it merits at least understanding why r131198
is breaking the linkage on darwin. It may well be that darwin
to exposing a latent bug in the use of install-leaf.


I didn't mean to imply otherwise.  My statement was simply that 
Darwin-only problems are not in and of themselves release-blockers for 
4.3.0.


Thanks,

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

merging trunk into MELT branch: svn merge or svnmerge merge?

[Basile STARYNKEVITCH]

Hello All,

I'm trying to have the MELT branch following as closely as possible the 
GCC trunk. I'm on Debian/Sid/AMD64 and have both svn (version 
1.4.6dfsg1-1 of package subversion) and svnmerge (in package 
subversion-tools of same version) which is coded in Python (I've got 
version 2.4.4)


But I probably misunderstood what is the best tool for merging the GCC 
trunk into the MELT branch. Usually the merging is straightforward, 
because the MELT branch is mostly new files. Occasionnaly, I have to 
"merge" by hand (i.e. handle conflicts, typically in gcc/passes.c).


What is the best tool to use, svnmerge or the merge subcommand of svn?

I'm quite confused actually. I tried to use svnmerge but I tend to think 
it didn't do what I expect.


Ideally either a reference or the full sequence of commands to run would 
be helpful (assuming I can restart from pristine MELT branch & trunk)


I'm sorry to ask, but I remember having read both hints I suppose 
svnmerge is some wrapper above svn merge, but I know have doubts. And I 
am not a Subversion expert. I know only the few commands I'm using daily...


Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: merging trunk into MELT branch: svn merge or svnmerge merge?

[Diego Novillo]

On 2/29/08 3:35 PM, Basile STARYNKEVITCH wrote:

Ideally either a reference or the full sequence of commands to run would 
be helpful (assuming I can restart from pristine MELT branch & trunk)


I personally prefer to use svnmerge.py.  It Just Works.  There is a 
short tutorial on the GCC wiki somewhere (sorry, I forget exactly where).


Once initialized, doing a merge is just a matter of executing 
'svnmerge.py merge'.  It even leaves a merge log file for you to use in 
your commit message (I use it to get the revision numbers).


I have never used 'svn merge', so I cannot really give you an unbiased 
opinion.



Diego.

Re: merging trunk into MELT branch: svn merge or svnmerge merge?

[Ben Elliston]

> What is the best tool to use, svnmerge or the merge subcommand of svn?

I have never used svn merge, but instead learned to use svnmerge right
from the outset, from advice given to me at the time.

> I'm quite confused actually. I tried to use svnmerge but I tend to think 
> it didn't do what I expect.
> 
> Ideally either a reference or the full sequence of commands to run would 
> be helpful (assuming I can restart from pristine MELT branch & trunk)

When you create your branch, you need to run svnmerge init.  This will
create an svn property at the top-level of your tree, which you check
in.

>From time to time, you will run svnmerge merge.  The svnmerge script
knows which trunk revisions are present on your branch and will bring
across any that are missing.  You then commit these.  (Make sure you
have no local changes in your tree before doing this, otherwise you will
end up committing them, too.)

It's really quite easy once you get the hang of it!

Cheers, Ben

GCC wiki very slow?

[Basile STARYNKEVITCH]

Hello

Is it only me, or not: I'm finding the GCC wiki very slow and 
unresponsive... Apparently, much more than a couple of months ago


It seems so slow (and I'm using the same PC, the same network, ...) that 
sometimes I click twice on the Save button (hence overloading the HTTP 
server which is already crowded).


I'm afraid I cannot help much about it...

Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: merging trunk into MELT branch: svn merge or svnmerge merge?

[Ben Elliston]

> I added a small note on http://gcc.gnu.org/wiki/SvnMerge

As I was replying, I knew that this should have been going into the
wiki.  Thanks for paying your dues.  :-)

Ben

Re: merging trunk into MELT branch: svn merge or svnmerge merge?

[Basile STARYNKEVITCH]

Hello All,

Diego Novillo wrote:
I personally prefer to use svnmerge.py.  It Just Works.  


I suppose that svnmerge.py is the /usr/bin/svnmerge (at least, it seems 
to be last time I checked)


And Ben Elliston wrote:
> From time to time, you will run svnmerge merge.

That is what I think I did.

Regards, and thanks to both of you.

I added a small note on http://gcc.gnu.org/wiki/SvnMerge

Sorry for the noise.

Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: GCC wiki very slow?

[Manuel López-Ibáñez]

On 29/02/2008, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> I use the exact same trick when I edit CompileFarm. The save button very
>  rarely returns (it happens less than 10% of the time) but always
>  work when I check in the second tab.

Brilliant minds think alike. ;-) Is that a saying or I just made it up?

Cheers,

Manuel.

Re: GCC wiki very slow?

[Laurent GUERBY]

On Fri, 2008-02-29 at 22:22 +0100, Manuel López-Ibáñez wrote:
> On 29/02/2008, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
> > Hello
> >
> >  Is it only me, or not: I'm finding the GCC wiki very slow and
> >  unresponsive... Apparently, much more than a couple of months ago
> 
> I experience the same, even worse, after saving the page I always get
> an error but then the page is saved correctly. I normally have an
> extra tab with the page open and as soon as I click save, I switch to
> the other tab and reload the page. The page is saved way before the
> original tab gives any indication whatsoever. You can even give up and
> close the original tab and start working in the saved page.

I use the exact same trick when I edit CompileFarm. The save button very
rarely returns (it happens less than 10% of the time) but always
work when I check in the second tab.

Laurent

Re: GCC wiki very slow?

[Manuel López-Ibáñez]

On 29/02/2008, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
> Hello
>
>  Is it only me, or not: I'm finding the GCC wiki very slow and
>  unresponsive... Apparently, much more than a couple of months ago

I experience the same, even worse, after saving the page I always get
an error but then the page is saved correctly. I normally have an
extra tab with the page open and as soon as I click save, I switch to
the other tab and reload the page. The page is saved way before the
original tab gives any indication whatsoever. You can even give up and
close the original tab and start working in the saved page.

Cheers,

Manuel.

Re: merging trunk into MELT branch: svn merge or svnmerge merge?

[Manuel López-Ibáñez]

On 29/02/2008, Ben Elliston <[EMAIL PROTECTED]> wrote:
> > I added a small note on http://gcc.gnu.org/wiki/SvnMerge
>
>
> As I was replying, I knew that this should have been going into the
>  wiki.  Thanks for paying your dues.  :-)
>

The seach function of the wiki is crap. Do use google
site:http://gcc.gnu.org/wiki to search in the wiki.

Now, there is:

http://gcc.gnu.org/wiki/SvnBranch

We have the information about using subversion very scattered around...

Also we miss some important info and links. For example:
http://www.orcaware.com/svn/wiki/Svnmerge.py

Cheers,

Manuel.

Re: Some help with fold_convert() on RECORD_TYPEs

[FX Coudert]

Works for me.  Ok if that passes bootstrap / regtest and with a proper
changelog entry.


Committed as rev. 132780 with the following ChangeLog, thanks!

2008-02-29  Francois-Xavier Coudert  <[EMAIL PROTECTED]>

* fold-const.c (fold_convertible_p): Correct the logic to  
follow

that in fold_convert().


FX

--
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/

gcc-4.4-20080229 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 132780

You'll find:

gcc-4.4-20080229.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20080229.tar.bz2 C front end and core compiler

gcc-ada-4.4-20080229.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20080229.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20080229.tar.bz2  C++ front end and runtime

gcc-java-4.4-20080229.tar.bz2 Java front end and runtime

gcc-objc-4.4-20080229.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20080229.tar.bz2The GCC testsuite

Diffs from 4.4-20080222 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
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.

Issues stopping us from removing libcall notes

[Steven Bosscher]

Hello,

Every time someone brings up the idea to remove libcall notes, people
have to think really hard why GCC still has them.  It seemed like a
good idea to record and collect these issues in a meta-bug. Thus, see
PR35413.  Please open a new bug report (enhancement request, probably)
for things that GCC still needs libcalls for, and make your new bug
report block PR34513.  Of course, it'd help if you then go on and
remove that dependency on libcall notes ;-)

Gr.
Steven

[PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

This is a request to depcrecate -ftrapv which has numerous problems
making it not work as expected since a long time.  As nobody seems
to have the energy to ensure it is working I propose to deprecate it
for GCC 4.3 to make it possible to remove it during 4.4 (and not
block removing libcall notes by it).

Ok for 4.3?  I'll prepare an entry for the changes.html as well.

Thanks,
Richard.

2008-03-01  Richard Guenther  <[EMAIL PROTECTED]>

* doc/invoke.texi (ftrapv): Deprecate.

Index: doc/invoke.texi
===
*** doc/invoke.texi (revision 132767)
--- doc/invoke.texi (working copy)
*** this option defaults to true and false r
*** 14752,14759 
  
  @item -ftrapv
  @opindex ftrapv
! This option generates traps for signed overflow on addition, subtraction,
! multiplication operations.
  
  @item -fwrapv
  @opindex fwrapv
--- 14752,14760 
  
  @item -ftrapv
  @opindex ftrapv
! This option is supposed to generate traps for signed overflow on addition,
! subtraction and multiplication operations.  This option is deprecated
! as it does not work in most cases.
  
  @item -fwrapv
  @opindex fwrapv

Re: birthpoints in rtl.

[Diego Novillo]

On 2/28/08 8:32 AM, Paolo Bonzini wrote:

FUD chains are basically SSA without subscripts -- and hence, without 
overlapping live ranges.


No, they have subscripts.  They just do not have OLRs.


Diego.

Re: birthpoints in rtl.

[Diego Novillo]

On 2/27/08 6:15 PM, Kenneth Zadeck wrote:


Comments? Volunteers?


How about adding FUD chains instead of the dense UD chains we have 
today?  FUD chains are almost trivial to port from gimple-ssa into RTL. 
We already overlay a use-def web on the RTL representation using the new 
dataflow bits.


Unless I'm missing something obvious, we could easily convert those 
dense chains into factored chains by inserting real PHI nodes and 
building a FUD chain web.


The code to compute insertion points is almost totally independent from 
the IL (it should not be hard to adapt to the DF def/use 
representation).  We just need to have a way of representing PHI nodes. 
 No changes to the RTL representation should be necessary.


We could even adapt the global live-in computation to prune the 
dominance frontiers.  But that's just an optimization.


I may be able to spend some time on this.



Diego.

Re: birthpoints in rtl.

[Diego Novillo]

On 2/28/08 8:59 AM, Jan Hubicka wrote:


Yes, I do believe that wast majority of DU/UD code can stay as it is.
We just need to introduce the PHI nodes, either in a way Gimple does
that in separate section of CFG or as real RTL noop moves (or we can
even have RTL PHI code that would behave same way as USEs does
not, ie bypass machine validation issues).


Introducing them as objects in the DF datastructures may be more 
convenient.  You just make them a separate list of PHI nodes in each BB 
as we have in GIMPLE.




Diego.

Re: birthpoints in rtl.

[Diego Novillo]

On 2/28/08 8:03 AM, Kenneth Zadeck wrote:


The big difference between what i am proposing with birthpoints and a
full blown ssa implementation is that i plan to do no rewriting since
there are no operands of the phis to support this.


You don't need to do a rewriting SSA implementation to have PHI nodes 
with operands.  FUD chains fully support PHI nodes with operands.




I believe that what i am proposing is actually currently called (or at
least related to) factored use def chains, but i need to read up on the
literature to see if they really are the same.


Yes, they are.  FUD chains are what I initially used on GIMPLE, but they 
do not allow overlapping live ranges for different SSA names of the same 
symbol, so for GIMPLE registers I implemented the basic rewriting form 
and for memory symbols I implemented FUD chains (the SSA web over 
VDEF/VUSEs are FUD chains).


If we are not going to use a rewriting SSA form, I believe that the 
original problems we had with RTL-SSA can be avoided.



Diego.

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Sat, 1 Mar 2008, Richard Guenther wrote:

> 
> This is a request to depcrecate -ftrapv which has numerous problems
> making it not work as expected since a long time.  As nobody seems
> to have the energy to ensure it is working I propose to deprecate it
> for GCC 4.3 to make it possible to remove it during 4.4 (and not
> block removing libcall notes by it).

Actually not wrapping libcall notes around the libcalls will fix
some bugs with -ftrapv (not that it would work then -- the tree
optimizers break it completely, then expansion, then the
libcall notes and then libgcc itself).  Still, -ftrapv is broken
and we should get rid of it.  But there is probably no hurry to
do so for 4.3, it just would be nice to see it all gone in 4.4 ;)

Richard.

Re: birthpoints in rtl.

[Steven Bosscher]

On Fri, Feb 29, 2008 at 11:51 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>  If we are not going to use a rewriting SSA form, I believe that the
>  original problems we had with RTL-SSA can be avoided.

The nice thing about birth points would be that most RTL optimizers
can look through NOPs (amazingly ;-). That's a big plus IMHO.

I am not sure what would happen if GCC would start using FUD chains.
Is it like in SSA that every register is assigned only once?  That
would break all RTL optimizers that look at lexical equivalence of
expressions, like e.g. all optimizations in gcse.c. When faced with a
PHI node, those optimizers would punt and lose.

Gr.
Steven

Re: [PATCH][4.3] Deprecate -ftrapv

[Mark Mitchell]

Richard Guenther wrote:

This is a request to depcrecate -ftrapv which has numerous problems
making it not work as expected since a long time.  As nobody seems
to have the energy to ensure it is working I propose to deprecate it
for GCC 4.3 to make it possible to remove it during 4.4 (and not
block removing libcall notes by it).


Why doesn't it work?  Can it be made to work relatively easily?  Do we 
need functionality like this for Ada or Java?


Thanks,

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

Re: birthpoints in rtl.

[Diego Novillo]

On 2/29/08 7:04 PM, Steven Bosscher wrote:


I am not sure what would happen if GCC would start using FUD chains.
Is it like in SSA that every register is assigned only once?


But this would only affect the UD chains built by the DF code.  My idea 
is to build the same UD chains, but make them sparse instead of the 
dense web we have today.  None of this would be in the IL stream, only 
on the DF web.


Representing PHI nodes as a NOP could be an option for getting an 
initial implementation quickly.



Diego.

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Kenner]

> Why doesn't it work?  Can it be made to work relatively easily?  Do we 
> need functionality like this for Ada or Java?

Ada currently has to do this itself, precisely because -ftrapv doesn't
work, so it's not the case that Ada "needs" it.

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Sat, 1 Mar 2008, Richard Guenther wrote:

> This is a request to depcrecate -ftrapv which has numerous problems
> making it not work as expected since a long time.  As nobody seems
> to have the energy to ensure it is working I propose to deprecate it
> for GCC 4.3 to make it possible to remove it during 4.4 (and not
> block removing libcall notes by it).
> 
> Ok for 4.3?  I'll prepare an entry for the changes.html as well.

If this does need to be deprecated (and it's a feature for which I hope 
someone will step forward to fix or reimplement it, since we know people 
have used it to find integer overflow bugs in their code, despite its 
known limitations), it should give a deprecation warning on all 
compilations using the option, not just be deprecated in documentation.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Fri, 29 Feb 2008, Mark Mitchell wrote:

> Richard Guenther wrote:
> > This is a request to depcrecate -ftrapv which has numerous problems
> > making it not work as expected since a long time.  As nobody seems
> > to have the energy to ensure it is working I propose to deprecate it
> > for GCC 4.3 to make it possible to remove it during 4.4 (and not
> > block removing libcall notes by it).
> 
> Why doesn't it work?  Can it be made to work relatively easily?  Do we need
> functionality like this for Ada or Java?

The tree optimizers do not recognize +-* of singed integers as
possibly trapping which causes functions to become const/pure that
should not and causes 'dead' code to be removed that should not.

We do expand +-* allowing LIBCALL_WIDEN which will for example
use DImode on x86_64 where the libgcc implementation then of course
traps on DImode overflow rather than whatever smaller mode we
were interested in.

We wrap the libcalls inside libcall notes using REG_EQUAL notes
which indicate the libcalls compute non-trapping +-* (there's no
RTX code for the trappingness), so we combine and simplify the
operations making the libcall possibly dead and remove it again.

Just to mention the few problems I stumbled over while looking
at PR19020 some time ago.

Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[David Daney]

Mark Mitchell wrote:

Richard Guenther wrote:

This is a request to depcrecate -ftrapv which has numerous problems
making it not work as expected since a long time.  As nobody seems
to have the energy to ensure it is working I propose to deprecate it
for GCC 4.3 to make it possible to remove it during 4.4 (and not
block removing libcall notes by it).


Why doesn't it work?  Can it be made to work relatively easily?  Do we 
need functionality like this for Ada or Java?




Java only traps on integer division by zero.  As I understand it, this 
is handled by a different mechanism.


David Daney

Re: [PATCH][4.3] Deprecate -ftrapv

[Richard Guenther]

On Sat, 1 Mar 2008, Joseph S. Myers wrote:

> On Sat, 1 Mar 2008, Richard Guenther wrote:
> 
> > This is a request to depcrecate -ftrapv which has numerous problems
> > making it not work as expected since a long time.  As nobody seems
> > to have the energy to ensure it is working I propose to deprecate it
> > for GCC 4.3 to make it possible to remove it during 4.4 (and not
> > block removing libcall notes by it).
> > 
> > Ok for 4.3?  I'll prepare an entry for the changes.html as well.
> 
> If this does need to be deprecated (and it's a feature for which I hope 
> someone will step forward to fix or reimplement it, since we know people 
> have used it to find integer overflow bugs in their code, despite its 
> known limitations), it should give a deprecation warning on all 
> compilations using the option, not just be deprecated in documentation.

I seriously doubt anyone has used it for anything useful since at least
the advent of tree-ssa.  I see we for example warn for -fforce-mem
in 4.2, but that is a no-op there.  Do we have an option to disable
such warnings?  After all it would break -Werror.

Richard.

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Sat, 1 Mar 2008, Richard Guenther wrote:

> I seriously doubt anyone has used it for anything useful since at least
> the advent of tree-ssa.  I see we for example warn for -fforce-mem
> in 4.2, but that is a no-op there.  Do we have an option to disable
> such warnings?  After all it would break -Werror.

-fforce-mem isn't an option affecting the semantics of code the same way 
as -ftrapv is, and -ftrapv is more likely to be used manually from time to 
time to check for certain types of bugs rather than in makefiles with 
-Werror.  Telling someone using it manually as a debugging tool that it's 
being deprecated seems useful.  (NB: we should be clear that it's only the 
particular implementation that's proposed for deprecation and removal, and 
not the principle of having the -ftrapv feature should someone wish to fix 
or reimplement it.)

Bruno Haible used -ftrapv to find bugs in GNU clisp a year ago 
 (that message doesn't 
state whether the compiler version was post-tree-ssa).  Building without 
optimization, as in that case, would I suppose have avoided some of the 
-ftrapv bugs.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: [PATCH][4.3] Deprecate -ftrapv

[Mark Mitchell]

Richard Guenther wrote:


The tree optimizers do not recognize +-* of singed integers as
possibly trapping which causes functions to become const/pure that
should not and causes 'dead' code to be removed that should not.


Thanks for the explanations.  It seems like tree-ssa should in theory 
make it easier to implement this; for example, at the point of 
gimplification one could insert checks, and then just let everything 
else do its thing.  I don't see how libcalls and such would matter in 
that scheme.  I'm not denying that this is a project, though.


I fully agree that claiming things work when they don't is bad -- we 
don't want to lie to the users!  But, is the failure mode that we issue 
run-time errors when we shouldn't, or that we don't issue run-time 
errors when we should?  The latter is much less severe than the former.


I guess you've withdrawn the deprecation request, so maybe this is 
something of a moot point now?  I certainly agree that we shouldn't let 
a non-working feature stand in the way of improvements in 4.4.


Thanks,

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

Re: Issues stopping us from removing libcall notes

[Kenneth Zadeck]

Steven Bosscher wrote:
> Hello,
>
> Every time someone brings up the idea to remove libcall notes, people
> have to think really hard why GCC still has them.  It seemed like a
> good idea to record and collect these issues in a meta-bug. Thus, see
> PR35413.  Please open a new bug report (enhancement request, probably)
> for things that GCC still needs libcalls for, and make your new bug
> report block PR34513.  Of course, it'd help if you then go on and
> remove that dependency on libcall notes ;-)
>
> Gr.
> Steven
>   
note that steven listed two bugzilla's.  The correct number is 35413.
It is remarkable that i was able to notice this with my dyslexia.

kenny

Re: birthpoints in rtl.

[Kenneth Zadeck]

Diego Novillo wrote:
> On 2/29/08 7:04 PM, Steven Bosscher wrote:
>
>> I am not sure what would happen if GCC would start using FUD chains.
>> Is it like in SSA that every register is assigned only once?
>
> But this would only affect the UD chains built by the DF code.  My
> idea is to build the same UD chains, but make them sparse instead of
> the dense web we have today.  None of this would be in the IL stream,
> only on the DF web.
>
> Representing PHI nodes as a NOP could be an option for getting an
> initial implementation quickly.
>
>
> Diego.
Diego,

I am leaning to just adding noop moves at the birthpoints (dominance
frontiers) as real noop move insns in the streams in the passes that use
ud or du chains.   The back end is tolerant of noop moves and without
the rest of the baggage of phi functions most of the passes that want du
or ud chains will just do fine with the moves.  I personally dislike the
fact that the middle end keeps the phi's separate.  Once you do the
renaming for ssa form, the program has no meaning without the phi
functions, so keeping them separate always seemed somewhat bogus. 
however i do not work on the middle end, so i never had standing to
complain about. 

 The two complications are:
1) libcalls
2) how do you merge different types of subregs stores. 

We have our best people working on (1) and the hope is that unless
someone adds a killer reason to enhancement bugzilla 35413, we should be
able to make that abomination go away forever.  I plan to clear
enhancement bugzilla 35404 this weekend.

I am still hoping for one of the subreg elite to volunteer to help me
with (2). 

Then my plan is to "adapt" as much of the tree ssa code (there is no
reason for me to write dominance frontier code for the 4 time from
scratch) as possible to inserting the noop moves where the phi would
normally go and adapt the renaming step to build the chains. I have not
read the fud papers closely, but reif's trick of using for using the
birthpoints means that you can actually avoid having to solve reaching
defs, and can just adapt the ssa stack based renaming algorithm to build
the chains rather than rename the vars.  I have no idea if wolfe ever
figured this part out or not. 

Kenny

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Fri, 29 Feb 2008, Mark Mitchell wrote:

> Thanks for the explanations.  It seems like tree-ssa should in theory make it
> easier to implement this; for example, at the point of gimplification one
> could insert checks, and then just let everything else do its thing.  I don't
> see how libcalls and such would matter in that scheme.  I'm not denying that
> this is a project, though.

Obviously you need to keep the functions in libgcc in any event for the 
sake of old object code (just as we keep __eprintf there), even if you 
make GCC generate inline code rather than libcalls or remove the option 
entirely.

You also need to deal with fold, which will optimize away potentially 
trapping computations with -ftrapv and runs before gimplification 
(possibly in association with making fold run at gimplification time and 
not before).

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: [PATCH][4.3] Deprecate -ftrapv

[Mark Mitchell]

Joseph S. Myers wrote:

You also need to deal with fold, which will optimize away potentially 
trapping computations with -ftrapv and runs before gimplification 
(possibly in association with making fold run at gimplification time and 
not before).


Indeed.  However, errors missed due to fold eliminating them before 
gimplification would be a false negative, so less of a problem.  Since 
this feature is designed to crash your program when it has a bug, 
crashing your program somewhat less often doesn't make the feature 
useless; just less useful.


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

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Richard Guenther wrote:

This is a request to depcrecate -ftrapv which has numerous problems
making it not work as expected since a long time.  As nobody seems
to have the energy to ensure it is working I propose to deprecate it
for GCC 4.3 to make it possible to remove it during 4.4 (and not
block removing libcall notes by it).


Seems a pity, this feature is really needed for Ada, which requires
efficient overflow checking for signed arithmetic, and it seems
useful for C, where signed overflow is undefined, and it would be
nice to enable trapping.

Right now, Ada uses really horrible double length arithmetic to
do trapping.

So I would hestitate to deprecate it so quickly

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

[Jack Howarth]

Mark,
   One other question. Does the bug fixed by the offending patch...

http://gcc.gnu.org/ml/gcc-patches/2007-12/msg01010.html

...merit breaking even a secondary target? Wouldn't it be better
to regress that patch out for gcc 4.3.0 (to be reintroduced in
gcc 4.3.1 when the problems that it causes for darwin are solved)?
Jack



On Fri, Feb 29, 2008 at 11:57:33AM -0800, Mark Mitchell wrote:
> Jack Howarth wrote:
>> Mark,
>>I can understand the FSF gcc developers' frustration at
>> the lack of participation by the darwin developers. However
>> I still think it merits at least understanding why r131198
>> is breaking the linkage on darwin. It may well be that darwin
>> to exposing a latent bug in the use of install-leaf.
>
> I didn't mean to imply otherwise.  My statement was simply that Darwin-only 
> problems are not in and of themselves release-blockers for 4.3.0.
>
> Thanks,
>
> -- 
> Mark Mitchell
> CodeSourcery
> [EMAIL PROTECTED]
> (650) 331-3385 x713

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Richard Kenner wrote:
Why doesn't it work?  Can it be made to work relatively easily?  Do we 
need functionality like this for Ada or Java?


Ada currently has to do this itself, precisely because -ftrapv doesn't
work, so it's not the case that Ada "needs" it.


Well no one "needs" anything in this sense, any interfaced is Turing
complete so there is *always* a work around deficiencies in the back 
end. But right now, the "do this itself" is really horribly inefficient:



procedure k (x : out integer; y,z : integer) is
begin
   x := y + z;
end;



procedure k (x : out integer; y : integer; z : integer) is
begin
   [constraint_error when
 not (long_long_integer?(y) + long_long_integer?(z) in
   -16#8000_# .. 16#7FFF_#)
 "overflow check failed"]
   x := integer?(long_long_integer?(y) + long_long_integer?(z));
   return;
end k;



assembly language (-O2) with -gnato to enable overflow checking


__ada_k:
LFB3:
pushl   %ebp
LCFI0:
movl%esp, %ebp
LCFI1:
pushl   %ebx
LCFI2:
subl$4, %esp
LCFI3:
movl8(%ebp), %eax
movl12(%ebp), %ecx
movl%eax, %edx
movl%ecx, %ebx
sarl$31, %edx
sarl$31, %ebx
addl%eax, %ecx
adcl%edx, %ebx
movl%ecx, %eax
addl$-2147483648, %eax
movl%ebx, %edx
adcl$0, %edx
cmpl$0, %edx
jbe L6
pushl   %eax
pushl   %eax
pushl   $3
pushl   $LC0
LCFI4:
call___gnat_rcheck_10
.p2align 4,,7
L6:
movl%ecx, %eax
movl-4(%ebp), %ebx
leave
ret


pretty gruesome :-(

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

David Daney wrote:

Mark Mitchell wrote:

Richard Guenther wrote:

This is a request to depcrecate -ftrapv which has numerous problems
making it not work as expected since a long time.  As nobody seems
to have the energy to ensure it is working I propose to deprecate it
for GCC 4.3 to make it possible to remove it during 4.4 (and not
block removing libcall notes by it).
Why doesn't it work?  Can it be made to work relatively easily?  Do we 
need functionality like this for Ada or Java?




Java only traps on integer division by zero.  As I understand it, this 
is handled by a different mechanism.


The situation is:

Ada: integer overflow checking required (it's off by default in GNAT,
but you get required standard behavior by using -gnato, the reason
it is off by default is that the code is so horrible).

Java: integer overflow checking is prohibited, wrap around semantics
is required (IMO a horrible choice, but there you are!)

C: integer overflow undefined, checking desirable at least for
debugging purposes.

I think latest Fortran is same as C, can someone confirm?


David Daney

Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin

[Mark Mitchell]

Jack Howarth wrote:

Mark,
   One other question. Does the bug fixed by the offending patch...

http://gcc.gnu.org/ml/gcc-patches/2007-12/msg01010.html

...merit breaking even a secondary target? Wouldn't it be better
to regress that patch out for gcc 4.3.0 (to be reintroduced in
gcc 4.3.1 when the problems that it causes for darwin are solved)?


I think it's important, since, IIUC, it improves our ability to test on 
all platforms.  But, I certainly encourage you to figure out why it 
breaks Darwin and work out how to fix it!


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

Re: [PATCH][4.3] Deprecate -ftrapv

[Joseph S. Myers]

On Fri, 29 Feb 2008, Robert Dewar wrote:

> Well no one "needs" anything in this sense, any interfaced is Turing
> complete so there is *always* a work around deficiencies in the back end. But
> right now, the "do this itself" is really horribly inefficient:

You can see the C code in libgcc2.c (__addvSI3 etc.) used by -ftrapv (that 
code depends on signed overflow wrapping as has been noted before, it 
should of course be written with unsigned types).  It does use 
double-width types for multiplication (and some more complicated code for 
multiplication of types that are already double-width).

If it were done at gimplification time I imagine something like the libgcc 
code would be used, but with conversions to/from unsigned inserted as 
needed.  It would be possible to do optimizations at gimplification time 
if one argument is constant (converting to a range check).

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: [PATCH][4.3] Deprecate -ftrapv

[Robert Dewar]

Joseph S. Myers wrote:

On Fri, 29 Feb 2008, Robert Dewar wrote:


Well no one "needs" anything in this sense, any interfaced is Turing
complete so there is *always* a work around deficiencies in the back end. But
right now, the "do this itself" is really horribly inefficient:


You can see the C code in libgcc2.c (__addvSI3 etc.) used by -ftrapv (that 
code depends on signed overflow wrapping as has been noted before, it 
should of course be written with unsigned types).  It does use 
double-width types for multiplication (and some more complicated code for 
multiplication of types that are already double-width).


If it were done at gimplification time I imagine something like the libgcc 
code would be used, but with conversions to/from unsigned inserted as 
needed.  It would be possible to do optimizations at gimplification time 
if one argument is constant (converting to a range check).


Well presumably one would want to use target dependent stuff for
detecting overflow where it exists (sticky overflow bits on
power, O flag on PC, trapping add on MIPS etc).

Re: birthpoints in rtl.

[Diego Novillo]

On Fri, Feb 29, 2008 at 20:39, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:

>  I personally dislike the fact that the middle end keeps the phi's separate.

Six of one, half a dozen of the other.  If you put the PHIs in the IL
stream, then you need to be careful about not moving anything before
or in between them.  They also have different semantic properties:
they execute all in parallel and so the result of one PHI cannot be
used as an argument in another PHI in the same block.  Things like SSA
propagation need to treat them differently, etc.

Some things would potentially become easier, while others become more
difficult.  It would probably a good experiment to run on a branch
some time.

>  Then my plan is to "adapt" as much of the tree ssa code (there is no
>  reason for me to write dominance frontier code for the 4 time from
>  scratch)

You don't need to.  Dominance information is completely IL
independent.  It only needs the CFG.

>  [ ... ] and can just adapt the ssa stack based renaming algorithm to build
>  the chains rather than rename the vars.  I have no idea if wolfe ever
>  figured this part out or not.

Yes, he did.  That's the main point behind my proposal.

Both FUD chains and rewriting SSA operate in *exactly* the same way,
we do not need two renaming algorithms in tree-into-ssa.c.  The only
difference between FUD chains and rewriting SSA is that the former
does not modify the statement, it merely rewrites the VDEF/VUSE
operands (thus creating the SSA web).  If you adapt the algorithm to
simply rewrite the DF chains, you will be set.

FUD chains are never part of the IL, so by converting the UD links to
factored UD links in the DF data structure, you should be able to get
all the benefit of the sparser representation.

What if you treated subregs as total writes (like we do arrays) and
libcalls as clobbering points?  Though I guess that may not be
sufficient.


Diego.

Re: birthpoints in rtl.

[Kenneth Zadeck]

Diego Novillo wrote:
> What if you treated subregs as total writes (like we do arrays) and
> libcalls as clobbering points?  Though I guess that may not be
> sufficient.
>
>   
it is more productive to spend the cycles getting rid of the libcalls
rather than figuring out the edge cases.   as steven implied, we have
been on the verge of getting rid of them for years and just have just
not fixed the last reason.   The amount of time that we spent in 4.3
fixing the last two libcall bugs could have been much better spent just
ditching them.

subcall writes are not total kills and we are careful to model them
correctly when we see them individually.  The question that i have is
when you see a join where one arm modifies the the first byte and the
other arm modifies the 4th byte.   there is no store to the second and
third bytes and no way in rtl to exactly model it as a single move. 

I just do not know.  It may be that you just assume that you move the
entire reg and be done with it.

kenny

> Diego.
>   

RE: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

[Weddington, Eric]

 

> -Original Message-
> From: Ralf Wildenhues [mailto:[EMAIL PROTECTED] 
> Sent: Friday, February 29, 2008 11:33 AM
> To: dju
> Cc: gcc@gcc.gnu.org
> Subject: Re: Successfull build of gcc 4.2.3 with MinGW 5.13 
> in windows XP
> 
> * dju wrote on Fri, Feb 29, 2008 at 03:19:45AM CET:
> > platform : microsoft windowsXP(32) sp2 intel core duo
> >
> > i managed to build gcc-4.2.3 using MinGW-5.1.3 candidate 
> with gcc 3.4.5
> and binutils-2.17.50 in MSYS-1.0.10
> [...]
> >
> > only one change in gcc-4.2.3 source :
> >  in /work/src/gcc-4.2.3/libada/Makefile.in line 30
> >  [EMAIL PROTECTED]@
> >  by
> >  LN_S=cp
> 
> Why was that change necessary?  Can you post the error that you got
> without it?
> 
> Thanks,
> Ralf

Hi Ralf,

This is a very old issue. MinGW/MSYS does not support links. The easiest
way around this is to just copy the file.

I don't know if there is a bug report around for this.

Eric Weddington

Re: Draft SH uClinux FDPIC ABI

[Alexandre Oliva]

On Feb 29, 2008, "Joseph S. Myers" <[EMAIL PROTECTED]> wrote:

> Thanks - there were lots more typos in the original (spell-checking it 
> might be a good idea).

Indeed :-(  Thanks.

>> I've just fixed it in FR-V FDPIC 1.0b.

> Is there a more recent location to reference than 
> , which still seems to 
> have 1.0a?

No, that's it, I just hadn't pushed it yet.  Just did.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}

Re: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

[Brian Dessent]

"Weddington, Eric" wrote:

> This is a very old issue. MinGW/MSYS does not support links. The easiest
> way around this is to just copy the file.

But MSYS's 'ln -s' command makes copies of files for exactly this
reason, so the question remains why it's necessary to hack it to be cp.

Brian

Re: GCC wiki very slow?

[NightStrike]

On 2/29/08, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 29/02/2008, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
> > I use the exact same trick when I edit CompileFarm. The save button very
> >  rarely returns (it happens less than 10% of the time) but always
> >  work when I check in the second tab.

If no one can edit the wiki without timeouts, shouldn't something be
done on the server to address that?

> Brilliant minds think alike. ;-) Is that a saying or I just made it up?

It exists in various forms, such as "Great minds..." etc.

RE: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

[Weddington, Eric]

 

> -Original Message-
> From: Brian Dessent [mailto:[EMAIL PROTECTED] 
> Sent: Friday, February 29, 2008 9:35 PM
> To: Weddington, Eric
> Cc: Ralf Wildenhues; dju; gcc@gcc.gnu.org
> Subject: Re: Successfull build of gcc 4.2.3 with MinGW 5.13 
> in windows XP
> 
> "Weddington, Eric" wrote:
> 
> > This is a very old issue. MinGW/MSYS does not support 
> links. The easiest
> > way around this is to just copy the file.
> 
> But MSYS's 'ln -s' command makes copies of files for exactly this
> reason, so the question remains why it's necessary to hack it 
> to be cp.

Hi Brian,

You're definitely the expert on this. Has MSYS always done this? Or was
there an older version that didn't that the OP might be using?

Re: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

[Brian Dessent]

"Weddington, Eric" wrote:

> You're definitely the expert on this. Has MSYS always done this? Or was
> there an older version that didn't that the OP might be using?

I'm fairly sure it has been implemented like that since the beginning.

One possible reason why you might need to force cp to be used would be
if you're using Cygwin as a build environment (but with MinGW tools
first in the PATH, i.e. not using Cygwin gcc.)  In that case the Cygwin
'ln -s' would be used and would create Cygwin symlinks, but the MinGW
tools won't be able to recognise them.  But the poster said he was using
MSYS so that doesn't appear to be relevant here.

Brian

RE: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

[Weddington, Eric]

 

> -Original Message-
> From: Brian Dessent [mailto:[EMAIL PROTECTED] 
> Sent: Friday, February 29, 2008 10:12 PM
> To: Weddington, Eric
> Cc: gcc@gcc.gnu.org; Ralf Wildenhues; dju
> Subject: Re: Successfull build of gcc 4.2.3 with MinGW 5.13 
> in windows XP
> 
> I'm fairly sure it has been implemented like that since the beginning.
> 
> One possible reason why you might need to force cp to be used would be
> if you're using Cygwin as a build environment (but with MinGW tools
> first in the PATH, i.e. not using Cygwin gcc.)  In that case 
> the Cygwin
> 'ln -s' would be used and would create Cygwin symlinks, but the MinGW
> tools won't be able to recognise them.

Ah, that's where I remember this issue! I've done exactly that in the
past and run into the same problem as the OP.

>  But the poster said 
> he was using
> MSYS so that doesn't appear to be relevant here.

Hmpf. Dunno then. But if the symptoms fit...

Re: [PATCH][4.3] Deprecate -ftrapv

[Tom Tromey]

> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:

Mark> Do we need functionality like this for Ada or Java?

It is not needed for Java.

Tom