Re: does TARGET_MEM_REF documentation need updating?

[Richard Biener via Gcc]

On Wed, Nov 3, 2021 at 7:26 PM Martin Sebor via Gcc  wrote:
>
> The manual says that the first argument of a TARGET_MEM_REF
>
>"is @code{TMR_SYMBOL} and must be a @code{VAR_DECL} of an object
>with a fixed address."
>
> The TARGET_MEM_REF below has as its first argument an ADDR_EXPR
> and not a VAR_DECL as the manual claims.  The code I looked at
> seems to be prepared for the first argument to be pretty much
> any address, including an SSA_NAME.  What should the manual be
> updated to, to make it accurate?
>
> The description also says:
>
>The second argument is @code{TMR_BASE} and the third one is
>@code{TMR_INDEX}.
>
> and gives the formula below to compute its address:
>
>&TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET
>
> The second argument of my TARGET_MEM_REF is a pointer and not
> something I'd expect to see added to the address of something.
> Is the second argument meant to have a dual purpose like in
> a MEM_REF?

The docs are out of date, I will update them.  Yes, operands zero and one
are exactly like for MEM_REF.  There's two extra offset pieces,
TMR_INDEX * TMR_STEP (operands 2 and 3) and TMR_INDEX2 (operand 3).

As usual tree.def is a better source of information.

>
> Thanks
> Martin
>
>
> type   type  0x7fffe7c0fd20 tree_node>
>  sizes-gimplified public unsigned type_6 DI
>  size 
>  unit-size 
>  align:64 warn_if_not_align:0 symtab:0 alias-set -1
> canonical-type 0x7fffe7c0fdc8
>  pointer_to_this 
> reference_to_this >
>  readonly sizes-gimplified unsigned DI size  0x7fffea7f5f48 64> unit-size 
>  user align:128 warn_if_not_align:0 symtab:0 alias-set -1
> canonical-type 0x7fffe6836dc8>
>  readonly
>  arg:0   type 
>  public unsigned DI size 
> unit-size 
>  align:64 warn_if_not_align:0 symtab:0 alias-set -1
> canonical-type 0x7fffe4b2d540>
>  readonly constant
>  arg:0  0x7fffe6836348>
>  readonly used static tree_1 tree_2 tree_6 read decl_5
> decl_6 BLK /src/gcc/trunk/gcc/c-family/c-common.c:301:26
>  size 
>  unit-size 
>  align:256 warn_if_not_align:0 context
>  initial
>  chain >>
>  arg:1  0x7fffe666a3f0> constant 0>
>  arg:2   type  type_6 DI size  unit-size  0x7fffea7f5f60 8>
>  align:64 warn_if_not_align:0 symtab:0 alias-set -1
> canonical-type 0x7fffea815000 precision:64 min  0x7fffea7f5f78 0> max >
>  visited
>  def_stmt _6 = ivtmp.4177_35 * 16;
>  version:6
>  ptr-info 0x7fffe63de020>>
>

Re: [PATCH] Bump required minimum DejaGnu version to 1.5.3

[Segher Boessenkool]

On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches wrote:
> On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
> Gcc-patches  wrote:
> >
> > From: Bernhard Reutner-Fischer 
> >
> > Bump required DejaGnu version to 1.5.3 (or later).
> > Ok for trunk?
> 
> OK.

If we really want to require such a new version of DejaGnu (most
machines I use have 1.5.1 or older), can we include it with GCC please?


Segher

Re: [PATCH] Bump required minimum DejaGnu version to 1.5.3

[Martin Liška]

On 11/4/21 12:55, Segher Boessenkool wrote:

On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches wrote:

On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
Gcc-patches  wrote:


From: Bernhard Reutner-Fischer 

Bump required DejaGnu version to 1.5.3 (or later).
Ok for trunk?


OK.


If we really want to require such a new version of DejaGnu (most
machines I use have 1.5.1 or older), can we include it with GCC please?


Do you mean in contrib/download_prerequisites?

Note the version 1.5.1 is 8 years old, what legacy system do you use that has 
such
an old version?

Martin




Segher

Re: [PATCH] Bump required minimum DejaGnu version to 1.5.3

[Richard Biener via Gcc]

On Thu, Nov 4, 2021 at 12:57 PM Segher Boessenkool
 wrote:
>
> On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches 
> wrote:
> > On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
> > Gcc-patches  wrote:
> > >
> > > From: Bernhard Reutner-Fischer 
> > >
> > > Bump required DejaGnu version to 1.5.3 (or later).
> > > Ok for trunk?
> >
> > OK.
>
> If we really want to require such a new version of DejaGnu (most
> machines I use have 1.5.1 or older), can we include it with GCC please?

I checked before approving that all regularly supported SLES releases have
1.5.3 or newer (in fact they even have 1.6+).  Only before SLE12 SP2 you
had the chance to run into 1.4.4.  I guess you run into old versions on
big-endian ppc-linux which tend to be quite old if you rely on enterprise OS?

Richard.

>
> Segher

Re: [PATCH] Bump required minimum DejaGnu version to 1.5.3

[Jonathan Wakely via Gcc]

