Re: Testing compiler reliability using Csmith

[Andi Kleen]

Radu Ometita  writes:

> Hello everyone!
>
> We are working on writing a paper about testing the reliability of C 
> compilers by using Csmith (a random C99 program generator).
>
> A previous testing effort, using Csmith, found 79 GCC bugs, and 25 of
> those have been marked by developers as P1
> (https://www.flux.utah.edu/download?uid=114
> ): . However, after this
> paper was published we are unaware of any further testing using
> Csmith, and we would like to ask you, if you are aware of any such
> efforts or further results.

Sameeran has been doing some additional testing with modified csmith.

There's currently no systematic effort to run csmith regularly
to find regressions.

-Andi

Re: Source code coverage of gcc

[Andi Kleen]

sameeran joshi  writes:

> Hi,
> I have a random C program as a test case, for which I need to do
> source code coverage on gcc.
> I have used the gcov tool and further the lcov tool. The percentage of
> source code coverage which I get after using gcov, Is that the final %
> which I need to do gcc source code coverage?
>
> What does it mean to build gcc with -pg option, how does that help in
> source code coverage?

lcov/gcov can only work if the code is instrumented.
So this requires building gcc with BOOT_CFLAGS="-O2 -g -pg"
(see the chapter on building gcc in the manual for more information)

You would then run the instrumented gcc, which writes coverage
data to disk. Then lcov can be used to get a summary of coverage.

-Andi

Re: Bug in divmodhi4(), plus poor inperformant code

[Stefan Kanthak]

"Segher Boessenkool"  wrote:

> On Wed, Dec 05, 2018 at 02:19:14AM +0100, Stefan Kanthak wrote:
>> "Paul Koning"  wrote:
>> 
>> > Yes, that's a rather nasty cut & paste error I made.
>> 
>> I suspected that.
>> Replacing
>> !(den & (1L<<31))
>> with
>> (signed short) den >= 0
>> avoids this type of error: there's no need for a constant here!
>> 
>> JFTR: of course the 1L should be just a 1, without suffix.
> 
> "int" can be 16 bits only, I think?

This function works on short int, which can only be 16 bits.

> If you change to 15 you can remove the L, sure.
> 
>> > But if the 31 is changed to a 15, is the code correct?
>> > I would think so.
> 
> I think so, too.
> 
>> > For optimization I'd think that an assembly language
>> > version would make more sense, and a few targets do that.
>> 
>> Moving 2 of 3 conditions from the loop is not an optimisation,
>> but a necessity!
> 
> The compiler can optimise things quite well.

It but doesn't, see : lines 15 to 20
are inside the loop, line 6 and 9 to 11 skip the loop.

>> In other words: why test 3 conditions in every pass of the
>> loop when you need to test only 1 condition inside the loop,
>> and the other 2 outside/before the loop?
> 
> Maybe the code is easier to read this way.  Maybe it doesn't matter for
> performance.  Maybe no one cared, this routine is for correctness anyway,

No, no & yes, yes: it's not very likely that it will really be called.
OTOH, an unsuspecting kid may find and copy it, assuming that a routine
shipped with GCC can't be THAT bad.-P
Or the (almost) identical
 ...

> any target that cares for performance will do an asm version, or (partly)
> inline this even.
> 
> Send a patch if you want to see it changed :-)

I saw my last PDP-11 more than 30 years ago!

regards
Stefan

gcc-7-20181206 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch 
revision 266871

You'll find:

 gcc-7-20181206.tar.xzComplete GCC

  SHA256=ca49cb7994c72f126df52d7a470172078746e7d87bd749350775da5aad1d690e
  SHA1=4607337dd4af308b707e9f9c4914014081f82d6b

Diffs from 7-20181129 are available in the diffs/ subdirectory.

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

Testing compiler reliability using Csmith

[Radu Ometita]

Hello everyone!

We are working on writing a paper about testing the reliability of C compilers 
by using Csmith (a random C99 program generator).

A previous testing effort, using Csmith, found 79 GCC bugs, and 25 of those 
have been marked by developers as P1 
(https://www.flux.utah.edu/download?uid=114 
): . However, after this paper was 
published we are unaware of any further testing using Csmith, and we would like 
to ask you, if you are aware of any such efforts or further results.

