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/ directo
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.
>
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
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
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 ge
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.000
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-l
> 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
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.000
[ 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 =
* 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?
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 coul
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
> 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 doe
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:
> >
> >
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
> pa
is available
URL is
ftp://gcc.gnu.org/pub/gcc/infrastructure/svn-trunk-entire-history.tar.rz
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
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
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 cou
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 ca
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
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 uninitialize
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.
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 Ma
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 i
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
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 specif
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
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
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
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 a
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
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
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
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.
> >
> > Inst
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
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
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
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/M
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
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, whi
> 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
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
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 --h
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
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;
>
> T
> 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
> 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 re
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,
0xf
50 matches
Mail list logo
