Re: Old GCC-on-Tru64 bugfix needs applying

[Gerald Pfeifer]

I have seen Bruce very response, even recently, but your mail does
not have any direct reference to [fixincl] in the subject, so let
me include him explicitly.

Gerald

On Fri, 27 Feb 2009, Daniel Richard G. wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
> 
> This bug was originally reported against 3.4.0. It is still present in 
> 4.3.3. Giovanni Bajo came up with a patch to fixincludes to take care of 
> it. Bruce Korb was supposed to apply it, but he seems to have gone AWOL.
> 
> To whoever is currently maintaining fixincludes: Please apply this fix, and 
> let this bug die with dignity.
> 
> 
> --Daniel
> 
> 
> P.S.: Please Cc: me on any replies, as I am not subscribed to this list.

Re: New no-undefined-overflow branch

[Richard Guenther]

On Fri, 27 Feb 2009, Diego Novillo wrote:

> On Thu, Feb 26, 2009 at 06:05, Richard Guenther  wrote:
> 
> 
> >  There shall be no construct in the GIMPLE IL that invokes
> >  undefined behavior.
> 
> Excellent!  Thanks for starting this branch.
> 
> > Thus, from now on integer overflow is defined and will wrap with
> > the usual twos-complement semantics.  Thus, for the middle-end
> > -fwrapv is always in effect.  This extends to pointer overflow.
> 
> You mean that -fwrapv is always in effect for the *V_EXPR operations,
> right?  PLUS_EXPR will always be defined as not overflowing.  It's up
> to the front end to emit one or the other.

-fwrapv is always in effect for the regular variants (PLUS_EXPR).
It is also in effect for the *NV_EXPR variants (yeah, the *V naming
was confusing...), but we know that overflow doesn't happen for them
so it doesn't matter what semantics overflow has - thus you can as
well say -fno-wrapv is in effect for them - but! - the *NV_EXPR
variants also exist for unsigned arithmetic just specifying the
same restriction - no overflow.

> How should we define merging two different TUs compiled with different
> -fwrapv settings?  This is something that may be common in the context
> of LTO:
> 
> $ gcc -flto -fwrapv f1.c
> $ gcc -flto f2.c
> $ gcc -o f -O2 f1.o f2.o
> 
> We will be reading IL containing both overflow and non-overflow
> operations.  We should define the combination rules for them.

There will be no use of flag_wrapv left after the frontends finished,
everything is encoded in the IL.  So combination of -fwrapv and
-fno-wrapv CUs is just "combine them".

> > Naming suggestions welcome, at the moment I consider NEGATEV_EXPR
> > (thus appending V to the first part).
> 
> As good a convention as any.

As was noted, NEGATENV_EXPR is less confusing.

Richard.

Re: New no-undefined-overflow branch

[Richard Guenther]

On Sat, 28 Feb 2009, Joseph S. Myers wrote:

> On Fri, 27 Feb 2009, Diego Novillo wrote:
> 
> > We will be reading IL containing both overflow and non-overflow
> > operations.  We should define the combination rules for them.
> 
> The rules are simple:
> 
> * No transformation (of arithmetic operations, which is what we are 
> discussing here) may change defined behavior for given inputs to undefined 
> behavior for those same inputs.  (The reverse transformation is permitted.  
> For example, a mixed set of addition/subtraction operations might usefully 
> be converted to all overflow-defined operations to allow the operands to 
> be rearranged and cancellation to take place.  For example, if both 
> versions of a+b with the same operands are in use at some point, the 
> overflow-undefined version need not be computed, only the overflow-wraps 
> version.)
> 
> * No transformation may change defined behavior for given inputs to 
> different, defined behavior for those inputs.

Indeed.  A safe way of combining mixed trees is to just drop the
*NV_EXPR variants to *_EXPR variants on the result.  Consider
(a -/nv 20) +/nv (b -/nv 20) where we see a re-association
opportunity to combine both constants.  The result is (a + b) - 40,
_not_ (a +/nv b) -/nv 40.  On trunk we have to disable this
re-association because the result would still be undefined overflow
(we don't have means to avoid this - other than doing the arithmetic
unsigned and perform conversions of course).

Richard.

Re: GNAT vs DW2/ZCX EH.

[Dave Korn]

Laurent GUERBY wrote:
> On Fri, 2009-02-27 at 21:04 +0100, Rolf Ebert wrote:
>>> Right, that's why the change should be reverted on the 4.3 branch.  On the 
>>> other hand, if you can get the ZCX support to work on the mainline before 
>>> 4.4.0 is released, we could try there.
>> FYI, I have just succeeded in building gcc-4.3.3 including Ada for MinGW 
>> by setting
>>ZCX_By_Default: constant Boolean := True;
>> in system-mingw.ads as suggested by Danny Smith.  The ACATS tests show 
>> quite some failures, though.  I don't know if they are due to the EH or 
>> if there are other causes.
> 
> Sometimes from the list of failures it's possible to identify what's
> broken. Did you send your test results to gcc-testresu...@? I couldn't
> find them.

  These figures are from Cygwin so won't be strictly commensurable, but it
would be interesting to compare them to the figures with that accidental
change reverted.

gcc-4.3.2, GNAT runtime statically linked, --disable-sjlj-exceptions.  (I
think this is basically 'anything that raises an exception fails'):

