Re: Disabling TLS address caching to help QEMU on GNU/Linux

[Thomas Huth via Gcc]

On 20/07/2021 16.52, Florian Weimer wrote:

Currently, the GNU/Linux ABI does not really specify whether the thread
pointer (the address of the TCB) may change at a function boundary.

[...]

One important piece of software for GNU is QEMU (not just for GNU/Linux,
Hurd development also benefits from virtualization).  QEMU uses stackful
coroutines extensively.  There are some hard-to-change code areas where
resumption happens across threads unfortunately.  These increasingly
cause problems with more inlining, inter-procedural analysis, and a
general push towards LTO (which is also needed for some security
hardening features).


Thanks a lot for your mail, Florian!

As a context for those who read about this for the very first time: We're 
currently facing the problem that the coroutines in QEMU fail when compiling 
QEMU with -flto on a non-x86 architecture, see:


 https://bugzilla.redhat.com/show_bug.cgi?id=1952483#c6


Should the GNU toolchain offer something to help out the QEMU
developers?


I guess that would be extremely helpful...

 Thomas

GCC 11.1.1 Status Report (2021-07-21), branch frozen for release

[Richard Biener]

Status
==

The GCC 11 branch is now frozen for the upcoming GCC 11.2 release.
All changes require release manager approval now.


Quality Data


Priority  #   Change from last report
---   ---
P1  
P2  260   -  12
P3   96   +   2
P4  206   -   4
P5   24
---   ---
Total P1-P3 356   -  10
Total   586   -  14


Previous Report
===

https://gcc.gnu.org/pipermail/gcc/2021-July/236674.html

GCC 11.2 Release Candidate available

[Richard Biener]

The first release candidate for GCC 11.2 is available from

https://sourceware.org/pub/gcc/snapshots/11.2-RC-20210721/

and shortly its mirrors.  It has been generated from git commit
076930b9690ac3564638636f6b13bbb6bc608aea.

I have so far bootstrapped and tested the release candidate
on x86_64-linux.

Please test it and report any issues to bugzilla.

If all goes well I'd like to release 11.2 on Wednesday, July 28th.

Re: Pushing XFAILed test cases

[Tobias Burnus]

Hi all, hi Thomas (2x), hi Sandra,

On 16.07.21 09:52, Thomas Koenig via Fortran wrote:

The part of the patch to add tests for this goes on top of my base
TS29113 testsuite patch, which hasn't been reviewed or committed yet.


It is my understanding that it is not gcc policy to add xfailed test
cases for things that do not yet work. Rather, xfail is for tests that
later turn out not to work, especially on certain architectures.


...

On 17.07.21 09:25, Thomas Koenig via Fortran wrote:

Is it or is it not gcc policy to push a large number of test cases
that currently do not work and XFAIL them?


In my opinion, it is bad to add testcases which _only_ consist of
xfails for 'target *-*-*'; however, for an extensive set of test
cases, I think it is better to xfail missing parts than to comment
them out - or not having them at all. That permits a better
test coverage once the features have been implemented.

For the TS29113 patch, which Sandra has posted on July 7, I count:

* 77 'dg-do run' tests - of which 27 are xfailed (35%)
* 28 compile-time tests
* 291 dg-error - of which 59 are xfailed (20%)
* 29 dg-bogus - of which are 25 are xfailed (86%)
(And of course, those lines which are valid do not have
a dg-error - and usually also no dg-bogus.)

And in total:
* 1 '.exp' file
* 105 '.f90' files (with 8232 lines in total including comment lines)
* 53 '.c'files (5281 lines)
* 1 '.h' file (12 lines)

Hence, for me this sounds a rather reasonable amount of xfail.
Especially, given that several pending patches do/will reduce
the amount of xfails by fixing issues exposed by the testsuite
(which has been posted but so far not reviewed).

Of course, in an ideal world, xfail would not exist :-)

On 07.07.21 05:40, Sandra Loosemore wrote:

