weird installation problem on i686-pc-linux-gnu

[Martin Reinecke]

Hi,

I'm observing a strange installation problem with the current mainline.
After configuration with

configure --quiet --prefix=$DESTDIR --enable-languages=c++,fortran 
--with-gmp=/afs/mpa/data/martin/mygmp --disable-checking

bootstrapping and installing, I end up with the following bin/ directory:

~>ls -R ~/data/ugcc/bin
/afs/mpa/home/martin/data/ugcc/bin:
c++*  g++*  gccbug  gfortran*   i686-pc-linux-gnu-g++*
cpp*  gcc/  gcov*   i686-pc-linux-gnu-c++*  i686-pc-linux-gnu-gfortran*

/afs/mpa/home/martin/data/ugcc/bin/gcc:
xgcc*

i.e. the "gcc" binary ends up as "xgcc" in a subdirectory called "gcc".

Interestingly enough, this does not happen on a x86_64-unknown-linux-gnu
machine.

Any idea what's happening here?

Thanks,
  Martin

-- 

Re: -Wuninitialized issues

[Neil Booth]

Jeffrey A Law wrote:-

> After pondering this some more I almost wonder if what we need is a 
> separate warning for variables which were potentially uninitialized
> but which optimization passes somehow proved were unused or the paths
> in which the variable was uninitialized were unexecutable.
> 
> So the early pass would catch unconditionally uninitialized variables;
> it would also record (but not warn for) maybe uninitialized variables
> (by detecting default definitions appearing in PHI nodes).
> 
> The late pass would then issue a may-be-uninitialized warning for
> any variables which still had a default definition appearing in a
> PHI node.

I think this is a better approach than the current one, and that
if we go down this patch then we should grasp the opportunity to
do it right - the early pass should be in the front end.  Let the
optimizers do the fancy cases.  90% of cases that catch bugs can
be handled in the front end I expect, with a very simple algorithm.

Neil.

Re: Vectorizing HIRLAM 4: complicated access patterns examined.

[Paul Thomas]

Toon,

I just read your contribution to the 2005 gcc summit about gfortran and 
HIRLAM.  The two PRs(18283 and 21034) you wrote about are now fixed.  
LOC is now available.  That just leaves some of the extra functionality 
of FLUSH(IOSTAT?), does it not?  Would it compile completely if I were 
to add that functionality?


Given the scale of your code, it would be a triumph worth reporting if 
we could get it up and running with gfortran.


Best regards

Paul

insufficient inline optimisation?

[Anthony Shipman]

I have a C++ class and code that looks like this:

#include 
using namespace std;

class Z
{
public:
Z() {}
~Z() {}

protected:
int z_;
};


int
main(int argc, char** argv)
{
Z   buf[100];

cout << sizeof(buf) << endl;
return 0;
}

The compiler version is 4.01 (on Fedora 4). If I compile with -O0 then the 
creation of buf results in a loop being generated which calls the Z() 
constructor 100 times.

But then if I compile with -O the constructor will be inlined. The generated 
machine code contains a loop which does nothing 100 times:
movl$100, %eax
.L11:
decl%eax
jne .L11

I think that the optimiser should get rid of the loop once it has got rid of 
the body!

Should I submit this as a bug?

Re: insufficient inline optimisation?

[Steven Bosscher]

On Nov 01, 2005 01:07 PM, Anthony Shipman <[EMAIL PROTECTED]> wrote:
> But then if I compile with -O the constructor will be inlined. The
> generated
> machine code contains a loop which does nothing 100 times:
> movl $100, %eax
> L11:
> decl %eax
> jne .L11
>
> I think that the optimiser should get rid of the loop once it has got
> rid of
> the body!
>
> Should I submit this as a bug?

I don't think so.  This kind of thing is optimized away by gcc 4.1
already.

Gr.
Steven
 
 

possible problem with long double

[Vivaldo]

Dear Sir,

I have found a difficult do work with long double. I have written a 
simple test code and compiled it with gcc 4.0.0. The code was the following


#include 
#include 

using namespace std;

main(){

long double x,y,a;
x = 1.001;  //(1 at 15th decimal place)
y = 1.002; //(idem)
a = y - x;
cout.precision(30);
cout << a << endl;
}

Surprinsingly, the output written in the screen was not

1.e-15

with 19 correct decimal places. Instead the result was

8.88178419700125232338905334473e-16

with error at the 16-th place!

How should I proceed to have the precision of 19 significative digits?

Thanks.

Vivaldo L. Campo.
Physicist - ICCMP - Brasilia - Brazil.

Re: GCC 4.0.2 Canadian Cross Compile

[Mark Fortescue]

Hi DJ Delorie,

I did not specify all the commandline arguments used in my email. I am
using --build= in the GCC builds (as required). The build arguments
in use when things go pair shaped are:
'/L64/src/gcc-4.0.0/gcc-4.0.2-p01/configure --build=i686-pc-linux-gnu
--target=sparc-linux --host=sparc-linux --prefix=/usr/crbld
--with-sysroot=/L64/sparc/tree/sparc-linux/sys-root
--includedir=/usr/include --with-local-prefix=/usr/local --disable-nls
--enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c,c++,ada --enable-shared --enable-c99
--enable-long-long'

I have found three issues so far. They are all in the ADA build. They are:

1) For native compiler builds, the build system assumes it can compile and
then run gnatmake using the  compiler. This only works if  =
. The fix I have used is to force a cross compilation. Under this
situation, the compiler build system does not fall for this error. I will
take another look at this and try to refine my changes so that they only
change things that are visibly incorrect. The error shows up when the
compilation gets to gcc-4.0.2/gcc/ada/Make-lang.in line 370. The problems
identified are:
 a) GCC_FOR_TARGET is set to ./xgcc {arguments} but ./xgcc will not run on
the  host.
 b) SET_GCC_LIB_PATH_CMD is set to include the build directory. This is
not valid when compiled code will not run on .

2) The build system assumes that ../../xgcc will run even if  is
not the same as . This can be fixed by changing the
gcc-4.0.2-p01/gcc/ada/Makefile.in gnatlib target to use a configuration
defined CC. See patch below:

-- PATCH ---
diff -ru gcc-4.0.2/gcc/ada/Makefile.in gcc-4.0.2-p01/gcc/ada/Makefile.in
--- gcc-4.0.2/gcc/ada/Makefile.in   2005-10-26 17:52:33.0 +0100
+++ gcc-4.0.2-p01/gcc/ada/Makefile.in   2005-11-01 08:14:46.0 +
@@ -135,6 +135,7 @@
 MISCLIB =
 SYMDEPS = $(LIBINTL_DEP)
 OUTPUT_OPTION = @OUTPUT_OPTION@
[EMAIL PROTECTED]@
 
 objext = .o
 exeext =
@@ -1825,12 +1826,12 @@
 # is guaranteed to overflow the buffer.
 
 gnatlib: ../stamp-gnatlib1 ../stamp-gnatlib2
-   $(MAKE) -C rts CC="../../xgcc -B../../" \
+   $(MAKE) -C rts CC="$(GNATLIB_GCC)" \
INCLUDES="$(INCLUDES_FOR_SUBDIR) -I./../.." \
 CFLAGS="$(GNATLIBCFLAGS_FOR_C)" \