=== acats tests ===
FAIL:   a26007a
FAIL:   a83a02b
FAIL:   a85013b
FAIL:   a87b59a
FAIL:   a95001c
FAIL:   a95074d
FAIL:   a97106a
FAIL:   a99006a
FAIL:   ac3207a
FAIL:   ad7201a
FAIL:   ad7203b
FAIL:   ad7205b
FAIL:   ad8011a
FAIL:   ada101a
FAIL:   c23003a
FAIL:   c23003b
FAIL:   c23003g
FAIL:   c23003i
FAIL:   c32001b
FAIL:   c34007j
FAIL:   c34008a
FAIL:   c35102a
FAIL:   c35502d
FAIL:   c35502f
FAIL:   c35503d
FAIL:   c35503f
FAIL:   c37402a
FAIL:   c37403a
FAIL:   c380004
FAIL:   c38102d
FAIL:   c38202a
FAIL:   c390002
FAIL:   c39008a
FAIL:   c39008b
FAIL:   c39008c
FAIL:   c392002
FAIL:   c392003
FAIL:   c392013
FAIL:   c393008
FAIL:   c393009
FAIL:   c3a0003
FAIL:   c3a0004
FAIL:   c3a0010
FAIL:   c41306a
FAIL:   c41306b
FAIL:   c41306c
FAIL:   c41307d
FAIL:   c41401a
FAIL:   c43204g
FAIL:   c45231d
FAIL:   c45282b
FAIL:   c45291a
FAIL:   c46051a
FAIL:   c4a007a
FAIL:   c51004a
FAIL:   c59002c
FAIL:   c64201b
FAIL:   c64201c
FAIL:   c650001
FAIL:   c74004a
FAIL:   c74401k
FAIL:   c74406a
FAIL:   c760013
FAIL:   c761006
FAIL:   c761007
FAIL:   c83023a
FAIL:   c85004b
FAIL:   c85005a
FAIL:   c85005b
FAIL:   c85005c
FAIL:   c85005d
FAIL:   c85005e
FAIL:   c85006a
FAIL:   c85006b
FAIL:   c85006c
FAIL:   c85006d
FAIL:   c85006e
FAIL:   c85014a
FAIL:   c85014b
FAIL:   c85014c
FAIL:   c85018a
FAIL:   c85018b
FAIL:   c87b26b
FAIL:   c87b41a
FAIL:   c87b45c
FAIL:   c87b54a
FAIL:   c87b62d
FAIL:   c910001
FAIL:   c910002
FAIL:   c91004b
FAIL:   c91004c
FAIL:   c91006a
FAIL:   c91007a
FAIL:   c92002a
FAIL:   c92003a
FAIL:   c92005a
FAIL:   c92005b
FAIL:   c92006a
FAIL:   c930001
FAIL:   c93001a
FAIL:   c93002a
FAIL:   c93003a
FAIL:   c93004a
FAIL:   c93004b
FAIL:   c93004c
FAIL:   c93004d
FAIL:   c93004f
FAIL:   c93005a
FAIL:   c93005b
FAIL:   c93005d
FAIL:   c93007a
FAIL:   c93008a
FAIL:   c93008b
FAIL:   c940001
FAIL:   c940005
FAIL:   c940007
FAIL:   c940010
FAIL:   c940013
FAIL:   c940014
FAIL:   c940016
FAIL:   c94001a
FAIL:   c94001b
FAIL:   c94001c
FAIL:   c94001e
FAIL:   c94001f
FAIL:   c94001g
FAIL:   c94002a
FAIL:   c94002b
FAIL:   c94002d
FAIL:   c94002e
FAIL:   c94002f
FAIL:   c94002g
FAIL:   c94005b
FAIL:   c94006a
FAIL:   c94007a
FAIL:   c94007b
FAIL:   c94008a
FAIL:   c94008b
FAIL:   c94008c
FAIL:   c94008d
FAIL:   c94010a
FAIL:   c94011a
FAIL:   c94020a
FAIL:   c95008a
FAIL:   c95009a
FAIL:   c95010a
FAIL:   c95011a
FAIL:   c95012a
FAIL:   c95021a
FAIL:   c95022a
FAIL:   c95022b
FAIL:   c95033a
FAIL:   c95033b
FAIL:   c95034a
FAIL:   c95034b
FAIL:   c95035a
FAIL:   c95040a
FAIL:   c95040b
FAIL:   c95040c
FAIL:   c95040d
FAIL:   c95041a
FAIL:   c95065a
FAIL:   c95065b
FAIL:   c95065c
FAIL:   c95065d
FAIL:   c95065e
FAIL:   c95065f
FAIL:   c95066a
FAIL:   c95067a
FAIL:   c95071a
FAIL:   c95072a
FAIL:   c95072b
FAIL:   c95073a
FAIL:   c95074c
FAIL:   c95076a
FAIL:   c95078a
FAIL:   c95080b
FAIL:   c95082g
FAIL:   c95085a
FAIL:   c95085b
FAIL:   c95085c
FAIL:   c95085d
FAIL:   c95085e
FAIL:   c95085f
FAIL:   c95085g
FAIL:   c95085h
FAIL:   c95085i
FAIL:   c95085j
FAIL:   c95085k
FAIL:   c95085l
FAIL:   c95085m
FAIL:   c95085n
FAIL:   c95085o
FAIL:   c95086a
FAIL:   c95086b
FAIL:   c95086c
FAIL:   c95086d
FAIL:   c95086e
FAIL:   c95086f
FAIL:   c95087a
FAIL:   c95087b
FAIL:   c95087c
FAIL:   c95087d
FAIL:   c95088a
FAIL:   c95089a
FAIL:   c95090a
FAIL:   c95092a
FAIL:   c95093a
FAIL:   c95095a
FAIL:   c95095b
FAIL:   c95095c
FAIL:   c95095d
FAIL:   c95095e
FAIL:   c951001
FAIL:   c951002
FAIL:   c953001
FAIL:   c953002
FAIL:   c953003
FAIL:   c954001
FAIL:   c954010
FAIL:   c954011
FAIL:   c954012
FAIL:   c954013
FAIL:   c954014
FAIL:   c954015
FAIL:   c954016
FAIL:   c954017
FAIL:   c954018
FAIL:   c954019
FAIL:   c954020
FAIL:   c954021
FAIL:   c954022
FAIL:   c954023
FAIL:   c954024
FAIL:   c954025
FAIL:   c954026
FAIL:   c954a01
FAIL:   c954a02
FAIL:   c954a03
FAIL:   c960001
FAIL:   c960002
FAIL:   c960004
FAIL: 