On Thu, 4 Nov 2021 at 12:42, Richard Biener via Gcc  wrote:
>
> On Thu, Nov 4, 2021 at 12:57 PM Segher Boessenkool
>  wrote:
> >
> > On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches 
> > wrote:
> > > On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
> > > Gcc-patches  wrote:
> > > >
> > > > From: Bernhard Reutner-Fischer 
> > > >
> > > > Bump required DejaGnu version to 1.5.3 (or later).
> > > > Ok for trunk?
> > >
> > > OK.
> >
> > If we really want to require such a new version of DejaGnu (most
> > machines I use have 1.5.1 or older), can we include it with GCC please?
>
> I checked before approving that all regularly supported SLES releases have
> 1.5.3 or newer (in fact they even have 1.6+).  Only before SLE12 SP2 you
> had the chance to run into 1.4.4.  I guess you run into old versions on
> big-endian ppc-linux which tend to be quite old if you rely on enterprise OS?

Like most of the ones in the compile farm, which run CentOS 7 and have
1.5.1. I've installed a newer version in /opt/cfarm on most of the
machines that need it.

I'm still in favour of updating the minimum version, because otherwise
we have FAILs for correct tests. The old version is just not good
enough.

Custom Float

[Amit Hmath via Gcc]

Hello All,

I am badly stuck at custom float encode and decode, I humbly request your
assistance.

I am trying to incorporate in custom floats in RISCV-32 elf, I am encoding
and assigning to image at line 2985 in
https://github.com/riscv-collab/riscv-gcc/blob/5964b5cd72721186ea2195a7be8d40cfe6554023/gcc/real.c
I am decoding in line 2989 from const long *buf and assigning values to
lines 3031-3034

// custom logic...
// I removed case statements
r->cl = rvc_normal;
r->sign = sign;
SET_REAL_EXP (r, exp); // I am assigning unbiased exp
r->sig[SIGSZ-1] = image | SIG_MSB;

In my view, encode_ieee_single function send IEEE-754 format float value to
FPU part of RISCV-32 and decode_ieee_single function decode IEEE-754 float
format from FPU part of RISCV-32

But I am getting some different values. In order to debug the the
functions/compiler I assigned some random value to decode function like:

  r->cl = rvc_normal;
  r->sign = 1;
  SET_REAL_EXP (r, 12);
  r->sig[SIGSZ-1] = 0xDADB62D5; 

And built the compiler.

In my view, regardless of custom float values. I should always get real
equivalent above assigned value. But I am not getting this value either; i
seems to me there are other dependency functions which calculate real value
decoded from above function?

I look forward to hearing from you soon.

Many Thanks,

-Amith
ReplyForward

Re: [PATCH] Bump required minimum DejaGnu version to 1.5.3

[Segher Boessenkool]

On Thu, Nov 04, 2021 at 01:22:24PM +0100, Martin Liška wrote:
> On 11/4/21 12:55, Segher Boessenkool wrote:
> >On Fri, Oct 29, 2021 at 09:32:21AM +0200, Richard Biener via Gcc-patches 
> >wrote:
> >>On Fri, Oct 29, 2021 at 2:42 AM Bernhard Reutner-Fischer via
> >>Gcc-patches  wrote:
> >>>
> >>>From: Bernhard Reutner-Fischer 
> >>>
> >>>Bump required DejaGnu version to 1.5.3 (or later).
> >>>Ok for trunk?
> >>
> >>OK.
> >
> >If we really want to require such a new version of DejaGnu (most
> >machines I use have 1.5.1 or older), can we include it with GCC please?
> 
> Do you mean in contrib/download_prerequisites?

I was thinking as actual code, so we can make modifications where we
need to / want to as well.  But your idea is much less contentious :-)

> Note the version 1.5.1 is 8 years old, what legacy system do you use that 
> has such
> an old version?

CentOS 7.  Some of those systems cannot run CentOS 8.  And CentOS 8 will
reach EoL in less than two months, and CentOS Stream is not an option at
all (and even if it were, it cannot work on many of the machines).

Everything else on CentOS 7 is supported by GCC (it is the oldest
supported for pretty much everything, but still).  It would be bad for
DejaGnu to be the limiting factor :-/


Segher

gcc-9-20211104 is now available

[GCC Administrator via Gcc]

Snapshot gcc-9-20211104 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20211104/
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 321ce15186ae15738074753d0e366a58900a304e

You'll find:

 gcc-9-20211104.tar.xzComplete GCC

  SHA256=6282d73e27b15db424bf25cfb620d55b5c1be74a47d8596836ec03262650b504
  SHA1=fe0515f3158b5a4cb274f024519ca02967ac37e5

Diffs from 9-20211028 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.

gcc's error description for missing MACRO arguments is wrong.

[Roy Qu via Gcc]

Version: GCC 11.2 (msys2 mingw-w64 X86_64)
When a macro have more than one arguments, and u call it with no argument,
gcc will compliant with " only 1 given" instead of " 0 given"

Demo code:

#define TEST(x,y) test(x,y)
int main() {
int x=TEST();
}:

Error message:
F:/test.cpp:4:20: error: macro "TEST" requires *2* arguments, but only *1*
given

4 | int x=TEST();

| ^