There was a question in one of the issues about why this testsuite
references TS29113 instead of the 2018 standard.  Well, that is what
our customer is interested in: finding out what parts of the TS29113
functionality remain unimplemented or broken, and fixing them, so that
gfortran can say that it implements that specification.


I believe the only real difference between TS29113 and
Fortran 2018's interoperability support is that
'select rank' was added in Fortran 2018.

The testsuite also tests 'select rank'; in that sense,
it is also for Fortran 2018. Thus, ts29113 + ts29113.exp
or 'f2018-c-interop' + 'f2018-c-interop.exp' are both
fine to me. — 'ts29113' is shorter while the other is
clearer to those who did not follow the Fortran standards
and missed that there was a technical specification (TS)
between F2008 and F2018, incorporated (with tiny modifications)
in F2018.

Tobias

-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955

gcc_assert() and inhibit_libc

[Sebastian Huber]

Hello,

while testing this patch

https://www.google.com/search?client=firefox-b-e&q=gcc+enable_runtime_checking

I noticed that __gcov_info_to_gcda() uses abort(). This is due to (from 
tsystem.h):


#ifdef ENABLE_RUNTIME_CHECKING
#define gcc_assert(EXPR) ((void)(!(EXPR) ? abort (), 0 : 0))
#else
/* Include EXPR, so that unused variable warnings do not occur.  */
#define gcc_assert(EXPR) ((void)(0 && (EXPR)))
#endif

In tsystem.h there is this if inhibit_libc is defined:

#ifndef abort
extern void abort (void) __attribute__ ((__noreturn__));
#endif

Who is supposed to define abort here optionally? Can this be defined for 
example by a target configuration header like gcc/config/rtems.h?


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

6.55 Built-in Functions for Memory Model Aware Atomic Operations

[Amar Memic]

Hi,6.55 Built-in Functions for Memory Model Aware Atomic Operations 
(https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html)  says:Note 
that the ‘__atomic’ builtins assume that programs will conform to the C++11 
memory model. In particular, they assume that programs are free of data races. 
See the C++11 standard for detailed requirements.

I think the second sentence is a bit misleading because atomics should handle 
data races.
Especially, interleaving read/write or write/write operations should be 
well-defined.
If you assume that programs are free of data races, then you could not 
implement spinlock based on these atomics, for example.
I hope you can help me to interpret the paragraph in the right manner. 

Thanks in advance
Amar Memic

Re: 6.55 Built-in Functions for Memory Model Aware Atomic Operations

[Jonathan Wakely via Gcc]

N.B. I already answered this when you sent it to the libstdc++ list,
read past the first line of my reply:
https://gcc.gnu.org/pipermail/libstdc++/2021-July/052932.html

On Wed, 21 Jul 2021 at 14:00, Amar Memic  wrote:
>
>
> Hi,6.55 Built-in Functions for Memory Model Aware Atomic Operations 
> (https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html)  
> says:Note that the ‘__atomic’ builtins assume that programs will conform to 
> the C++11 memory model. In particular, they assume that programs are free of 
> data races. See the C++11 standard for detailed requirements.
>
> I think the second sentence is a bit misleading because atomics should handle 
> data races.
> Especially, interleaving read/write or write/write operations should be 
> well-defined.
> If you assume that programs are free of data races, then you could not 
> implement spinlock based on these atomics, for example.
> I hope you can help me to interpret the paragraph in the right manner.
>
> Thanks in advance
> Amar Memic

Re: daily report on extending static analyzer project [GSoC]

[Ankur Saini via Gcc]