Re: GNAT vs DW2/ZCX EH.

[Dave Korn]

Dave Korn wrote:

>   I've attached my current Ada patches 

  No I haven't!  I mean, Now I have!

cheers,
  DaveK
--- origsrc/gcc-4.3.2/gcc/ada/Makefile.in	2008-02-13 19:04:53.0 +
+++ src/gcc-4.3.2/gcc/ada/Makefile.in	2009-02-21 20:13:03.40625 +
@@ -198,6 +198,10 @@
 # Type of tools build we are doing; default is not compiling tools.
 TOOLSCASE =
 
+# Which install goal to use.
+INSTALL_GNATLIB_MAIN  = install-gnatlib
+INSTALL_GNATLIB_WIN32 = unused-install-gnatlib
+
 # End of variables for you to override.
 
 all: all.indirect
@@ -1298,7 +1302,7 @@
   LIBRARY_VERSION := $(subst .,_,$(LIB_VERSION))
 endif
 
-ifeq ($(strip $(filter-out cygwin32% mingw32% pe,$(osys))),)
+ifeq ($(strip $(filter-out cygwin% mingw% pe,$(osys))),)
   LIBGNAT_TARGET_PAIRS = \
   a-dirval.adb
+
+int
+__gnat_is_windows_xp (void)
+{
+  static int is_win_xp=0, is_win_xp_checked=0;
+
+  if (!is_win_xp_checked)
+{
+  OSVERSIONINFO version;
+
+  is_win_xp_checked = 1;
+
+  memset (&version, 0, sizeof (version));
+  version.dwOSVersionInfoSize = sizeof (version);
+
+  is_win_xp = GetVersionEx (&version)
+&& version.dwPlatformId == VER_PLATFORM_WIN32_NT
+&& (version.dwMajorVersion > 5
+|| (version.dwMajorVersion == 5 && version.dwMinorVersion >= 1));
+}
+  return is_win_xp;
+}
+
+#endif /* __CYGWIN__ */
+
 #ifdef VMS
 
 /* This gets around a problem with using the old threads library on VMS 7.0. */
--- origsrc/gcc-4.3.2/gcc/ada/system-mingw.ads	2007-12-19 16:22:26.0 +
+++ src/gcc-4.3.2/gcc/ada/system-mingw.ads	2009-02-22 04:08:37.28125 +
@@ -141,7 +141,7 @@
Always_Compatible_Rep : constant Boolean := True;
Suppress_Standard_Library : constant Boolean := False;
Use_Ada_Main_Program_Name : constant Boolean := False;
-   ZCX_By_Default: constant Boolean := False;
+   ZCX_By_Default: constant Boolean := True;
GCC_ZCX_Support   : constant Boolean := True;
 
---
--- origsrc/gcc-4.3.2/gcc/testsuite/ada/acats/run_all.sh	2006-09-14 11:12:03.0 +0100
+++ src/gcc-4.3.2/gcc/testsuite/ada/acats/run_all.sh	2009-02-08 02:29:10.359375000 +
@@ -13,7 +13,7 @@
 gnatflags="-gnatws"
 
 target_run () {
-$*
+	$testdir/run_test.exp $1 > $2 2>&1
 }
 
 # End of customization section.
@@ -99,7 +99,7 @@
 
 # Find out the size in bit of an address on the target
 target_gnatmake $testdir/support/impbit.adb >> $dir/acats.log 2>&1
-target_run $dir/support/impbit > $dir/support/impbit.out 2>&1
+target_run $dir/support/impbit $dir/support/impbit.out
 target_bit=`cat $dir/support/impbit.out`
 echo target_bit="$target_bit" >> $dir/acats.log
 
@@ -276,7 +276,7 @@
   if [ ! -x $dir/tests/$chapter/$i/$binmain ]; then
  sync
   fi