srcdir=$(fsrcdir) \
-f ../Makefile $(LIBGNAT_OBJS)
-   $(MAKE) -C rts CC="../../xgcc -B../../" \
+   $(MAKE) -C rts CC="$(GNATLIB_GCC)" \
ADA_INCLUDES="" \
 CFLAGS="$(GNATLIBCFLAGS)" \
ADAFLAGS="$(GNATLIBFLAGS)" \
diff -ru gcc-4.0.2/gcc/configure.ac gcc-4.0.2-p01/gcc/configure.ac
--- gcc-4.0.2/gcc/configure.ac  2005-10-29 02:22:29.0 +0100
+++ gcc-4.0.2-p01/gcc/configure.ac  2005-10-29 18:30:49.0 +0100
@@ -3331,6 +3331,7 @@
 echo "Links are now set up to build a cross-compiler" 1>&2
 echo " from ${host} to ${target}." 1>&2
   fi
+  GNATLIB_GCC="../../xgcc -B../../"
 else
   if test x${host} = x${target} ; then
 echo "Links are now set up to build (on ${build}) a native compiler" 1>&2
@@ -3339,8 +3340,11 @@
 echo "Links are now set up to build (on ${build}) a cross-compiler" 1>&2
 echo " from ${host} to ${target}." 1>&2
   fi
+  GNATLIB_GCC="${target_alias}-gcc"
 fi
 
+AC_SUBST(GNATLIB_GCC)
+
 AC_ARG_VAR(GMPLIBS,[How to link GMP])
 AC_ARG_VAR(GMPINC,[How to find GMP include files])
 
diff -ru gcc-4.0.2/gcc/configure gcc-4.0.2-p01/gcc/configure
--- gcc-4.0.2/gcc/configure 2005-10-29 02:22:29.0 +0100
+++ gcc-4.0.2-p01/gcc/configure 2005-10-29 18:31:42.0 +0100
@@ -309,7 +309,7 @@
 # include 
 #endif"
 
-ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME 
PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix 
program_transform_name bindir sbindir libexecdir datadir sysconfdir 
sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir 
build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS build 
build_cpu build_vendor build_os host host_cpu host_vendor host_os target 
target_cpu target_vendor target_os target_noncanonical build_subdir host_subdir 
target_subdir gcc_version_trigger gcc_version_full gcc_version GENINSRC CC 
CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT NO_MINUS_C_MINUS_O OUTPUT_OPTION 
CPP EGREP strict1_warn warn_cflags WERROR nocommon_flag TREEBROWSER 
valgrind_path valgrind_path_defines valgrind_command coverage_flags 
enable_multilib enable_shared TARGET_SYSTEM_ROOT TARGET_SYSTEM_ROOT_DEFINE 
CROSS_SYSTEM_HEADER_DIR onestep SET_MAKE AWK LN_S LN RANLIB ac_ct_RANLIB 
ranlib_flags INSTALL INSTALL_PROGRAM INSTALL_DATA make_compare_target 
have_mktemp_command MAKEINFO BUILD_INFO GENERATED_MANPAGES FLEX BISON NM AR 
stage1_cflags COLLECT2_LIBS GNAT_LIBEXC LDEXP_LIB TARGET_GETGROUPS_T LIBICONV 
LTLIBICONV LIBICONV_DEP manext objext gthread_flags extra_modes_file PACKAGE 
VERSION USE_NLS LIBINTL LIBINTL_DE

Re: Vectorizing HIRLAM 4: complicated access patterns examined.

[Toon Moene]

> I just read your contribution to the 2005 gcc summit about gfortran
> and HIRLAM. The two PRs(18283 and 21034) you wrote about are now
> fixed. LOC is now available. That just leaves some of the extra
> functionality of FLUSH(IOSTAT?), does it not? Would it compile
> completely if I were to add that functionality?

I still have to construct a bug report of something that confuses the 
parser and that basically looks like this:


  IMPLICIT CHARACTER*8 (Y)
  CHARACTER*11 Y1, Y2, Y3
  ...
  YA = 'D' // Y1 // Y2(1:3) // Y3(1:3) //
 1 // YB(1:5)
   1
Unclassifiable statement at (1)

Unfortunately, if I reduce the code to this one (continued) line and the 
necessary declarations, it doesn't fail ;-)


All the other problems are with non-standard code (like flush, getarg, 
et al.), where I have to find standard-conforming solutions.  Note that 
I'm used to the fact that with almost all OS/compiler combinations we 
have to make a few local mods, because different compilers support 
different extensions (not surprising ...)


> Given the scale of your code, it would be a triumph worth reporting if
> we could get it up and running with gfortran.

Yep.  I'm convinced that by the time we hold the 2006 GCC summit I can 
not only compile all of HIRLAM, but present a running example and 
profiled runs, to direct optimizations.


Cheers,

--
Toon Moene, KNMI, The Netherlands
Phone: +31 30 2206443; e-mail: [EMAIL PROTECTED]

Re: possible problem with long double

[Andrew Haley]

Vivaldo writes:
 > Dear Sir,
 > 
 > I have found a difficult do work with long double. I have written a 
 > simple test code and compiled it with gcc 4.0.0. The code was the following
 > 
 > #include 
 > #include 
 > 
 > using namespace std;
 > 
 > main(){
 > 
 > long double x,y,a;
 > x = 1.001;  //(1 at 15th decimal place)
 > y = 1.002; //(idem)
 > a = y - x;
 > cout.precision(30);
 > cout << a << endl;
 > }
 > 
 > Surprinsingly, the output written in the screen was not
 > 
 > 1.e-15
 > 
 > with 19 correct decimal places. Instead the result was
 > 
 > 8.88178419700125232338905334473e-16
 > 
 > with error at the 16-th place!
 > 
 > How should I proceed to have the precision of 19 significative digits?

This list is not for general gcc enquiries, but for the development of
gcc itself.  Please address queries to gcc-help.

This is not a bug.  The type of a floating-point literal is double by
default, not long double.  See Section 2.13.3 of the C++ Standard,
"floating literals"

Andrew.

Re: Vectorizing HIRLAM 4: complicated access patterns examined.

[Tobias . Schlueter]

[ Bringing this back to fortran@, taking the optimizer guys out of CC: ]

Quoting Toon Moene:
> I still have to construct a bug report of something that confuses the parser
> and that basically looks like this:
>
>  IMPLICIT CHARACTER*8 (Y)
>  CHARACTER*11 Y1, Y2, Y3
>  ...
>  YA = 'D' // Y1 // Y2(1:3) // Y3(1:3) //
> 1 // YB(1:5)
>   1
> Unclassifiable statement at (1)
>
> Unfortunately, if I reduce the code to this one (continued) line and the
> necessary declarations, it doesn't fail ;-)

Does this fail as long as you keep the type implicit?  This reminds me of
another PR, where the parser would decide too early that it had seen an array
range instead of a substring, which would lead to these kinds of niceties
further down the line.  Unfortunately, I couldn't find this bug in bugzilla,
looks like its PR's summary is not very descriptive.

- Tobi

Re: insufficient inline optimisation?

[Florian Weimer]

* Steven Bosscher:

>> I think that the optimiser should get rid of the loop once it has got
>> rid of
>> the body!

> I don't think so.  This kind of thing is optimized away by gcc 4.1
> already.

Shouldn't this be listed in the changes.html file?

RE: resolving backslash newline whisky tango foxtrot: a proposal

[Dave Korn]

