Re: A value number issue

[Richard Biener via Gcc]

On Wed, Jul 28, 2021 at 11:03 PM Gary Oblock  wrote:
>
> Richard,
>
> Here is more on the actual failure.
>
> From the pre pass dump:
>
> :
> Inserted _975 = (struct node.reorg.reorder *) dedangled_865;
> Replaced bea_43->tail with _975 in dedangled_864 = bea_43->tail;
>
>
>
> EMERGENCY DUMP:
>
> void master.constprop ()
> {
>   :
>   unsigned long _974;
>   struct node.reorg.reorder * _975;
>
>   :
>[local count: 4422246]:
>   _58 = MEM[(int64_t *)&net + 608B];
>   _59 = _58 + 1;
>   MEM[(int64_t *)&net + 608B] = _59;
>   dedangled_865 = bea_43->tail;
>   dedangled_863 = bea_43->head;
>   _975 = (struct node.reorg.reorder *) dedangled_865;
>   dedangled_864 = bea_43->tail;
>   dedangled_866 = bea_43->head;
>   if (red_cost_of_bea_42 > 0)
> goto ; [59.00%]
>   else
> goto ; [41.00%]
>   :
> --
> In tree-ssa-sccvn.c at about line 6000 or so there is
> this sequence:
>
>   if (!useless_type_conversion_p (TREE_TYPE (lhs),
>   TREE_TYPE (sprime)))
> {
>   /* We preserve conversions to but not from function or method
>  types.  This asymmetry makes it necessary to re-instantiate
>  conversions here.  */
>   if (POINTER_TYPE_P (TREE_TYPE (lhs))
>&& FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (lhs
> sprime = fold_convert (TREE_TYPE (lhs), sprime);
>   else
> gcc_unreachable ();
> }
>
> We reach the gcc_unreachable because:
>
> lhs = dedangled_864, TREE_TYPE(lhs) = unsigned long
> sprime = _975, TREE_TYPE(sprime) = struct node.reorg.reorder *
>
> I've got to ask why does the _975 have that type?

Because the value was used with that type?

> The ssa var dedangled_865 is an unsigned long.
> If I knew why this happens then, hopefully, I can adjust
> the GIMPLE I create to avoid this situation...
>
> Question, would have including all references to denangled_865
> in the pre pass dump helped you answer this? By the way, I couldn't
> find a spot where dedangled_865 or any of its phi related uses
> (a use of x where x <- phi<... denanged_865..> and so on recursively)
> was converted to struct node.reorg.reorder *.

So what did you change in GCC?  If you did not change value-numbering
then you can reduce the testcase down and extract a GIMPLE frontend
testcase for VN (use -fdump-tree-all-gimple and massage the GIMPLE
dumped before the FRE/PRE pass that causes the issue)

> Gary
>
>
> 
> From: Richard Biener 
> Sent: Wednesday, July 28, 2021 3:40 AM
> To: Gary Oblock 
> Cc: gcc@gcc.gnu.org 
> Subject: Re: A value number issue
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
> be mindful of safe email handling and proprietary information protection 
> practices.]
>
>
> On Fri, Jul 23, 2021 at 3:40 AM Gary Oblock  wrote:
> >
> > Richard,
> >
> > OK, all that I've gotten so far out of the dump file is
> > that the name of "_920" is just something sccvn concocted
> > and wasn't something I accidentally caused.
> >
> > That still leaves me with the question of what is going on.
> >
> > Here's all the interesting bits of the dumpfile concerning
> > dedangled_864:
> >
> > :
> > dedangled_865 = *bea_43 + 64
> > dedangled_863 = *bea_43 + 128
> > dedangled_864 = *bea_43 + 64
> > dedangled_866 = *bea_43 + 128
> > dedangled_867 = dedangled_863
> > dedangled_867 = dedangled_865
> > dedangled_868 = dedangled_864
> > dedangled_868 = dedangled_866
> > :
> > Equivalence classes for indirect node id 160 "dedangled_865": pointer 84, 
> > location 0
> > Equivalence classes for indirect node id 161 "dedangled_863": pointer 85, 
> > location 0
> > Equivalence classes for indirect node id 162 "dedangled_864": pointer 86, 
> > location 0
> > :
> > dedangled_865 = { ESCAPED NONLOCAL }
> > dedangled_863 = { ESCAPED NONLOCAL }
> > dedangled_864 = { ESCAPED NONLOCAL }
> > dedangled_866 = { ESCAPED NONLOCAL }
> > dedangled_867 = { ESCAPED NONLOCAL }
> > dedangled_868 = { ESCAPED NONLOCAL }
> > :
> > Value numbering store MEM[(int64_t *)&net + 608B] to _59
> > Setting value number of .MEM_123 to .MEM_123 (changed)
> > Value numbering stmt = dedangled_865 = bea_43->tail;
> > Setting value number of dedangled_865 to dedangled_865 (changed)
> > Making available beyond BB36 dedangled_865 for value dedangled_865
> > Value numbering stmt = dedangled_863 = bea_43->head;
> > Setting value number of dedangled_863 to dedangled_863 (changed)
> > Making available beyond BB36 dedangled_863 for value dedangled_863
> > Value numbering stmt = dedangled_864 = bea_43->tail;
> > Inserting name _920 for expression (struct node.reorg.reorder *) 
> > dedangled_865
>
> this means that the earlier dedangled_865 = bea_43->tail; somehow did not
> produce a value that was considered OK but it was close enough so VN
> remembers the expression (struct node.reorg.reorder *) dedangled_865
> as known result, using _920 as value.  _920 should be then inserted during
> elimination.
>
> I'm not sure wh

Re: A value number issue

[Gary Oblock via Gcc]

Richard,

I didn't find a use of _975 with that type...

A small test case is easier said than done. It's mcf
and I pulled a copy out of SPEC for my unit tests (we have
a SPEC license) and that passes. However, when I compile it
in the SPEC framework, it fails. Otherwise, I'd have used
creduce to make a really tiny test case a couple of weeks
ago... ;-(

In RTL a trick I used to use in the bad old days when I did one off VLIW
schedulers, was to instrument the bit that assigns the RTL's id
number and put a trap there to catch the creation of an interesting
bit of RTL. Does that kind of trick work with SSA variable creation?

Thanks, I really appreciate your help even though in this case
I'm still kind of stuck.

Gary


From: Richard Biener 
Sent: Thursday, July 29, 2021 12:12 AM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: A value number issue

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Wed, Jul 28, 2021 at 11:03 PM Gary Oblock  wrote:
>
> Richard,
>
> Here is more on the actual failure.
>
> From the pre pass dump:
>
> :
> Inserted _975 = (struct node.reorg.reorder *) dedangled_865;
> Replaced bea_43->tail with _975 in dedangled_864 = bea_43->tail;
>
>
>
> EMERGENCY DUMP:
>
> void master.constprop ()
> {
>   :
>   unsigned long _974;
>   struct node.reorg.reorder * _975;
>
>   :
>[local count: 4422246]:
>   _58 = MEM[(int64_t *)&net + 608B];
>   _59 = _58 + 1;
>   MEM[(int64_t *)&net + 608B] = _59;
>   dedangled_865 = bea_43->tail;
>   dedangled_863 = bea_43->head;
>   _975 = (struct node.reorg.reorder *) dedangled_865;
>   dedangled_864 = bea_43->tail;
>   dedangled_866 = bea_43->head;
>   if (red_cost_of_bea_42 > 0)
> goto ; [59.00%]
>   else
> goto ; [41.00%]
>   :
> --
> In tree-ssa-sccvn.c at about line 6000 or so there is
> this sequence:
>
>   if (!useless_type_conversion_p (TREE_TYPE (lhs),
>   TREE_TYPE (sprime)))
> {
>   /* We preserve conversions to but not from function or method
>  types.  This asymmetry makes it necessary to re-instantiate
>  conversions here.  */
>   if (POINTER_TYPE_P (TREE_TYPE (lhs))
>&& FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (lhs
> sprime = fold_convert (TREE_TYPE (lhs), sprime);
>   else
> gcc_unreachable ();
> }
>
> We reach the gcc_unreachable because:
>
> lhs = dedangled_864, TREE_TYPE(lhs) = unsigned long
> sprime = _975, TREE_TYPE(sprime) = struct node.reorg.reorder *
>
> I've got to ask why does the _975 have that type?

Because the value was used with that type?

> The ssa var dedangled_865 is an unsigned long.
> If I knew why this happens then, hopefully, I can adjust
> the GIMPLE I create to avoid this situation...
>
> Question, would have including all references to denangled_865
> in the pre pass dump helped you answer this? By the way, I couldn't
> find a spot where dedangled_865 or any of its phi related uses
> (a use of x where x <- phi<... denanged_865..> and so on recursively)
> was converted to struct node.reorg.reorder *.

So what did you change in GCC?  If you did not change value-numbering
then you can reduce the testcase down and extract a GIMPLE frontend
testcase for VN (use -fdump-tree-all-gimple and massage the GIMPLE
dumped before the FRE/PRE pass that causes the issue)

> Gary
>
>
> 
> From: Richard Biener 
> Sent: Wednesday, July 28, 2021 3:40 AM
> To: Gary Oblock 
> Cc: gcc@gcc.gnu.org 
> Subject: Re: A value number issue
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
> be mindful of safe email handling and proprietary information protection 
> practices.]
>
>
> On Fri, Jul 23, 2021 at 3:40 AM Gary Oblock  wrote:
> >
> > Richard,
> >
> > OK, all that I've gotten so far out of the dump file is
> > that the name of "_920" is just something sccvn concocted
> > and wasn't something I accidentally caused.
> >
> > That still leaves me with the question of what is going on.
> >
> > Here's all the interesting bits of the dumpfile concerning
> > dedangled_864:
> >
> > :
> > dedangled_865 = *bea_43 + 64
> > dedangled_863 = *bea_43 + 128
> > dedangled_864 = *bea_43 + 64
> > dedangled_866 = *bea_43 + 128
> > dedangled_867 = dedangled_863
> > dedangled_867 = dedangled_865
> > dedangled_868 = dedangled_864
> > dedangled_868 = dedangled_866
> > :
> > Equivalence classes for indirect node id 160 "dedangled_865": pointer 84, 
> > location 0
> > Equivalence classes for indirect node id 161 "dedangled_863": pointer 85, 
> > location 0
> > Equivalence classes for indirect node id 162 "dedangled_864": pointer 86, 
> > location 0
> > :
> > dedangled_865 = { ESCAPED NONLOCAL }
> > dedangled_863 = { ESCAPED NONLOCAL }
> > dedangled_864 = { ESCAPED NONLOCAL }
> > dedangled_866 = { ESCAPED NONLOCAL }
> > dedangled_867

Re: A value number issue

[Richard Biener via Gcc]

On Thu, Jul 29, 2021 at 9:29 AM Gary Oblock  wrote:
>
> Richard,
>
> I didn't find a use of _975 with that type...
>
> A small test case is easier said than done. It's mcf
> and I pulled a copy out of SPEC for my unit tests (we have
> a SPEC license) and that passes. However, when I compile it
> in the SPEC framework, it fails. Otherwise, I'd have used
> creduce to make a really tiny test case a couple of weeks
> ago... ;-(

Does it pass if you cut&paste the exact command SPEC uses
in its build directory?

>
> In RTL a trick I used to use in the bad old days when I did one off VLIW
> schedulers, was to instrument the bit that assigns the RTL's id
> number and put a trap there to catch the creation of an interesting
> bit of RTL. Does that kind of trick work with SSA variable creation?

Well, I'm usually debugging cc1 then and conditionally break on
the return from make_ssa_name_fn if t->base.u.version == the SSA version
or for any GC allocated entity at the return of ggc_internal_alloc and the
corresponding address of the object.

> Thanks, I really appreciate your help even though in this case
> I'm still kind of stuck.
>
> Gary
>
> 
> From: Richard Biener 
> Sent: Thursday, July 29, 2021 12:12 AM
> To: Gary Oblock 
> Cc: gcc@gcc.gnu.org 
> Subject: Re: A value number issue
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
> be mindful of safe email handling and proprietary information protection 
> practices.]
>
>
> On Wed, Jul 28, 2021 at 11:03 PM Gary Oblock  wrote:
> >
> > Richard,
> >
> > Here is more on the actual failure.
> >
> > From the pre pass dump:
> >
> > :
> > Inserted _975 = (struct node.reorg.reorder *) dedangled_865;
> > Replaced bea_43->tail with _975 in dedangled_864 = bea_43->tail;
> >
> >
> >
> > EMERGENCY DUMP:
> >
> > void master.constprop ()
> > {
> >   :
> >   unsigned long _974;
> >   struct node.reorg.reorder * _975;
> >
> >   :
> >[local count: 4422246]:
> >   _58 = MEM[(int64_t *)&net + 608B];
> >   _59 = _58 + 1;
> >   MEM[(int64_t *)&net + 608B] = _59;
> >   dedangled_865 = bea_43->tail;
> >   dedangled_863 = bea_43->head;
> >   _975 = (struct node.reorg.reorder *) dedangled_865;
> >   dedangled_864 = bea_43->tail;
> >   dedangled_866 = bea_43->head;
> >   if (red_cost_of_bea_42 > 0)
> > goto ; [59.00%]
> >   else
> > goto ; [41.00%]
> >   :
> > --
> > In tree-ssa-sccvn.c at about line 6000 or so there is
> > this sequence:
> >
> >   if (!useless_type_conversion_p (TREE_TYPE (lhs),
> >   TREE_TYPE (sprime)))
> > {
> >   /* We preserve conversions to but not from function or method
> >  types.  This asymmetry makes it necessary to re-instantiate
> >  conversions here.  */
> >   if (POINTER_TYPE_P (TREE_TYPE (lhs))
> >&& FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (lhs
> > sprime = fold_convert (TREE_TYPE (lhs), sprime);
> >   else
> > gcc_unreachable ();
> > }
> >
> > We reach the gcc_unreachable because:
> >
> > lhs = dedangled_864, TREE_TYPE(lhs) = unsigned long
> > sprime = _975, TREE_TYPE(sprime) = struct node.reorg.reorder *
> >
> > I've got to ask why does the _975 have that type?
>
> Because the value was used with that type?
>
> > The ssa var dedangled_865 is an unsigned long.
> > If I knew why this happens then, hopefully, I can adjust
> > the GIMPLE I create to avoid this situation...
> >
> > Question, would have including all references to denangled_865
> > in the pre pass dump helped you answer this? By the way, I couldn't
> > find a spot where dedangled_865 or any of its phi related uses
> > (a use of x where x <- phi<... denanged_865..> and so on recursively)
> > was converted to struct node.reorg.reorder *.
>
> So what did you change in GCC?  If you did not change value-numbering
> then you can reduce the testcase down and extract a GIMPLE frontend
> testcase for VN (use -fdump-tree-all-gimple and massage the GIMPLE
> dumped before the FRE/PRE pass that causes the issue)
>
> > Gary
> >
> >
> > 
> > From: Richard Biener 
> > Sent: Wednesday, July 28, 2021 3:40 AM
> > To: Gary Oblock 
> > Cc: gcc@gcc.gnu.org 
> > Subject: Re: A value number issue
> >
> > [EXTERNAL EMAIL NOTICE: This email originated from an external sender. 
> > Please be mindful of safe email handling and proprietary information 
> > protection practices.]
> >
> >
> > On Fri, Jul 23, 2021 at 3:40 AM Gary Oblock  
> > wrote:
> > >
> > > Richard,
> > >
> > > OK, all that I've gotten so far out of the dump file is
> > > that the name of "_920" is just something sccvn concocted
> > > and wasn't something I accidentally caused.
> > >
> > > That still leaves me with the question of what is going on.
> > >
> > > Here's all the interesting bits of the dumpfile concerning
> > > dedangled_864:
> > >
> > > :
> > > dedangled_865 = *bea_43 + 64
> > > dedangled_863 = *bea_43 + 128
> > > dedangled

Re: How to detect user uses -masm=intel?

[Florian Weimer via Gcc]

* unlvsur unlvsur via Gcc:

> What I mean is that what macro GCC sets when it compiles -masm=intel
>
>
> Int main()
> {
> #ifdef /*__INTEL_ASM*/
> printf(“intel”);
> #else
> printf(“at&t”);
> #endif
> }

There doesn't seem to be such a macro:

$ diff -u <(gcc -dM -E -x c /dev/null) <(gcc -masm=intel -dM -E -x c /dev/null)
$ 

It doesn't look like it's possible to detect this as the GAS level
directly.  So you have to use the alternatives syntax that Andrew
suggested.

Thanks,
Florian

Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4

[Lawrence Doctors]

Dear Sir/Madam:

I would firstly like to thank the folks at GCC for their fine work on 
developing the Fortran compilers, which I have been using for about 12 years 
now, on a series of four MacBook Pro computers. In total, I have had over 50 
years experience using Fortran, this being on a variety of different platforms. 
I therefore do consider myself as being a very experienced programmer.

I have recently installed your gfortran-10.2-catalina.dmg on macOS Big Sur 
Version 11.4 with a 2.4 GHz 8-core Intel Core i9 processor. The computer has 64 
GB 2667 MHz DDR4 of memory, with a disk capacity of 8 TB. During my previous 
experience, when I switched to a new computer on about six or seven occasions, 
most of my programs (now 553 in number) compiled successfully the first time, 
but some of the programs required minor modifications. On this occasion, I 
encountered the following new challenges:

(1) I see that you now check consistency of the argument types and rank, in 
CALL statements. Thus, if an argument would normally be an array, but is unused 
in some CALL statements, my practice was to use a dummy argument with a short 
name, such as "d". This has worked for over 50 years without trouble. However, 
you now check for consistency. Obviously this was easy to fix, as I simple 
declared a dummy array in a DIMENSION statement with the name "d (1)", which 
solved the problem. On reflection, I would say that this is an improvement, 
because it forces the programmer to think carefully when writing the CALL 
statement.

(2) I encountered a curious failure on compilation with the following statement 
using integer arithmetic:
  n= (m + 4)/5
with the message
Error: Integer division truncated to constant ‘2’ at (1) 
[-Werror=integer-division]
f951: all warnings being treated as errors

This error only occurs if both (a) the value of  "m" would lead to a truncation 
(say 7 but not 6), and ALSO if (b) the value of "m" was set in a PARAMETER 
statement. I can work my way around this difficulty by rewriting the statement 
as:
  n= int ((1.0*m + 4)/5)
but it does seem clumsy.

(3) The new compiler seems to dislike large fixed DIMENSION statements, such as 
the following at the beginning of the program unit:
  parameter (n= 105)
  dimension a (n)

The compiler then issues the following message:
3 |   dimension a (n)
  | 1
Error: Array ‘a’ at (1) is larger than limit set by ‘-fmax-stack-var-size=’, 
moved from stack to static storage. This makes the procedure unsafe when called 
recursively, or concurrently from multiple threads. Consider using 
‘-frecursive’, or increase the ‘-fmax-stack-var-size=’ limit, or change the 
code to use an ALLOCATABLE array. [-Werror=surprising]
f951: all warnings being treated as errors

I agree that the message is clear and I was able to follow the suggestion to 
use an ALLOCATABLE statement, but I still wonder why you consider the program 
unsatisfactory in the first place. I can understand (to some degree) why such a 
large array is frowned upon, because one should economize on the size of 
arrays. On the other hand, if the use of a large array makes the task of the 
programmer easier, it should be allowed. Furthermore, an array size of 100 
elements or so is very small, considering the size of the RAM and the disk 
available nowadays.

I would be pleased if you have the time to respond and I would like to express 
my appreciation again for the considerable effort that your group has invested 
in the Fortran compilers over the years.

Sincerely,

Larry

Lawrence J. Doctors
Emeritus Professor
Naval Architecture Program
School of Mechanical and Manufacturing Engineering
The University of New South Wales
Sydney, NSW 2052, Australia
Email: l.doct...@unsw.edu.au
Telephone: +61-2-9371 4158

Re: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4

[Jonathan Wakely via Gcc]

On Thu, 29 Jul 2021, 11:59 Lawrence Doctors,  wrote:

> Dear Sir/Madam:
>
> I would firstly like to thank the folks at GCC for their fine work on
> developing the Fortran compilers, which I have been using for about 12
> years now, on a series of four MacBook Pro computers. In total, I have had
> over 50 years experience using Fortran, this being on a variety of
> different platforms. I therefore do consider myself as being a very
> experienced programmer.
>
> I have recently installed your gfortran-10.2-catalina.dmg on macOS Big Sur
> Version 11.4 with a 2.4 GHz 8-core Intel Core i9 processor. The computer
> has 64 GB 2667 MHz DDR4 of memory, with a disk capacity of 8 TB. During my
> previous experience, when I switched to a new computer on about six or
> seven occasions, most of my programs (now 553 in number) compiled
> successfully the first time, but some of the programs required minor
> modifications. On this occasion, I encountered the following new challenges:
>

This mail seems off-topic for this mailing list, which is about development
of GCC, see https://gcc.gnu.org/lists.html

The gcc-help or fortran mailing lists would be more appropriate.



> (1) I see that you now check consistency of the argument types and rank,
> in CALL statements. Thus, if an argument would normally be an array, but is
> unused in some CALL statements, my practice was to use a dummy argument
> with a short name, such as "d". This has worked for over 50 years without
> trouble. However, you now check for consistency. Obviously this was easy to
> fix, as I simple declared a dummy array in a DIMENSION statement with the
> name "d (1)", which solved the problem. On reflection, I would say that
> this is an improvement, because it forces the programmer to think carefully
> when writing the CALL statement.
>

Is this related to https://gcc.gnu.org/gcc-8/porting_to.html#fortran ?

Or maybe the item about dummy arguments at
https://gcc.gnu.org/gcc-8/changes.html#fortran



> (2) I encountered a curious failure on compilation with the following
> statement using integer arithmetic:
>   n= (m + 4)/5
> with the message
> Error: Integer division truncated to constant ‘2’ at (1)
> [-Werror=integer-division]
> f951: all warnings being treated as errors


>
This was a new warning in GCC 6, which is an error because you're using
-Werror to turn warnings into errors.

https://gcc.gnu.org/gcc-6/changes.html#fortran



This error only occurs if both (a) the value of  "m" would lead to a
> truncation (say 7 but not 6), and ALSO if (b) the value of "m" was set in a
> PARAMETER statement. I can work my way around this difficulty by rewriting
> the statement as:
>   n= int ((1.0*m + 4)/5)
> but it does seem clumsy.
>
> (3) The new compiler seems to dislike large fixed DIMENSION statements,
> such as the following at the beginning of the program unit:
>   parameter (n= 105)
>   dimension a (n)
>
> The compiler then issues the following message:
> 3 |   dimension a (n)
>   | 1
> Error: Array ‘a’ at (1) is larger than limit set by
> ‘-fmax-stack-var-size=’, moved from stack to static storage. This makes the
> procedure unsafe when called recursively, or concurrently from multiple
> threads. Consider using ‘-frecursive’, or increase the
> ‘-fmax-stack-var-size=’ limit, or change the code to use an ALLOCATABLE
> array. [-Werror=surprising]
> f951: all warnings being treated as errors


>
Again, you've turned a warning into an error.


I agree that the message is clear and I was able to follow the suggestion
> to use an ALLOCATABLE statement, but I still wonder why you consider the
> program unsatisfactory in the first place.


Because you asked for warnings to be errors.


I can understand (to some degree) why such a large array is frowned upon,
> because one should economize on the size of arrays. On the other hand, if
> the use of a large array makes the task of the programmer easier, it should
> be allowed.



It is allowed, that's why it's only a warning by default.

GCC provides various ways to control warnings/errors, see the manual.

Furthermore, an array size of 100 elements or so is very small,
> considering the size of the RAM and the disk available nowadays.
>
> I would be pleased if you have the time to respond and I would like to
> express my appreciation again for the considerable effort that your group
> has invested in the Fortran compilers over the years.
>
> Sincerely,
>
> Larry
>
> Lawrence J. Doctors
> Emeritus Professor
> Naval Architecture Program
> School of Mechanical and Manufacturing Engineering
> The University of New South Wales
> Sydney, NSW 2052, Australia
> Email: l.doct...@unsw.edu.au
> Telephone: +61-2-9371 4158
>
>

Named address spaces on x86 GNU/Linux

[Florian Weimer via Gcc]

The x86-64 architecture supports two instruction prefixes, SEGFS and
SEGGS that apply an additional offset to memory operands.  The offset
lives in a special register that is accessible to the kernel only
(historically).

On GNU/Linux, SEGFS is used to implement the thread pointer, to avoid
dedicating a general-purpose register to it.  At address zero with the
SEGFS prefix, the offset itself is stored so that userspace can read it
without having to call into the kernel.  So the SEGFS null pointer is a
valid address, and so are some bytes after it (depending on TCB layout,
some of which is specified by the ABI or is part of the de-facto ABI
used by GCC).

GCC 12 has started warning on __seg_fs null pointer arithmetic.  In
glibc, we use this construct:

  *(struct pthread *__seg_fs *) offsetof (struct pthread, header.self)

And this is now causing build failures due to -Werror.

It's been suggested that I should prove that these warnings are invalid
under the N1275 document referenced in the GCC manual.

However, I think N1275 is not actually implemented by GCC on x86-64.
The address spaces are treated as disjoint by the front end.  That is,
this

int *
f (int __seg_fs *q)
{
  return (int *) q;
}

results in

| warning: cast to generic address space pointer from disjoint __seg_fs
|   address space pointer

But I would argue that this is not correct under the N1275 rules because
the address spaces are overlapping in practice.  I assume the CPU wraps
around address arithmetic, which would make them completely equivalent.

The optimizers appear to treat the address spaces as overlapping, as
expected.  In this,

int
f(int *p, int __seg_fs *q)
{
  *p = 1;
  *q = 2;
  return *p;
}

the read in the return statement is not optimized away.

I have trouble deriving from N1275 if pointer casts are supposed to
apply offsets or perform some other sort of address translation to
produce a pointer to the same object.  The GCC implementation does not
do this, it preserves the representation.  With a shifted address space,
the rule for mapping null pointers to null pointers does not make sense
and is actually not helpful in the GNU/Linux case (because a copy of the
thread pointer is stored at address zero, as mentioned above).

I can't shake the impression that N1275 is about something else and not
the offsets that the x86-64 architecture can apply to addresses.

Thanks,
Florian

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

[Ankur Saini via Gcc]

I have attached the patches(one is the updated version of previous patch to 
detect calls via function pointers) of the changed done to make the analyzer 
understand the calls to virtual functions for initial review. 

1. I decided to make a dedicated function to create enodes and eedges for the 
dynamically discovered calls as I found myself using the exact same peice of 
code again to analyse vfunc calls.

2. Boostaraping and testing of these changes are underway.

3. Regarding the regress tests that have to be added to test functionality of 
vfunc extension patch :
Should I add many test files for different types of inheritences or should I 
add one ( or two ) test files, with a lot of fucntions in them testing 
different 
types of calls ?

---
Patches :


fn_ptr.patch
Description: Binary data


v_table.patch
Description: Binary data


Thank you 
- Ankur

Re: Named address spaces on x86 GNU/Linux

[Joseph Myers]

On Thu, 29 Jul 2021, Florian Weimer via Gcc wrote:

> On GNU/Linux, SEGFS is used to implement the thread pointer, to avoid
> dedicating a general-purpose register to it.  At address zero with the
> SEGFS prefix, the offset itself is stored so that userspace can read it
> without having to call into the kernel.  So the SEGFS null pointer is a
> valid address, and so are some bytes after it (depending on TCB layout,
> some of which is specified by the ABI or is part of the de-facto ABI
> used by GCC).

That suggests that we need a target hook to describe null pointer 
properties for a given address space.  In an address space where null 
pointers are valid to dereference, there should be no diagnostics for 
arithmetic on / dereferencing them - and more generally, 
-fno-delete-null-pointer-checks should be in effect for pointers to such 
an address space (so I don't think this is just a warning issue, you can 
probably get wrong code from null pointer check deletion in such an 
address space).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: rust frontend and UTF-8/unicode processing/properties

[Manuel López-Ibáñez]

For the gcc rust frontend I was thinking of importing a couple of
gnulib modules to help with UTF-8 processing, conversion to/from
unicode codepoints and determining various properties of those
codepoints. But it seems gcc doesn't yet have any gnulib modules
imported, and maybe other frontends already have helpers to this that
the gcc rust frontend could reuse.


Although I agree that factoring out the code in libcpp so that it can be used 
by other FEs would be great and in line with the goals of 
https://gcc.gnu.org/wiki/ModularGCC that is a significant amount of work. 
Importing gnulib has its own advantages and it would allow GCC to finally 
deprecate libiberty:


https://gcc.gnu.org/wiki/replacelibibertywithgnulib

There is a preliminary patch here: 
https://gcc.gnu.org/legacy-ml/gcc-patches/2016-08/msg01554.html


Cheers,

Manuel.

Re: An asm constraint issue (ARM FPU)

[Zoltán Kócsi]

Dear Marc,

Sorry for the late answer, I was away for a few days.
Yes, that fixes it. THANK YOU!

Do you know which gcc source file contains the magic qualifiers for the
asm arguments? I wouldn't mind to go through the code and extract what
I can. Probably I'd find a couple of gems that are useful for inline
asm stuff. Maybe even write the info pages that describe them, so
that others can make use of them...

Thanks again,

Best Regards,

Zoltan


On Sun, 25 Jul 2021 14:19:56 +0200 (CEST)
Marc Glisse  wrote:

> On Sun, 25 Jul 2021, Zoltán Kócsi wrote:
> 
> > [...]
> > double spoof( uint64_t x )
> > {
> > double r;
> >
> >   asm volatile
> >   (
> > " vmov.64 %[d],%Q[i],%R[i] \n"  
> 
> Isn't it supposed to be %P[d] for a double?
> (the documentation is very lacking...)
> 
> > [...]
> -- 
> Marc Glisse

gcc-9-20210729 is now available

[GCC Administrator via Gcc]

Snapshot gcc-9-20210729 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20210729/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 
revision 49a2cbb3f5906ac20d7a4619d5d3112584d46cf7

You'll find:

 gcc-9-20210729.tar.xzComplete GCC

  SHA256=aa74d4a2a22bd63f5d066d3f81ea39983a921a59a3bc65fb60fb2950e6c8e358
  SHA1=c13a2bb60b761ca9dc90531e64f8b21fd8ebb988

Diffs from 9-20210722 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
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: daily report on extending static analyzer project [GSoC]

[David Malcolm via Gcc]

On Thu, 2021-07-29 at 18:20 +0530, Ankur Saini wrote:
> I have attached the patches(one is the updated version of previous
> patch to 
> detect calls via function pointers) of the changed done to make the
> analyzer 
> understand the calls to virtual functions for initial review. 
> 
> 1. I decided to make a dedicated function to create enodes and eedges
> for the 
> dynamically discovered calls as I found myself using the exact same
> peice of 
> code again to analyse vfunc calls.

Makes sense.

> 
> 2. Boostaraping and testing of these changes are underway.
> 
> 3. Regarding the regress tests that have to be added to test
> functionality of 
> vfunc extension patch :
> Should I add many test files for different types of inheritences or
> should I 
> add one ( or two ) test files, with a lot of fucntions in them testing
> different 
> types of calls ?

Both approaches have merit, and there's an element of personal taste.

I find that during development and debugging it's handy to have the
tests broken out into individual files, but it's good to eventually
combine the tests to minimize the number of invocations that the test
harness has to do.

That said, interprocedural tests tend to be fiddly, so it's often good
to keep these in separate files.

I tend to combine my tests and add them to git, and then to temporarily
trim them down when debugging them to minimize the amoung of unrelated
stuff I'm having to look at when debugging, knowing that git has the
full version saved.

I hope that answers your question.

> 
> ---
> Patches :

This isn't a full review, but...

fn_ptr.patch:

> diff --git a/gcc/testsuite/gcc.dg/analyzer/function-ptr-4.c 
> b/gcc/testsuite/gcc.dg/analyzer/function-ptr-4.c
> new file mode 100644
> index 000..c62510c026f
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/analyzer/function-ptr-4.c
> @@ -0,0 +1,25 @@
> +/*Test to see if the analyzer detect and analyze calls via 
> +  fucntion pointers or not. */
> +
> +#include 
> +#include 
> +
> +void fun(int *int_ptr)
> +{
> + free(int_ptr); /* { dg-warning "double-'free' of 'int_ptr'" } */
> +}
> +
> +void single_call()
> +{
> + int *int_ptr = (int*)malloc(sizeof(int));
> + void (*fun_ptr)(int *) = &fun;
> + (*fun_ptr)(int_ptr);
> +}
> +
> +void double_call()
> +{
> + int *int_ptr = (int*)malloc(sizeof(int));
> + void (*fun_ptr)(int *) = &fun;
> + (*fun_ptr)(int_ptr);
> + (*fun_ptr)(int_ptr);
> +}

...thinking back to our discussion about events, it would be good to
verify that the analyzer is emitting them.  You can put directives
like:

   /* { dg-message "calling 'fun' from 'double_call'" } */

on the appropriate lines to test this via DejaGnu.

"analyzer: detect and analyzer vfunc calls"

[...snip...]

> @@ -1242,6 +1243,17 @@ exploded_node::on_stmt (exploded_graph &eg,
>   unknown_side_effects = false;
>  }
>  
> +  /* If the statmement is a polymorphic call then assume 
> + there are no side effects.  */
> +  gimple *call_stmt = const_cast(stmt);
> +  if (gcall *call = dyn_cast (call_stmt))
> +  {
> +function *fun = this->get_function();
> +cgraph_edge *e = cgraph_node::get (fun->decl)->get_edge (call);
> +if ((e && e->indirect_info) && (e->indirect_info->polymorphic))
> +unknown_side_effects = false;
> +  }
> +

This seems wrong; surely it depends on what the call is - or am I
missing something?  Is the issue that we're speculating lots of
possibilities as dynamic calls?  If so, would it be better to terminate
the remaining analysis path (if that makes sense), and assume that any
further analysis happens on extra edges added for the speculated calls?

FWIW I've been experimenting with adding "bifurcation" support so that
you can do:
  program_state *other = ctxt->bifurcate ();
and have it split the analysis into states (e.g. for handling realloc,
so that we can split into 3 states: "succeeded", "succeeded but moved",
"failed").  Unfortunately my code for this is a mess (it's a hacked up
prototype).  Should I try to post what I have for this?


[...snip...]


> @@ -3327,9 +3338,44 @@ exploded_graph::process_node (exploded_node *node)
>  region_model *model = state.m_region_model;
>  
>  /* Call is possibly happening via a function pointer.  */
> -if (tree fn_decl = model->get_fndecl_for_call(call,&ctxt))
> -  create_dynamic_call (call, fn_decl, node, next_state,
> -   next_point, &uncertainty);
> +if (tree fn_decl = model->get_fndecl_for_call (call,&ctxt))
> +  create_dynamic_call (call,
> +fn_decl,
> +node,
> +next_state,
> +   next_point,
> +   &uncertainty);
> +else
> +  {
> +/* Call is possibly a polymor

RE: How to detect user uses -masm=intel?

[unlvsur unlvsur via Gcc]

Can we add one??

Sent from Mail for Windows 10

From: Florian Weimer
Sent: Thursday, July 29, 2021 04:39
To: unlvsur unlvsur via Gcc
Cc: Andrew Pinski; unlvsur 
unlvsur
Subject: Re: How to detect user uses -masm=intel?

* unlvsur unlvsur via Gcc:

> What I mean is that what macro GCC sets when it compiles -masm=intel
>
>
> Int main()
> {
> #ifdef /*__INTEL_ASM*/
> printf(“intel”);
> #else
> printf(“at&t”);
> #endif
> }

There doesn't seem to be such a macro:

$ diff -u <(gcc -dM -E -x c /dev/null) <(gcc -masm=intel -dM -E -x c /dev/null)
$

It doesn't look like it's possible to detect this as the GAS level
directly.  So you have to use the alternatives syntax that Andrew
suggested.

Thanks,
Florian