-  target_run $dir/tests/$chapter/$i/$binmain > $dir/tests/$chapter/$i/${i}.log 2>&1
+  target_run $dir/tests/$chapter/$i/$binmain $dir/tests/$chapter/$i/${i}.log
   cd $dir/tests/$chapter/$i
   cat ${i}.log >> $dir/acats.log
   egrep -e '( |\+\+\+\+ |\!\!\!\! )' ${i}.log > /dev/null 2>&1
--- origsrc/gcc-4.3.2/gcc/testsuite/ada/acats/run_test.exp	1970-01-01 00:00:00.0 +
+++ src/gcc-4.3.2/gcc/testsuite/ada/acats/run_test.exp	2009-02-08 02:28:26.015625000 +
@@ -0,0 +1,10 @@
+#!/usr/bin/expect -f
+
+set timeout 300
+
+spawn -noecho $argv
+expect timeout {
+   send_user "Program timed out.\n"
+   exit 1
+}
+

Re: GNAT vs DW2/ZCX EH.

[Laurent GUERBY]

On Sat, 2009-02-28 at 10:51 +, Dave Korn wrote:
> Laurent GUERBY wrote:
> > On Fri, 2009-02-27 at 21:04 +0100, Rolf Ebert wrote:
> >>> Right, that's why the change should be reverted on the 4.3 branch.  On 
> >>> the 
> >>> other hand, if you can get the ZCX support to work on the mainline before 
> >>> 4.4.0 is released, we could try there.
> >> FYI, I have just succeeded in building gcc-4.3.3 including Ada for MinGW 
> >> by setting
> >>ZCX_By_Default: constant Boolean := True;
> >> in system-mingw.ads as suggested by Danny Smith.  The ACATS tests show 
> >> quite some failures, though.  I don't know if they are due to the EH or 
> >> if there are other causes.
> > 
> > Sometimes from the list of failures it's possible to identify what's
> > broken. Did you send your test results to gcc-testresu...@? I couldn't
> > find them.
> 
>   These figures are from Cygwin so won't be strictly commensurable, but it
> would be interesting to compare them to the figures with that accidental
> change reverted.
> 
> gcc-4.3.2, GNAT runtime statically linked, --disable-sjlj-exceptions.  (I
> think this is basically 'anything that raises an exception fails'):

Thanks for the list. I think it's more tasking which is broken than
exceptions since many exception tests do PASS, eg: c34001c. "c9"
tests are tasking test and they all FAIL.

Laurent

Re: GNAT vs DW2/ZCX EH.

[Arnaud Charlet]

> IMO you cannot backport such an incompatible change to a release branch.  If 
> the Windows maintainers are confident enough with it and given that we know 
> there is no fundamental issue as far as GNAT is concerned, why not try?

Because stage 4 is not the right stage for such experiments.

Also, we're talking about cygwin AFAIK, which we've never built/tested,
so we have no idea what the state of things are there.

Arno

Re: GNAT vs DW2/ZCX EH.

[Rolf Ebert]

OK, I rebuilt gnat-4.3.3 on MinGW using ZCX_By_Default = False 
(system-mingw.ads) and no EH_MECHANISM line in Makefile.in for MinGW.

I also increased the default stack size in system-mingw.ads to
   pragma Linker_Options ("-Wl,--stack=0x280");

Here are the ACATS results running gnat with gccflags="-O3 
-fomit-frame-pointer -funroll-all-loops -finline-functions"



=== acats tests ===
Running chapter a ...
Running chapter c2 ...
Running chapter c3 ...
FAIL:   c37010a   stack overflow
FAIL:   c380004
Running chapter c4 ...
FAIL:   c43204i   stack overflow
FAIL:   c45672a
FAIL:   c460009
Running chapter c5 ...
FAIL:   c52103p   stack overflow
FAIL:   c52104f
FAIL:   c52104p   stack overflow
Running chapter c6 ...
Running chapter c7 ...
Running chapter c8 ...
FAIL:   c83e02a   stack overflow
Running chapter c9 ...
FAIL:   c91006a   stack overflow
FAIL:   c95008a
Running chapter ca ...
Running chapter cb ...
Running chapter cc ...
FAIL:   cc3121a
FAIL:   cc3601a
Running chapter cd ...
FAIL:   cd10001   build problem
FAIL:   cd1009a   stack overflow
FAIL:   cd1009i   stack overflow
FAIL:   cd1c03a   stack overflow
FAIL:   cd2a21a   stack overflow
FAIL:   cd2a21c   stack overflow
FAIL:   cd2a21e   stack overflow
FAIL:   cd2a22j   stack overflow
FAIL:   cd2a23a   stack overflow
FAIL:   cd2a23e   stack overflow
FAIL:   cd2a24a   stack overflow
FAIL:   cd2a31a   stack overflow
FAIL:   cd2a31c   stack overflow
FAIL:   cd2a32a   stack overflow
FAIL:   cd30001   build problem
FAIL:   cd5003a   build problem
FAIL:   cd5003b   build problem
FAIL:   cd5003c   build problem
FAIL:   cd5003d   build problem
FAIL:   cd5003e   build problem
FAIL:   cd5003f   build problem
FAIL:   cd5003g   build problem
FAIL:   cd5003h   build problem
FAIL:   cd5003i   build problem
FAIL:   cd5011a   build problem
FAIL:   cd5011c   build problem
FAIL:   cd5011e   build problem
FAIL:   cd5011g   build problem
FAIL:   cd5011i   build problem
FAIL:   cd5011k   build problem
FAIL:   cd5011m   build problem
FAIL:   cd5011q   build problem
FAIL:   cd5011s   build problem
FAIL:   cd5012a   build problem
FAIL:   cd5012b   build problem
FAIL:   cd5012e   build problem
FAIL:   cd5012f   build problem
FAIL:   cd5012i   build problem
FAIL:   cd5012m   build problem
FAIL:   cd5013a   build problem
FAIL:   cd5013c   build problem
FAIL:   cd5013e   build problem
FAIL:   cd5013g   build problem
FAIL:   cd5013i   build problem
FAIL:   cd5013k   build problem
FAIL:   cd5013m   build problem
FAIL:   cd5013o   build problem
FAIL:   cd5014a   build problem
FAIL:   cd5014c   build problem
FAIL:   cd5014e   build problem
FAIL:   cd5014g   build problem
FAIL:   cd5014i   build problem
FAIL:   cd5014k   build problem
FAIL:   cd5014m   build problem
FAIL:   cd5014o   build problem
FAIL:   cd5014t   build problem
FAIL:   cd5014v   build problem
FAIL:   cd5014x   build problem
FAIL:   cd5014y   build problem
FAIL:   cd5014z   build problem
Running chapter ce ...
Running chapter cxa ...
FAIL:   cxacb01
FAIL:   cxacb02
FAIL:   cxacc01
Running chapter cxb ...
Running chapter cxf ...
Running chapter cxg ...
Running chapter cxh ...
Running chapter cz ...
Running chapter d ...
Running chapter e ...
Running chapter gcc ...
Running chapter l ...
=== acats Summary ===
# of expected passes2200
# of unexpected failures76