Per Bothner wrote:
> Joe Buck wrote:
>> So you want the compiler to only consider '\\$" a continuation,
> 
> Not my preference, but that is my proposal, in the interest
> of compatibility.
> 
>> but to have an unsilenceable warning about '\\ *$'?
> 
> Not unsilenceable - but on-by-default.  It could be silenced with
> an explicit -Wno-comment.  (Or whatever mechanism we use to
> control warnings.)
> 
> The point is that since it's silly and dangerous to depend on
> trailing whitespace, and it's normally a mistake, we should
> warn about it even without -Wall, but if people really want to
> live dangerously they can turn it off.
> 
>> That would appear not to
>> solve the problem of the customers who are wedded to their line art,
>> that started this discussion in the first place.
> 
> They can use -Wno-comment.


  Per, please.  We've been through these ***exact*** interchanges before.
You're now just reiterating the entire thread.  You aren't adding anything
new, just informing everyone which of the already-discussed possibilities your
own personal opinion happens to be.  And you aren't even offering a patch.

  This thread should have been over long ago.  Please, let it die with
dignity.[*]


cheers,
  DaveK

[*]  Or even without.  But please, let it die!
-- 
Can't think of a witty .sigline today

Re: insufficient inline optimisation?

[Steven Bosscher]

On Nov 01, 2005 02:07 PM, Florian Weimer <[EMAIL PROTECTED]> wrote:

> * Steven Bosscher:
>
> >> I think that the optimiser should get rid of the loop once it has
> >> got
> >> rid of
> >> the body!
>
> > I don't think so.  This kind of thing is optimized away by gcc 4.1
> > already.
>
> Shouldn't this be listed in the changes.html file?

Go ahead and propose a patch! ;-)
 
Gr.
Steven
 


Steven Bosscher
SUSE Labs

Re: insufficient inline optimisation?

[Andrew Pinski]

> The compiler version is 4.01 (on Fedora 4). If I compile with -O0 then the 
> creation of buf results in a loop being generated which calls the Z() 
> constructor 100 times.
> 
> But then if I compile with -O the constructor will be inlined. The generated 
> machine code contains a loop which does nothing 100 times:
>   movl$100, %eax
> .L11:
>   decl%eax
>   jne .L11
> 
> I think that the optimiser should get rid of the loop once it has got rid of 
> the body!
> 
> Should I submit this as a bug?

This has been fixed in 4.1.0 already.  This is the normal not removing
empty loops problem which was fixed in 4.1.0.

-- Pinski

Re: Vectorizing HIRLAM 4: complicated access patterns examined.

[Jakub Jelinek]

On Tue, Nov 01, 2005 at 02:01:43PM +0100, [EMAIL PROTECTED] wrote:
> [ Bringing this back to fortran@, taking the optimizer guys out of CC: ]
> 
> Quoting Toon Moene:
> > I still have to construct a bug report of something that confuses the parser
> > and that basically looks like this:
> >
> >  IMPLICIT CHARACTER*8 (Y)
> >  CHARACTER*11 Y1, Y2, Y3
> >  ...
> >  YA = 'D' // Y1 // Y2(1:3) // Y3(1:3) //
> > 1 // YB(1:5)
> >   1
> > Unclassifiable statement at (1)
> >
> > Unfortunately, if I reduce the code to this one (continued) line and the
> > necessary declarations, it doesn't fail ;-)
> 
> Does this fail as long as you keep the type implicit?  This reminds me of
> another PR, where the parser would decide too early that it had seen an array
> range instead of a substring, which would lead to these kinds of niceties
> further down the line.  Unfortunately, I couldn't find this bug in bugzilla,
> looks like its PR's summary is not very descriptive.

You mean PR18833?

Jakub

Re: Vectorizing HIRLAM 4: complicated access patterns examined.

[Tobias . Schlueter]

Quoting Jakub Jelinek <[EMAIL PROTECTED]>:
> On Tue, Nov 01, 2005 at 02:01:43PM +0100,
> [EMAIL PROTECTED] wrote:
> > [ Bringing this back to fortran@, taking the optimizer guys out of CC: ]
> >
> > Quoting Toon Moene:
> > > I still have to construct a bug report of something that confuses the
> parser
> > > and that basically looks like this:
> > >
> > >  IMPLICIT CHARACTER*8 (Y)
> > >  CHARACTER*11 Y1, Y2, Y3
> > >  ...
> > >  YA = 'D' // Y1 // Y2(1:3) // Y3(1:3) //
> > > 1 // YB(1:5)
> > >   1
> > > Unclassifiable statement at (1)
> > >
> > > Unfortunately, if I reduce the code to this one (continued) line and the
> > > necessary declarations, it doesn't fail ;-)
> >
> > Does this fail as long as you keep the type implicit?  This reminds me of
> > another PR, where the parser would decide too early that it had seen an
> array
> > range instead of a substring, which would lead to these kinds of niceties
> > further down the line.  Unfortunately, I couldn't find this bug in
> bugzilla,
> > looks like its PR's summary is not very descriptive.
>
> You mean PR18833?

Yes, but I don't have time right now to investigate if this is indeed the same
parser problem.  The patch for 18833 only added a special case for
EQUIVALENCEs, so it might well be.

- Tobi

SVK Tarball for complete trunk history

[Daniel Berlin]

is available

URL is
ftp://gcc.gnu.org/pub/gcc/infrastructure/svn-trunk-entire-history.tar.rz

Re: -Wuninitialized issues

[Diego Novillo]

On Monday 31 October 2005 18:49, Jeffrey A Law wrote:

> Thoughts?
>
I'm not sure this would buy you much better precision.  I was tinkering 
with PR 18501 a few days ago.  This is one of those cases where the 
optimizers (CCP in this case) remove the code that we were supposed to 
warn about.  It goes something like this (all variables are locals):

bitmap_print_value_set ()
{
  # first_1 = PHI ;
:;
  D.1286_3 = bmp_iter_set ();
  if (D.1286_3 != 0) goto ; else goto ;

:;
  if (first_1 == 0) goto ; else goto ;

:;
  something ();

:;
  first_4 = 0;
  goto ;

:;
  return;
}

To prevent losing location information for the warning, I had modified the 
propagation engine to warn as it folded the expression away.  In this 
case, we were missing the warning because constant propagation was merging 
an UNDEFINED value (first_2) with a CONSTANT (first_4 == 0), which yields 
the constant because we explicitly ignore undefined values on locals.

So, as we fold 'if (first_1 == 0)' into 'if (1)', the patch emits the 
warning about the possibly uninitialized value of 'first'.  My approach 
improved precision of the warning because we are able to indicate exactly 
what statement is doing the uninitialized reference.

However, there are two huge problems with the approach: (1) it is 
intrusive.  Passes are required to keep track of their actions, in this 
case, CCP would inform the propagation engine that it had called the merge 
operator with an uninitialized value.

(2) it introduces false positives:

sub ()
{
  i_3 = 0;
  j_4 = 0;

  # k_2 = PHI ;
  # i_1 = PHI ;
:;
  D.1285_6 = i_1 | j_4;
  if (D.1285_6 == 0) goto ; else goto ;

:;
  k_9 = 10;
  i_10 = sub ();
  goto ;

:;
  return k_2;
}

Again, when CCP evaluates k_2 = PHI , it will merge the undefined 
name k_5 with the constant value k_9 == 10.  So, when we replace 'return 
k_2' with 'return 10' in , we will warn that 'k' may be used 
uninitialized.  However, in this case the loop is guaranteed to execue at 
least once, so the undefined value k_5 is never actually used by the 
program.

