Re: Question about constructing vector types in GIMPLE pass

[Marc Glisse via Gcc]

On Mon, 8 Apr 2024, Hanke Zhang via Gcc wrote:


Hi,
I've been working on strengthening auto-vectorization on intel CPUs
recently. I tried to do it in the GIMPLE pass. And I noticed that some
vector types in the GIMPLE code are confusing to me. The example code
is here:

_1 = MEM[(const __m256i_u * {ref-all})_2];

I wondered how I could construct or get the type `(const __m256i_u *
{ref-all})` in the GIMPLE pass.

If you have any ideas that can help me. I'll be so grateful! :)


I am not sure what you are asking exactly. If you already have access to 
such a MEM_REF, then the doc tells you where to look for this type:


"The first operand is the pointer being dereferenced; it will always have
pointer or reference type.  The second operand is a pointer constant
serving as constant offset applied to the pointer being dereferenced
with its type specifying the type to be used for type-based alias 
analysis.

The type of the node specifies the alignment of the access."

If you want to create a new type similar to this one, you can build it 
with various tools:


build_vector_type or build_vector_type_for_mode
build_pointer_type_for_mode(*, VOIDmode, true) to build a pointer that can 
alias anything
build_qualified_type to add const (probably useless)
build_aligned_type to specify that it is unaligned

--
Marc Glisse

Re: Building gcc with "-O -g"?

[Marc Glisse via Gcc]

On Sat, 10 Feb 2024, Steve Kargl via Gcc wrote:


So, how does one biulding all parts of gcc with "-O -g"?

In my shell script, I have

CFLAGS="-O -g"
export CFLAGS

CXXFLAGS="-O -g"
export CXXFLAGS

BOOT_CFLAGS="-O -g"
export BOOT_CFLAGS

../gcc/configure --prefix=$HOME/work --enable-languages=c,c++,fortran \
 --enable-bootstrap --disable-libssp --disable-multilib

but during bootstrap I see

/home/kargl/gcc/obj/./prev-gcc/xg++ -B/home/kargl/gcc/obj/./prev-gcc/ 
-B/home/kargl/work/x86_64-unknown-freebsd15.0/bin/ -nostdinc++ 
-B/home/kargl/gcc/obj/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/src/.libs 
-B/home/kargl/gcc/obj/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/libsupc++/.libs
  
-I/home/kargl/gcc/obj/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/include/x86_64-unknown-freebsd15.0
  -I/home/kargl/gcc/obj/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/include  
-I/home/kargl/gcc/gcc/libstdc++-v3/libsupc++ 
-L/home/kargl/gcc/obj/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/src/.libs 
-L/home/kargl/gcc/obj/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/libsupc++/.libs
  -fno-PIE -c   -g -O2 -fno-checking -gtoggle -DIN_GCC-fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Wconditionally-supported 
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
-Wno-overlength-strings -Werror -f

no-common  -DHAVE_CONFIG_H -fno-PIE -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
-I../../gcc/gcc/../include  -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libcody -I/usr/local/include  
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd 
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o fibonacci_heap.o -MT 
fibonacci_heap.o -MMD -MP -MF ./.deps/fibonacci_heap.TPo 
../../gcc/gcc/fibonacci_heap.cc


Note the "-g -O2".  Why?


In addition to CFLAGS and BOOT_CFLAGS, you are missing CFLAGS_FOR_TARGET 
(plus the same 3 for CXX). I don't know if that's still sufficient, but 
that's what I used to set a few years ago.


--
Marc Glisse

Re: Expected warning maybe-uninitialized does not appear using g++13.2.0?

[Marc Glisse via Gcc]

On Thu, 21 Dec 2023, David Malcolm via Gcc wrote:


On Wed, 2023-12-20 at 11:16 -0800, Eric Batchelor wrote:

Hello, I unintentionally stumbled upon some strange behaviour that
occurred due to a typo.
I reproduced the behaviour where an object (std::string in my case)
can
be passed to a function by reference, uninitialized, WITHOUT a
compiler
warning.
Changing the code to pass the object by value DOES emit the warning.
I don't think the compiled code is incorrect, it segfaults presumably
due to uninitialized members.
I understand there may seldom be a reason to use uninitialized
objects,
so "don't do that," but as I said this was unintentional and it seems
that it should have generated a warning, which have saved some
head-scratching.

Code to reproduce:

#include 
std::string f(std::string &s) {
   s.append("x");
   return s;
}
int main() {
   std::string a = f(a);
}

Compile and run (no warning):

$ g++ -o uninit_obj uninit_obj.cpp -std=c++23 -Wall -Wpedantic -
Wextra
&& ./uninit_obj
Segmentation fault (core dumped)

No difference whether using -O0 (or 1 2 3)


