Re: Question about function Split with va_args
On Wed, Nov 1, 2023 at 11:12 AM Hanke Zhang via Gcc wrote: > > Hi > > I've been working on function splits recently, and I've noticed that > functions with va_args arguments won't be split, so why is that? I > tried to understand the comments in the source code, but I still don't > get the specific reason. There was probably no pressing reason to support it. It's difficult (or impossible?) to split after the first .VA_ARG call and if there's no .VA_LIST object constructed (I don't think that's easily visible in the IL) you have to construct one to pass to the split part, or alternatively guarantee the split part doesn't access any of the variadic arguments. All this analysis isn't implemented I think, we simply give up when the function has variadic args > At the same time, if I do want to split functions with va_args > arguments when it's safe to do, how do I define security here? In > other words, how should I know that a function with va_args can be > split? Or I can't? > > Thanks > Hanke Zhang
Re: Question on GIMPLE shifts
On Wed, Nov 1, 2023 at 5:01 PM Andrew Pinski via Gcc wrote:
>
> On Wed, Nov 1, 2023 at 3:56 AM Daniil Frolov wrote:
> >
> > Hi!
> >
> > When investigating bit shifts I got an incomprehensible moment with
> > the following example:
> >
> > int f(int x, int k)
> > {
> > int tmp = x >> k;
> > return (tmp & 1) << 10;
> > }
> >
> > If we would like to take a look into GIMPLE then we'll get:
> >
> > int f (int x, int k)
> > {
> >int tmp;
> >int D.2746;
> >int _1;
> >int _5;
> >
> > :
> >tmp_4 = x_2(D) >> k_3(D);
> >_1 = tmp_4 << 10;
> >_5 = _1 & 1024;
> >
> > :
> > :
> >return _5;
> >
> > }
> >
> > Is the expression '_1 = tmp_4 << 10' considered legal in GIMPLE? Given
> > the
> > semantics of C bit shifts, this statement could modify the sign bit,
> > potentially leading to overflow.
>
> Except it was not undefined in C90.
Also in GIMPLE/GENERIC left-shifts are always logical and the result is
modulo-reduced to the target type. There's no (undefined) arithmetic overflow
involved for any shift operation (but there is for multiply). Only the shift
argument magnitude is constrained.
Richard.
> Thanks,
> Andrew
>
> >
> > ---
> > With best regards,
> > Daniil
Re: Suspecting a wrong behavior in the value range propagation analysis for __builtin_clz
On Wed, Nov 1, 2023 at 12:30 PM Giuseppe Tagliavini via Gcc
wrote:
>
> I found an unexpected issue working with an experimental target (available
> here: https://github.com/EEESlab/tricore-gcc), but I was able to reproduce it
> on mainstream architectures. For the sake of clarity and reproducibility, I
> always refer to upstream code in the rest of the discussion.
>
> Consider this simple test:
>
> #include
> int f(unsigned int a) {
> unsigned int res = 8*sizeof(unsigned int) - __builtin_clz(a);
> if(res>0) printf("test passed\n");
> return res-1;
> }
>
> I tested this code on GCC 9 and GCC 11 branches, obtaining the expected
> result from GCC 9 and the wrong one from GCC 11. In GCC 11 and newer
> versions, the condition check is removed by a gimple-level optimization (I
> will provide details later), and the printf is always invoked at the assembly
> level with no branch.
>
> According to the GCC manual, __builtin_clz "returns the number of leading
> 0-bits in x, starting at the most significant bit position. If x is 0, the
> result is undefined." However, it is possible to define a
> CLZ_DEFINED_VALUE_AT_ZERO in the architecture backend to specify a defined
> behavior for this case. For instance, this has been done for SPARC and
> AARCH64 architectures. Compiling my test with SPARC GCC 13.2.0 with the -O3
> flag on CompilerExplorer I got this assembly:
Note the semantic of __builtin_clz is _not_ altered by
CLZ_DEFINED_VALUE_AT_ZERO, the behavior
of __builtin_clz (x) is that is has undefined result for x == 0.
CLZ_DEFINED_VALUE_AT_ZERO
is only used to optimize code generation when the user writes say
x == 0 ? 0 : __builtin_clz (x)
Richard.
> .LC0:
> .asciz "test"
> f:
> save%sp, -96, %sp
> call__clzsi2, 0
> mov%i0, %o0
> mov %o0, %i0
> sethi %hi(.LC0), %o0
> callprintf, 0
> or %o0, %lo(.LC0), %o0
> mov 31, %g1
> return %i7+8
> sub%g1, %o0, %o0
>
> After some investigation, I found this optimization derives from the results
> of the value range propagation analysis:
> https://github.com/gcc-mirror/gcc/blob/master/gcc/gimple-range-op.cc#L917
> In this code, I do not understand why CLZ_DEFINED_VALUE_AT_ZERO is verified
> only if the function call is tagged as internal. A gimple call is tagged as
> internal at creation time only when there is no associated function
> declaration (see
> https://github.com/gcc-mirror/gcc/blob/master/gcc/gimple.cc#L371), which is
> not the case for the builtins. From my point of view, this condition prevents
> the computation of the correct upper bound for this case, resulting in a
> wrong result from the VRP analysis.
>
> Before considering this behavior as a bug, I prefer to ask the community to
> understand if there is any aspect I have missed in my reasoning.
Re: Suboptimal warning formatting with `bool` type in C
On 02/11/2023 00:28, peter0x44 via Gcc wrote: On 2023-11-01 23:13, Joseph Myers wrote: On Wed, 1 Nov 2023, peter0x44 via Gcc wrote: Why is #define used instead of typedef? I can't imagine how this could possibly break any existing code. That's how stdbool.h is specified up to C17. In C23, bool is a keyword instead. I see, I didn't know it was specified that way. It seems quite strange that typedef wouldn't be used for this purpose. I suppose perhaps it matters if you #undef bool and then use it to define your own type? Still, it seems very strange to do this. Yes, that is part of the reason. The C standards mandate a number of things to be macros when it would seem that typedef's, functions, enumeration constants or other things would be "nicer" in some sense. Macros have two advantages, however - you can "#undef" them, and you can use "#ifdef" to test for them. This makes them useful in several cases in the C standards, especially for changes that could break backwards compatibility. Someone writing /new/ code would hopefully never make their own "bool" type, but there's plenty of old code around - if you ever need to include some pre-C99 headers with their own "bool" type and post-C99 headers using , within the same C file, then it's entirely possible that you'll be glad "bool" is a macro. Maybe it's something to offer as a GNU extension? Though, I'm leaning towards too trivial to be worth it, just for a (very minor) improvement to a diagnostic that can probably be handled in other ways. Speaking as someone with absolutely zero authority (I'm a GCC user, not a GCC developer), I strongly doubt that "bool" will be made a typedef as a GCC extension. But if there are problems with the interaction between pre-processor macros and the formatting of diagnostic messages, then that is definitely something that you should file as a bug report and which can hopefully be fixed. David
Re: Suspecting a wrong behavior in the value range propagation analysis for __builtin_clz
On Thu, Nov 02, 2023 at 04:44:30PM +, Joseph Myers wrote: > On Thu, 2 Nov 2023, Richard Biener via Gcc wrote: > > > Note the semantic of __builtin_clz is _not_ altered by > > CLZ_DEFINED_VALUE_AT_ZERO, the behavior > > of __builtin_clz (x) is that is has undefined result for x == 0. > > Note also the discussion in bug 111309 of possible future type-generic > versions of operations such as clz (under a different name because > __builtin_clz is already taken), in order to support _BitInt, where > there's a plausible argument for defining the result for all argument > values rather than leaving it undefined at 0. I plan to work on that soon. The current plan is to let the users choose what they want, by having the type-generic variants of the builtin support either one or two arguments (just for clz/ctz obviously), if only one is provided, it is undefined at 0, if two are provided, then the second argument is the value to be returned for 0. So, __builtin_clzg (0uwb) or __builtin_clzg (0ULL) would be UB, while __builtin_clzg (0uwb, 42) would return 42. We'd need something like __builtin_widthof as well because _Bitwithof or something similar hasn't been standardized yet, so people can use the type-generic function in macro and ask for the number of bits to be returned for 0 (or something based on that). Jakub
Re: Suspecting a wrong behavior in the value range propagation analysis for __builtin_clz
On Thu, 2 Nov 2023, Richard Biener via Gcc wrote: > Note the semantic of __builtin_clz is _not_ altered by > CLZ_DEFINED_VALUE_AT_ZERO, the behavior > of __builtin_clz (x) is that is has undefined result for x == 0. Note also the discussion in bug 111309 of possible future type-generic versions of operations such as clz (under a different name because __builtin_clz is already taken), in order to support _BitInt, where there's a plausible argument for defining the result for all argument values rather than leaving it undefined at 0. -- Joseph S. Myers jos...@codesourcery.com
gcc-11-20231102 is now available
Snapshot gcc-11-20231102 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20231102/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 0836caff6ad2fe56cf92c11db1c53a37c2ed3429 You'll find: gcc-11-20231102.tar.xz Complete GCC SHA256=28f3e4bdc5a0ff0a6041c1a02d41ba80b9a5544db4ea7626598a771caf08f7a5 SHA1=0ff7e1dbb39ce53bc4685a2b768705ee71de80c7 Diffs from 11-20231026 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 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.