Re: GNAT vs DW2/ZCX EH.

[Eric Botcazou]

> Here are the ACATS results running gnat with gccflags="-O3
> -fomit-frame-pointer -funroll-all-loops -finline-functions"

Thanks a lot.  Would you mind running it again with the default flags (-O2)?  
We don't have comparison points with these non-standard flags.

-- 
Eric Botcazou

Re: GNAT vs DW2/ZCX EH.

[Rolf Ebert]

Would you mind running it again with the default flags (-O2)?  
We don't have comparison points with these non-standard flags.


OK, here are the results with only -O2.  All the errors in chapter cd 
are due to a build problem on my machine (the test programs cannot find 
spprt13.ads).  Altough I already provide a linker option to increase 
stack size to 40MB there is still one program failing in a stack overflow.


Rolf

=== acats tests ===
Running chapter a ...
Running chapter c2 ...
Running chapter c3 ...
FAIL:   c32001b   stack overflow
Running chapter c4 ...
Running chapter c5 ...
Running chapter c6 ...
Running chapter c7 ...
Running chapter c8 ...
Running chapter c9 ...
Running chapter ca ...
Running chapter cb ...
Running chapter cc ...
Running chapter cd ...
FAIL:   cd10001
FAIL:   cd30001
FAIL:   cd5003a
FAIL:   cd5003b
FAIL:   cd5003c
FAIL:   cd5003d
FAIL:   cd5003e
FAIL:   cd5003f
FAIL:   cd5003g
FAIL:   cd5003h
FAIL:   cd5003i
FAIL:   cd5011a
FAIL:   cd5011c
FAIL:   cd5011e
FAIL:   cd5011g
FAIL:   cd5011i
FAIL:   cd5011k
FAIL:   cd5011m
FAIL:   cd5011q
FAIL:   cd5011s
FAIL:   cd5012a
FAIL:   cd5012b
FAIL:   cd5012e
FAIL:   cd5012f
FAIL:   cd5012i
FAIL:   cd5012m
FAIL:   cd5013a
FAIL:   cd5013c
FAIL:   cd5013e
FAIL:   cd5013g
FAIL:   cd5013i
FAIL:   cd5013k
FAIL:   cd5013m
FAIL:   cd5013o
FAIL:   cd5014a
FAIL:   cd5014c
FAIL:   cd5014e
FAIL:   cd5014g
FAIL:   cd5014i
FAIL:   cd5014k
FAIL:   cd5014m
FAIL:   cd5014o
FAIL:   cd5014t
FAIL:   cd5014v
FAIL:   cd5014x
FAIL:   cd5014y
FAIL:   cd5014z
Running chapter ce ...
Running chapter cxa ...
Running chapter cxb ...
Running chapter cxf ...
Running chapter cxg ...
Running chapter cxh ...
Running chapter cz ...
Running chapter d ...
Running chapter e ...
Running chapter gcc ...
Running chapter l ...
=== acats Summary ===
# of expected passes2232
# of unexpected failures48

Re: Old GCC-on-Tru64 bugfix needs applying

[Bruce Korb]

Based on my read of the bug report, it looks like I had meant to "approve"
Daniel's patch and expected him to install it.  It looks like I managed
to miss the ``Will you take care of committing the final patch please?''
comment.  Sorry about that.  By February 2007, I was no longer getting
Veritas email.  I'll likely always get GNU email.  Anyway, I've got
to rebuild current GCC source and test this thing again, so it may not
be today.