Best regards,
Radu Ometita,
Functional compilers engineer @IOHK

Re: [PATCH v2 1/1] stackleak: Register the 'stackleak_cleanup' pass before the '*free_cfg' pass

[Kees Cook]

On Thu, Dec 6, 2018 at 7:13 AM Alexander Popov  wrote:
>
> Currently the 'stackleak_cleanup' pass deleting a CALL insn is executed
> after the 'reload' pass. That allows gcc to do some weird optimization in
> function prologues and epilogues, which are generated later [1].
>
> Let's avoid that by registering the 'stackleak_cleanup' pass before
> the '*free_cfg' pass. It's the moment when the stack frame size is
> already final, function prologues and epilogues are generated, and the
> machine-dependent code transformations are not done.
>
> [1] https://www.openwall.com/lists/kernel-hardening/2018/11/23/2
>
> Reported-by: kbuild test robot 
> Signed-off-by: Alexander Popov 

Thanks! I've applied this to me tree and I'll send a pull request soon.

-Kees

> ---
>  scripts/gcc-plugins/stackleak_plugin.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/gcc-plugins/stackleak_plugin.c 
> b/scripts/gcc-plugins/stackleak_plugin.c
> index 2f48da9..dbd3746 100644
> --- a/scripts/gcc-plugins/stackleak_plugin.c
> +++ b/scripts/gcc-plugins/stackleak_plugin.c
> @@ -363,10 +363,12 @@ __visible int plugin_init(struct plugin_name_args 
> *plugin_info,
> PASS_POS_INSERT_BEFORE);
>
> /*
> -* The stackleak_cleanup pass should be executed after the
> -* "reload" pass, when the stack frame size is final.
> +* The stackleak_cleanup pass should be executed before the 
> "*free_cfg"
> +* pass. It's the moment when the stack frame size is already final,
> +* function prologues and epilogues are generated, and the
> +* machine-dependent code transformations are not done.
>  */
> -   PASS_INFO(stackleak_cleanup, "reload", 1, PASS_POS_INSERT_AFTER);
> +   PASS_INFO(stackleak_cleanup, "*free_cfg", 1, PASS_POS_INSERT_BEFORE);
>
> if (!plugin_default_version_check(version, &gcc_version)) {
> error(G_("incompatible gcc/plugin versions"));
> --
> 2.7.4
>


-- 
Kees Cook

RE: EXTERNAL: GCC 7.4 Released UNSUBSCRIBE

[Conquest, Jeff]

UNSUBSCRIBE

GCC 7.4 Released

[Richard Biener]

The GNU Compiler Collection version 7.4 has been released.

GCC 7.4 is a bug-fix release from the GCC 7 branch
containing important fixes for regressions and serious bugs in
GCC 7.3 with more than 189 bugs fixed since the previous release.

This release is available from the FTP servers listed at:

  http://www.gnu.org/order/ftp.html

Please do not contact me directly regarding questions or comments
about this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!

Re: LTO Test Case Help

[Martin Jambor]

Hi,

On Wed, Dec 05 2018, Michael Ploujnikov wrote:
> Hi,
>
> I'm trying to write a testcase to reproduce duplicate clone symbols
> such as in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297 I
> started with a testcase that is known to have constprop clones and
> split it into two object files:

so as we discussed on IRC, the testcase as you posted it to the mailing
list re-defined functions in a way that would not link, with or without
LTO.

When I fixed that, I had to make the following changes in order to
trigger IPA-CP cloning:  1. I had to put the calls in main into a loop,
otherwise everything is cold and we would not clone.  2. I had to make
different foos and bars actually semantically different, otherwise
IPA-ICF unified them, as it should.

The result reproduces the bug.  The two files are below.

Martin


 1.c 

volatile int g;

void __attribute__ ((noipa))
use (int v)
{
  g = v;
}

static int __attribute__ ((noinline))
foo (int arg)
{
  return 7 * arg;
}

static int __attribute__ ((noinline))
bar (int arg)
{
  return arg * arg;
}

extern int __attribute__ ((noinline))
entry2 (void);

int  __attribute__ ((noipa))
get_opaque_number (void)
{
  return 1;
}

int main (void)
{
  int i;
  for (i = 0; i < get_opaque_number (); i++)
{
  use (bar (3));
  use (bar (4));
  use (foo (5));
  use (foo (6));

  entry2 ();
}
  return 0;
}

 2.c 

extern void __attribute__ ((noipa))
use (int v);


static int __attribute__ ((noinline))
foo (int arg)
{
  return 8 * arg;
}

static int __attribute__ ((noinline))
bar (int arg)
{
  return arg * arg + 3;
}

int __attribute__ ((noinline))
entry2 (void)
{
  use (bar (3));
  use (bar (4));
  use (foo (5));
  use (foo (6));
  return 0;
}

[PATCH v2 1/1] stackleak: Register the 'stackleak_cleanup' pass before the '*free_cfg' pass

[Alexander Popov]

Currently the 'stackleak_cleanup' pass deleting a CALL insn is executed
after the 'reload' pass. That allows gcc to do some weird optimization in
function prologues and epilogues, which are generated later [1].

Let's avoid that by registering the 'stackleak_cleanup' pass before
the '*free_cfg' pass. It's the moment when the stack frame size is
already final, function prologues and epilogues are generated, and the
machine-dependent code transformations are not done.

[1] https://www.openwall.com/lists/kernel-hardening/2018/11/23/2

Reported-by: kbuild test robot 
Signed-off-by: Alexander Popov 
---
 scripts/gcc-plugins/stackleak_plugin.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/scripts/gcc-plugins/stackleak_plugin.c 
b/scripts/gcc-plugins/stackleak_plugin.c
index 2f48da9..dbd3746 100644
--- a/scripts/gcc-plugins/stackleak_plugin.c
+++ b/scripts/gcc-plugins/stackleak_plugin.c
@@ -363,10 +363,12 @@ __visible int plugin_init(struct plugin_name_args 
*plugin_info,
PASS_POS_INSERT_BEFORE);
 
/*
-* The stackleak_cleanup pass should be executed after the
-* "reload" pass, when the stack frame size is final.
+* The stackleak_cleanup pass should be executed before the "*free_cfg"
+* pass. It's the moment when the stack frame size is already final,
+* function prologues and epilogues are generated, and the
+* machine-dependent code transformations are not done.
 */
-   PASS_INFO(stackleak_cleanup, "reload", 1, PASS_POS_INSERT_AFTER);
+   PASS_INFO(stackleak_cleanup, "*free_cfg", 1, PASS_POS_INSERT_BEFORE);
 
if (!plugin_default_version_check(version, &gcc_version)) {
error(G_("incompatible gcc/plugin versions"));
-- 
2.7.4

Re: [PATCH 1/1] stackleak: Register the 'stackleak_cleanup' pass before the 'mach' pass

[Alexander Popov]

On 03.12.2018 21:25, Alexander Popov wrote:
> But I think it's better to register the 'stackleak_cleanup' pass just one pass
> earlier -- before the '*free_cfg' pass. I'll double check it for different
> versions of gcc on all supported architectures and return with a new patch.

I've tested this idea for gcc-5,6,7,8 on x86_64, x86_32, and arm64.
I'll send the patch soon.

Best regards,
Alexander

Source code coverage of gcc

[sameeran joshi]

Hi,
I have a random C program as a test case, for which I need to do
source code coverage on gcc.
I have used the gcov tool and further the lcov tool. The percentage of
source code coverage which I get after using gcov, Is that the final %
which I need to do gcc source code coverage?

What does it mean to build gcc with -pg option, how does that help in
source code coverage?

Thanks,
Sameeran Joshi

Re: LTO Test Case Help

[Michael Ploujnikov]

On 2018-12-05 2:38 p.m., Michael Ploujnikov wrote:
> Hi,
> 
> I'm trying to write a testcase to reproduce duplicate clone symbols
> such as in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297 I
> started with a testcase that is known to have constprop clones and
> split it into two object files:
> 
> 
> bash-4.2# cat /gcc/src/gcc/testsuite/gcc.dg/lto/independent-cloneids-lto_0.c 
> /* { dg-require-effective-target lto } */
> /* { dg-lto-options {{-O3 -fipa-cp -fipa-cp-clone}}  } */
> /* { dg-lto-do run } */
> 
> #include 
> 
> extern int foo (int arg);
> extern int bar (int arg);
> int __attribute__ ((noinline))
> foo (int arg)
> {
>   return 7 * arg;
> }
> 
> int __attribute__ ((noinline))
> bar (int arg)
> {
>   return arg * arg;
> }
> 
> int main (void)
> {
>   printf("%d\n", bar (3));
>   printf("%d\n", bar (4));
>   printf("%d\n", foo (5));
>   printf("%d\n", foo (6));
>   return 0;
> }
> 
> bash-4.2# cat /gcc/src/gcc/testsuite/gcc.dg/lto/independent-cloneids-lto_1.c 
> int __attribute__ ((noinline))
> foo (int arg)
> {
>   return 7 * arg;
> }
> 
> int __attribute__ ((noinline))
> bar (int arg)
> {
>   return arg * arg;
> }
> 
> but now decide_whether_version_node does not call decide_about_value
> and I don't know enough about ipa/lattices to figure out what's
> missing. Any help would be appreciated.
> 
> 
> - Michael
> 

If I print out the lattices in decide_whether_version_node right
before the call to gather_context_independent_values (and some more
info within the loop and after) I see:

debug: decide_whether_version_node - node: bar count is 1

Lattices:
  Node: main/13:
  Node: bar/12:
param [0]: BOTTOM
 ctxs: BOTTOM
 Bits unusable (BOTTOM)
 VARYING
AGGS BOTTOM
  Node: foo/11:
param [0]: BOTTOM
 ctxs: BOTTOM
 Bits unusable (BOTTOM)
 VARYING
AGGS BOTTOM
debug: decide_whether_version_node - !lat->bottom: 0
debug: decide_whether_version_node - !plats->aggs_bottom: 0
debug: decide_whether_version_node - node : bar 
info->do_clone_for_all_contexts: 0
debug: decide_whether_version_node - node: foo count is 1

Lattices:
  Node: main/13:
  Node: bar/12:
param [0]: BOTTOM
 ctxs: BOTTOM
 Bits unusable (BOTTOM)
 VARYING
AGGS BOTTOM
  Node: foo/11:
param [0]: BOTTOM
 ctxs: BOTTOM
 Bits unusable (BOTTOM)
 VARYING
AGGS BOTTOM
debug: decide_whether_version_node - !lat->bottom: 0
debug: decide_whether_version_node - !plats->aggs_bottom: 0
debug: decide_whether_version_node - node : foo 
info->do_clone_for_all_contexts: 0





signature.asc
Description: OpenPGP digital signature

Re: gcc-9-20181202 is now available

[Jeffrey Walton]

On Sun, Dec 2, 2018 at 5:41 PM  wrote:
>
> Snapshot gcc-9-20181202 is now available on
>   ftp://gcc.gnu.org/pub/gcc/snapshots/9-20181202/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

GCC 9 on PowerPC is doing well. I was able to test on GCC110 and
GCC112 from the compile farm. I tested both a regular build (not much
more than -DNDEBUG -g2 -O3) and a UBsan build (-fsanitize=undefined).

One thing that was slightly unusual during the build with gcc-9 was
undefined references when using UBsan. I had to manually specify both
-lrt and -ldl:

$ LDLIBS="-lrt -ldl" CXX=/home/mik/misc/gcc-9/bin/g++-9 make ubsan
...

It is unusual because I have never had to add libraries for GCC before.

I mention it in case it is something that the devs would like to address.

Jeff

GCC 7.5 Status Report (2018-12-06)

[Richard Biener]

Status
==

The GCC 7 branch is open for regression and documentation fixes again.
The next release from the GCC 7 branch is due after GCC 9 was released
and will close the branch.


Quality Data


Priority  #   Change from last report
---   ---
P1   
P2  233   -   8
P3   14   +   3
P4  177
P5   28 
---   ---
Total P1-P3 247   -   5
Total   452   -   5


Previous Report
===

https://gcc.gnu.org/ml/gcc/2018-11/msg00118.html