Unless I'm misunderstanding your approach, it will have the same problem.  
The early pass will have marked the PHI node 'k_2 = PHI ' as 
problematic.  Depending on when the second pass runs, it will not have a 
chance of marking it as problematic, and we will emit the warning.

The thing here is that both test cases are structurally similar.  In both 
cases we are disregarding an undefined value during optimization.  We 
don't actually know whether that undefined value will be executed or not.  
In the first test case, it will be.  In the second test case, it will not 
(k_2 is guaranteed to get its value from k_9 the first time).

A more robust solution would have to involve some kind of symbolic 
processing on our part.  Mechanically noticing whether we see undefined 
names in PHI nodes will always have this problem.

We could implement some variant of Gated SSA to record predicates in PHI 
nodes.  Uses of potentially uninitialized names would have to be analyzed 
for two things:

(1) if the use is protected by a predicate with the same value number as 
the predicate protecting a real definition, then you don't need to warn.  
Assume x_0 is undefined and that pred_5 and pred_9 have the same value 
number.

if (pred_5)
  x_5 = 3;
x_6 = PHI 
...
if (pred_9)
  ... = x_6;

(2) if we can guarantee that at least one of the PHI arguments with real 
definitions will execute at least once, then we don't need to warn.  This 
is the case in the second test case I described above.

Note, however, that this approach is not foolproof either and I suspect it 
would not be trivial to implement.  I think it would allow us to not be at 
the mercy of the order in which optimizations are executed, but it can be 
easily confused in the presence of aliasing and other nasties that prevent 
you from computing good value numbers or execution paths.  I suspect that 
in the extreme, this problem can be reduced to the stopping problem.

Re: resolving backslash newline whisky tango foxtrot: a proposal

[Per Bothner]

Dave Korn wrote:

Per, please.  We've been through these ***exact*** interchanges before.
You're now just reiterating the entire thread.  You aren't adding anything
new,


I didn't see my specific proposal ('\\' follow by space is not a line
continuation *and* an improved -Wcomment defaults to on when no options
are given) in the previous discussion, though of course the issues and
possibilities were covered in excessive depth.


just informing everyone which of the already-discussed possibilities your
own personal opinion happens to be.  And you aren't even offering a patch.


You're missing an important point: I'm currently the only person listed
as cpplib maintainer.  I very much favored Zack's change to allow
trailing whitespace after a continuation character, and have just said
I'm willing to change this *if* we make -Wcomment the default. So even
though I have very little time to spend on gcc, my "personal opinion"
matters.  If my proposal is acceptable to Apple (and I haven't heard
them chime in about it), then we may have a solution that could be
acceptable to everybody, without Apple having to create (another) fork
in their code-base.  It means that Apple can produce a patch with
reasonable assurance that it will be approved (assuming we also get
consensus from the global write maintainers on the -Wcomment changes.)
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

[RFC] c++ template instantiation generates zero-sized array (pr 19989)

[Josh Conner]

I've been investigating PR 19989, where we are rejecting code when a
template instantiation generates a zero-sized array, such as:

  template struct A
  {
static const int i = 0;
  }

  template struct B
  {
int x[A::i];
  };

  B<0> b;

This is rejected on the grounds that not failing could generate an
incorrect match in other instances, e.g.:

  template void foobar (int (*) [M] = 0 );
  template void foobar ( );

  void fn (void)
  {
foobar<0>();
  }

Where we are required to match the second form of foobar.

Before I propose a patch for this behavior, however, I'd like to
understand the most desirable behavior (understanding that
implementation complexity may limit what is possible in the short term).
 For my first example (the class template), I believe gcc should in an
ideal world:

  * by default: accept it with no warnings/errors
  * with -pedantic: generate an error
  * with -pedantic -fpermissive: generate a warning

For the second example (the function template), I believe gcc should:

  * by default: bind to the second foobar
  * with -fpermissive: bind to the first foobar (which will generate a
duplicate matching template error)
  * with -fpermissive -pedantic: bind to the first foobar, with a
warning (also generating a duplicate matching template error)

Is this an accurate summary of what we'd like to see?

Thanks -

Josh

Re: -Wuninitialized issues

[Jeffrey A Law]

On Tue, 2005-11-01 at 20:49 +0900, Neil Booth wrote:

> I think this is a better approach than the current one, and that
> if we go down this patch then we should grasp the opportunity to
> do it right - the early pass should be in the front end.  Let the
> optimizers do the fancy cases.  90% of cases that catch bugs can
> be handled in the front end I expect, with a very simple algorithm.
I don't think we want/need to catch any cases in the front-end.  One
of the nice things about our SSA form is the algorithm for uninitialized
uses is very very simple.

An uninitialized use is trivially detected as any use in the IL 
which refers to the "default definition" of a variable.

If the use occurs in a real statement, then what we have is a use in
which no paths through the CFG which reach the use ever define the
variable in question.

If the use occurs in a PHI node, then what we have is a use which
_might_ be uninitialized depending on whether or not a particular
edge in the CFG can be traversed at runtime.

This simplicity is a natural side effect of our SSA form.

The complications are merely an artifact of where in the optimization
pipeline we choose to issue warnings.  The *exact* same code can be
used to satisfy either end of the desired warning spectrum -- all that
changes is whether or not the maybe-uninitialized warning code fires
early or late in the optimization pipeline.

Moving the warning into the front-end just adds unnecessary complexity
to the problem and more code to maintain.

Jeff

Re: -Wuninitialized issues

[Jeffrey A Law]

On Tue, 2005-11-01 at 11:06 -0500, Diego Novillo wrote:
> On Monday 31 October 2005 18:49, Jeffrey A Law wrote:
> 
> > Thoughts?
> >
> I'm not sure this would buy you much better precision. 
It's less about better precision as it is about catching those
cases which are hidden because of actions of the optimizers without
introducing more false positives, unless the user has explicitly
asked for them :-)


>  I was tinkering with PR 18501 a few days ago.
It's worth noting that my change will catch 18501 -- without having
to twiddle the optimizers in any way shape or form.

Assembling functions:
 bitmap_print_value_set
zz.c: In function 'bitmap_print_value_set':
zz.c:7: warning: 'first' may have been used uninitialized in this
function, but was later optimized away or proven always initialized

Again, all it's doing is running the "maybe uninitialized" test during
the early uninitialized warning pass and comparing the results to
the running the "maybe uninitialized" test during the late uninitialized
warning pass.

This little table summarizes the possibilities:

   MarkedMarked
   Early  Late
no no-> Variable is always initialized before its uses
noyes-> Optimization error, checking failure, abort
yesno-> Variable might have been used uninitialized, but
those uses were either deleted or some paths
through the CFG were unexecutable with the net
result being all uses in the optimized code were
initialized
yes   yes -> Variable may be uninitialized before its uses


Jeff

Re: -Wuninitialized issues

[Jeffrey A Law]

On Tue, 2005-11-01 at 11:06 -0500, Diego Novillo wrote:
> To prevent losing location information for the warning, I had modified the 
> propagation engine to warn as it folded the expression away.
Possibly a useful thing to have, but I don't think we want to put
the burden of detecting uninitialized variables onto each 
optimizer :-)



> So, as we fold 'if (first_1 == 0)' into 'if (1)', the patch emits the 
> warning about the possibly uninitialized value of 'first'.  My approach 
> improved precision of the warning because we are able to indicate exactly 
> what statement is doing the uninitialized reference.
Instead of warning about the uninitialized reference here, I think 
we want to be conditionally warning about the fact that the conditional
is always taken (or not-taken).  