As I understand it, -Wmaybe-uninitialized is purely intraprocedural
i.e. it works within each individual function, without considering the
interactions *between* functions.


If you compile

#include 
static std::string f(std::string &s) {
 s.append("x");
 return s;
}
void g() {
 std::string a = f(a);
}

with -O3, by the time we get to the uninit pass, function g starts with

void g ()
{
  size_type __dnew;
  struct string a;
[...]
   [local count: 1073741824]:
  _26 = a._M_string_length;
  if (_26 == 4611686018427387903)

which should not require any interprocedural logic.

--
Marc Glisse

Re: Question about merging if-else blocks

[Marc Glisse via Gcc]

On Wed, 27 Sep 2023, Hanke Zhang via Gcc wrote:


Hi, I have recently been working on merging if-else statement blocks,
and I found a rather bizarre phenomenon that I would like to ask
about.
A rough explanation is that for two consecutive if-else blocks, if
their if statements are exactly the same, they should be merged, like
the following program:

int a = atoi(argv[1]);
if (a) {
 printf("if 1");
} else {
 printf("else 1");
}
if (a) {
 printf("if 2");
} else {
 printf("else 2");
}

After using the -O3 -flto optimization option, it can be optimized as follows:

int a = atoi(argv[1]);
if (a) {
 printf("if 1");
 printf("if 2");
} else {
 printf("else 1");
 printf("else 2");
}

But `a` here is a local variable. If I declare a as a global variable,
it cannot be optimized as above. I would like to ask why this is? And
is there any solution?


If 'a' is a global variable, how do you know 'printf' doesn't modify its 
value? (you could know it for printf, but it really depends on the 
function that is called)


--
Marc Glisse

Re: Different ASM for ReLU function between GCC11 and GCC12

[Marc Glisse via Gcc]

On Mon, 19 Jun 2023, André Günther via Gcc wrote:


I noticed that a simple function like
auto relu( float x ) {
   return x > 0.f ? x : 0.f;
}
compiles to different ASM using GCC11 (or lower) and GCC12 (or higher). On
-O3 -mavx2 the former compiles above function to

relu(float):
   vmaxss xmm0, xmm0, DWORD PTR .LC0[rip]
   ret
.LC0:
   .long 0

which is what I would naively expect and what also clang essentially does
(clang actually uses an xor before the maxss to get the zero). The latter,
however, compiles the function to

relu(float):
   vxorps xmm1, xmm1, xmm1
   vcmpltss xmm2, xmm1, xmm0
   vblendvps xmm0, xmm1, xmm0, xmm2
   ret

which looks like a missed optimisation. Does anyone know if there's a
reason for the changed behaviour?


With -fno-signed-zeros -ffinite-math-only, gcc-12 still uses max instead 
of cmp+blend. So the first thing to check would be if both versions give 
the same result on negative 0 and NaN.


--
Marc Glisse

Re: [GSoC] Conflicted Built-in Trait Name

[Marc Glisse via Gcc]

On Sat, 25 Mar 2023, Ken Matsui via Gcc wrote:


Built-in trait naming simply adds two underscores (__) to the original
trait name. However, the same names are already in use for some
built-in traits, such as is_void, is_pointer, and is_signed.

For example, __is_void is used in the following files:

* gcc/testsuite/g++.dg/tm/pr46567.C


This is a testcase, you can rename __is_void to whatever in there, it 
doesn't matter.



* libstdc++-v3/include/bits/cpp_type_traits.h


This __is_void seems to be used in a single place in 
include/debug/helper_functions.h, couldn't we tweak that code so __is_void 
becomes unused and can be removed?


--
Marc Glisse

Re: Triggering -save-temps from the front-end code

[Marc Glisse via Gcc]

On Mon, 28 Nov 2022, Florian Weimer via Gcc wrote:


* Arsen Arsenović:


Hi,

Florian Weimer via Gcc  writes:


Unfortunately, some build systems immediately delete the input source
files.  Is there some easy way I can dump the pre-processed and
non-preprocessed sources to my log file?  I tried to understand how
-save-temps for crash recovery works, but it seems that this runs
outside of the frontend, in the driver.


Would dumping unconditionally into some "side channel" -dumpdir be a
sufficient workaround?


Of the file names overlap, and it seems in this case, the dump files are
just overwritten.  I don't see a way to make the file names unique.

I guess for the tough cases, I can just keep running the build under
strace.


You could override unlink with LD_PRELOAD. Use a special purpose 
filesystem (gitfs? I haven't tried it yet). Wrap gcc with a command that 
calls the true gcc with a different TMPDIR / -dumpdir each time.


--
Marc Glisse

Re: Please, really, make `-masm=intel` the default for x86

[Marc Glisse via Gcc]

On Fri, 25 Nov 2022, LIU Hao via Gcc wrote:

I am a Windows developer and I have been writing x86 and amd64 assembly for 
more than ten years. One annoying thing about GCC is that, for x86 if I need 
to write I piece of inline assembly then I have to do it twice: one in AT&T 
syntax and one in Intel syntax.


The doc for -masm=dialect says:

Darwin does not support ‘intel’.

Assuming that's still true, and even with Mac Intel going away, it doesn't 
help.


--
Marc Glisse

Re: Different outputs in Gimple pass dump generated by two different architectures

[Marc Glisse via Gcc]

On Thu, 10 Nov 2022, Kevin Lee wrote:


While looking at the failure for gcc.dg/uninit-pred-9_b.c, I observed that
x86-64 and risc-v has a different output for the gimple pass since
r12-4790-g4b3a325f07acebf4
.


Probably since earlier.

What would be causing the difference? Is this intended? Link 
 for details. Thank you!


See LOGICAL_OP_NON_SHORT_CIRCUIT in fold-const.cc (and various discussions 
on the topic in mailing lists and bugzilla).


--
Marc Glisse

Re: clarification question

[Marc Glisse via Gcc]

On Sat, 22 Oct 2022, Péntek Imre via Gcc wrote:


https://gcc.gnu.org/backends.html

by "Architecture does not have a single condition code register" do you mean 
it has none or do you mean it has multiple?


Either.

If you look at the examples below, there is a C for riscv, which has 0, 
and one for sparc, which has several.


--
Marc Glisse

Re: Floating-point comparisons in the middle-end

[Marc Glisse via Gcc]

On Thu, 1 Sep 2022, Joseph Myers wrote:


On Thu, 1 Sep 2022, FX via Gcc wrote:


A tentative patch is attached, it seems to work well on simple examples,
but for test coverage the hard part is going to be that the comparisons
seem to be optimised away very easily into their non-signaling versions.
Basically, if I do:


Presumably that can be reproduced without depending on the new built-in
function?  In which case it's an existing bug somewhere in the optimizers.


 (simplify
  (cmp @0 REAL_CST@1)
[...]
   (if (REAL_VALUE_ISNAN (TREE_REAL_CST (@1))
&& !tree_expr_signaling_nan_p (@1)
&& !tree_expr_maybe_signaling_nan_p (@0))
{ constant_boolean_node (cmp == NE_EXPR, type); })

only tries to preserve a comparison with sNaN, but not with qNaN. There 
are probably other issues since various gcc devs used to have a different 
opinion on the meaning of -ftrapping-math.



--
Marc Glisse

Re: GCC 12.1 Release Candidate available from gcc.gnu.org

[Marc Glisse via Gcc]

On Mon, 2 May 2022, Boris Kolpackov wrote:


Jakub Jelinek  writes:


The first release candidate for GCC 12.1 is available [...]


There is an unfixed bogus warning that is a regression in 12
and that I think will have a pretty wide effect (any code
that assigns/appends a 1-char string literal to std::string):

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329

For example, in my relatively small codebase I had about 20
instances of this warning. Seeing that it's enabled as part
of -Wall (not just -Wextra), I believe there will be a lot
of grumpy users.

There is a proposed work around in this (duplicate) bug that
looks pretty simple:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336

Perhaps it makes sense to consider it?


Please no, that workaround looks like a fragile hack (basically writing 
a+b-a to obfuscate b) that may break if you look at it sideways and likely 
makes the generated code a bit worse. Besides, we should take it as a hint 
that user code is also likely to trigger the warning by accident.


IMO there are several ways to make progress on this in parallel:

* improve the optimizer (as investigated by Andrew)

* tweak the warning so it becomes either cleverer or less eager (maybe 
even use the fact that this special case is in a system header? that 
should be a last resort though)


* battle that has already been lost, no need to rehash it:

--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1450,3 +1450,3 @@ Warn when a declaration has duplicate const, 
volatile, restrict or _Atomic speci

 Wrestrict
-C ObjC C++ ObjC++ Var(warn_restrict) Warning LangEnabledBy(C ObjC C++ ObjC++, 
Wall)
+C ObjC C++ ObjC++ Var(warn_restrict) Warning LangEnabledBy(C ObjC C++ ObjC++, 
Wextra)
 Warn when an argument passed to a restrict-qualified parameter aliases with

Or admit that

--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5729,4 +5729,3 @@ by this option and not enabled by the latter and vice 
versa.
 This enables all the warnings about constructions that some users
-consider questionable, and that are easy to avoid (or modify to
-prevent the warning), even in conjunction with macros.  This also
+consider questionable.  This also
 enables some language-specific warnings described in @ref{C++ Dialect

--
Marc Glisse