Regards, Bruce

Gerald Pfeifer wrote:
> I have seen Bruce very responsive, even recently, but your mail does
> not have any direct reference to [fixincl] in the subject, so let
> me include him explicitly.
> 
> Gerald
> 
> On Fri, 27 Feb 2009, Daniel Richard G. wrote:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
>>
>> This bug was originally reported against 3.4.0. It is still present in 
>> 4.3.3. Giovanni Bajo came up with a patch to fixincludes to take care of 
>> it. Bruce Korb was supposed to apply it, but he seems to have gone AWOL.
>>
>> To whoever is currently maintaining fixincludes: Please apply this fix, and 
>> let this bug die with dignity.
>>
>>
>> --Daniel
>>
>>
>> P.S.: Please Cc: me on any replies, as I am not subscribed to this list.
> 

Re: GNAT vs DW2/ZCX EH.

[Eric Botcazou]

> OK, here are the results with only -O2.

Thanks, not bad modulo the cd chapter.

> All the errors in chapter cd are due to a build problem on my machine (the
> test programs cannot find spprt13.ads).

It is supposed to be generated during the preparation phase.

> Altough I already provide a linker option to increase stack size to 40MB
> there is still one program failing in a stack overflow. 

That could also be just a segmentation fault.

-- 
Eric Botcazou

Re: GNAT vs DW2/ZCX EH.

[Eric Botcazou]

> Because stage 4 is not the right stage for such experiments.

I doubt that this can be deemed an experiment, we know that it works.

> Also, we're talking about cygwin AFAIK, which we've never built/tested,
> so we have no idea what the state of things are there.

It's not just cygwin, it's also mingw.  The Ada compiler is quite broken on 
Windows since 4.3 because of the merge glitch.

-- 
Eric Botcazou

GCC Build failure

[Bruce Korb]

Hi all,

This got far enough along to run fixincludes, so I can test this
``Old GCC-on-Tru64 bugfix'' thing, but still.  Using current SVN source:

# If this is the top-level multilib, build all the other
# multilibs.
/home/gnu/proj/gcc/_bld/./gcc/xgcc -B/home/gnu/proj/gcc/_bld/./gcc/ 
-B/usr/local/x86_64-unknown-linux-gnu/bin/ 
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem 
/usr/local/x86_64-unknown-linux-gnu/include -isystem 
/usr/local/x86_64-unknown-linux-gnu/sys-include -g -O2 -m32 -O2  -g -O2 
-DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
-Wcast-qual -Wold-style-definition  -isystem ./include  -fPIC -g 
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. 
-I../../.././gcc -I../../../../libgcc -I../../../../libgcc/. 
-I../../../../libgcc/../gcc -I../../../../libgcc/../include 
-I../../../../libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS 
-DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c 
../../../../libgcc/../gcc/libgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
In file included from /usr/include/features.h:354,
 from /usr/include/stdio.h:28,
 from ../../../../libgcc/../gcc/tsystem.h:90,
 from ../../../../libgcc/../gcc/libgcc2.c:34:
/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory
make[5]: *** [_muldi3.o] Error 1
make[5]: Leaving directory 
`/home/gnu/proj/gcc/_bld/x86_64-unknown-linux-gnu/32/libgcc'
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory 
`/home/gnu/proj/gcc/_bld/x86_64-unknown-linux-gnu/libgcc'
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory 
`/home/gnu/proj/gcc/_bld/x86_64-unknown-linux-gnu/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/home/gnu/proj/gcc/_bld'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/gnu/proj/gcc/_bld'
make: *** [bootstrap] Error 2

$ history
[...]
   11  rm -rf *
   12  ../configure --enable-languages=c
   13  make
   14  rm -rf *
   15  ../configure --enable-languages=all
   16  make bootstrap
   17  history
$ ../config.guess
x86_64-unknown-linux-gnu
$ gcc --version
gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Re: GNAT vs DW2/ZCX EH.

[Arnaud Charlet]

> I doubt that this can be deemed an experiment, we know that it works.

We know that it works with our sources and GCC 4.3. We have no idea how
well it works with GCC 4.4: we don't do mingw builds there.

> It's not just cygwin, it's also mingw.  The Ada compiler is quite broken on 
> Windows since 4.3 because of the merge glitch.

The merge glitch should be fixed, no doubt about that.

But I'm against doing more than fixing the merge glitch at this stage.

Arno

Re: GCC Build failure

[H.J. Lu]

On Sat, Feb 28, 2009 at 9:27 AM, Bruce Korb  wrote:
> Hi all,
>
> This got far enough along to run fixincludes, so I can test this
> ``Old GCC-on-Tru64 bugfix'' thing, but still.  Using current SVN source:
>
> # If this is the top-level multilib, build all the other
> # multilibs.
> /home/gnu/proj/gcc/_bld/./gcc/xgcc -B/home/gnu/proj/gcc/_bld/./gcc/ 
> -B/usr/local/x86_64-unknown-linux-gnu/bin/ 
> -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem 
> /usr/local/x86_64-unknown-linux-gnu/include -isystem 
> /usr/local/x86_64-unknown-linux-gnu/sys-include -g -O2 -m32 -O2  -g -O2 
> -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
> -Wcast-qual -Wold-style-definition  -isystem ./include  -fPIC -g 
> -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. 
> -I../../.././gcc -I../../../../libgcc -I../../../../libgcc/. 
> -I../../../../libgcc/../gcc -I../../../../libgcc/../include 
> -I../../../../libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS 
> -DUSE_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c 
> ../../../../libgcc/../gcc/libgcc2.c \
>          -fvisibility=hidden -DHIDE_EXPORTS
> In file included from /usr/include/features.h:354,
>                 from /usr/include/stdio.h:28,
>                 from ../../../../libgcc/../gcc/tsystem.h:90,
>                 from ../../../../libgcc/../gcc/libgcc2.c:34:
> /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or 
> directory

You need to install 32bit glibc or disable multilib.


-- 
H.J.

Re: GNAT vs DW2/ZCX EH.

[Arnaud Charlet]

> > I doubt that this can be deemed an experiment, we know that it works.
> 
> We know that it works with our sources and GCC 4.3. We have no idea how
> well it works with GCC 4.4: we don't do mingw builds there.

BTW, we have local patches not yet integrated that are needed for proper
ZCX support, in particular the need of a libgcc_s.dll becomes important when
you enable ZCX. We may have a few other mingw patches, to be checked.

Arno

Re: GNAT vs DW2/ZCX EH.

[Eric Botcazou]

> But I'm against doing more than fixing the merge glitch at this stage.

I think that the Windows maintainers should have the final word though.

-- 
Eric Botcazou

Re: GNAT vs DW2/ZCX EH.

[Arnaud Charlet]

> > But I'm against doing more than fixing the merge glitch at this stage.
> 
> I think that the Windows maintainers should have the final word though.

This change concerns more Ada than the windows port but in any case, I
can't imagine such change being put in stage 4.

Arno

Re: GCC Build failure

[Bruce Korb]

On Sat, Feb 28, 2009 at 9:31 AM, H.J. Lu  wrote:
>> In file included from /usr/include/features.h:354,
>>                 from /usr/include/stdio.h:28,
>>                 from ../../../../libgcc/../gcc/tsystem.h:90,
>>                 from ../../../../libgcc/../gcc/libgcc2.c:34:
>> /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or 
>> directory
>
> You need to install 32bit glibc or disable multilib.

Ah.  Thank you.  Would it be possible to fiddle the make in some way
so it says that a little more explicitly?  Thanks again.  Regards, Bruce

Re: Old GCC-on-Tru64 bugfix needs applying

[Daniel Richard G.]

On Sat, 2009 Feb 28 08:53:49 -0800, Bruce Korb wrote:
> Based on my read of the bug report, it looks like I had meant to "approve"
> Daniel's patch and expected him to install it.  It looks like I managed
> to miss the ``Will you take care of committing the final patch please?''
> comment.  Sorry about that.  By February 2007, I was no longer getting
> Veritas email.  I'll likely always get GNU email.  Anyway, I've got
> to rebuild current GCC source and test this thing again, so it may not
> be today.

Bruce, I appreciate the update. I wasn't sure that you were still the go-to 
guy for fixincludes.

It's Giovanni's patch, by the way :-)  I'm just the reporter.


--Daniel


-- 
NAME   = Daniel Richard G.   ##  Remember, skunks   _\|/_  meef?
EMAIL1 = sk...@iskunk.org##  don't smell bad---(/o|o\) /
EMAIL2 = sk...@alum.mit.edu  ##  it's the people who   < (^),>
WWW= http://www.**.org/  ##  annoy them that do!/   \
--
(** = site not yet online)

Getting better understanding of constraints and reload

[Georg-Johann Lay]

Hi, I already submitted some patches for the avr backend and have still 
a bunch of ideas for implrovements.


However, I am still unsure about insn constraints and what they must 
look like to work in any situation, and I want to learn more about that 
subject before commnuity tars and feathers me because of some bugs in 
some corner cases...


I am aware that reload is one of the most complex parts of gcc. However, 
from the backend's perspective, it should be sufficient to understand 
reload in terms of the constraint-interface, so that there is no need to 
dive into reload's internals too deep, no matter what technique reload 
applies internally.


I read

http://gcc.gnu.org/onlinedocs/gccint/Multi_002dAlternative.html#Multi_002dAlternative

several times but not everything is clear to me. Because it's hard to 
tell what's unclear, let me start by describing my understanding of insn 
constraints and please correct me if I am wrong or fundamentally 
uncomplete.


As far as I understand, before reload an insn matches because all of its 
predicates match (and, of course, insn pattern and insn condition match).


If a predicate P is regarded as a set, all predicates span a cross 
product P1 x P2 x ... Pn of sets. Reloading then means to map this set 
into a smaller set that can be described as the union of the cross 
products of constraints.


To make it a little bit more explicit, let's consider an insn that has 
just three operands and two constraint alternatives, i.e. what reload 
has to map is


P = P1 x P2 x P3 -> (A1 x A2 x A3) + (B1 x B2 x B3) = K

Or in terms of sloppy rtl
 (match_operand "P1"  "A1,B1")
 (match_operand "P2"  "A2,B2")
 (match_operand "P3"  "A3,B3")

What is unclear to me is what conditions the constraints must satisfy to 
make reload do a (good) job. And of course not abort.


If the constraints were written as one alternative like in
 (match_operand "P1"  "A1 B1")
 (match_operand "P2"  "A2 B2")
 (match_operand "P3"  "A3 B3")
the problem would be much easier, because then we had

P = P1 x P2 x P3 -> (A1 + B1) x (A2 + B2) x (A3 + B3) = K'

If K' covers the hard reg part of P, everything is fine. Right?
Reload will map each pseudo/virtual in Pn to some hard reg in An+Bn or 
do just noting if the operand is an immediate.


But what happens when two alternatives are present? Obviously K is (in 
general) smaller than K' and reload must avoid the "holes" by generating 
new insns. These new insns can be movXX insns or insns that describe 
secondary reloads (or insns to spill a reg to get a needed reg_class free).


Is the condition "K' covers the hard reg part of P" also sufficient so 
that reload will never encounter problems like "insn does not satisfy 
its contraints" in the case of more than one alternative?


Do ?, ! and * have effects on running reload without problems? Or are 
they just present to improve the work of reload?


Internals say that reload scans constraints from left to right and 
choses the alternative with the most matches, skipping *-alternatives 
for reg_class preference. Then it tries to reload the pseudos that did 
not yet get a hard reg into an appropriate reg_class, i.e. some that 
matches the constraint, preferably one returned in 
PREFERRED_RELOAD_CLASS. If that macro return NO_REGS, reload reruns and 
also takes alternatives which are !-marked into account.


What is the situation if some regs are already hard regs? Is reload 
allowed to move a hard reg to some other hard reg (provided the 
destination is unused) to satisfy (more) constraints?


What happens when elimination takes place? For AVR eliminating the frame 
pointer aginst stack pointer is trivial because offset is 0. But what is 
about the fake argument pointer elimination whose offset is not 0?
Does eliminating the arg pointer suddenly turn (reg) into (plus reg x) 
and mov must reload a plus expression? Or does reload switch to addhi3 
and addhi3 suddenly faces the predicates/constraints of movhi and must 
handle a much more general case?


Thanks in advance,

Georg-Johann

[wwwdocs] Re: Status of the DLX backend for GCC?

[Gerald Pfeifer]

On Tue, 7 Oct 2008, Peter Bergner wrote:
>> The reason I asked was that we have that reference from our site to that
>> URL and I failed to find any replacement so far.  The first two hits that
>> I get in Google actually are mails by you in the gcc archives. ;-)
>> 
>> I guess we'll just have to remove that reference?
> I talked with Aaron Sawdey and he still had the tarballs which he has
> given me.  Let me go through a build process with them to make sure they
> still build and then I'll post them somewhere you can link to.

It seems this hasn't made it to the top of your list, and I can understand 
that.  Let's not spend time on this, I'd say.  Today I realized that the 
DLX emulator also faces a similar fate and only builds with GCC 2.95, so 
let's just remove the reference.  Clearly interest is minimal.

The patch below is what I committed now.  Thanks again for the background
you provided, Peter!

Gerald

Index: extensions.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/extensions.html,v
retrieving revision 1.44
diff -u -3 -p -r1.44 extensions.html
--- extensions.html 25 Jan 2009 16:35:21 -  1.44
+++ extensions.html 28 Feb 2009 22:44:35 -
@@ -12,9 +12,6 @@ reason or the other, did not (yet) make 
 tree. Please direct feedback and bugreports to their respective
 maintainers, not our mailing lists.
 
-http://www-mount.ee.umn.edu/~okeefe/mcerg/gcc-dlx.html";>DLX 
port
-A GCC Machine Description for the DLX machine described in Computer
-Architecture: A Quantitative Approach by Hennessy and Patterson.
 
 http://pdp10.nocrew.org/gcc/";>PDP-10 port
 This is an experimental port of GCC to the DEC PDP-10

Re: Announce: MPFR 2.4.1 is released

[Vincent Lefevre]

Hi Kaveh,

On 2009-02-27 10:40:07 -0500, Kaveh R. GHAZI wrote:
> Thanks for the note.  I grep'ed the gcc sources and I don't see any uses
> of mpfr_snprintf or mpfr_vsnprintf.  So I don't believe any change in the
> minimum mpfr version checks (either "required" version or "recommended"
> version) is necessary in gcc due to this issue in mpfr.

FYI, mpfr_snprintf and mpfr_vsnprintf are new in MPFR 2.4.0 (but were
buggy in MPFR 2.4.0). So, if gcc needs them in the future, the minimum
required version would be 2.4.1.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

gcj -v --help: ecj switches

[Ralf Wildenhues]

Hello,

I have a patch (accompanying those other ones on gcc-paches) to fix

--- a/gcc/java/lang.opt
+++ b/gcc/java/lang.opt
@@ -209,212 +209,213 @@ Java
 
 ;
 ; Warnings handled by ecj.
-; FIXME: document them
 ;
 

but I did start off with the help texts from

which AFAICS falls under the Eclipse Public License - v 1.0
.

Now my question, before I blindly post this to {gcc,java}-patches and
thus create potential legal hassles for whoever works on it: was it
OKed (by the SC or FSF) to integrate such material into GCC?
If not, would you think that it suffices if I reformulate the entries
sufficiently, or do we need to start playing the legal game, if the
situation is to be improved?

Thanks!
Ralf