> However, there are two huge problems with the approach: (1) it is 
> intrusive.  Passes are required to keep track of their actions, in this 
> case, CCP would inform the propagation engine that it had called the merge 
> operator with an uninitialized value.
Yup, which I really don't like.

> (2) it introduces false positives:
I think false positives are inevitable if we attempt to solve the
problems Mark is complaining about.  That's part of the reason why
I think this needs to be switch controlled.

Your example is probably derived from C code which looks something
like this:

sub()
{
  int i = 0;
  int j = 0;
  int k;

  while ((i | j) == 0)
{
  k = 10;
  i = sub ();
}

  return k;
}


And my proposal will generate a warning like this:
yy.c:5: warning: 'k' may have been used uninitialized in this function,
but was later optimized away or proven always uninitialized

Clearly the message could be better, but it's easy to see how this
warning distinguishes itself from the "blah may be used uninitialized in
this function" warning we give in other cases.  We clearly state that
it appeared to be used uninitialized, but optimizations changed that
assessment.



> this problem can be reduced to the stopping problem.
Precisely.

jeff

Re: -Wuninitialized issues

[Diego Novillo]

On Tuesday 01 November 2005 13:02, Jeffrey A Law wrote:

> It's worth noting that my change will catch 18501 -- without having
> to twiddle the optimizers in any way shape or form.
>
Excellent.  That sounds so much better to what I had in mind.  I'll 
reassign 18501 then.

Thanks.

Re: -Wuninitialized issues

[Diego Novillo]

On Tuesday 01 November 2005 13:17, Jeffrey A Law wrote:

> Possibly a useful thing to have, but I don't think we want to put
> the burden of detecting uninitialized variables onto each
> optimizer :-)
>
Heh.  Indeed.

> I think false positives are inevitable if we attempt to solve the
> problems Mark is complaining about.  That's part of the reason why
> I think this needs to be switch controlled.
>
Agreed.

> Your example is probably derived from C code which looks something
> like this:
>
Yeah, it's gcc.dg/m-un-1.c, IIRC.

> Clearly the message could be better, but it's easy to see how this
> warning distinguishes itself from the "blah may be used uninitialized in
> this function" warning we give in other cases.  We clearly state that
> it appeared to be used uninitialized, but optimizations changed that
> assessment.
>
Sounds good.

We won't get perfect answers, which is fine given the nature of the 
problem.  However, I would like, to get *consistent* answers.  If we 
decide to re-organize the optimization pipeline, we should not be getting 
different -Wuninitialized behaviour.  Perhaps that's an easier problem to 
solve.  For instance, for GCC bootstraps we could ignore the warning when 
it's from "... but was later optimized away ...".

RE: resolving backslash newline whisky tango foxtrot: a proposal

[Dave Korn]

Per Bothner wrote:
> Dave Korn wrote:
>> Per, please.  We've been through these ***exact*** interchanges before.
>> You're now just reiterating the entire thread.  You aren't adding
>> anything new,
> 
> I didn't see my specific proposal ('\\' follow by space is not a line
> continuation *and* an improved -Wcomment defaults to on when no options
> are given) in the previous discussion, though of course the issues and
> possibilities were covered in excessive depth.

  True, but we've been through all the arguments about what should be the
'correct' behaviour, and everyone had basically agreed that there was no one
behaviour that would satisfy (where 'satisfy' means 'not oblige them to
rewrite megalines of legacy code') everyone, which is why I felt you were
retreading already-covered ground.

>> just informing everyone which of the already-discussed possibilities your
>> own personal opinion happens to be.  And you aren't even offering a
>> patch. 
> 
> You're missing an important point: I'm currently the only person listed
> as cpplib maintainer.  

  LOL, yes, I did miss that, and yes, it is very relevant!

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: -Wuninitialized issues

[Joe Buck]

On Tue, Nov 01, 2005 at 11:17:52AM -0700, Jeffrey A Law wrote:
> On Tue, 2005-11-01 at 11:06 -0500, Diego Novillo wrote:
> > To prevent losing location information for the warning, I had modified the 
> > propagation engine to warn as it folded the expression away.
> Possibly a useful thing to have, but I don't think we want to put
> the burden of detecting uninitialized variables onto each 
> optimizer :-)

Just an off-the-wall idea: What if dereferencing an uninitialized variable
is considered a side effect?  Then that side effect must be preserved
unless it is unreachable.  Consider

   while (i > 0)
  i--;
   // no more uses of i.

Instead of throwing everything away, this would become

__check_initialized(i);

and we would still get the warning.

Re: resolving backslash newline whisky tango foxtrot: a proposal

[Joe Buck]

On Tue, Nov 01, 2005 at 06:28:21PM -, Dave Korn wrote:
> Per Bothner wrote:
> > Dave Korn wrote:
> >> Per, please.  We've been through these ***exact*** interchanges before.
> >> You're now just reiterating the entire thread.  You aren't adding
> >> anything new,
> > 
> > I didn't see my specific proposal ('\\' follow by space is not a line
> > continuation *and* an improved -Wcomment defaults to on when no options
> > are given) in the previous discussion, though of course the issues and
> > possibilities were covered in excessive depth.
> 
>   True, but we've been through all the arguments about what should be the
> 'correct' behaviour, and everyone had basically agreed that there was no one
> behaviour that would satisfy (where 'satisfy' means 'not oblige them to
> rewrite megalines of legacy code') everyone, which is why I felt you were
> retreading already-covered ground.

It was precisely because there is no one behavior that would satisfy
everyone that I proposed the -f flag.

Re: Bug in install of gfortran for gcc-4.0.2

[Jim Wilson]

Rainer Emrich wrote:

rm -f /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \
ln /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/gfortran
/appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \


Looking at gcc/fortran/Make-lang.in we see that the command here is
  rm -f $(DESTDIR)$(bindir)/$(GFORTRAN_TARGET_INSTALL_NAME)$(exeext);
and we also see that GFORTRAN_TARGET_INSTALL_NAME is not defined 
anywhere.  This code was copied from the install-driver rule in 
gcc/Makefile.in, and we can see that it defines GCC_TARGET_INSTALL_NAME 
to $(target_noncanonical)-gcc.  However, looking at this, I see that the 
install-driver rule has changed significantly since it was copied into 
the fortran directory, and as a result, there are also other bugs here. 
 For instance, fortran is setting GFORTRAN_CROSS_NAME from 
program_transform_cross_name, but this was deleted 2 years ago.  So this 
whole fortran install rule needs to be rewritten, presumably by copying 
it again from the install-driver rule and modifying it appropriately.


I think we need a PR here to keep track of this.

The install rule starts with a "-", so it shouldn't have caused the 
install to fail, even though it is wrong.  I haven't seen install 
failures because of this problem.

--
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: -Wuninitialized issues

[Jeffrey A Law]

On Tue, 2005-11-01 at 13:26 -0500, Diego Novillo wrote:

> We won't get perfect answers, which is fine given the nature of the 
> problem. 
Right.

>  However, I would like, to get *consistent* answers.
Depends on how you define "consistent" :-)


>   If we 
> decide to re-organize the optimization pipeline, we should not be getting 
> different -Wuninitialized behaviour.  Perhaps that's an easier problem to 
> solve.  For instance, for GCC bootstraps we could ignore the warning when 
> it's from "... but was later optimized away ...".
I don't think you're going to achieve this goal, unless you fall back to
just warning before the optimizers get started (and the increased false
positives that are inherent with that solution).


