Re: Many analyzer failures on non-Linux system (x86_64-apple-darwin)
> No, that's "dg-do compile" (as in "compile but don't assemble").
I can confirm that this patch:
diff --git a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
index c235e22fd01..4730255bb3c 100644
--- a/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
+++ b/gcc/testsuite/gcc.dg/analyzer/asm-x86-lp64-1.c
@@ -1,4 +1,4 @@
-/* { dg-do assemble { target x86_64-*-* } } */
+/* { dg-do compile { target x86_64-*-* } } */
/* { dg-require-effective-target lp64 } */
#include "analyzer-decls.h”
fixes the gcc.dg/analyzer/asm-x86-lp64-1.c failure on x86_64-apple-darwin. The
same is true of this one:
diff --git
a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
index e90dccf58dd..4cbf43206dc 100644
---
a/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
+++
b/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-wfx_get_ps_timeout-full.c
@@ -1,4 +1,4 @@
-/* { dg-do assemble { target x86_64-*-* } } */
+/* { dg-do compile { target x86_64-*-* } } */
/* { dg-require-effective-target lp64 } */
/* { dg-additional-options "-fsanitize=bounds -fno-analyzer-call-summaries" }
*/
/* { dg-skip-if "" { *-*-* } { "-O0" } { "" } } */
These other three:
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-2.c
FAIL: gcc.dg/analyzer/torture/asm-x86-linux-rdmsr-paravirt.c
still fail with dg-do compile, as explained, become the error comes from the C
front-end, not the assembler:
/Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3:
warning: 'asm' operand 6 probably does not match constraints
/Users/fx/gcc/gcc/testsuite/gcc.dg/analyzer/torture/asm-x86-linux-cpuid-paravirt-1.c:27:3:
error: impossible constraint in 'asm'
FX
Re: reordering of trapping operations and volatile
Am Samstag, den 15.01.2022, 16:38 -0500 schrieb Paul Koning: > > On Jan 15, 2022, at 4:28 PM, Martin Sebor wrote: > > > > On 1/14/22 07:58, Paul Koning via Gcc wrote: > > > > On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc > > > > wrote: > > > > > > > > > ... > > > > But right now that's equivalent to making it observable, > > > > because we don't have any other terms than observable or > > > > undefined. As aluded to later you would have to > > > > introduce a new concept, something pseudo-observable, > > > > which you then started doing. So, see below. > > > I find it really hard to view this notion of doing work for UB with any > > > favor. The way I see > > > it is that a program having UB is synonymous with "defective program" and > > > for the compiler to > > > do extra work for these doesn't make much sense to me. > > > > This is also the official position of the C committee on record, > > but it's one that's now being challenged. "nonportable or erroneous" is the official position. > > > If the issue is specifically the handling of overflow traps, perhaps a > > > better answer would be > > > to argue for language changes that manage such events explicitly rather > > > than having them be > > > undefined behavior. Another (similar) option might be to choose a > > > language in which this is > > > done. (Is Ada such a language? I don't remember.) > > > > A change to the language standard is only feasible if it doesn't > > overly constrain existing implementations. > > I was thinking that if a new feature is involved, rather than a new > definition of behavior for > existing code, it wouldn't be a constraint on existing implementations (in > the sense of "what the > compiler does for existing code written to the current rules"). In other > words, suppose there was > a concept of "trapping operations" that could be enabled by some new > mechanism in the program > text. If you use that, then you're asking the compiler to do more work and > your code may get > slower or bigger. But if you don't, the existing rules apply and nothing bad > happens (other than > that the compiler is somewhat larger and more complex due to the support for > both cases). There are also different proposal for doing something like this, e.g. making certain undefined behaviour defined as trapping operations, either as a language variant or by default. But this is not my idea here, I want to limit the impact of UB on defective programs - accepting the reality that in the real world programs often have defects and any serious field of engineering needs to deal with this in a better way than to say "the ISO standard says no requirements - so you loose". Imagine an aurospace, biomedical, mechanical, or civil engineer saying: " It makes no sense to consider for the case where one part fails, this is then just then a defective airplane/CT scanner/car/bridge. Not worth spending extra resources on it, and a non-defective airplane might potentially be a little bit slower if we were to give you some guarantees in this failure case. First you need to show that this has no performance impact at all to anybody anywhere, then maybe we consider this." (When, at the same time there is quite substantial damage caused by defective C programs). I thought limiting the impact of UB on previous defined I/O would be a rather modest step towards more reliable software, considering that this is already the case for most I/O and it seems only some volatile accesses would need fixing (where I still do not see how this could affect performance anywhere where it actually matters). Martin
Accessing const parameter of GIMPLE_CALL
Hello,
My aim is to iterate over gimple call stmt parameters and check
whether it is constant or constant expression and mark/store them for
some gimple transformation.
I have an intrinsic function call of the following -
__builtin_xyz(void*, 7, addr + 10);
I want to find its parameters which are either constant or constant
expression i.e. 7 and addr + 10 from above case.
[1] I tried below macro but there is very less usage in the entire source code -
tree fn_ptr = gimple_call_fn (dyn_cast (stmt));//stmt
= gimple_call
function_args_iterator iter;
tree argtype;
if (TREE_CODE (fn_ptr) == ADDR_EXPR)
{
FOREACH_FUNCTION_ARGS (fn_ptr, argtype, iter)
{
if (TREE_CONSTANT (argtype))
// Found a constant expression parameter
}
}
The problem is I am getting only one parameter tree but there are 2
constants in the above function call. Even if "addr + 10" is treated
differently, I want to mark it for the transformation.
a. Is the above correct method to iterate over function call parameters?
b. Is there a different way to achieve the above goal?
Thanks and Regards,
Shubham
Hilfsfonds – 5 Millionen €
- This e-mail is subjected to the disclaimer that can be viewed at: * http://www.cut.ac.za/www/disclaimer/email_disclaimer -
gcc-12-20220116 is now available
Snapshot gcc-12-20220116 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20220116/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 90045c5df5b3c8853e7740fb72a11aead1c489bb You'll find: gcc-12-20220116.tar.xz Complete GCC SHA256=a5053a81a814496c95f3a5e3ae4a6c2d3164bd7ddc832e694f64f6267bae98aa SHA1=c4866e76b2b6243751fb186e20c33d95aae12e02 Diffs from 12-20220109 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 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: Accessing const parameter of GIMPLE_CALL
On Sun, 2022-01-16 at 18:52 +0530, Shubham Narlawar via Gcc wrote:
> Hello,
Hi; various notes inline below...
>
> My aim is to iterate over gimple call stmt parameters and check
> whether it is constant or constant expression and mark/store them for
> some gimple transformation.
>
> I have an intrinsic function call of the following -
>
> __builtin_xyz(void*, 7, addr + 10);
>
> I want to find its parameters which are either constant or constant
> expression i.e. 7 and addr + 10 from above case.
Gimple "flattens" all tree-like operations into a sequence of simple
operations, so I would expect the gimple for this to look something
like this:
_tmp = addr + 10;
__builtin_xyx (7, _tmp);
Your email doesn't specify *when* your code runs.
The IR for a function goes through several stages:
- an initial gimple IR without a CFG
- gimple with a CFG, but not in SSA
- gimple-SSA with a CFG
(most of the gimple optimization passes operate in this form of the
IR)
- gimple with a CFG, but no longer in CFG form, immediately before
conversion to RTL-with-CFG form
- RTL-with-CFG
- RTL-without a CFG
- assembler
Are you doing it as part of a plugin, or modifying an existing pass?
In either case, it's a good idea to dump the gimple and see what the
code has been turned into. You'll probably find the following options
useful:
-fdump-tree-all -fdump-gimple-all
or alternatively just turn it on for the pass that you're working on.
>
> [1] I tried below macro but there is very less usage in the entire
> source code -
>
> tree fn_ptr = gimple_call_fn (dyn_cast (stmt)); //stmt
gimple_call_fn returns the function that will be called, a pointer.
This is very general, for handling things like jumps through function
pointers, but here you have the common case of a callsite that calls a
specific function, so "fn_ptr" here is:
&__builtin_xyx
i.e. an ADDR_EXPR where operand 0 is the FUNCTION_DECL for the builtin.
> = gimple_call
> function_args_iterator iter;
> tree argtype;
>
> if (TREE_CODE (fn_ptr) == ADDR_EXPR)
> {
> FOREACH_FUNCTION_ARGS (fn_ptr, argtype, iter)
Looking in tree.h, FOREACH_FUNCTION_ARGS takes a FUNCTION_TYPE as its
first argument, but the code above is passing it the ADDR_EXPR wrapping
the FUNCTION_DECL.
Unfortunately, because these things are all of type "tree", this kind
of type mismatch doesn't get caught - unless you build gcc from source
(with --enable-checking=debug) in which case all these accesses are
checked at the compiler's run time (which is probably a good thing to
do if you're hoping to work on gcc for GSoC).
You can get the FUNCTION_TYPE of a FUNCTION_DECL via TREE_TYPE
(fndecl), or alternatively, gimple_call_fntype (call) will get the type
of the function expected at the call stmt (useful if there was a type
mismatch).
That said, FOREACH_FUNCTION_ARGS iterates through the types of the
params of the FUNCTION_TYPE, but it sounds like you want to be
iterating through the arguments at this particular *callsite*.
For that you can use
gimple_call_num_args (call);
and
gimple_call_arg (call, idx);
> {
> if (TREE_CONSTANT (argtype))
> // Found a constant expression parameter
> }
> }
>
> The problem is I am getting only one parameter tree but there are 2
> constants in the above function call. Even if "addr + 10" is treated
> differently, I want to mark it for the transformation.
I think you're seeing the function pointer being called, ather than the
params.
>
> a. Is the above correct method to iterate over function call
> parameters?
As noted above, it depends on whether you want to iterate over the
types of the parameters in the function's decl, or over the expressions
of the arguments at the callsite. I believe the above explains how to
do each of these.
> b. Is there a different way to achieve the above goal?
If you're looking to get familiar with GCC's insides, I recommend
stepping through it in the debugger, rather than relying on injecting
print statements and recompiling, since the former makes it much easier
to spot mistakes like the one above (which we all make).
I've written a guide to debugging GCC here:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
Hope this is helpful
Dave
Re: GSoC: Working on the static analyzer
On Fri, 2022-01-14 at 22:15 +0530, Mir Immad wrote: > HI David, > I've been tinkering with the static analyzer for the last few days. I > find > the project of adding SARIF output to the analyzer intresting. I'm > writing > this to let you know that I'm trying to learn the codebase. > Thank you. Excellent. BTW, I think adding SARIF output would involve working more with GCC's diagnostics subsystem than with the static analyzer, since (in theory) all of the static analyzer's output is passing through the diagnostics subsystem - though the static analyzer is probably the only GCC component generating diagnostic paths. I'm happy to mentor such a project as I maintain both subsystems and SARIF output would benefit both - but it would be rather tangential to the analyzer - so if you had specifically wanted to be working on the guts of the analyzer itself, you may want to pick a different subproject. The SARIF standard is rather long and complicated, and we would want to be compatible with clang's implementation. It would be very cool if gcc could also accept SARIF files as an *input* format, and emit them as diagnostics; that might help with debugging SARIF output. (I have a old patch for adding JSON parsing support to GCC that could be used as a starting point for this). Hope the above makes sense Dave > > On Tue, Jan 11, 2022, 7:09 PM David Malcolm > wrote: > > > On Tue, 2022-01-11 at 11:03 +0530, Mir Immad via Gcc wrote: > > > Hi everyone, > > > > Hi, and welcome. > > > > > I intend to work on the static analyzer. Are these documents > > > enough to > > > get > > > started: https://gcc.gnu.org/onlinedocs/gccint and > > > > > https://gcc.gnu.org/onlinedocs/gccint/Analyzer-Internals.html#Analyzer-Internals > > > > Yes. > > > > There are also some high-level notes here: > > https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer > > > > Also, given that the analyzer is part of GCC, the more general > > introductions to hacking on GCC will be useful. > > > > I recommend creating a trivial C source file with a bug in it (e.g. > > a > > 3-line function with a use-after-free), and stepping through the > > analyzer to get a sense of how it works. > > > > Hope this is helpful; don't hesitate to ask questions. > > Dave > > > >