> On 17-Jul-2021, at 2:57 AM, David Malcolm  wrote:
> 
> On Fri, 2021-07-16 at 21:04 +0530, Ankur Saini wrote:
>> 
>> 
>>> On 15-Jul-2021, at 4:53 AM, David Malcolm 
>>> wrote:
>>> 
>>> On Wed, 2021-07-14 at 22:41 +0530, Ankur Saini wrote:
>>> 
>>> 
> 
> [...snip...]
> 
>>> 
 
   2. ( pr100546.c <   
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546 < 
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100546>>)
   ```
   #include 
   #include 
   
   static void noReturn(const char *str) __attribute__((noreturn));
   static void noReturn(const char *str) {
   printf("%s\n", str);
   exit(1);
   }
   
   void (*noReturnPtr)(const char *str) = &noReturn;
   
   int main(int argc, char **argv) {
   char *str = 0;
   if (!str)
   noReturnPtr(__FILE__);
   return printf("%c\n", *str);
   }
   ```
   (godbolt link >)
 
 - But at the time of testing ( command used 
   was `make check-gcc RUNTESTFLAGS="-v -v
 analyzer.exp=pr100546.c"`),
 both of 
   them failed unexpectedly with Segmentation fault at the call
 
 - From further inspection, I found out that this is due 
   "-fanalyzer-call-summaries" option, which looks like activats
 call
 summaries
 
 - I would look into this in more details ( with gdb ) tomorrow,
 right
 now 
   my guess is that this is either due too the changes I did in
 state-
 purge.cc 
   or is a call-summary related problem ( I remember it not being 
   perfetly implemented right now). 
>>> 
>>> I'm not proud of the call summary code, so that may well be the
>>> problem.
>>> 
>>> Are you able to use gdb on the analyzer?  It ought to be fairly
>>> painless to identify where a segfault is happening, so let me know if
>>> you're running into any problems with that.
>> 
>> Yes, I used gdb on the analyzer to go into details and looks like I was
>> correct, the program was crashing in “analysis_plan::use_summary_p ()”
>> on line 114 ( const cgraph_node *callee = edge->callee; ) where program
>> was trying to access callgraph edge which didn’t exist .
>> 
>> I fixed it by simply making analyzer abort using call summaries in
>> absence of callgraph edge.
>> 
>> File: {src-dir}/gcc/analyzer/analysis-plan.cc
>> 
>> 105: bool
>> 106: analysis_plan::use_summary_p (const cgraph_edge *edge) const
>> 107: {
>> 108:   /* Don't use call summaries if -fno-analyzer-call-summaries.  */
>> 109:   if (!flag_analyzer_call_summaries)
>> 110: return false;
>> 111: 
>> 112:   /* Don't use call summaries if there is no callgraph edge */
>> 113:   if(!edge || !edge->callee)
>> 114: return false;
>> 
>> and now the tests are passing successfully. ( both manually and via
>> DejaGnu ).
> 
> Great.
> 
>> 
>> I have attached a sample patch of work done till now with this mail for
>> review ( I haven’t sent this one to the patches list as it’s change log
>> was not complete for now ).
>> 
>> P.S. I have also sent another mail (   
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575396.html <  
>> https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575396.html> ) to
>> patches list with the previous call-string patch and this time it
>> popped up in my inbox as it should, did you also received it now ?
> 
> I can see it in the archive URL, but for some reason it's not showing
> up in my inbox.  Bother.  Please can you try resending it directly to
> me?

Ok, I have sent the call-string patch directly to you. I have actually sent 2 
mails ( from different mail ids ) to check if it’s the id which is causing the 
issue or the contents of the mail itself.

> 
> Putting email issues to one side, the patch you linked to above looks
> good.  To what extent has it been tested?  If it bootstraps and passes
> the test suite, it's ready for trunk.

It bootstrapped successfully on a couple of the x86_64 machines ( on gcc farm ) 
And regress testing is underway.

> 
> Note that over the last couple of days I pushed my "use of
> uninitialized values" detection work to trunk (aka master), along with
> various other changes, so it's worth pulling master and rebasing on top
> of that before testing.  I *think* we've been touching different parts
> of the analyzer code, but there's a chance you might have to resolve
> some merge conflicts.

I have been constantly updating my branch as soon as I see a commit on analyzer 
( on patches list ) to avoid any conflicts. 
Till now I haven’t encountered any.

> 
> As for the patch you attached to this email
>  "[PATCH] analyzer: make analyer detect calls via function pointers"
> here's an initial review:

thanks for the review

> 
>> diff --git a/gcc/analyzer/analysis-plan.cc b/gcc/analyzer/analysis-plan.cc
>> index 7dfc48e9c3e..1c7e4d2cc84 100644
>> --- a/gcc/analyzer/analysis-plan.cc
>> +++ b/g

Re: tree decl stored during LGEN does not map to a symtab_node during WPA

[Erick Ochoa via Gcc]

Hello Richard, I need a little bit more help. In our previous messages
you mentioned ""

> >
> > > I guess the way to encode SSA trees would be to use sth like a
> > > , SSA-version tuple much like PTA internally
> > > uses the varinfo array index as identifier for the variables in the
> > > constraints.  For local decls (as opposed to SSA names) it's a bit
> > > more difficult - you'd have to devise your own encoding here.
> > >

There was a little confusion on my part about what "encoder" meant

>
> > You mention that I need to devise my own "encoder", but I am not sure
> > if we are conflating two notions:
> >
> > 1. encoding tree variables to constraint variables (i.e., a mapping of
> > some tuple (cgraph_node x symtab_node x ssa-version) to an integer
> > that represents the constraint variable)
> > 2. encoding as an implementation of a data structure used during LTO
> > to stream in and stream out trees/symbols to and from partitions.
> > (e.g., lto_symtab_encoder_t).
>

And you proceed with the following answer

> I meant 1) and streaming using the LTO cgraph encoder for the cgraph
> part and simply using the SSA version for the second part.
>