If you change the pipeline, you may have a case where we miss an 
optimization.  That in turn might cause us to not detect that a
particular edge in the CFG is not executable.  That in turn may prevent
us from realizing that a particular variable which appeared 
uninitialized is really initialized on all paths to its uses.

The opposite is true as well.  ie, we add a new stage in the pipeline
and we determine more edges in the CFG are unexecutable or more code
is dead.  Thus variables which appeared uninitialized are now either
proven always initialized, or optimized away.


If you really want answers that don't change, then you just run the
existing warning code early in the pipeline (switch controlled of
course).  We see something potentially uninitialized and we warn
and forget.

If you're willing to tolerate some changes, then you have choices.

You just run the existing code as it stands today -- you get fewer false
positives.  As the pipeline changes the set of false positives will
fluctuate, but hopefully over the long term the set of false positives
is generally reduced.

You run something similar to what I've suggested.  The set of false
positives will fluctuate as will the set of "optimized away false
positives".  However, the union of those two sets would be consistent.



So, to summarize, I think this is the complete set of viable
alternatives:

  1. Status quo.  Nothing changes.

  2. Run the maybe uninitialized warning code earlier in the pipeline
 with no other changes.  Will result in more false positives, but
 more consistent results.

  3. Allow a user switch to determine if the maybe uninitialized code
 runs early in the pipeline (more false positives, but more
 consistent results), or late in the pipeline (fewer false
 positives, but results fluctuate as optimizers change).

 3a. Switch on with -Wuninitialized
 3b. Switch off with -Wuninitialized

  4. Use an approach which runs both late and early which allows us
 to explicitly warn about cases where a maybe-uninitialized variable
 was either eliminated or proven always initialized.  A switch
 controls the new warning.

 4a. Switch defaults to on with -Wuninitialized
 4b. Switch defaults to off with -Wuninitialized.


My favorites (in preferred order) would be 3b, 4b, and 4a.

3a and 1 are less appealing with 2 being the worst choice IMHO.

Other thoughts, opinions and comments are encouaged :-)

jeff

Re: dump CFG and callgraph

[Jim Wilson]

sean yang wrote:
(1) if I want to dump a gimple tree representation of a program, where 
should I start to look at? And I read gcc internal manual, the control 
flow graph information is represented by BB data structure. If I want to 
walk through a control flow graph, where should I start to look at?


-fdump-tree-all will dump gimple after every gimple optimization pass. 
Try looking at the output files, and try looking at the code that does 
the dumping.


(2) Can I dump call-graph information to a file from gcc? It seems that 
-da doesn't give such a file.


-fdump-ipa-all will dump the cgraph info.  You will need to enable IPA 
optimizations to see this stuff.  Try compiling with -O3.  The cgraph 
code is used even without IPA, but apparently we don't have support for 
dumping it in that case.  Probably an oversight.


cgraph.c says it builds "intraprocedural optimization", which seems a 
bit confusing(considering that callgraph can be used as inlining etc.)


Looks like a typo.  English isn't the author's first language.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: -Wuninitialized issues

[Jeffrey A Law]

On Tue, 2005-11-01 at 10:32 -0800, Joe Buck wrote:
> On Tue, Nov 01, 2005 at 11:17:52AM -0700, Jeffrey A Law wrote:
> > On Tue, 2005-11-01 at 11:06 -0500, Diego Novillo wrote:
> > > To prevent losing location information for the warning, I had modified 
> > > the 
> > > propagation engine to warn as it folded the expression away.
> > Possibly a useful thing to have, but I don't think we want to put
> > the burden of detecting uninitialized variables onto each 
> > optimizer :-)
> 
> Just an off-the-wall idea: What if dereferencing an uninitialized variable
> is considered a side effect?  Then that side effect must be preserved
> unless it is unreachable.  Consider
> 
>while (i > 0)
>   i--;
>// no more uses of i.
> 
> Instead of throwing everything away, this would become
> 
>   __check_initialized(i);
> 
> and we would still get the warning.
I think that solves a subset of the stuff we're discussing, but
I don't think it's general enough.  Consider a variable which is
used in a statement and the result of that statement is never
used.  ie

foo(int a)
{
  int i, x;

  x = a;
  x += i;
}


Or unreachable code issues:
  
foo()
{
   int i;

   if (0)
 i++;

   i = ...
   more code...
}





I think that picking one of the alternatives I outlined a few 
minutes ago will take us to a better place without resorting to
these kind of tricks.


In my mind it's more a matter of determining what behavior we
want.  Once we've selected the desired behavior, achieving that
behavior with the basic framework we've already got is pretty
straightforward (unless we are determined to try and solve the
halting problem :-)

Jeff

Re: weird installation problem on i686-pc-linux-gnu

[Jim Wilson]

Martin Reinecke wrote:

i.e. the "gcc" binary ends up as "xgcc" in a subdirectory called "gcc".


The gcc makefile install rule just does
  rm -f $destdir/bin/gcc
  install xgcc $destdir/bin/gcc
If destdir/bin/gcc is non-existant, or a plain file, then this works as 
expected.  If destdir/bin/gcc is a directory, then this will cause the 
result you saw, as xgcc will be copied into the directory.


The question is then: Who created the directory?

That I probably can't figure out without makefile logs.  It is also 
possible that the directory was there before you started the install. 
In this case, you might want to do a rm -rf $destdir to get a clean install.

--
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: Bug in install of gfortran for gcc-4.0.2

[Steven Bosscher]

On Tuesday 01 November 2005 19:59, Jim Wilson wrote:
> Rainer Emrich wrote:
> > rm -f /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \
> > ln /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/gfortran
> > /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \
>
> Looking at gcc/fortran/Make-lang.in we see that the command here is
>rm -f $(DESTDIR)$(bindir)/$(GFORTRAN_TARGET_INSTALL_NAME)$(exeext);
> and we also see that GFORTRAN_TARGET_INSTALL_NAME is not defined
> anywhere.  This code was copied from the install-driver rule in
> gcc/Makefile.in, and we can see that it defines GCC_TARGET_INSTALL_NAME
> to $(target_noncanonical)-gcc.  However, looking at this, I see that the
> install-driver rule has changed significantly since it was copied into
> the fortran directory, and as a result, there are also other bugs here.
>   For instance, fortran is setting GFORTRAN_CROSS_NAME from
> program_transform_cross_name, but this was deleted 2 years ago.  So this
> whole fortran install rule needs to be rewritten, presumably by copying
> it again from the install-driver rule and modifying it appropriately.
>
> I think we need a PR here to keep track of this.
>
> The install rule starts with a "-", so it shouldn't have caused the
> install to fail, even though it is wrong.  I haven't seen install
> failures because of this problem.

Wasn't this whole issue fixed by this patch:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01785.html

Gr.
Steven

Re: Bug in install of gfortran for gcc-4.0.2

[James E Wilson]

On Tue, 2005-11-01 at 11:39, Steven Bosscher wrote:
> Wasn't this whole issue fixed by this patch:
> http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01785.html

Yes.  Andreas Schwab's patch appears to fix this correctly.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: -Wuninitialized issues

[Joe Buck]

I wrote:

