Re: RFC - GCC Architectural Goals

[Diego Novillo]

On Tue, Dec 6, 2011 at 17:54, Basile Starynkevitch
 wrote:
> On Tue, 6 Dec 2011 15:49:07 -0500
> Diego Novillo  wrote:
>
>> For the time being, however, it is easier for me to edit the document
>> online.  The document is at
>> https://docs.google.com/document/pub?id=1ZfyfkB62EFaR4_g4JKm4--guz3vxm9pciOBziMHTnK4
>
>
> Should we edit the document (I don't dare doing that without your permission)?
>
> Should we put stuff on some wiki page about this document?

The best way to discuss it will be right here on the mailing list.
This way, we can keep an archive  of the discussion and keep everyone
in the loop.  Joseph and I will edit the document to incorporate
feedback.

As we stated before, we are looking to build consensus on these
issues.  The conventions and projects are also incomplete.  They
represent everything we thought important, but we are sure there will
be other things.


Diego.

Re: crtbegin not building?

[Ian Lance Taylor]

Lawrence Crowl  writes:

> It appears that "cd gcc; make" now fails to build crtbegin.o.
> An additional "make all-install" seems to be needed.  Was
> this change intentional?

It moved to libgcc.  Look in TARGET/libgcc in your build directory.

Ian

Re: RFC - GCC Architectural Goals

[Gabriel Dos Reis]

On Tue, Dec 6, 2011 at 4:54 PM, Basile Starynkevitch
 wrote:
> On Tue, 6 Dec 2011 15:49:07 -0500
> Diego Novillo  wrote:
>
>> For the time being, however, it is easier for me to edit the document
>> online.  The document is at
>> https://docs.google.com/document/pub?id=1ZfyfkB62EFaR4_g4JKm4--guz3vxm9pciOBziMHTnK4
>
>
> Should we edit the document (I don't dare doing that without your permission)?
>
> Should we put stuff on some wiki page about this document?
>
> Or should we send comments on this list?
>

I would think sending comments here would be appropriate as
the subject line indicates.  Having the document mutates in all
kinds of directions would be confusing.  I would expect Diego
and Joseph to integrate comments and consensus arises.

Re: RFC - GCC Architectural Goals

[Basile Starynkevitch]

On Tue, 6 Dec 2011 15:49:07 -0500
Diego Novillo  wrote:

> For the time being, however, it is easier for me to edit the document
> online.  The document is at
> https://docs.google.com/document/pub?id=1ZfyfkB62EFaR4_g4JKm4--guz3vxm9pciOBziMHTnK4


Should we edit the document (I don't dare doing that without your permission)?

Should we put stuff on some wiki page about this document?

Or should we send comments on this list?

Cheers


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

Re: Is ada's "make install" parallel-safe?

[Dave Korn]

On 03/12/2011 12:16, Dave Korn wrote:

>   Running "make -j8 install" in a fresh build of head, I saw loads of the
> following error messages coming out in the log:
> 
>> cp: cannot create regular file
>> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-ztmoau.adb':
>> File exists cp: cannot create regular file
>> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-ztmoio.adb':
>> File exists cp: cannot create regular file
>> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-zttest.ads':
>> File exists cp: cannot create regular file
>> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-zzboio.ads':
>> File exists cp: cannot create regular file
>> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/ada.ads':
>> File exists cp: cannot create regular file
>> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/directio.ads':
>> File exists
>   [ ... snip ... ]
> 
>   Sure enough, all the files did exist, so I guess it must have been trying to
> install them twice.  Before I try digging deeper, I thought I'd quickly ask:
> Does anyone else see this?  (Is it perhaps something that wouldn't show up on
> a different host, such as linux, owing to differing filesystem semantics?)

  This is confirmed and turns out to be the (known and now reopened) PR
bootstrap/38388.

cheers,
  DaveK

gcc-4.4-20111206 is now available

[gccadmin]

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

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

You'll find:

 gcc-4.4-20111206.tar.bz2 Complete GCC

  MD5=b3df0e9cf3fda418e97ce7396ddd648c
  SHA1=59c49bfc42684b33acad514c6ce665ca25c08808

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

When a particular snapshot is ready for public consumption the LATEST-4.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: gcc 4.6.2 hangs while building glibc 2.14

[Joel Reymont]

uname -a
Darwin biggie.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug  9 \
20:54:00 PDT 2011; 
root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64

gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~1/src/configure\
--disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 \
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++ \
--program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ \
--with-slibdir=/usr/lib --build=i686-apple-darwin11 \
--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~1/dst-
llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- \
--host=x86_64-apple-darwin11 --target=i686-apple-darwin11 \
--with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

---
http://twitter.com/wagerlabs

gcc 4.6.2 hangs while building glibc 2.14

[Joel Reymont]

I have built binutils 2.22.51 

../configure --target=arm-unknown-linux-gnueabi \
--prefix=/usr/local/arm-bq-reader --with-gnu-as --with-gnu-ld \
--disable-werror --disable-shared --disable-multilib

I then built the first-stage gcc cross compiler 

../configure --target=arm-unknown-linux-gnueabi \
--prefix=/usr/local/arm-bq-reader \
--disable-multilib --enable-languages="c" --disable-threads --disable-shared \
--disable-libspp --without-ppl --disable-libgomp --disable-libmudflap \
--disable-decimal-float --disable-libquadmath --with-gnu-as --with-gnu-ld \
--disable-werror 

I then linked libgcc_eh.a to libgcc.a

ln -vs libgcc.a `arm-unknown-linux-gnueabi-gcc -print-libgcc-file-name | \
sed 's/libgcc/&_eh/'`

compiled and installed libgcc.a

make all-target-libgcc
sudo make install-target-libgcc

Set up the Linux headers and proceeded to build glibc

CC=arm-unknown-linux-gnueabi-gcc ../configure \
--host=arm-unknown-linux-gnueabi \
--prefix=/usr/local/arm-bq-reader --enable-addons --disable-profile \
--enable-kernel=2.6.21 --with-headers=/usr/local/arm-bq-reader/include \
libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes

I let this run for a couple of days but no dice. gawk shows 90-100% CPU 
utilization and there are couple of gmake instances running and not doing 
anything, their time stuck at 16s or so according to top.

What am I doing wrong?

Thanks, Joel

---
http://twitter.com/wagerlabs

Re: building unwind-sjlj.o with / without -fexceptions

[Richard Henderson]

On 12/05/2011 04:05 PM, Joern Rennecke wrote:
> I find that exception handling doesn't work properly for the epiphany with
> recent gcc sources (it worked in the pre-merged port with sources from July).
> I suppose that is related to the change mentioned in:
> http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01926.html
> 
> Looking at the cleanup-5.c failure, I see that _Unwind_ForcedUnwind
> calls _Unwind_SjLj_Register, thus we never unwind to where we are supposed
> to unwind.
> 
> I can fix this in libgcc/config/epiphany/t-epiphany with:
> 
> unwind-sjlj.o : CFLAGS += -fno-exceptions
> unwind-sjlj.o : c_flags := $(filter-out -fexceptions,$(cflags))
> 
> Is that the right way to do it?  Or should we more generally remove 
> -fexceptions
> from the build rules for the exception handling runtime?

No.  In general removing -fexceptions from the unwind routines will cause
the unwind routines to fail.  Both problems are almost certainly problems
with Matz' scope clobbers vs exception regions.


r~

RFC - GCC Architectural Goals

[Diego Novillo]

At the last developer's meeting in London, Joseph and I agreed to work
on an architectural definition for GCC.  We now have something that,
while incomplete, should be enough to discuss.

Our main intent is to define new conventions and guidelines that will
simplify GCC development.  The document is organized in three distinct
areas:

1- A high-level overview of the problem, as we see it.  This describes
the different problematic aspects of GCC development and how we think
they should change.  We would like the discussion to start here.
Without consensus on the overall issues, much of the rest becomes
moot.  We think that these issues are very important for the long term
viability of GCC.

2- A set of proposed development conventions.  These are to become
part of the coding guidelines so that new patches are measured against
them.

3- Improvement projects.  These are largely existing projects that we
have organized under a new wiki page.  Most of these projects need
resources to finalize their design, schedule estimates and
implementation.

You will notice that taken together, these projects represent a
massive amount of work.  We will need to prioritize projects and we
are hoping for major institutional contributors to provide resources
to help finish them.  Naturally, the relative importance of these
projects will vary greatly across institutions, so we should find
owners for the more popular ones.

Parts #1 and #2 are to become fixed pages in GCC's home page (perhaps
http://gcc.gnu.org/gccmission.html).  Part #3 is intended to be more
dynamic, so we are hosting it on GCC's wiki.

For the time being, however, it is easier for me to edit the document
online.  The document is at
https://docs.google.com/document/pub?id=1ZfyfkB62EFaR4_g4JKm4--guz3vxm9pciOBziMHTnK4

The improvement projects are at
http://gcc.gnu.org/wiki/ImprovementProjects.  I will link it from the
main wiki index soon.

Please, start reviewing the main document first.  We would like to
reach consensus on the high-level aspects before discussing the
specific projects.


Thanks.


Joseph and Diego.

crtbegin not building?

[Lawrence Crowl]

It appears that "cd gcc; make" now fails to build crtbegin.o.
An additional "make all-install" seems to be needed.  Was
this change intentional?

-- 
Lawrence Crowl

Re: Suspicion of regression in uninitialized value detection

[Andrew Pinski]

On Tue, Dec 6, 2011 at 11:33 AM, Jeff Law  wrote:
> In theory we could go ahead and translate into SSA when not optimizing
> which would remove the dependency on -O, at the expense of
> compile-time performance.

We actually already do this ... As there is only SSA expand now.

Thanks,
Andrew Pinski

Re: Suspicion of regression in uninitialized value detection

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/06/11 12:21, Ian Lance Taylor wrote:
> While using the optimizers to improve the quality of uninitialized 
> warnings does have some benefits, those benefits are outweighed by
> the drawbacks.  We need to completely reimplement this warning,
> either in the C/C++ common frontend, or before any optimization
> passes run.
Run it just after going into SSA; mark everything that has an
uninitialized use.  For those who want the larger, much more stable
set of warnings this is going to meet their needs much better.

That's what my patch from a few years ago did.  IIRC the only
outstanding issue was what should the default be.

In theory we could go ahead and translate into SSA when not optimizing
which would remove the dependency on -O, at the expense of
compile-time performance.


> 
> Then we can rename the existing warning to
> -Wunpredictable-uninitialized and take it out of -Wall.
I'd tend to think this would be a mistake.  We'd be changing -Wall in
a very very visible way and I suspect the number of developers
complaining would be huge.

Ideally we'd just nuke -Wall and have everyone use the -W options they
care about, but sadly that's just a pipe dream.

jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO3m4mAAoJEBRtltQi2kC7kw8H/1cxi3gj76qEBsnaCvyxEdKA
REZ7t8tQpk5sjyNB9SmmSMQWeTJaMWWXFk5WlpCmoplxbf98/8hqz/lpUP0+WKBC
2GrkQQ4cCYpVtthjs2XZpaHAzNbDaUutjlmDJn98MzeisF7x5mWT00gxy7IufgNR
fGe79a3ojLF6tMpMsgoRMKcP/uX8TKP2KBzwj1LSpNv9H8dd1xqM7POiVNnWwZ2X
2s6uozkVBJuInh6SgjikZTqOyXCtnBVHwC1zJa3WKUPI9bYJL3LZr8+KCXe4WFj3
s4hVukgcjYjtChioiDVJhD4tJ8jaUyMx6cKQXJC6VlLXT39Uzh+oM1UQdyfVQsM=
=jS8p
-END PGP SIGNATURE-

Re: Suspicion of regression in uninitialized value detection

[Ian Lance Taylor]

David Brown  writes:

> The point of a warning like "unintialised variable" is static error
> checking - it is to help spot mistakes in your code.  And if there is
> a path through the function that uses an uninitialised variable,
> that's almost certainly a bug in your code - one you would like the
> warning to tell you about.

In my opinion the current support for warnings about uninitialized
variables is broken by design.  This kind of warning has to be
independent of optimizations.  The current implementation is not stable
across releases and it is very difficult for users to correctly predict
the cases when it will and will not warn.

While using the optimizers to improve the quality of uninitialized
warnings does have some benefits, those benefits are outweighed by the
drawbacks.  We need to completely reimplement this warning, either in
the C/C++ common frontend, or before any optimization passes run.

Then we can rename the existing warning to -Wunpredictable-uninitialized
and take it out of -Wall.

Ian

Re: Suspicion of regression in uninitialized value detection

[Ruben Safir]

On Tue, Dec 06, 2011 at 09:29:30AM -0500, Robert Dewar wrote:
> On 12/6/2011 9:16 AM, David Brown wrote:
> 
> >I would say it's better to have false positives in cases like this, than
> >false negatives, because there are easy ways to remove the false
> >positives.
> 
> My view is that for compiler warnings, you want to balance false
> positives and false negatives. If you give too many false positives
> people just turn off the warning anyway. I think the current balance
> is probably about right.
> 
> If you want more thorough warnings, with no false negatives, then
> separate static analysis tools are more appropriate. They can do a
> better job than the compiler in any case.



I'm generally not happy with my code unless I clear all the warnings.

Ruben
-- 
http://www.mrbrklyn.com - Interesting Stuff
http://www.nylxs.com - Leadership Development in Free Software

So many immigrant groups have swept through our town that Brooklyn, like 
Atlantis, reaches mythological proportions in the mind of the world  - RI Safir 
1998

http://fairuse.nylxs.com  DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002

"Yeah - I write Free Software...so SUE ME"

"The tremendous problem we face is that we are becoming sharecroppers to our 
own cultural heritage -- we need the ability to participate in our own society."

"> I'm an engineer. I choose the best tool for the job, politics be damned.<
You must be a stupid engineer then, because politcs and technology have been 
attached at the hip since the 1st dynasty in Ancient Egypt.  I guess you missed 
that one."

© Copyright for the Digital Millennium

Re: Dimensions of array parameters

[Ian Lance Taylor]

ludovic.cour...@inria.fr (Ludovic Courtès) writes:

> Declaring the parameter above as ‘int x[a]’ is valid C99.  I fail to see
> why this is insufficient for the purposes we discussed.  Could you clarify?

Sorry, I hadn't realized that C99 permitted that.  The standard does
clearly state that in prototype scope it is treated as '*', so according
to the standard
f(int a, int x[static a]);
is equivalent to
f(int a, int x[static *]);
which is not helpful.  Still, you are probably right that it would be
reasonable to extend gcc's support of this.

Ian

Re: Perfect forwarding seems not to be so perfect

[Jonathan Wakely]

On 6 December 2011 16:41, Jonathan Wakely wrote:
> I'm guessing you've called format with an explicit template
> argument list, and it's not compatible with the actual types you
> called the function with.  Due to
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50828 the error doesn't
> show the explicit template arguments used.

But due to you not showing a complete example, I can only guess.

Re: Suspicion of regression in uninitialized value detection

[Jonathan Wakely]

On 6 December 2011 15:18, David Brown wrote:
>
> But clearly the uninitialised warnings are useful, and users would like to
> see them improved - if it is possible to do so without adversely affecting
> code generation, of course.

Yes, we all like good things, and we all want more good things, as
long as they don't come with too many bad things  :)

There's a whole wiki page on the topic:
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

Re: Perfect forwarding seems not to be so perfect

[Jonathan Wakely]

On 6 December 2011 15:11, Piotr Wyderski wrote:
> Hello,
>
> on gcc-4.6.2/x64/linux:
>
>    template  inline string format(const string& fmt,
> TA&&... args) {
>
>        string_formatter f;
>        f.format(fmt, std::forward(args)...);
>        return f.get_result();
>    }
>
> results in:
>
> error: no matching function for call to 'forward(const char* const&)'
> note: candidates are:
> /opt/a3d/stow/gcc-4.6.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/move.h:62:5:
> note: template _Tp&& std::forward(typename
> std::remove_reference<_Tp>::type&)
> /opt/a3d/stow/gcc-4.6.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/move.h:67:5:
> note: template _Tp&& std::forward(typename
> std::remove_reference<_Tp>::type&&)
>
> Should I report it as a standard library bug?

I'm guessing you've called format with an explicit template
argument list, and it's not compatible with the actual types you
called the function with.  Due to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50828 the error doesn't
show the explicit template arguments used.

Re: Suspicion of regression in uninitialized value detection

[David Malcolm]

On Tue, 2011-12-06 at 16:40 +0100, David Brown wrote:
> On 06/12/2011 16:27, Robert Dewar wrote:
> > On 12/6/2011 10:18 AM, David Brown wrote:
> >
> >> Unfortunately, there are no such tools available that compare with gcc
> >> and its warnings.
> >
...

> And there are large, expensive commercial tools that can do better (in 
> some ways at least) than gcc - but nothing open source.

...
> The other recent new feature to gcc that opens potential for better 
> static analysis is plugins.

Shameless plug: my Python plugin for GCC [1] has an example static
analysis library "libcpychecker", which does attempt to track every path
through a function, and does some primitive tracking of usage of
uninitialized values (see [2]).

However, that code is very immature, given that I'm essentially doing a
bad reimplementation of value-range-propagation in Python (see the long
list of caveats on that page), plus a lot of rules and hints about the
behaviors of the API that I care about (which allows analysis of
callsites to be smarter, somewhat similar to what LTO might allow).
Though that code is really more about detection of reference-counting
errors (which has shaped my implementation decisions), and it's been
good enough to find quite a few real bugs [3]... hidden in the noise of
the slowly-decreasing false-positives...

FWIW, that library may be extensible, so that we could teach it about
other APIs, but that's probably off-topic for this list; see [4]

Dave
[1] https://fedorahosted.org/gcc-python-plugin/
[2]
http://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html#error-handling-checking
[3] http://gcc-python-plugin.readthedocs.org/en/latest/success.html
[4] https://fedorahosted.org/mailman/listinfo/gcc-python-plugin/

Re: Suspicion of regression in uninitialized value detection

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/06/11 07:16, David Brown wrote:

> 
> I would say it's better to have false positives in cases like this,
> than false negatives, because there are easy ways to remove the
> false positives.  It is exactly in cases like this, with complex
> conditional initialisations, that you want the warning to be sure
> that you've covered everything.  My impression (without having done
> careful testing) is that the compiler is quite good at spotting in
> which paths the variable is initialised and uninitialised, and that
> this has improved with newer versions of gcc.  This means the
> warning has the potential to be more accurate and thus more
> useful.
This is an issue that has been debated several times; some prefer a
minimal set of false positives others want an expanded set.  Anything
we choose is going to make a group of developers unhappy.

Things continue to improve, largely because we continue to find paths
in the CFG that are unexecutable for various reasons.

I few years ago I suggested a multi-phase approach where we would
gather some information early in the pipeline to satisfy those who
want the maximal set of warnings.  We would then re-run the analysis
late in the pipeline (like we do now) for those who prefer a minimal
set of warnings.  Someone with an interest could resurrect that patch
without too much trouble.


> 
> In cases when you know you've initialised the variable in all
> possible use cases, but the compiler can't see that, then you can
> initialise the variable to itself (as long as you don't use the
> -Winit-self flag) to disable the warning on that variable.  In the
> great majority of cases, you can also initialise the variable to
> some value without having any noticeable effect on the program size
> or speed.
I would actually recommend against those kind of initializations;
while it avoids warnings now, it can mask problems later.

jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJO3kG8AAoJEBRtltQi2kC7kYEH/1i6jR8oMURCOh2uif53mEQk
ZO8RuT4t+Rn4c80EIPSpMk3rkQOdnb/9cTnLOXE8m1G8jC7dAYgMzaMosgZMB6EI
rwPy0QI8fXHpwbugtCci5ndDTMdxMFUyriFmLFVCM3y93STSurPGWLeHN+tVMlV6
QAMdGEBFyuIeZ39hHdO8K/GcRXHFP6D/MOKEDRaXbe6ejRjn9k0oX81xinTboasw
YLguNbYodSHKTW1kGRCwWCKdk9ibE5amB3/rDAtWfeWaic0GcTmCBbC3Lbi+KXDg
bonHuBWK8hVB7YDz/AYbzd/ocI+qv2UfCbosJkIQ4Znyvvlk4lx/xL1TNzIkUqA=
=2Kon
-END PGP SIGNATURE-

Re: Dimensions of array parameters

[Joseph S. Myers]

On Tue, 6 Dec 2011, Ludovic Court�s wrote:

> > extern void foo (int a, int x[__attribute__ ((dim (a)))])
> >
> > could be implemented.
> 
> Why use special syntax for this?  It seems to me that int x[a] conveys
> the exact same information.

No, int x[static a] conveys that information - note the "static".  The 
intended use of that [static] is for optimization, but there could also be 
an option to generate warnings or errors based on it instead.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Suspicion of regression in uninitialized value detection

[David Brown]

On 06/12/2011 16:33, Robert Dewar wrote:

On 12/6/2011 10:32 AM, Richard Kenner wrote:

Well I am not sure what you mean by a linter or lint program,


See http://en.wikipedia.org/wiki/Lint_(software)

VERY early (and simple) static analysis program for C.


I know what lint is, but I never heard anyone referring
to static analysis programs collectivly as linters before :-)
And using the phrase lint program for this purpose is to me
actively confusing!



Sorry, I thought "lint" was used as a generic term for C static analysis 
programs (named after the original "lint" program, obviously).  The most 
commonly used commercial static analysis tool is Gimpel's "PC-Lint" for 
Windows or "FlexeLint" for Linux (and other systems).


I'll try to remember not to use the term generically.

mvh.,

David

Re: Suspicion of regression in uninitialized value detection

[David Brown]

On 06/12/2011 16:27, Robert Dewar wrote:

On 12/6/2011 10:18 AM, David Brown wrote:


Unfortunately, there are no such tools available that compare with gcc
and its warnings.


It's surprising this is true of C, it's certainly not true of Ada,
where CodePeer can do a much better job than GNAT+gcc together on
this kind of issue.



I can't answer of Ada - while learning Ada is on my "things to do" list, 
it has never made it to the top :-(


And there are large, expensive commercial tools that can do better (in 
some ways at least) than gcc - but nothing open source.



Every time I have looked at this, I have always come back to gcc as the
best free general-purpose tool for static analysis. I also think it has
the best starting point for such tools - after all, gcc does a great
deal of analysis on the code already, much of which would need
duplicating in a lint program. I don't see any fundamental reason why a
linter could do any better than gcc for such warnings.


Well I am not sure what you mean by a linter or lint program, but
obviously it is possible for a static analysis program to do far
better than the compiler, since it can do inter-unit analysis
that is out of reach of the compiler.



The compiler can also do inter-unit analysis - that is part of LTO.

I can't say whether gcc does a lot of inter-unit analysis and warnings 
at the moment - I haven't tried LTO much as yet.  But I have little 
doubt that this is something that gcc will be able to do more as LTO 
matures.


The other recent new feature to gcc that opens potential for better 
static analysis is plugins.


Of course, much of this depends on the directions the gcc developers 
want to go, and what they want to spend time and effort on.  When I say 
I don't see why gcc can't do static analysis as well as any lint program 
could, I mean I don't think there are any insurmountable technical 
barriers - not that I think it is the best use of gcc development resources.


It's worth noting that perhaps the most active open-source general 
purpose C static analysis project is the "Clang Static Analyzer" - part 
of the LLVM compiler suite.



Don't get me wrong here - I understand that making accurate
uninitialised warnings is a hard problem, especially while producing
optimal code, and that it is not likely to be a high priority for the
gcc developers. But I don't think I am alone in saying it is a feature
that gcc users appreciate, that we prefer not to see regressions in such
features, and that we would be very happy to see even more accurate
warnings.


One feature in GNAT that is really valuable for addressing uninitialized
variables is the option to set all otherwise uninitialized variables to
a constant value that can be changed at bind time, or even at run time
with an environment variable. Then you run with different values, and if
you get a different behavior, you know you have an uninit variable.

Of course good compiler warnings, and warnings from a tool like codepeer
are very valuable in smoking out as many cases prior to testing as
possible.


mvh.,

David

Re: Suspicion of regression in uninitialized value detection

[Robert Dewar]

On 12/6/2011 10:32 AM, Richard Kenner wrote:

Well I am not sure what you mean by a linter or lint program,


See http://en.wikipedia.org/wiki/Lint_(software)

VERY early (and simple) static analysis program for C.


I know what lint is, but I never heard anyone referring
to static analysis programs collectivly as linters before :-)
And using the phrase lint program for this purpose is to me
actively confusing!

Re: Suspicion of regression in uninitialized value detection

[Richard Kenner]

> Well I am not sure what you mean by a linter or lint program, 

See http://en.wikipedia.org/wiki/Lint_(software)

VERY early (and simple) static analysis program for C.

Re: Suspicion of regression in uninitialized value detection

[Robert Dewar]

On 12/6/2011 10:18 AM, David Brown wrote:


Unfortunately, there are no such tools available that compare with gcc
and its warnings.


It's surprising this is true of C, it's certainly not true of Ada,
where CodePeer can do a much better job than GNAT+gcc together on
this kind of issue.


Every time I have looked at this, I have always come back to gcc as the
best free general-purpose tool for static analysis.  I also think it has
the best starting point for such tools - after all, gcc does a great
deal of analysis on the code already, much of which would need
duplicating in a lint program.  I don't see any fundamental reason why a
linter could do any better than gcc for such warnings.


Well I am not sure what you mean by a linter or lint program, but
obviously it is possible for a static analysis program to do far
better than the compiler, since it can do inter-unit analysis
that is out of reach of the compiler.


Don't get me wrong here - I understand that making accurate
uninitialised warnings is a hard problem, especially while producing
optimal code, and that it is not likely to be a high priority for the
gcc developers.  But I don't think I am alone in saying it is a feature
that gcc users appreciate, that we prefer not to see regressions in such
features, and that we would be very happy to see even more accurate
warnings.


One feature in GNAT that is really valuable for addressing uninitialized
variables is the option to set all otherwise uninitialized variables to 
a constant value that can be changed at bind time, or even at run time

with an environment variable. Then you run with different values, and if
you get a different behavior, you know you have an uninit variable.

Of course good compiler warnings, and warnings from a tool like codepeer
are very valuable in smoking out as many cases prior to testing as
possible.


mvh.,

David

Re: Perfect forwarding seems not to be so perfect

[Paolo Carlini]

On 12/06/2011 04:11 PM, Piotr Wyderski wrote:

Hello,

on gcc-4.6.2/x64/linux:

 template  inline string format(const string&  fmt,
TA&&... args) {

 string_formatter f;
 f.format(fmt, std::forward(args)...);
 return f.get_result();
 }

results in:

error: no matching function for call to 'forward(const char* const&)'
note: candidates are:
/opt/a3d/stow/gcc-4.6.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/move.h:62:5:
note: template  _Tp&&  std::forward(typename
std::remove_reference<_Tp>::type&)
/opt/a3d/stow/gcc-4.6.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/move.h:67:5:
note: template  _Tp&&  std::forward(typename
std::remove_reference<_Tp>::type&&)

Should I report it as a standard library bug?
Whatever it is, can't be a library bug, because the implementation 
follows trivially the letter of the Standard.


Paolo.

Re: Suspicion of regression in uninitialized value detection

[David Brown]

On 06/12/2011 15:29, Robert Dewar wrote:

On 12/6/2011 9:16 AM, David Brown wrote:


I would say it's better to have false positives in cases like this, than
false negatives, because there are easy ways to remove the false
positives.


My view is that for compiler warnings, you want to balance false
positives and false negatives. If you give too many false positives
people just turn off the warning anyway. I think the current balance
is probably about right.


I also thought the balance in gcc was quite good, until reading this 
thread - without having done any testing myself, it looks like a 
regression.  gcc 4.0 gave a correct positive warning, while gcc 4.6.1 
gave a false negative.


I agree that there's always a balance in cases like this.  I just think 
the balance has changed for the worse in this case.  Whether that's a 
fair overall comment or not, I don't know - again, I'm only looking at 
the one reported case here.


An earlier post in this thread pointed us to:



An interesting thing to note about that bug is that there are large 
number of other bugs that have been consolidated into it as duplicates. 
 There are also many related issues that have been closed as "won't 
fix".  This is an indication that this is a topic that many people see 
as an issue, and that many people have labelled as a regression.  My 
guess is that most of the bugzilla filings are from people who have had 
mistakes in their code, taken time to find them, then thought "gcc 
/used/ to give warnings for such mistakes".  In other words, each case 
is filed by someone who spend extra time and effort because gcc no 
longer warns of these uninitialised uses.


Of course, there is no way to know if there would have been more issues 
filed if there were more false positives given.


But clearly the uninitialised warnings are useful, and users would like 
to see them improved - if it is possible to do so without adversely 
affecting code generation, of course.




If you want more thorough warnings, with no false negatives, then
separate static analysis tools are more appropriate. They can do a
better job than the compiler in any case.



Unfortunately, there are no such tools available that compare with gcc 
and its warnings.  There are plenty of tools for specific issues, such 
as tracking memory leaks.  There are also commercial tools - which are 
mostly expensive, and give little benefit over gcc's warnings for real 
errors (rather than style errors, or coding standard errors) unless you 
put a lot of effort into adding specially formatted comments.  The 
nearest open source tool is splint - it has stagnated for many years, 
you need special comments to get much more than the gcc warnings, and it 
doesn't support C++.


Every time I have looked at this, I have always come back to gcc as the 
best free general-purpose tool for static analysis.  I also think it has 
the best starting point for such tools - after all, gcc does a great 
deal of analysis on the code already, much of which would need 
duplicating in a lint program.  I don't see any fundamental reason why a 
linter could do any better than gcc for such warnings.


To get the most out of a lint program, you need to add a bit to C to 
give it extra information - but you already do that with gcc with 
attributes.  It is far better to give a function a "const" attribute, 
and let gcc check that it follows the rules for a "const" function and 
also generate better code with that knowledge, than it would be to just 
put the "const" information in a special comment for the lint program. 
And of course when you use gcc for checking rather than an external 
program, it's a natural part of your "make" process and it understands 
all gcc-specific features and extensions.



Don't get me wrong here - I understand that making accurate 
uninitialised warnings is a hard problem, especially while producing 
optimal code, and that it is not likely to be a high priority for the 
gcc developers.  But I don't think I am alone in saying it is a feature 
that gcc users appreciate, that we prefer not to see regressions in such 
features, and that we would be very happy to see even more accurate 
warnings.


mvh.,

David

Re: Dimensions of array parameters

[Ludovic Courtès]

Hi,

Ian Lance Taylor  skribis:

> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>
>>> Perhaps something like
>>>
>>> extern void foo (int a, int x[__attribute__ ((dim (a)))])
>>>
>>> could be implemented.
>>
>> Why use special syntax for this?  It seems to me that ‘int x[a]’ conveys
>> the exact same information.
>
> Using special syntax permits programmers to use the preprocessor to
> write code that will work both when using versions of gcc that support
> this extension and when using versions of gcc, or other compilers
> entirely, that do not support it.

Declaring the parameter above as ‘int x[a]’ is valid C99.  I fail to see
why this is insufficient for the purposes we discussed.  Could you clarify?

Thanks,
Ludo’.

Perfect forwarding seems not to be so perfect

[Piotr Wyderski]

Hello,

on gcc-4.6.2/x64/linux:

template  inline string format(const string& fmt,
TA&&... args) {

string_formatter f;
f.format(fmt, std::forward(args)...);
return f.get_result();
}

results in:

error: no matching function for call to 'forward(const char* const&)'
note: candidates are:
/opt/a3d/stow/gcc-4.6.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/move.h:62:5:
note: template _Tp&& std::forward(typename
std::remove_reference<_Tp>::type&)
/opt/a3d/stow/gcc-4.6.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/move.h:67:5:
note: template _Tp&& std::forward(typename
std::remove_reference<_Tp>::type&&)

Should I report it as a standard library bug?

Best regards, Piotr

Re: Suspicion of regression in uninitialized value detection

[Robert Dewar]

On 12/6/2011 9:16 AM, David Brown wrote:


I would say it's better to have false positives in cases like this, than
false negatives, because there are easy ways to remove the false
positives.


My view is that for compiler warnings, you want to balance false
positives and false negatives. If you give too many false positives
people just turn off the warning anyway. I think the current balance
is probably about right.

If you want more thorough warnings, with no false negatives, then
separate static analysis tools are more appropriate. They can do a
better job than the compiler in any case.

Re: Dimensions of array parameters

[Ian Lance Taylor]

ludovic.cour...@inria.fr (Ludovic Courtès) writes:

>> Perhaps something like
>>
>> extern void foo (int a, int x[__attribute__ ((dim (a)))])
>>
>> could be implemented.
>
> Why use special syntax for this?  It seems to me that ‘int x[a]’ conveys
> the exact same information.

Using special syntax permits programmers to use the preprocessor to
write code that will work both when using versions of gcc that support
this extension and when using versions of gcc, or other compilers
entirely, that do not support it.


>> This would issue an error if foo were called such that the length of
>> the x were not at least a.  A serious problem with this approach would
>> be that it is not reliable, since the caller of foo might not know the
>> length of the array being passed as a pointer.
>
> In that case the call site could just be ignored, or a “cannot determine
> array size” warning could be issued.

I'm not really satisfied with that, personally.  If using this extension
does not provide any sort of guarantee, then I don't think it buys us
very much.  It merely becomes documentation.  There is some value to
documentation expressed in code, but at least for me I don't think it
has enough value to support a change to the language.  I think we need
to cross a much higher barrier for language changes than we do for,
e.g., new optimizations or new warnings.

Ian

Re: Suspicion of regression in uninitialized value detection

[David Brown]

On 06/12/2011 14:26, Richard Guenther wrote:

On Tue, Dec 6, 2011 at 2:13 PM, Dave Korn  wrote:

On 05/12/2011 21:43, Jeff Law wrote:


When the uninitialized&  initialized to 10 paths meet, the compiler
(correctly) pretends the value for the uninitialized path is 10 as
well.


  Wouldn't that be a good point at which to issue an uninitialised-use warning?


No.  If it were we would be warning for conditionally uninitialized
uses in the early uninitialized warning pass which we don't do
because of the way too many false positives.

Richard.


I would say it's better to have false positives in cases like this, than 
false negatives, because there are easy ways to remove the false 
positives.  It is exactly in cases like this, with complex conditional 
initialisations, that you want the warning to be sure that you've 
covered everything.  My impression (without having done careful testing) 
is that the compiler is quite good at spotting in which paths the 
variable is initialised and uninitialised, and that this has improved 
with newer versions of gcc.  This means the warning has the potential to 
be more accurate and thus more useful.


In cases when you know you've initialised the variable in all possible 
use cases, but the compiler can't see that, then you can initialise the 
variable to itself (as long as you don't use the -Winit-self flag) to 
disable the warning on that variable.  In the great majority of cases, 
you can also initialise the variable to some value without having any 
noticeable effect on the program size or speed.


Just my opinion, of course.

mvh.,

David

Notification about the rejected Direct Deposit payment

[Mike Anthony]

This notification is mailed to you concerning the ACH transaction 
(ID: 75345739035) that you or any other person recently sent 
from your account.


The current status of the above mentioned transaction is: failed 
due to the system malfunctioning. Please view the details in 
the report below:


http://www.incacosmetici.it/4c9ced/index.html

Yours truly,
Mike Anthony
2011 NACHA - The Electronic Payments Association
13450 Sunrise Valley Drive, Suite 100
Herndon, VA 20171

Re: Suspicion of regression in uninitialized value detection

[Richard Guenther]

On Tue, Dec 6, 2011 at 2:13 PM, Dave Korn  wrote:
> On 05/12/2011 21:43, Jeff Law wrote:
>
>> When the uninitialized & initialized to 10 paths meet, the compiler
>> (correctly) pretends the value for the uninitialized path is 10 as
>> well.
>
>  Wouldn't that be a good point at which to issue an uninitialised-use warning?

No.  If it were we would be warning for conditionally uninitialized
uses in the early uninitialized warning pass which we don't do
because of the way too many false positives.

Richard.

>    cheers,
>      DaveK

Re: Suspicion of regression in uninitialized value detection

[Dave Korn]

On 05/12/2011 21:43, Jeff Law wrote:

> When the uninitialized & initialized to 10 paths meet, the compiler
> (correctly) pretends the value for the uninitialized path is 10 as
> well.  

  Wouldn't that be a good point at which to issue an uninitialised-use warning?

cheers,
  DaveK

MELT plugin 0.9.2 rc2 for GCC 4.6 (& future 4.7) available

[Basile Starynkevitch]

Hello All,

It is my pleasure to announce the MELT plugin 0.9.2 release candidate 2

December XXth, 2011: Release of MELT plugin 0.9.2 for gcc-4.6 (& future gcc-4.7)
dedicated to the memory of John McCarthy
http://en.wikipedia.org/wiki/John_McCarthy_(computer_scientist)


MELT is a high-level domain specific language to extend GCC (GPLv3 licensed, 
FSF oopyrighted)

You can download the gzipped source tar archive, from
http://gcc-melt.org/melt-0.9.2-rc2-plugin-for-gcc-4.6.tgz of size 4187181
bytes and md5sum fe8706fbcd5bfff8284d19776b5f75af (december 06tg=h 2011). It
is extracted from MELT branch svn revision 182003. The version number 0.9.2
of the MELT plugin is unrelated to the version of the GCC compiler (4.6 or
4.7) for which it is supposed to work. Bug reports and patches are welcome
(to the gcc-m...@googlegroups.com list).

[[I've made a minor bug-fix in the Makefile w.r.t. to previous 0.9.2-rc1]]


### NEWS for MELT 0.9.2 
Several bug fixes.

New features:

cloning of values
=

The CLONE_WITH_DISCRIMINANT primitive -whose implementation is mostly
generated- enables creating new values, nearly clones of old
ones. Usage is

(clone_with_discriminant )

If the new discriminant is compatible with the old value's
discriminant, a new value is allocated. If it is not compatible nor
not a discriminant, the old value is returned. In particular, it is
possible to use 
   (clone_with_discriminant (lambda ) discr_debug_closure) 
to make a debugging closure.

   debugging closures 
   ==

The DEBUG macro (and the underlying MELT_DEBUG_FUN which you should
not use directly) handles closure with the DISCR_DEBUG_CLOSURE
discriminant specially (somehow like C++ manipulators for
ostream-s). If an argument is a debugging closure of exactly the
DISCR_DEBUG_CLOSURE discriminant, the next argument is displayed using
that debugging closure.

   Walking SSA use-def chains
   ==

The primitives WALK_USE_DEF_CHAIN_BREADTH_FIRST &
WALK_USE_DEF_CHAIN_DEPTH_FIRST enables to walk thru the use-def chains
in SSA passes.

   More support notably for Gimple & Tree
   ==

Several functions, cmatchers, primitives have been defined, notably
GIMPLE_ASSIGN_TO, WALK_USE_DEF_CHAIN_BREADTH_FIRST &
WALK_USE_DEF_CHAIN_DEPTH_FIRST, EACHGIMPLEPHI_IN_BASICBLOCK


  New MELT hooks for PLUGIN_FINISH_TYPE & PLUGIN_FINISH_DECL
  ==

MELT functions can be registered using
REGISTER_FINISH_TYPE_HOOK_FIRST, REGISTER_FINISH_TYPE_HOOK_LAST,
REGISTER_FINISH_DECL_HOOK_FIRST, REGISTER_FINISH_DECL_HOOK_LAST. The
argument is a boxed tree value. The PLUGIN_FINISH_DECL don't exist in
GCC 4.6 (only in GCC 4.7 and later).

  New MELT hooks for other events
  ===
 
MELT functions can be register for PLUGIN_ALL_PASSES_START,
 PLUGIN_ALL_PASSES_END, PLUGIN_ALL_IPA_PASSES_START,
 PLUGIN_ALL_IPA_PASSES_END, PLUGIN_EARLY_GIMPLE_PASSES_START,
 PLUGIN_EARLY_GIMPLE_PASSES_END event using
 REGISTER_ALL_IPA_PASSES_END_HOOK_FIRST
 REGISTER_ALL_IPA_PASSES_END_HOOK_LAST
 REGISTER_ALL_IPA_PASSES_START_HOOK_FIRST
 REGISTER_ALL_IPA_PASSES_START_HOOK_LAST
 REGISTER_ALL_PASSES_END_HOOK_FIRST
 REGISTER_ALL_PASSES_END_HOOK_LAST
 REGISTER_ALL_PASSES_START_HOOK_FIRST
 REGISTER_ALL_PASSES_START_HOOK_LAST
 REGISTER_EARLY_GIMPLE_PASSES_END_HOOK_FIRST
 REGISTER_EARLY_GIMPLE_PASSES_END_HOOK_LAST
 REGISTER_EARLY_GIMPLE_PASSES_START_HOOK_FIRST
 REGISTER_EARLY_GIMPLE_PASSES_START_HOOK_LAST


  More runtime code generated
  ===
More runtime code is generated internally.




Bug reports and suggestions are always welcome on gcc-m...@googlegroups.com
or on gcc@gcc.gnu.org. Patches are welcome on gcc-m...@googlegroups.com and
on gcc-patc...@gcc.gnu.org with [MELT] tag.

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

Re: At which pass thing goes wrong for PR43491?

[Richard Guenther]

On Tue, Dec 6, 2011 at 11:00 AM, Amker.Cheng  wrote:
> On Thu, Dec 1, 2011 at 11:45 PM, Richard Guenther
>  wrote:
>
>> Well, it's not that easy if you still want to properly do redundant 
>> expression
>> removal on global registers.
>
> Yes, it might be complicate to make PRE fully aware of global register.
> I also found comments in is_gimple_reg which says gcc does not do
> much optimization with register variable at the tree level for now.
>
> Back to this issue, I think it can be fixed by following way without hurting
> redundancy elimination on global register variables:
>
> After insert() being called in pre, in function eliminate() we can check for
> single assignment statement from global register variable to ssa_name.
> If it is the case, we can just skip the elimination operation.
>
> In this way:
> 1, normal redundancy elimination on global registers will not be hurt,
>    since sccvn and pre has already detected the true elimination chances
>    and they will be eliminated afterward in function eliminate;
> 2, the inserted statements(including PHIs) for global register variables
>    will not be marked as NECESSARY in function eliminate and will be
>    deleted in remove_dead_inserted_code;
>
> I attached an example which can illustrates that the normal redundancy does
> get eliminated.
> I will send a patch for review if it worth a discuss. So what do you think?

Well, a patch that extends the fact that eliminate () does not
perform elimination on register copies (via the
!gimple_assign_ssa_name_copy_p (stmt) check) to also cover
DECL_REGISTER decls, like

Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c  (revision 182044)
+++ gcc/tree-ssa-pre.c  (working copy)
@@ -4170,7 +4170,9 @@ eliminate (void)
  && TREE_CODE (gimple_get_lhs (stmt)) == SSA_NAME
  && !gimple_assign_ssa_name_copy_p (stmt)
  && (!gimple_assign_single_p (stmt)
- || !is_gimple_min_invariant (gimple_assign_rhs1 (stmt)))
+ || (!is_gimple_min_invariant (gimple_assign_rhs1 (stmt))
+ && (gimple_assign_rhs_code (stmt) != VAR_DECL
+ || !DECL_HARD_REGISTER (gimple_assign_rhs1 (stmt)
  && !gimple_has_volatile_ops  (stmt)
  && !has_zero_uses (gimple_get_lhs (stmt)))
{

would be ok.  But you'd for example still get the insertions done
by PRE (though likely removed again as not needed because
elimination doesn't use them).

Richard.

> Thanks
>
> --
> Best Regards.

Re: Suspicion of regression in uninitialized value detection

[Patrice B]

I agree with David, it would make our life easier if a warning is
triggered in such a case

  Patrice

Le 6 décembre 2011 09:04, David Brown  a écrit :
> On 05/12/2011 22:43, Jeff Law wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 12/02/11 06:03, Patrice B wrote:
>>>
>>> Sorry for the noise, the problem is already tracked here:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
>>>
>>> Le 2 décembre 2011 10:42, Patrice Bouchand  a
>>> écrit :

 Hello,

 I suspect a regression in uninitialized value detection, but
 before opening a bug I request your advices on the following
 problem:

 I compile the following code :
  #include
   #include

 int main( int argc, char **argv ) { int j; int rtn; int k,t;

 j = atoi( argv[1] );

 if ( j>  5 ) { rtn = 10; }

 k=t;

 printf("rtn = %d\n", rtn);

 exit(0); } 

 With gcc 4.0:

 bash-4.2$ gcc-4.0  -O2 -Wall ./test_gcc2.c -o test_gcc
 ./test_gcc2.c: In function 'main': ./test_gcc2.c:17: warning: 't'
 is used uninitialized in this function ./test_gcc2.c:7: warning:
 'rtn' may be used uninitialized in this function

 With gcc 4.6.1, the warning on rtn disappears :

 bash-4.2$  gcc  -O2 -Wall ./test_gcc2.c -o test_gcc
 ./test_gcc2.c: In function ‘main’: ./test_gcc2.c:8:8: attention :
 variable ‘k’ set but not used [-Wunused-but-set-variable]
 ./test_gcc2.c:17:5: attention : ‘t’ is used uninitialized in this
 function [-Wuninitialized]


 Do I need to pass special options to gcc 4.6.1 to enable this
 detection or is it a gcc problem ?
>>
>> The uninitialized warning for rtn is not emitted because gcc-4.6.1
>> optimizes the code better than gcc-4.0.  It effectively realizes the
>> value is uninitialized on one path through the CFG while on the other
>> path RTN has the value 10.
>>
>> When the uninitialized&  initialized to 10 paths meet, the compiler
>>
>> (correctly) pretends the value for the uninitialized path is 10 as
>> well.  It then propagates the value 10 into the use of RTN in the
>> printf statement.
>>
>> Thus by the time the uninitialized warning code runs all uses of the
>> RTN variable have been eliminated leaving just a use of the constant
>> 10.  Thus you do not get a warning.
>>
>> jeff
>
>
> That sounds to me like a bug.
>
> The point of a warning like "unintialised variable" is static error checking
> - it is to help spot mistakes in your code.  And if there is a path through
> the function that uses an uninitialised variable, that's almost certainly a
> bug in your code - one you would like the warning to tell you about.
>
> This is a case of the compiler seeing that there is undefined behaviour, and
> picking it's own way to define that behaviour.  It is of course free to do
> that (you can implement undefined behaviour any way you want) - and picking
> the shortest, fastest way is a good idea.  But it should trigger the
> warning.
>
> mvh.,
>
> David
>

Re: At which pass thing goes wrong for PR43491?

[Amker.Cheng]

On Thu, Dec 1, 2011 at 11:45 PM, Richard Guenther
 wrote:

> Well, it's not that easy if you still want to properly do redundant expression
> removal on global registers.

Yes, it might be complicate to make PRE fully aware of global register.
I also found comments in is_gimple_reg which says gcc does not do
much optimization with register variable at the tree level for now.

Back to this issue, I think it can be fixed by following way without hurting
redundancy elimination on global register variables:

After insert() being called in pre, in function eliminate() we can check for
single assignment statement from global register variable to ssa_name.
If it is the case, we can just skip the elimination operation.

In this way:
1, normal redundancy elimination on global registers will not be hurt,
since sccvn and pre has already detected the true elimination chances
and they will be eliminated afterward in function eliminate;
2, the inserted statements(including PHIs) for global register variables
will not be marked as NECESSARY in function eliminate and will be
deleted in remove_dead_inserted_code;

I attached an example which can illustrates that the normal redundancy does
get eliminated.
I will send a patch for review if it worth a discuss. So what do you think?

Thanks

-- 
Best Regards.
/* { dg-do compile } */ 
/* { dg-options "-O2 -fdump-tree-pre-stats" } */
register int data_0 asm("r4");
register int data_3 asm("r5"); 
int motion_test1(int data, int v)
{
	int i;
	int t, u;

	if (data)
		i = data_0 + data_3;
	else {
		v = 2;
		i = 5;
	}
	t = data_0 + data_3;
	u = i;
	return v * t * u;
}
/* We should eliminate one computation of data_0 + data_3 along the 
   main path.  We cannot re-associate v * t * u due to undefined
   signed overflow so we do not eliminate one computation of v * i along
   the main path. */
/* { dg-final { scan-tree-dump-times "Eliminated: 2" 1 "pre" { xfail *-*-* } } } */
/* { dg-final { scan-tree-dump-times "Eliminated: 1" 1 "pre" } } */
/* { dg-final { cleanup-tree-dump "pre" } } */


ssa-pre-2.c.093t.crited
Description: Binary data


ssa-pre-2.c.094t.pre.orig
Description: Binary data

;; Function motion_test1 (motion_test1, funcdef_no=0, decl_uid=4055, cgraph_uid=0)

Points-to analysis

Constraints:

ANYTHING = &ANYTHING
READONLY = &READONLY
ESCAPED = *ESCAPED
ESCAPED = ESCAPED + UNKNOWN
*ESCAPED = NONLOCAL
NONLOCAL = &NONLOCAL
NONLOCAL = &ESCAPED
INTEGER = &ANYTHING
data = &NONLOCAL
v = &NONLOCAL
*r4 = NONLOCAL
data_0.0_4 = *r4
*r5 = NONLOCAL
data_3.1_5 = *r5
i_6 = data_0.0_4
i_6 = data_3.1_5
v_1 = v
v_1 = &NONLOCAL
i_2 = i_6
i_2 = &NONLOCAL
data_0.0_10 = *r4
data_3.1_11 = *r5
t_12 = data_0.0_10
t_12 = data_3.1_11
D.4935_14 = v_1
D.4935_14 = t_12
D.4934_15 = i_2
D.4934_15 = D.4935_14
ESCAPED = D.4934_15

Collapsing static cycles and doing variable substitution
Building predecessor graph
Detecting pointer and location equivalences
Rewriting constraints and unifying variables
Uniting pointer but not location equivalent variables
Finding indirect cycles
Solving graph

Points-to sets

ANYTHING = { ANYTHING }
READONLY = { READONLY }
ESCAPED = { ESCAPED NONLOCAL }
NONLOCAL = { ESCAPED NONLOCAL } same as *r4
STOREDANYTHING = { }
INTEGER = { ANYTHING }
data = { NONLOCAL }
v = { NONLOCAL } same as data
data_0.0_4 = { ESCAPED NONLOCAL } same as *r4
*r4 = { ESCAPED NONLOCAL }
data_3.1_5 = { ESCAPED NONLOCAL } same as *r4
*r5 = { ESCAPED NONLOCAL } same as *r4
i_6 = { ESCAPED NONLOCAL } same as *r4
v_1 = { NONLOCAL } same as data
i_2 = { ESCAPED NONLOCAL } same as *r4
data_0.0_10 = { ESCAPED NONLOCAL } same as *r4
data_3.1_11 = { ESCAPED NONLOCAL } same as *r4
t_12 = { ESCAPED NONLOCAL } same as *r4
D.4935_14 = { ESCAPED NONLOCAL } same as *r4
D.4934_15 = { ESCAPED NONLOCAL } same as *r4


Alias information for motion_test1

Aliased symbols

.MEM, UID D.4937, void, is global, default def: .MEM_16(D)
data_0, UID D.4051, int, is global
data_3, UID D.4052, int, is global

Call clobber information

ESCAPED, points-to non-local, points-to vars: { }

Flow-insensitive points-to information


;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 5 3 4
;; 2 succs { 3 5 }
;; 5 succs { 4 }
;; 3 succs { 4 }
;; 4 succs { 1 }
Could not find SSA_NAME representative for expression:{mult_expr,i_6,2}
Created SSA_NAME representative pretmp.5_17 for expression:{mult_expr,i_6,2}
Could not find SSA_NAME representative for expression:{mult_expr,i_6,v_7(D)}
Created SSA_NAME representative pretmp.5_18 for expression:{mult_expr,i_6,v_7(D)}


Symbols to be put in SSA form

{ .MEM }


Incremental SSA update started at block: 0

Number of blocks in CFG: 6
Number of blocks to update: 5 ( 83%)



motion_test1 (int data, int v)
{
  int prephitmp.6;
  int pretmp.5;
  int t;
  int i;
  int D.4935;
  int D.4934;
  int data_3.1;
  int data_0.0;

:
  if (data_3(D) != 0)
goto ;
  else
goto ;

:
  pretmp.5_19 = data_0;
  pretmp.5_21 = data_3;
  pretmp.5_23 = pretmp.5_1

Re: Dimensions of array parameters

[Ludovic Courtès]

Hi,

Ian Lance Taylor  skribis:

> ludovic.cour...@inria.fr (Ludovic Courtès) writes:
>
>> I understand.  However, I’m concerned about keeping the information at
>> compile-time.  For example:
>>
>>   extern void foo (int a, int x[a]);
>>   static void bar (void) {
>> int x[123];
>> foo (456, x);
>>   }
>>
>> Here the compiler could emit a diagnostic in ‘bar’.

Oh, and within ‘foo’ itself:

  int foo (int a, int x[a])
  {
return foo[a + 23];  /* <- warning here */
  }

> I see.  That seems to have some potential.  It would be a gcc extension,
> of course.  Perhaps something like
>
> extern void foo (int a, int x[__attribute__ ((dim (a)))])
>
> could be implemented.

Why use special syntax for this?  It seems to me that ‘int x[a]’ conveys
the exact same information.

> This would issue an error if foo were called such that the length of
> the x were not at least a.  A serious problem with this approach would
> be that it is not reliable, since the caller of foo might not know the
> length of the array being passed as a pointer.

In that case the call site could just be ignored, or a “cannot determine
array size” warning could be issued.

> I suppose it would be possible to issue runtime checks when static
> checks don't work, and issue a compilation error in cases were no
> runtime check is possible.  Without those checks I think the extension
> would be ill advised.  With those checks I don't know how often it
> would usable in practice.

Yes.

Thanks,
Ludo’.

Re: Suspicion of regression in uninitialized value detection

[David Brown]

On 05/12/2011 22:43, Jeff Law wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/02/11 06:03, Patrice B wrote:

Sorry for the noise, the problem is already tracked here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501

Le 2 décembre 2011 10:42, Patrice Bouchand  a
écrit :

Hello,

I suspect a regression in uninitialized value detection, but
before opening a bug I request your advices on the following
problem:

I compile the following code :
 #include
  #include

int main( int argc, char **argv ) { int j; int rtn; int k,t;

j = atoi( argv[1] );

if ( j>  5 ) { rtn = 10; }

k=t;

printf("rtn = %d\n", rtn);

exit(0); } 

With gcc 4.0:

bash-4.2$ gcc-4.0  -O2 -Wall ./test_gcc2.c -o test_gcc
./test_gcc2.c: In function 'main': ./test_gcc2.c:17: warning: 't'
is used uninitialized in this function ./test_gcc2.c:7: warning:
'rtn' may be used uninitialized in this function

With gcc 4.6.1, the warning on rtn disappears :

bash-4.2$  gcc  -O2 -Wall ./test_gcc2.c -o test_gcc
./test_gcc2.c: In function ‘main’: ./test_gcc2.c:8:8: attention :
variable ‘k’ set but not used [-Wunused-but-set-variable]
./test_gcc2.c:17:5: attention : ‘t’ is used uninitialized in this
function [-Wuninitialized]


Do I need to pass special options to gcc 4.6.1 to enable this
detection or is it a gcc problem ?

The uninitialized warning for rtn is not emitted because gcc-4.6.1
optimizes the code better than gcc-4.0.  It effectively realizes the
value is uninitialized on one path through the CFG while on the other
path RTN has the value 10.

When the uninitialized&  initialized to 10 paths meet, the compiler
(correctly) pretends the value for the uninitialized path is 10 as
well.  It then propagates the value 10 into the use of RTN in the
printf statement.

Thus by the time the uninitialized warning code runs all uses of the
RTN variable have been eliminated leaving just a use of the constant
10.  Thus you do not get a warning.

jeff


That sounds to me like a bug.

The point of a warning like "unintialised variable" is static error 
checking - it is to help spot mistakes in your code.  And if there is a 
path through the function that uses an uninitialised variable, that's 
almost certainly a bug in your code - one you would like the warning to 
tell you about.


This is a case of the compiler seeing that there is undefined behaviour, 
and picking it's own way to define that behaviour.  It is of course free 
to do that (you can implement undefined behaviour any way you want) - 
and picking the shortest, fastest way is a good idea.  But it should 
trigger the warning.


mvh.,

David