>From this exchange I understood that I should develop my own mapping
for ssa variables and local declarations. However, when dealing with
encoding a node which is available in the symbol table, I could use
the function lto_symtab_encoder_encode to map symbols to an integer
which would later make the symbol available at WPA time. Implicitly,
for me, this meant that this integer is the same for every distinct
symbol in different LGEN partitions. For example, if we encode symbol
X from partitions Y and we get the number N, then encoding symbol X in
partition Z should also yield N.

I believe this is not the case, during WPA time I am printing:
1. pid of lgen process that generated the encoding
2. index returned by lto_symtab_encoder_encode
3. varpool_node->name ()
4. the pointer address being pointed by varpool node

I think we had a previous discussion where it was mentioned that the
only way to distinguish between these cases is to look at varpool_node
cgraph_node:

(From a different email edited for brevity)

On Wed, 30 Jun 2021 at 19:38, Richard Biener  wrote:
>
> On June 30, 2021 6:28:29 PM GMT+02:00, Erick Ochoa  wrote:
> >So how would I be able to say that two different declarations are the
> >same variable?
>
> By looking at the associated varpool node.
>
> Richard.
>

If this is the case, I can indeed get the varpool node's at WPA time
(as shown above), but comparing their pointer addresses will be
distinct. How can one find out that two varpool nodes/cgraph nodes are
the same at WPA time? Is just looking at the assembler name enough? I
of course want this to be safe.

Another question, how is this currently handled in other IPA passes?
Alternatively, do you have suggestions for encoding functions and
global variables in a similar way to how you suggested encoding ssa
variables and local declarations?

Proper Place for builtin_define(__ELF__)

[Joel Sherrill]

Hi

We are in the process of porting RTEMS to the Microblaze and gcc does
not have __ELF__ as a predefine. In looking around at where to add it,
it looks like there are multiple ways to do it. We see variations on
the following patterns:

+ dbxelf.h
+ OS specific header in config/
+ Arch/OS specific header

Integrating dbxelf.h into the microblaze seems risky for one simple
builtin_define(). Adding it to config/microblaze/rtems.h won't address
the microblaze-elf target.

A suggestion on where to add the builtin_predefine is appreciated.

Thanks

--joel

Re: Proper Place for builtin_define(__ELF__)

[Michael Eager]

On 7/21/21 2:28 PM, Joel Sherrill wrote:

Hi

We are in the process of porting RTEMS to the Microblaze and gcc does
not have __ELF__ as a predefine. In looking around at where to add it,
it looks like there are multiple ways to do it. We see variations on
the following patterns:

+ dbxelf.h
+ OS specific header in config/
+ Arch/OS specific header

Integrating dbxelf.h into the microblaze seems risky for one simple
builtin_define(). Adding it to config/microblaze/rtems.h won't address
the microblaze-elf target.

A suggestion on where to add the builtin_predefine is appreciated.


There are very few defines for __ELF__ in the GCC target files.

Why don't you put this in rtems.h?

Alternately, you might put it in microblaze-s.c, wrapped with
#ifdef OBJECT_FORMAT_ELF/#endif.

--
Michael Eager

Re: Proper Place for builtin_define(__ELF__)

[Joel Sherrill]

On Wed, Jul 21, 2021, 7:12 PM Michael Eager  wrote:

> On 7/21/21 2:28 PM, Joel Sherrill wrote:
> > Hi
> >
> > We are in the process of porting RTEMS to the Microblaze and gcc does
> > not have __ELF__ as a predefine. In looking around at where to add it,
> > it looks like there are multiple ways to do it. We see variations on
> > the following patterns:
> >
> > + dbxelf.h
> > + OS specific header in config/
> > + Arch/OS specific header
> >
> > Integrating dbxelf.h into the microblaze seems risky for one simple
> > builtin_define(). Adding it to config/microblaze/rtems.h won't address
> > the microblaze-elf target.
> >
> > A suggestion on where to add the builtin_predefine is appreciated.
>
> There are very few defines for __ELF__ in the GCC target files.
>

Many  targets include dbxelf.h from the config.gcc script. There are 130
references to that file there. That seems to be where most architectures
get it.



> Why don't you put this in rtems.h?
>

That's ok for a hack but we haven't had to do that on the other ports so it
seems wrong.

I didn't mention but without this defined the cdefs.h file in newlib
produces incorrect macro definitions for at the weak_reference macro.


> Alternately, you might put it in microblaze-s.c, wrapped with
> #ifdef OBJECT_FORMAT_ELF/#endif.
>

Ok. This should fix it for microblaze-elf also.

Thanks.

--joel

>
> --
> Michael Eager
>

Re: Proper Place for builtin_define(__ELF__)

[Michael Eager]

On 7/21/21 5:22 PM, Joel Sherrill wrote:



On Wed, Jul 21, 2021, 7:12 PM Michael Eager > wrote:


On 7/21/21 2:28 PM, Joel Sherrill wrote:
 > Hi
 >
 > We are in the process of porting RTEMS to the Microblaze and gcc does
 > not have __ELF__ as a predefine. In looking around at where to
add it,
 > it looks like there are multiple ways to do it. We see variations on
 > the following patterns:
 >
 > + dbxelf.h
 > + OS specific header in config/
 > + Arch/OS specific header
 >
 > Integrating dbxelf.h into the microblaze seems risky for one simple
 > builtin_define(). Adding it to config/microblaze/rtems.h won't
address
 > the microblaze-elf target.
 >
 > A suggestion on where to add the builtin_predefine is appreciated.

There are very few defines for __ELF__ in the GCC target files.


Many  targets include dbxelf.h from the config.gcc script. There are 130 
references to that file there. That seems to be where most architectures 
get it.


AFAIK, no one has ever tried to build microblaze to generate stabs,
and I can't see a good reason why anyone would.  Including dbxelf.h
seems wrong.  I don't have an answer why other arch's do that.





Why don't you put this in rtems.h?


That's ok for a hack but we haven't had to do that on the other ports so 
it seems wrong.


Yep.



I didn't mention but without this defined the cdefs.h file in newlib 
produces incorrect macro definitions for at the weak_reference macro.



Alternately, you might put it in microblaze-s.c, wrapped with
#ifdef OBJECT_FORMAT_ELF/#endif.


Ok. This should fix it for microblaze-elf also.


ARM does something which looks screwy to me.  Instead of defining
__ELF__, they pass -D__ELF__ on the CPP command line.



Thanks.

--joel


-- 
Michael Eager




--
Michael Eager

Re: Proper Place for builtin_define(__ELF__)