> > Just an off-the-wall idea: What if dereferencing an uninitialized variable
> > is considered a side effect?  Then that side effect must be preserved
> > unless it is unreachable.  Consider
> > 
> >while (i > 0)
> >   i--;
> >// no more uses of i.
> > 
> > Instead of throwing everything away, this would become
> > 
> > __check_initialized(i);
> > 
> > and we would still get the warning.

On Tue, Nov 01, 2005 at 12:20:40PM -0700, Jeffrey A Law wrote:

> I think that solves a subset of the stuff we're discussing, but
> I don't think it's general enough.  Consider a variable which is
> used in a statement and the result of that statement is never
> used.  ie
> 
> foo(int a)
> {
>   int i, x;
> 
>   x = a;
>   x += i;
> }

My suggestion would report an uninitialized access for i in this case.
There's a read of an uninitialized variable; it does not go away.

> Or unreachable code issues:
>   
> foo()
> {
>int i;
> 
>if (0)
>  i++;
> 
>i = ...
>more code...
> }

For this one, my suggestion would not report a warning: the uninitialized
access to i is not reachable.  But as a developer, I don't care: I want
uninitialized warnings to expose lurking bugs, not as a theoretical
exercise.

> In my mind it's more a matter of determining what behavior we
> want.  Once we've selected the desired behavior, achieving that
> behavior with the basic framework we've already got is pretty
> straightforward (unless we are determined to try and solve the
> halting problem :-)

If the halting problem raises its ugly head, I'm fine with false
positives.

non coding contributions

[Benj FitzPatrick]

Hi,
I'm relatively new to linux as I have only been
seriously using it for less than a year.  However, I
have been following certain projects for much longer
(Transgaming.com, etc.) and was wondering if there was
a way to donate to help further gcc.  I have been
giving $5 a month to transgaming for over a year now,
and I know that other projects could use extra money
as well.  Would it be possible to setup something
similar for gcc?  I know it wouldn't be much, and a
rough estimate of the number of contributors would
have to be estimated first, but it might be enough to
get some new hardware when needed.  As far as
estimating the number of people who might contribute,
I bet that if somebody wrote up a small blurb it could
go up on slashdot.
Thanks,
Benj FitzPatrick

Re: -Wuninitialized issues

[Mark Mitchell]

Diego Novillo wrote:

> We won't get perfect answers, which is fine given the nature of the 
> problem.  However, I would like, to get *consistent* answers.

Yes, I agree that's very important.  In fact, I'd like to generalize
that to say that -- as much as possible -- the same code should generate
the same warnings across architectures, optimization levels, and
releases as well.  If -O3 causes us to say "might have been
uninitialized, but we removed it" while -O0 just says "uninitialized"
that's probably OK.  But, having warnings not appear at -O0, or go away
completely with higher levels of optimization isn't good.

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: non coding contributions

[Janis Johnson]

On Tue, Nov 01, 2005 at 12:42:54PM -0800, Benj FitzPatrick wrote:
> Hi,
> I'm relatively new to linux as I have only been
> seriously using it for less than a year.  However, I
> have been following certain projects for much longer
> (Transgaming.com, etc.) and was wondering if there was
> a way to donate to help further gcc.  I have been
> giving $5 a month to transgaming for over a year now,
> and I know that other projects could use extra money
> as well.  Would it be possible to setup something
> similar for gcc?  I know it wouldn't be much, and a
> rough estimate of the number of contributors would
> have to be estimated first, but it might be enough to
> get some new hardware when needed.  As far as
> estimating the number of people who might contribute,
> I bet that if somebody wrote up a small blurb it could
> go up on slashdot.
> Thanks,
> Benj FitzPatrick

GCC is part of the Free Software Foundation's GNU Project.  To help,
see https://www.fsf.org/donate and http://www.gnu.org/help/help.html.

Janis

Re: Bug in install of gfortran for gcc-4.0.2

[Andreas Schwab]

Jim Wilson <[EMAIL PROTECTED]> writes:

> Rainer Emrich wrote:
>> rm -f /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \
>> ln /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/gfortran
>> /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \
>
> Looking at gcc/fortran/Make-lang.in we see that the command here is
>   rm -f $(DESTDIR)$(bindir)/$(GFORTRAN_TARGET_INSTALL_NAME)$(exeext);
> and we also see that GFORTRAN_TARGET_INSTALL_NAME is not defined 
> anywhere.

This is already fixed by
.  I should have
copied gcc@ as well, sorry.

Andreas.

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

[G++] Implementing a C++0x standard proprosal (Design by Contract)

[nesotto]

Dear G++ developers,

Let me present my-self: My name is Thorsten Ottosen, I'm the
Danish member of WG21. I'm also the author of a few proposals for 
C++0x, most importantly Contract Programming (a.k.a. Design by 
Contract):


http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1866.html

I'm looking for volunters to implement a subset of this proposal s.t. we
can get more experience with the proposal. This is crusial if the 
proposal is going to make it into C++0x.


I'm not a compiler-writer myself, so I need you to implement the 
extension in G++.

OTOH, I'll augment the libstd standard library with contracts.

So if you think this is a valuable extension to C++ and think it could 
be fun to spend your spare-time on this task, I would very much like to 
talk with you.


Best regards

Thorsten Ottosen, Dezide 


This message was sent using IMP, the Internet Messaging Program.

[gfortran] fortran preprocessing, round 2

[FX Coudert]

This is an updated version of my patch taking care of warnings when cc1 
is called from gfortran to preprocess fortran source. I used a 
different (and in my view, cleaner) approach: Fortran options are not 
marked as C, but when preprocessing fortran source, cc1 is given a 
-lang-fortran flag, which makes the preprocessor not warning about use 
of Fortran options.


Tested on i686-linux, with both languages=c and languages=c,fortran. 
The current behaviour for compiling C and Fortran in a single 
command-line is kept. Regtested for languages=c, regtesting in progress 
for languages=c,fortran -- howdy, how long is that C testsuite to run! 
:(


OK for mainline when it reopens before branching?

FX
:ADDPATCH fortran,c:



preproc.ChangeLog
Description: Binary data


preproc.diff
Description: Binary data

Re: [gfortran] fortran preprocessing, round 2

[Andrew Pinski]

> This is an updated version of my patch taking care of warnings when cc1 
> is called from gfortran to preprocess fortran source. I used a 
> different (and in my view, cleaner) approach: Fortran options are not 
> marked as C, but when preprocessing fortran source, cc1 is given a 
> -lang-fortran flag, which makes the preprocessor not warning about use 
> of Fortran options.
> 
> Tested on i686-linux, with both languages=c and languages=c,fortran. 
> The current behaviour for compiling C and Fortran in a single 
> command-line is kept. Regtested for languages=c, regtesting in progress 
> for languages=c,fortran -- howdy, how long is that C testsuite to run! 
> :(

This looks like what I had in mind when I suggested this fix.

Thanks,
Andrew Pinski

Re: [gfortran] fortran preprocessing, round 2

[Richard Henderson]

On Tue, Nov 01, 2005 at 11:23:08PM +0100, FX Coudert wrote:
>   PR fortran/18452
>   * gcc/c.opt: Add a -lang-fortran option.
>   * gcc/c-opts.c: Add a lang_fortran flag.
>   (c_common_init_options): Handling the -lang-fortran option.
>   (c_common_handle_option): Add a case for Fortran options in
>   preprocessing. Remove cases for -ffixed-form and
>   -ffixed-line-length. Add a case for -lang-fortran.

Ok.


r~

Re: GCC 4.0.2 Canadian Cross Compile

[Nathanael Nerode]

Mark Fortesque wrote:
>I did not specify all the commandline arguments used in my email. I am
>using --build= in the GCC builds (as required). The build arguments
>in use when things go pair shaped are:
>'/L64/src/gcc-4.0.0/gcc-4.0.2-p01/configure --build=i686-pc-linux-gnu
>--target=sparc-linux --host=sparc-linux --prefix=/usr/crbld
>--with-sysroot=/L64/sparc/tree/sparc-linux/sys-root
>--includedir=/usr/include --with-local-prefix=/usr/local --disable-nls
>--enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit
>--enable-languages=c,c++,ada --enable-shared --enable-c99
>--enable-long-long'
>
>I have found three issues so far. They are all in the ADA build. They are:

Known bug.  Ada doesn't handle build!=host properly yet.  Ada has a wacky
build system and I have intermittently been trying to straighten it out
so that this can be fixed.

Your patches are all inappropriate because we are trying to perform a serious
overhaul of the Ada build system, specifically by pulling all the gnatlib
build stuff into libada/Makefile.* and all the gnattools build stuff into
gnattools/Makefile.* -- this will, eventually, solve these problems.

If you would like to help with that please contact me.

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

[Insert famous quote here]

powerpc/rs6000 implicit FPU usage

[Till Straumann]

The issue of gcc implicitely generating floating point
instructions (i.e., without 'double' or 'float' types
being used in the source code) has come up a few times
in the past (e.g., 2002/10: GCC floating point usage)

Miraculously, I found that gcc-4.0.2 (unlike 3.2 or 3.4)
no longer generates a lfd/stfd pair for something like this:

unsigned long long *px, *py;

 *px = *py;

However, I was unable to find any documentation or recent
discussion about the issue.
Has this kind of optimization (using the FPU for
data objects other than double/float) been deliberately
abandoned or is it the side-effect of other changes?

Thanks
-- Till

PS: Please CC me - I'm not on this list

Re: [RFC] c++ template instantiation generates zero-sized array (pr 19989)

[Mark Mitchell]

Josh Conner wrote:
> I've been investigating PR 19989, where we are rejecting code when a
> template instantiation generates a zero-sized array, such as:
> 
>   template struct A
>   {
> static const int i = 0;
>   }
> 
>   template struct B
>   {
> int x[A::i];
>   };
> 
>   B<0> b;
> 
> This is rejected on the grounds that not failing could generate an
> incorrect match in other instances

I understand what you're after: tolerate uses of the extension where
it's sufficiently harmless.

I don't think your proposed solution is correct, though, because we want
to maintain the invariant that all conforming programs compile and
behave as required by the standard in all compilation modes.  In other
words, supplying -fpermissive and friends can make non-conforming
programs compile, when they otherwise wouldn't, but conforming programs
should behave identically in all modes.

I would imagine that if we encounter a zero-sized array when the
"complain" flag is tf_error, then we can just issue a conditional
pedwarn, with "if (pedantic) pedwarn (...)".  But, if tf_error is not
set, we must reject the instantiation.

I know that sounds backwards.  The point is that when tf_error is set,
we're committed to the instantiation.  When tf_error is not set, SFINAE
applies.  And, in a conforming program, we must reject the instantiation
in that case.

-- 
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: powerpc/rs6000 implicit FPU usage

[David Edelsohn]

> Till Straumann writes:

Till> Has this kind of optimization (using the FPU for
Till> data objects other than double/float) been deliberately
Till> abandoned or is it the side-effect of other changes?

Side-effect of other changes.

David

Re: -Wuninitialized issues

[Kaveh R. Ghazi]

 > So, to summarize, I think this is the complete set of viable
 > alternatives:
 > 
 >   1. Status quo.  Nothing changes.
 > 
 >   2. Run the maybe uninitialized warning code earlier in the pipeline
 >  with no other changes.  Will result in more false positives, but
 >  more consistent results.
 > 
 >   3. Allow a user switch to determine if the maybe uninitialized code
 >  runs early in the pipeline (more false positives, but more
 >  consistent results), or late in the pipeline (fewer false
 >  positives, but results fluctuate as optimizers change).
 > 
 >  3a. Switch on with -Wuninitialized
 >  3b. Switch off with -Wuninitialized
 > 
 >   4. Use an approach which runs both late and early which allows us
 >  to explicitly warn about cases where a maybe-uninitialized
 >  variable
 >  was either eliminated or proven always initialized.  A switch
 >  controls the new warning.
 > 
 >  4a. Switch defaults to on with -Wuninitialized
 >  4b. Switch defaults to off with -Wuninitialized.
 > 
 > My favorites (in preferred order) would be 3b, 4b, and 4a.
 > 3a and 1 are less appealing with 2 being the worst choice IMHO.
 > Other thoughts, opinions and comments are encouaged :-)
 > jeff

I prefer consistency in warnings, regardless of optimization level.
We already say warning flags should not affect codegen and therefore
optimizations performed.  IMHO the reverse should also hold,
optimization level should not affect warnings generated.

False positives for -Wuninitialized are easily corrected by
initializing at declaration.  But lacking consistency can be annoying
when a newly detected stray false positive kills -Werror compilations
for infrequently tested configuration options, not because the code
changed but because different optimizations were performed.  Think
oddball configs in gcc bootstraps, or the occasional -O3 bootstraps on
any config yielding a new false positive.  Leaving aside cpp
conditional code paths, I want to know the universe (or as close as I
can) of possible false positives with my one and only common bootstrap
and fix them all right away, and be done with warning repairs.

If the initialization is redundant, it won't matter to codegen.
I.e. if the optimizer is smart enough to eliminate the uninitialized
path, then IMHO it should be smart enough (is already smart enough?)
to eliminate the dead store at the declaration.  Thus there shouldn't
be any pessimization penalty for silencing the warning.  In fact I'll
go as far as saying I don't think 4 is ever a useful warning,
especially from a -Werror perspective.

So if I understand #3 correctly where early==on and late==off for the
new flag, then my preferred order is 3a, 2.

I think 3b or 4a yield inherently inconsistent results by definition
and are therefore to be avoided.

I'm not sure what 4b means.  When this early&late switch is off does
-Wuninitialized degenerate to 2 (early-only) or 3b (late-only) in your
mind?  If 2 then IMHO it's not horrible but not useful, if 3b then I
don't like it.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

A question about memcpy

[Eric Fisher]

Hi,
When I compile such c codes as following,
  int a=0x,i;
  int 
sra[32]={0x,0x,0x,0x,0x,0x,0x,0x,
  
0x,0x,0x,0x,0x,0x,0x,0x,
  
0xfffa,0x,0x,0x,0x,0x,0x,0x,
  
0x,0x,0x,0x,0x,0x,0x,0x};
the compiler will come out the error messange like undefined reference
to `memcpy'.
The dumped rtl shows,
(call_insn 21 20 22 (parallel [
(set (reg:SI 2 $2)
(call (mem:SI (symbol_ref:SI ("memcpy") [flags 0x41]
) [0 S4 A32])
(const_int 16 [0x10])))
(clobber (reg:SI 30 $30))
]) -1 (nil)
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(expr_list (use (reg:SI 6 $6))
(expr_list (use (reg:SI 5 $5))
(expr_list (use (reg:SI 4 $4))
(nil)

  Can you where is the memcpy? And how the compiler call this funcion
implicitly?
  Need I implement it?

  Thanks.
  Eric.