[Jeff Law via Gcc]

On 7/21/2021 6:31 PM, Michael Eager wrote:



On 7/21/21 5:22 PM, Joel Sherrill wrote:



On Wed, Jul 21, 2021, 7:12 PM Michael Eager > wrote:


    On 7/21/21 2:28 PM, Joel Sherrill wrote:
 > Hi
 >
 > We are in the process of porting RTEMS to the Microblaze and 
gcc does

 > not have __ELF__ as a predefine. In looking around at where to
    add it,
 > it looks like there are multiple ways to do it. We see 
variations on

 > the following patterns:
 >
 > + dbxelf.h
 > + OS specific header in config/
 > + Arch/OS specific header
 >
 > Integrating dbxelf.h into the microblaze seems risky for one 
simple

 > builtin_define(). Adding it to config/microblaze/rtems.h won't
    address
 > the microblaze-elf target.
 >
 > A suggestion on where to add the builtin_predefine is 
appreciated.


    There are very few defines for __ELF__ in the GCC target files.


Many  targets include dbxelf.h from the config.gcc script. There are 
130 references to that file there. That seems to be where most 
architectures get it.


AFAIK, no one has ever tried to build microblaze to generate stabs,
and I can't see a good reason why anyone would.  Including dbxelf.h
seems wrong.  I don't have an answer why other arch's do that.
Avoiding dbxelf would be advisable.  We're really only supporting stabs 
for for aix anymore.  We need to start excising dbxelf from all the 
places it's being used.


jeff

A value number issue

[Gary Oblock via Gcc]

I seem to be having a problem with the pre pass.

When eliminate_dom_walker::eliminate_stmt is called with
the gsi to "dedangled_864 = bea_43->tail;" which in turn
calls eliminate_dom_walker::eliminate_avail op of dedangled_864.
This gives VN_INFO (lhs)->valnum of _920. The _920 is not
associated with any SSA variable in the function and I don't
see how it got associated with dedangled_864. This is not
a theoretical issue because it causes an error (the gcc_unreachable
in eliminate_stmt is called.)

Here is how _920 (in function main) is used.

  _920 = arcnew_916->head;
  _921 = MEM[(struct node.reorg.reorder *)_920].firstin;
  MEM[(struct node.reorg.reorder *)_920].firstin = arcnew_916;

Here is how dedangled_864 is used:

   [local count: 2609125]:
  dedangled_863 = bea_43->head;
  dedangled_864 = bea_43->tail;
  goto ; [100.00%]

   [local count: 1813121]:
  dedangled_865 = bea_43->tail;
  dedangled_866 = bea_43->head;

   [local count: 4422246]:
  # dedangled_867 = PHI 
  # dedangled_868 = PHI 
  delta_461 = 1;
  goto ; [100.00%]

Note, dedangled_868 is used in an ever widening net of
phis and operations. Also, the other similar statements

  dedangled_863 = bea_43->head;
  dedangled_865 = bea_43->tail;
  dedangled_866 = bea_43->head;

don't seem to be malformed.

I tried using a watchpoint to see what was happening but that turned
out to be not productive in that it was tripping on something
unrelated even if I set it at the start of the pre pass.

I'm assuming that some of my code is malformed in some
subtle way and I was wondering it anybody had any ideas?
I say subtle because this was all working on a slightly different
version of gcc without the code of some other Ampere optimizations
in the mix (I disabled those optimizations and things still failed.)

Note, if you guys don't have any ideas the next approach is adding
tons of brute force instrumentation and special purpose sanity
checking to the value numbering routine... please help me avoid that.

Thanks,

Gary


CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for 
the sole use of the intended recipient(s) and contains information that is 
confidential and proprietary to Ampere Computing or its subsidiaries. It is to 
be used solely for the purpose of furthering the parties' business 
relationship. Any unauthorized review, copying, or distribution of this email 
(or any attachments thereto) is strictly prohibited. If you are not the 
intended recipient, please contact the sender immediately and permanently 
delete the original and any copies of this email and any attachments thereto.