Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 15, 2015 7:39:39 PM GMT+02:00, Mike Stump  
wrote:
>On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
>>> Maybe GCC-6 can bump the required
>>> dejagnu version to allow for getting rid of all these superfluous
>>> load_gcc_lib? *blink* :)
>> I'd support that as a direction.
>> 
>> Certainly dropping the 2001 version from our website in favor of 1.5
>(which is what I'm using anyway) would be a step forward.
>
>So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
>1.5.  I don’t know of any reason to not update and just require 1.5 at
>this point.  I’m not a fan of feature chasing dejagnu, but an update
>every 2-4 years isn’t unreasonable.
>
>So, let’s do it this way…  Any serious and compelling reason to not
>update to 1.5?  If none, let’s update to 1.5 in another week or two, if
>no serious and compelling reasons not to.
>
>My general plan is, slow cycle updates on dejagnu, maybe every 2 years.
>LTS style releases should have the version in it before the requirement
>is updated.  I take this approach as I think this should be the maximal
>change rate of things like make, gcc, g++, ld, if possible.

Yea, although this means that 1.5.3 (a Version with the libdirs tweak) being 
just 5 months old will have to wait another bump, I fear. For my part going to 
plain 1.5 is useless WRT the load_lib situation. I see no value in 
conditionalizing simplified libdir handling on a lucky user with recentish 
stuff so i'm just waiting another 2 or 4 years for this very minor cleanup.

Cheers,

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 15, 2015 10:05:27 PM GMT+02:00, Jeff Law  wrote:
>On 09/15/2015 01:21 PM, David Malcolm wrote:
>> On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:
>>> On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
> Maybe GCC-6 can bump the required
> dejagnu version to allow for getting rid of all these superfluous
> load_gcc_lib? *blink* :)
 I'd support that as a direction.

 Certainly dropping the 2001 version from our website in favor of
>1.5
>>> (which is what I'm using anyway) would be a step forward.
>>>
>>> So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
>>> 1.5.  I don’t know of any reason to not update and just require 1.5
>at
>>> this point.  I’m not a fan of feature chasing dejagnu, but an update
>>> every 2-4 years isn’t unreasonable.
>>
>> FWIW, I believe RHEL 6 is at dejagnu-1.4.4   I don't know whether or
>not
>> that's an issue here.
>I'd consider it a non-issue.  Folks that want to do GCC development on 
>RHEL 6 are probably few and far between and can probably update dejagnu
>
>if need be ;-)
>
>If ubuntu, fedora, debian current releases were stuck at 1.4, then it'd
>
>be a bigger issue.

Debian sid has 1.5.3 fwiw, so I assume Debian 9 will have that too. Not sure if 
we can get it into Debian 8, I'm not intimately familiar with the policy. If 
OTOH GCC-6 requires it then that's probably a strong argument to let it bubble 
down to Debian 8 if need be.
Widespread other buildsystems should pose no problem, dunno about the big 
non-debian distros in this respect.

Thanks,

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 16, 2015 7:57:03 PM GMT+02:00, Mike Stump  
wrote:
>On Sep 16, 2015, at 9:25 AM, Ramana Radhakrishnan
> wrote:
>> 
>> Sorry about the obvious (possibly dumb) question.
>
>> Can't we just import a copy of dejagnu each year and install it as
>part of the source tree?
>
>TL;DR: No.
>
>We could, and indeed, some people do engineering that way.  We instead
>depend upon package managers, software updates and backwards
>compatibility to manage the issue.  This is generally speaking, a
>better way to do software. In the olden days, back before shared
>libraries, X11 was the straw that broke the camels back. 

[Well some thus later had KGI, GGI and fresco (the interviews thing), but 
that's another story for sure ;) ]

Either way. Importing doesn't make sense at all.

Establishing and maintaining duplicated gcc_load_lib cascades don't either IMO. 
If folks feel maintaining them is less hazzle than forcing a new dejagnu then 
fine with me (although we do require pretty recent libs anyway and developers 
will usually likewise use rather recent binutils et al for obvious reasons).

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On September 16, 2015 7:39:42 PM GMT+02:00, David Malcolm  
wrote:
>On Wed, 2015-09-16 at 10:36 -0600, Jeff Law wrote:
>> On 09/16/2015 10:25 AM, Ramana Radhakrishnan wrote:
>> >
>> >
>> > On 16/09/15 17:14, Mike Stump wrote:
>> >> On Sep 16, 2015, at 12:29 AM, Andreas Schwab 
>> >> wrote:
>> >>> Mike Stump  writes:
>> >>>
>>  The software presently works with 1.4.4 and there aren’t any
>>  changes that require anything newer.
>> >>>
>> >>> SLES 12 has 1.4.4.
>> >>
>> >> Would be nice to cover them as well, but their update schedule,
>3-4
>> >> years, means that their next update is 2018.  They didn’t update
>to
>> >> a 3 year old stable release of dejagnu for their last OS, meaning
>> >> they are on a > 7 year update cycle.  I love embedded and really
>> >> long term support cycles (20 years), but, don’t think we should
>> >> cater to the 20 year cycle just yet.  :-)  Since 7 is
>substantially
>> >> longer than 2, I don’t think we should worry about it.  If they
>had
>> >> updated at the time, they would have had 3 years of engineering
>and
>> >> testing before the release and _had_ 1.5.
>> >>
>> >
>> > Sorry about the obvious (possibly dumb) question.
>> >
>> > Can't we just import a copy of dejagnu each year and install it as
>> > part of the source tree ? I can't imagine installing dejagnu is
>> > adding a huge amount of time to build and regression test time ?
>> > Advantage is that everyone is guaranteed to be on the same version.
>I
>> > fully expect resistance due to specific issues with specific
>versions
>> > of tcl and expect, but if folks aren't aware of this .
>> That should work -- certainly that's the way we used to do things at 
>> Cygnus.  Some of that code may have bitrotted as single tree builds
>have 
>> fallen out-of-favor through the years.
>> 
>> As to whether or  not its a good idea.  I'm torn -- I don't like
>copying 
>> code from other repos because of the long term maintenance concerns.
>> 
>> I'd rather just move to 1.5 and get on with things. 
>
>AIUI, we specifically need >= 1.5.3 (or a version with a backport) to
>get support for multiple load_lib paths mentioned by Bernhard, which is
>what motivated this thread (on gcc-patches, before it spread to the gcc
>list):
> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01196.html
> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00983.html

And
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01395.html

Where Joseph said he'd wait some more.. I had thought I asked longer ago than 
that, time flies if one has fun.

I'd just require 1.5.3 just to avoid the time needed by folks to workaround 
those silly ordering gotchas and load cascades that propagate through the tree. 
Admittedly not my call but a pity IMHO.

Thanks,

stack_pointer_delta related ICE in libgcc on 4.9.1

[Bernhard Reutner-Fischer]

Trying to bootstrap m68k i hit an assert in emit_library_call_value_1
that wants to assure that the stack is aligned properly.

PUSH_ROUNDING(GET_MODE_SIZE(QImode)) for m5206 is currently 1 so
the testcase below has stack_pointer_delta = 1 + 1 + 4
but emit_library_call_value_1() has this:

  /* Stack must be properly aligned now.  */
  gcc_assert (!(stack_pointer_delta
& (PREFERRED_STACK_BOUNDARY / BITS_PER_UNIT - 1)));

where 6 & 3 != 0 and ICEs

I am not familier with m68k so i would be glad for any help!

Should the arg be partial? Doesn't look like, no.
Does m68k use stack save area? From the looks it doesn't.
Is the alignment_pad for QImode arg wrong?
Should PUSH_ROUNDING be changed back to the !CF variant?
Or is the alignment assert too strict?
Perhaps m5206 is not TARGET_CAS and should not compile this linux-atomic
in the first place?

(is emit_library_call_value_1 missing a do_pending_stack_adjust() before
NO_DEFER_POP ? Does not seem relevant for this case though)

Slightly simplified reproducer:

$ cat x.i ; echo "EOF"; # see libgcc/config/m68k/linux-atomic.c
unsigned char
  __attribute__ ((visibility ("hidden")))
__sync_val_compare_and_swap_1 (unsigned char *ptr, unsigned char soldval,
   unsigned char snewval)
{
  unsigned *wordptr = (unsigned *) ((unsigned long) ptr & ~3);
  unsigned int mask, shift, woldval, wnewval;
  unsigned oldval, newval, cmpval;
  shift = (((unsigned long) ptr & 3) << 3) ^ 24;
  mask = 0xffu << shift;
  woldval = (soldval & 0xffu) << shift;
  wnewval = (snewval & 0xffu) << shift;
  cmpval = *wordptr;
  do
{
  oldval = cmpval;
  if ((oldval & mask) != woldval)
break;
  newval = (oldval & ~mask) | wnewval;
  {
register unsigned *a0 asm ("a0") = wordptr;
register unsigned d2 asm ("d2") = oldval;
register unsigned d1 asm ("d1") = newval;
register unsigned d0 asm ("d0") = 335;
asm volatile ("trap #0":"=r" (d0), "=r" (d1), "=r" (a0):"r" (d0),
  "r" (d1), "r" (d2), "r" (a0):"memory", "a1");
cmpval = d0;
  }
}
  while (__builtin_expect (oldval != cmpval, 0));
  return (oldval >> shift) & 0xffu;
}

_Bool
  __attribute__ ((visibility ("hidden")))
__sync_bool_compare_and_swap_1 (unsigned char *ptr, unsigned char oldval,
unsigned char newval)
{
  return (__sync_val_compare_and_swap_1 (ptr, oldval, newval) == oldval);
}
EOF


/home/me/src/oe/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/m68k-oe-linux.gcc-cross-initial-m68k/m68k-oe-linux-gcc
  -mcpu=5206 
--sysroot=/home/me/src/oe/openembedded-core/build/tmp-glibc/sysroots/qemum68k 
-O2 -pipe -g -feliminate-unused-debug-types -O2  -g -Os -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  
-isystem ./include   -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc 
-fno-stack-protector -Dinhibit_libc  -fPIC -I. -I. 
-I/home/me/src/oe/openembedded-core/build/tmp-glibc/work/m5206-oe-linux/libgcc-initial/4.9.1-r0/gcc-4.9.1/build.m68k-oe-linux.m68k-oe-linux/m68k-oe-linux/libgcc/../.././gcc
 
-I/home/me/src/oe/openembedded-core/build/tmp-glibc/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc
 
-I/home/me/src/oe/openembedded-core/build/tmp-glibc/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/.
 
-I/home/me/src/oe/openembedded-core/build/tmp-glibc/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/../gcc
 
-I/home/me/src/oe/openembedded-core/build/tmp-glibc/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/../include
  -DHAVE_CC_TLS  -o o.o -MT linux-atomic.i -MD -MP -MF linux-atomic.dep  -c x.i 
-fvisibility=hidden -DHIDE_EXPORTS -v
Using built-in specs.
COLLECT_GCC=/home/me/src/oe/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/m68k-oe-linux.gcc-cross-initial-m68k/m68k-oe-linux-gcc
Target: m68k-oe-linux
Configured with: 
/home/me/src/oe/openembedded-core/build/tmp-glibc/work-shared/gcc-4.9.1-r0/gcc-4.9.1/configure
 --build=x86_64-linux --host=x86_64-linux --target=m68k-oe-linux 
--prefix=/home/me/src/oe/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr
 
--exec_prefix=/home/me/src/oe/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr
 
--bindir=/home/me/src/oe/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/m68k-oe-linux.gcc-cross-initial-m68k
 
--sbindir=/home/me/src/oe/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr/bin/m68k-oe-linux.gcc-cross-initial-m68k
 
--libexecdir=/home/me/src/oe/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr/libexec/m68k-oe-linux.gcc-cross-initial-m68k
 
--datadir=/home/me/src/oe/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/usr/share
 
--sysconfdir=/home/me/src/oe/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/etc
 
--sharedstatedir=/home/me/src/oe/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/com
 
--localstatedir=/home/me/src/oe/openembedded-core/buil

Re: [PATCH] gcc parallel make check

[Bernhard Reutner-Fischer]

On 11 September 2014 20:19:31 Jakub Jelinek  wrote:


On Thu, Sep 11, 2014 at 07:26:37PM +0200, Jakub Jelinek wrote:
> right now.  The patch below intends to serialize the content of the
> problematic *.exp tests (the first runtest to reach one of those will simply
> run all the tests from that *.exp file, others will skip it).

Forgotten patch below.  BTW, something will probably need to be done about
acats too, either similar approach or just splitting the chapters into
little more jobs, because otherwise in make -C check -j48 acats dominated
the testing time for me.



+   if [ -n "$(check_p_subno)" \
+-a -n "$$GCC_RUNTEST_PARALLELIZE_DIR" \
+-a -f $(TESTSUITEDIR)/$(check_p_tool)-parallel/finished ]; then \

test(1) -a and -o are obsolescent, please chain [] && [] instead.

Thanks -a cheers ;)


Sent with AquaMail for Android
http://www.aqua-mail.com

Re: [PATCH] gcc parallel make check

[Bernhard Reutner-Fischer]

On 12 September 2014 19:46:33 Mike Stump  wrote:


On Sep 12, 2014, at 9:32 AM, Jakub Jelinek  wrote:
> Here is my latest version of the patch.
>
> With this patch I get identical test_summary output on make -k check
> (completely serial testing) and make -j48 -k check from toplevel directory.
>
> Major changes since last version:
> 1) I've changed the granularity, now it does O_EXCL|O_CREAT attempt
>   only every 10th runtest_file_p invocation

So, I’d love to see the numbers for 5 and 20 to double check that 10 is the 
right number to pick.  This sort of refinement is trivial post checkin.


> 3) various other *.exp fails didn't use runtest_file_p, especially the
>   gcc.misc-tests/ ones, tweaked those like struct-layout-1.exp or
>   plugin.exp so that only the first runtest instance to encounter those
>   runs all of the *.exp file serially

> Regtested on x86_64-linux, ok for trunk?

Ok.  Please be around after you apply it to try and sort out any major fallout.


Usage of $(or) and $(and) will bump GNU make prerequisite version from our 
current 3.80 to at least 3.82 (IIRC).


PS: for the numbers I had used addsuffix  rather than patsubst in the hopes 
that it avoids lots of regexp calls. Very minor not though.


Cheers,


If someone can check their target post checkin (or help out pre-checkin) 
and report back, that would be nice.  Times before and post checkin with 
core count -j setting would be nice.


I wonder if the libstdc++ problems can be sorted out merely by finding a 
way to sort them so the expensive ones come early (regexp -> 0regexp for 
example).  Or, instead of sorting them by name, sort them by some other key 
(md5 per line).  The idea then would be that the chance of all regexp tests 
being in one group is 0.




Sent with AquaMail for Android
http://www.aqua-mail.com

Re: [PATCH] gcc parallel make check

[Bernhard Reutner-Fischer]

On 13 September 2014 02:04:51 Jakub Jelinek  wrote:


On Fri, Sep 12, 2014 at 04:42:25PM -0700, Mike Stump wrote:
> curious, when I run atomic.exp=stdatom\*.c:
>
>   gcc.dg/atomic/atomic.exp completed in 30 seconds.
>
> atomic.exp=c\*.c takes 522 seconds with 3, 2, 5 and 4 being the worst 
offenders.


That's the
@if [ -z "$(filter-out --target_board=%,$(filter-out 
--extra_opts%,$(RUNTESTFLAGS)))" ] \

&& [ "$(filter -j, $(MFLAGS))" = "-j" ]; then \
i.e. if you specify anything in RUNTESTFLAGS other than --target_board= or
--extra_opts, it is not parallelized.  This was done previously because
parallelization required setting the flags to something different (manually
created *.exp list).  The first [] could


Yes, this is very inconvenient, especially in the light of -v in the 
runtestflags which should certainly not prohibit parallel execution.

See https://gcc.gnu.org/ml/gcc-patches/2013-11/msg00997.html
for how I would fix that.. (findstring empty instead of filter-out).

TIA,

perhaps be removed now, if one e.g.

RUNTESTFLAGS=atomic.exp etc. with sufficiently enough tests, parallelization
will be still worth it.  I've been worried about the quick cases where
parallelization is not beneficial, like make check-gcc \
RUNTESTFLAGS=dg.exp=pr60123.c or similar, but one doesn't usually pass -jN
in that case.  So yes, the
[ -z "$(filter-out --target_board=%,$(filter-out 
--extra_opts%,$(RUNTESTFLAGS)))" ]

can be dropped (not in libstdc++ though, there are abi.exp and
prettyprinters.exp still run serially, though even that could be handled the
struct-layout-1.exp way, of running it by the first instance to encounter
those with small changes in those *.exp files).

Jakub




Sent with AquaMail for Android
http://www.aqua-mail.com

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On Tue, Sep 15, 2015 at 10:50:12PM +0200, Bernhard Reutner-Fischer wrote:
> On September 15, 2015 10:05:27 PM GMT+02:00, Jeff Law  wrote:
> >On 09/15/2015 01:21 PM, David Malcolm wrote:
> >> On Tue, 2015-09-15 at 10:39 -0700, Mike Stump wrote:
> >>> On Sep 14, 2015, at 3:37 PM, Jeff Law  wrote:
> >>>>> Maybe GCC-6 can bump the required
> >>>>> dejagnu version to allow for getting rid of all these superfluous
> >>>>> load_gcc_lib? *blink* :)
> >>>> I'd support that as a direction.
> >>>>
> >>>> Certainly dropping the 2001 version from our website in favor of
> >1.5
> >>> (which is what I'm using anyway) would be a step forward.
> >>>
> >>> So, even ubuntu LTS is 1.5 now.  No harm in upgrading the website to
> >>> 1.5.  I don’t know of any reason to not update and just require 1.5
> >at
> >>> this point.  I’m not a fan of feature chasing dejagnu, but an update
> >>> every 2-4 years isn’t unreasonable.
> >>
> >> FWIW, I believe RHEL 6 is at dejagnu-1.4.4   I don't know whether or
> >not
> >> that's an issue here.
> >I'd consider it a non-issue.  Folks that want to do GCC development on 
> >RHEL 6 are probably few and far between and can probably update dejagnu
> >
> >if need be ;-)
> >
> >If ubuntu, fedora, debian current releases were stuck at 1.4, then it'd
> >
> >be a bigger issue.
> 
> Debian sid has 1.5.3 fwiw, so I assume Debian 9 will have that too. Not sure 
> if we can get it into Debian 8, I'm not intimately familiar with the policy. 
> If OTOH GCC-6 requires it then that's probably a strong argument to let it 
> bubble down to Debian 8 if need be.

So Debian 9 will have dejagnu-1.6.

(Ubuntu 16.10 allegedly has 1.6 too)

I guess neither redhat
(https://access.redhat.com/downloads/content/dejagnu/ redirects to a
login page but there seem to be 1.5.1 packages) nor SuSE did update dejagnu in 
the meantime.

Someone should poke gentoo to bump their dejagnu-1.5 to current -1.6

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On 16 May 2017 11:54:18 CEST, Jonathan Wakely  wrote:
>On 13 May 2017 at 11:38, Jakub Jelinek wrote:
>> On Sat, May 13, 2017 at 12:24:12PM +0200, Bernhard Reutner-Fischer
>wrote:
>>> I guess neither redhat
>>> (https://access.redhat.com/downloads/content/dejagnu/ redirects to a
>>> login page but there seem to be 1.5.1 packages) nor SuSE did update
>dejagnu in the meantime.
>>
>> Fedora has dejagnu-1.6 in Fedora 25 and later, dejagnu-1.5.3 in
>Fedora 24, older
>> Fedora versions are EOL.  RHEL 7 has dejagnu-1.5.1, RHEL 6 as well as
>RHEL 5 has
>> dejagnu-1.4.4, older RHEL versions are EOL.
>
>FWIW 1.5.3 has a fix which I rely on for libstdc++ testing, but since
>newer versions are trivial to install by hand I'll be OK if we only
>bump the minimum to 1.5.0

1.5.0 wouldn't buy us anything as the "libdirs" handling is only in 1.5.2 and 
later.

thanks

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On 16 May 2017 at 14:16, Jonathan Wakely  wrote:
> On 16 May 2017 at 13:13, Bernhard Reutner-Fischer wrote:
>> 1.5.0 wouldn't buy us anything as the "libdirs" handling is only in 1.5.2 
>> and later.
>
> Ah I missed that in the earlier discussion.
>
> The change I care about in 1.5.3 is
> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347

the libdirs handling is
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5481f29161477520c691d525653323b82fa47ad7
and applies cleanly to everything 1.5.x-ish. Didn't try if it applies to 1.4.4.

thanks,

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On Tue, 16 May 2017 at 21:08, Mike Stump  wrote:
>
> On May 16, 2017, at 5:16 AM, Jonathan Wakely  wrote:
> > The change I care about in 1.5.3
>
> So, we haven't talked much about the version people want most.  If we update, 
> might as well get something that more people care about.  1.5.3 is in ubuntu 
> LTS 16.04 and Fedora 24, so it's been around awhile.  SUSU is said to be 
> using 1.6, in the post 1.4.4 systems.  People stated they want 1.5.2 and 
> 1.5.3, so, I'm inclined to say, let's shoot for 1.5.3 when we do update.
>
> As for the machines in the FSF compile farm, nah, tail wagging the dog.  I'd 
> rather just update the requirement, and the owners or users of those machines 
> can install a new dejagnu, if they are using one that is too old and they 
> want to support testing gcc.

So.. let me ping that, again, now that another year has passed :)

PS: Recap: https://gcc.gnu.org/ml/fortran/2012-03/msg00094.html was
later applied as
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5481f29161477520c691d525653323b82fa47ad7
and was part of the dejagnu-1.5.2 release from 2015. Jonathan requires
1.5.3 for libstdc++ testing.
The libdirs fix would allow us to remove the 150 occurrences of the
load_gcc_lib hack, refer to the patch to the fortran list back then.
AFAIR this is still not fixed: +# BUG: gcc-dg calls
gcc-set-multilib-library-path but does not load gcc-defs!

debian-stable (i think 9 ATM), Ubuntu LTS ship versions recent enough
to contain both fixes. Commercial distros seem to ship fixed versions,
too.

thanks,

Re: dejagnu version update?

[Bernhard Reutner-Fischer]

On 7 August 2018 18:34:30 CEST, Segher Boessenkool  
wrote:
>On Mon, Aug 06, 2018 at 08:25:49AM -0700, Mike Stump wrote:
>> Since g++ already requires 1.5.3, it make no sense to bump to
>anything older that 1.5.3, so let's bump to 1.5.3.  Those packaging
>systems and OSes that wanted to update by now, have had their chance to
>update.  Those that punt until we bump the requirement, well, they will
>now have to bump.  :-)
>
>"g++ requires it"?  In what way?  I haven't seen any issues with older
>dejagnu versions.

I think 
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347

>
>> Ok to update to 1.5.3.
>
>1.5.3 is only three years old, and not all distros carry it.  This is
>rather aggressive...

How come?
If one wants to develop on a distro that is notoriously outdated then you have 
to obtain the missing pieces yourself. I wouldn't call three years "aggressive".

[PATCH, RFC] plugin to warn about surplus includes

[Bernhard Reutner-Fischer]

Hi,

A couple of days ago i was asking:
does any frontend support some sort of noting that a user-header was
included but no decl of it was ever referenced (i.e. superfluous
#include) ?

I could not find an appropriate tool to diagnose them, so i was thinking
about a gcc plugin to do that.

Would some plugin like the attached be suitable to put into svn if
cleaned up a bit?
If so, where would they live?

Observations while thinking about all this:
- libcpp does not record LC_PSEUDO_ENTER (or something like that),
  so pristine libcpp cannot detect duplicate includes, like iostream
  in attached sample input.cc
- should figure out how to print a help-text for the plugin
  Hints?
- should handle structs.

Thanks in advance for hints on the help-text printing or comments about
the overall idea of such a facility.
/* Dump superfluous, missing or duplicate includes.
 *
 * Copyright (C) 2010 Bernhard Reutner-Fischer
*/
/*
This file is part of GCC.

GCC is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 3, or (at your option) any later
version.

GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING3.  If not see
<http://www.gnu.org/licenses/>.  */

#include "config.h"
#include "system.h"
#include "gcc-plugin.h"
#include "coretypes.h"
#include "tree.h"
#include "tree-iterator.h"
#include "tree-pass.h"
#include "intl.h"
#include "line-map.h"
#include "langhooks.h"
#include "target.h"
#include "toplev.h" /* warning_at */

//#define info warning
#define info(...) /**/

typedef struct include_t {
struct include_t *next;
const char *filename;
source_location location;
} include_t;
static include_t *incs = NULL, *referenced = NULL;

static bool warn_missing;
static bool warn_surplus;

/* Add filename to the end of the include list.  */
static void __attribute__ ((__nonnull__ (2)))
add_include (include_t **head, const char *filename, const source_location loc,
const bool mainfile)
{
  include_t *tail, *elt;

  if (filename == NULL)
gcc_unreachable ();
  tail = *head;
  while (1)
{
  if (tail && strcmp (tail->filename, filename) == 0)
	{
	  const bool old_warn_system_headers = warn_system_headers;

	  warn_system_headers = 1; /* to please warning_at */
	  if (tail->location != loc && mainfile && warn_surplus)
	warning_at (loc, 0, "Duplicate include %s", filename);
	  warn_system_headers = old_warn_system_headers;
	  return; /* don't enter duplicate */
	}
  if (tail && tail->next)
	tail = tail->next;
  else
	break;
}
  info (0, "ADDING %s", filename);
  elt = XNEW (include_t);
  elt->filename = filename;
  elt->location = loc;
  elt->next = NULL;
  if (tail)
tail->next = elt;
  else
*head = elt;
}

/* Remove filename from the include list.  */
static void __attribute__ ((__nonnull__ (2)))
remove_include (include_t **head, const char *filename)
{
  bool seen;

  if (filename == NULL)
gcc_unreachable ();
  seen = false;
  while (*head)
{
  if (strcmp ((*head)->filename, filename) == 0)
	{
	  include_t *delete = *head;

	  info (0, "REMOVE %s", filename);
	  *head = (*head)->next;
	  XDELETE (delete);
	  seen = true;
	  break;
	}
  head = &(*head)->next;
}
  if (!seen && warn_missing)
warning (0, "Missing include %s", filename);
}

/* Callback function to invoke after GCC finishes parsing a struct.  */

void
handle_struct (void *event_data, void *user_data)
{
  tree type = (tree) event_data;
  if (type == error_mark_node)
	  return;
  warning (0, G_("Process struct %s"),
   IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type;
}

static void
fn_add_includes (tree fndecl, const bool mainfile)
{
  tree decl, type;
  const struct line_map *map;

  map = linemap_lookup (line_table, DECL_SOURCE_LOCATION (fndecl));
  if (!MAIN_FILE_P (map))
{
  source_location loc = DECL_SOURCE_LOCATION (fndecl);
  info (0,"fn %s: %s", lang_hooks.decl_printable_name (fndecl, 3), LOCATION_FILE (DECL_SOURCE_LOCATION (fndecl)));
  add_include (&referenced, LOCATION_FILE (loc), loc, mainfile);
}
  for (decl = DECL_ARGUMENTS (fndecl); decl; decl = TREE_CHAIN (decl))
{
  map = linemap_lookup (line_table, DECL_SOURCE_LOCATION (decl));
  if (!MAIN_FILE_P (map))
	{
	  source_location loc = DECL_SOURCE_LOCATION (decl);
	  info (0,"fn arg %s: %s", lang_hooks.decl_print

Re: [PATCH, RFC] plugin to warn about surplus includes

[Bernhard Reutner-Fischer]

On Tue, May 18, 2010 at 06:53:18PM -0500, Joel Sherrill wrote:

>Would there be a way to exclude specific files?  Say something like
>config.h that by convention you might want every file to include?

Adding a
-fplugin-arg-warn_include-exclude-from=
should be doable, sure.

cheers,

v2: plugin to warn about surplus includes

[Bernhard Reutner-Fischer]

On Tue, May 18, 2010 at 11:05:46PM +0200, Bernhard Reutner-Fischer wrote:
>Hi,

>Observations while thinking about all this:
[]
>- should figure out how to print a help-text for the plugin
>  Hints?
>- should handle structs.

updated variant that handles functions a little bit better.
/* Dump superfluous, missing or duplicate includes.
 *
 * Copyright (C) 2010 Bernhard Reutner-Fischer
*/
/*
This file is part of GCC.

GCC is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 3, or (at your option) any later
version.

GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING3.  If not see
<http://www.gnu.org/licenses/>.  */

#include "config.h"
#include "system.h"
#include "gcc-plugin.h"
#include "coretypes.h"
#include "tree.h"
#include "tree-iterator.h"
#include "tree-pass.h"
#include "intl.h"
#include "line-map.h"
#include "langhooks.h"
#include "target.h"
#include "toplev.h" /* warning_at */

/* #define info warning */
#define info(...) /**/

typedef struct include_t {
struct include_t *next;
const char *filename;
source_location location;
} include_t;
static include_t *incs = NULL, *referenced = NULL;

static bool warn_missing;
static bool warn_surplus;

/* Add filename to the end of the include list.  */
static void __attribute__ ((__nonnull__ (2)))
add_include (include_t **head, const char *filename, const source_location loc,
const bool mainfile)
{
  include_t *tail, *elt;

  if (filename == NULL)
gcc_unreachable ();
  tail = *head;
  while (1)
{
  if (tail && strcmp (tail->filename, filename) == 0)
	{
	  const bool old_warn_system_headers = warn_system_headers;

	  warn_system_headers = 1; /* to please warning_at */
	  if (tail->location != loc && mainfile && warn_surplus)
	warning_at (loc, 0, "Duplicate include %s", filename);
	  warn_system_headers = old_warn_system_headers;
	  return; /* don't enter duplicate */
	}
  if (tail && tail->next)
	tail = tail->next;
  else
	break;
}
  info (0, "ADDING %s", filename);
  elt = XNEW (include_t);
  elt->filename = filename;
  elt->location = loc;
  elt->next = NULL;
  if (tail)
tail->next = elt;
  else
*head = elt;
}

/* Remove filename from the include list.  */
static void __attribute__ ((__nonnull__ (2)))
remove_include (include_t **head, const char *filename)
{
  bool seen;

  if (filename == NULL)
gcc_unreachable ();
  seen = false;
  while (*head)
{
  if (strcmp ((*head)->filename, filename) == 0)
	{
	  include_t *delete = *head;

	  info (0, "REMOVE %s", filename);
	  *head = (*head)->next;
	  XDELETE (delete);
	  seen = true;
	  break;
	}
  head = &(*head)->next;
}
  if (!seen && warn_missing)
warning (0, "Missing include %s", filename);
}

static void debug_location (location_t l)
{
  fprintf (stderr, "LOCATION_FILE=%s\n", LOCATION_FILE (l));
}


static void fn_add_includes (tree, const bool);
static void operands_add_includes (tree, location_t, const bool);


/* Callback function to invoke after GCC finishes parsing a struct.  */

void
handle_struct (void *event_data, void *user_data)
{
  const bool old_warn_system_headers = warn_system_headers;
  tree type = (tree) event_data;
  const struct line_map *map;
  location_t loc;

  if (type == error_mark_node)
	  return;
  warn_system_headers = 1;

  loc = DECL_NAME (TYPE_NAME (type))->decl_minimal.locus;
  map = linemap_lookup (line_table, loc);
  if (!MAIN_FILE_P (map))
{
  info (0, G_("Process struct %s"),
	   IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (type;
}
  warn_system_headers = old_warn_system_headers;
}

static void
fn_add_includes (tree fndecl, const bool mainfile)
{
  tree decl;
  const struct line_map *map;
  source_location loc = DECL_SOURCE_LOCATION (fndecl);

  map = linemap_lookup (line_table, loc);
  if (!MAIN_FILE_P (map))
{
  info (0,"fn %s: %s", lang_hooks.decl_printable_name (fndecl, 3), LOCATION_FILE (loc));
  add_include (&referenced, LOCATION_FILE (loc), loc, mainfile);
}
  else
operands_add_includes (DECL_SAVED_TREE (fndecl), loc, true);
  for (decl = DECL_ARGUMENTS (fndecl); decl; decl = TREE_CHAIN (decl))
{
  map = linemap_lookup (line_table, DECL_SOURCE_LOCATION (decl));
  if (!MAIN_FILE_P (map))
	{
	  source_location aloc = DECL_SOURCE_LOCATION (decl);
	  info (0,"

[testsuite] darwin leftover .dSYM dirs in the testsuite ?

[Bernhard Reutner-Fischer]

Hi,

  blindvt: BTW since you have looked at this piece of code, you 
may give me some advice:
  on darwin* all the tests compiled with -g generate *.dSYM 
folders. I'ld like to clean them.

Perhaps something like the attached? I find it a bit difficult to fit
that into the testsuite properly, so this is not a patch proposal.

Rainer, Mike, can you please advise on how we could do this properly?

TIA && cheers,
Not a patch!

diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 4666ede..7c704fc 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -425,6 +425,36 @@ proc remove-build-file { pat } {
 }
 }
 
+# Remove files matching the pattern from the build machine.
+# Same as remove-build-file except that it can delete directories, too..
+# AFAICS this would need fixing in dejagnu which explicitly checks
+# isfile, pity.
+proc remove-build-dir { pat } {
+rename standard_file saved-standard_file
+proc standard_file { dest op args } {
+set file [lindex $args 0]
+verbose "dest in proc repaired-standard_file is $dest" 3
+if { ![is_remote $dest] } {
+if ![string compare $op "delete"] { # "deletedir" ?
+		file delete -force -- $args
+	}
+} else {
+saved-standard_file $dest $op $args
+}
+}
+verbose "remove-build-dir `$pat'" 2
+set file_list "[glob -nocomplain $pat]"
+verbose "remove-build-dir `$file_list'" 2
+foreach output_file $file_list {
+	if [is_remote host] {
+	# Ensure the host knows the file is gone by deleting there
+	# first.
+	remote_file host delete $output_file
+	}
+	remote_file build delete $output_file
+}
+}
+
 # Remove runtime-generated profile file for the current test.
 proc cleanup-profile-file { } {
 remove-build-file "mon.out"
diff --git a/gcc/testsuite/lib/gcc.exp b/gcc/testsuite/lib/gcc.exp
index bb1763a..86996d4 100644
--- a/gcc/testsuite/lib/gcc.exp
+++ b/gcc/testsuite/lib/gcc.exp
@@ -127,7 +127,7 @@ proc gcc_target_compile { source dest type options } {
 global GCC_UNDER_TEST
 global TOOL_OPTIONS
 global TEST_ALWAYS_FLAGS
-	
+
 if {[target_info needs_status_wrapper] != "" && \
 	[target_info needs_status_wrapper] != "0" && \
 	[info exists gluefile] } {
@@ -161,5 +161,20 @@ proc gcc_target_compile { source dest type options } {
 lappend options "timeout=[timeout_value]"
 lappend options "compiler=$GCC_UNDER_TEST"
 set options [dg-additional-files-options $options $source]
+
+if [istarget *-*-darwin*] {
+# on darwin, files compiled with -g leave a .dSYM dir behind, nuke it
+# ??? probably additional_clean_{dir,file}s or the like?
+if {[lsearch -regexp $options "\[ \t=\]\-g"] >= 0} {
+upvar 2 dg-final-code finalcode
+if ![info exists finalcode] {
+upvar 3 dg-final-code finalcode
+}
+
+set dsym "[file rootname [file tail $dest]].dSYM"
+set finalcode [concat $finalcode "remove-build-dir $dsym{/\*,}\n"]
+}
+}
+
 return [target_compile $source $dest $type $options]
 }

Re: RFC: Sphinx for GCC documentation

[Bernhard Reutner-Fischer via Gcc]

On Mon, 7 Jun 2021 15:30:22 +0200
Martin Liška  wrote:

> Anyway, this is resolved as I use more appropriate directive:
> https://splichal.eu/scripts/sphinx/gfortran/_build/html/intrinsic-procedures/access-checks-file-access-modes.html

ISTM there's a typo s/Tailing/Trailing/ in gcc/fortran/intrinsic.texi

git grep -wi Tailing
seems to highlight a couple more.
Maybe you have time to fix these?

PS: The occurrence in gcc/testsuite/gcc.dg/format/strfmon-1.c sounds
odd.
TIA,

Re: dejagnu version update?

[Bernhard Reutner-Fischer via Gcc]

On Sat, 4 Aug 2018 18:32:24 +0200
Bernhard Reutner-Fischer  wrote:

> On Tue, 16 May 2017 at 21:08, Mike Stump  wrote:
> >
> > On May 16, 2017, at 5:16 AM, Jonathan Wakely  wrote: 
> >  
> > > The change I care about in 1.5.3  
> >
> > So, we haven't talked much about the version people want most.  If we 
> > update, might as well get something that more people care about.  1.5.3 is 
> > in ubuntu LTS 16.04 and Fedora 24, so it's been around awhile.  SUSU is 
> > said to be using 1.6, in the post 1.4.4 systems.  People stated they want 
> > 1.5.2 and 1.5.3, so, I'm inclined to say, let's shoot for 1.5.3 when we do 
> > update.
> >
> > As for the machines in the FSF compile farm, nah, tail wagging the dog.  
> > I'd rather just update the requirement, and the owners or users of those 
> > machines can install a new dejagnu, if they are using one that is too old 
> > and they want to support testing gcc.  
> 
> So.. let me ping that, again, now that another year has passed :)

or another 3 or 4 :)
> 
> PS: Recap: https://gcc.gnu.org/ml/fortran/2012-03/msg00094.html was
> later applied as
> http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5481f29161477520c691d525653323b82fa47ad7
> and was part of the dejagnu-1.5.2 release from 2015. Jonathan requires
> 1.5.3 for libstdc++ testing.
(i.e.
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=5256bd82343000c76bc0e48139003f90b6184347
 )
> The libdirs fix would allow us to remove the 150 occurrences of the
> load_gcc_lib hack, refer to the patch to the fortran list back then.
> AFAIR this is still not fixed: +# BUG: gcc-dg calls
> gcc-set-multilib-library-path but does not load gcc-defs!
> 
> debian-stable (i think 9 ATM), Ubuntu LTS ship versions recent enough
> to contain both fixes. Commercial distros seem to ship fixed versions,
> too.

It seems in May 2020 there was a thread on gcc with about the same
subject: https://gcc.gnu.org/pipermail/gcc/2020-May/232427.html
where Mike suggests to have approved to bump the required minimum
version to 1.5.3.
So who's in the position to update the
https://gcc.gnu.org/install/prerequisites.html
to s/1.4.4/1.5.3/g && git commit -m 'bump dejagnu required version' ?

Just asking patiently and politely.
I don't want to rush anybody into such a bump :)

But as you may remember, folks routinely run afoul of using too old
versions (without the 5256bd8 multilib prepending for example, recently
someone doing ARM stuff IIRC) so a bump would just be fair IMHO.

Maybe now, for gcc-12, is the time to bump prerequisites to 1.5.3?

thanks and sorry for my impatience (and, once again, the noise).
cheers,

[PATCH] Bump required minimum DejaGnu version to 1.5.3

[Bernhard Reutner-Fischer via Gcc]

From: Bernhard Reutner-Fischer 

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

gcc/ChangeLog:

* doc/install.texi: Bump required minimum DejaGnu version.
---
 gcc/doc/install.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 36c8280d7da..094469b9a4e 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -452,7 +452,7 @@ Necessary when modifying @command{gperf} input files, e.g.@:
 @file{gcc/cp/cfns.gperf} to regenerate its associated header file, e.g.@:
 @file{gcc/cp/cfns.h}.
 
-@item DejaGnu 1.4.4
+@item DejaGnu version 1.5.3 (or later)
 @itemx Expect
 @itemx Tcl
 @c Once Tcl 8.5 or higher is required, remove any obsolete
-- 
2.33.0

Re: [PATCH] git-backport: support renamed .cc files in commit message.

[Bernhard Reutner-Fischer via Gcc]

On Wed, 12 Jan 2022 16:54:46 +0100
Martin Liška  wrote:

> +def replace_file_in_changelog(lines, filename):
> +if not filename.endswith('.cc'):
> +return
> +
> +# consider all componenets of a path: gcc/ipa-icf.cc
> +while filename:
> +for i, line in enumerate(lines):
> +if filename in line:
> +line = line.replace(filename, filename[:-1])
> +lines[i] = line
> +return
> +parts = filename.split('/')
> +if len(parts) == 1:
> +return
> +filename = '/'.join(parts[1:])
> +

I think you mean os.sep instead of the hardcoded slash.
But i'd use os.path.split and os.path.join

thanks,

Re: GSoC Blog Post 0 - GCCprefab build system

[Bernhard Reutner-Fischer via Gcc]

On 13 June 2022 17:26:59 CEST, Jonathan Wakely via Fortran 
 wrote:

>https://gist.github.com/jwakely/95b3a790157f55d75e18f577e12b50d7#file-build_gcc_versions-sh

s/[[/[/
s/==/=/

The former are deprecated or obsolescent notations of test(1) syntax, fwiw.

PS: we should rm https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/gcc_build
It was not updated since the switch to git so, apparently, nobody uses it 
anymore (sadly, seeing who authored it).

Re: GSoC Blog Post 0 - GCCprefab build system

[Bernhard Reutner-Fischer via Gcc]

On 17 June 2022 21:55:47 CEST, Jakub Jelinek  wrote:
>On Fri, Jun 17, 2022 at 08:45:04PM +0200, Bernhard Reutner-Fischer via Gcc 
>wrote:
>> PS: we should rm 
>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/gcc_build
>
>No.  gcc_build is used by maintainer-scripts/gcc_release, so by killing it
>you'd make gcc unreleasable.

Doh, didn't grep in maintainer-scripts.
So, should the SVN parts be ripped out?

For non-maintainers, switch it to git instead?

>> It was not updated since the switch to git so, apparently, nobody uses it 
>> anymore (sadly, seeing who authored it).

The hunks talking about subversion do seem to be misleading nowadays, aren't 
they?

thanks,

Re: libsanitizer: sync from master

[Bernhard Reutner-Fischer via Gcc]

On 26 April 2023 20:31:10 CEST, Florian Weimer via Fortran 
 wrote:
>* Martin Liška:
>
>> On 11/15/22 16:47, Martin Liška wrote:
>>> Hi.
>>> 
>>> I've just pushed libsanitizer update that was tested on x86_64-linux and 
>>> ppc64le-linux systems.
>>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
>>> abidiff.
>>
>> Hello.
>>
>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
>
>So … we have the issue that involves interceptors outside of libc.so.6,
>namely crypt, crypt_r, and I posted an upstream patch for this:
>
>  sanitizers: Disable crypt, crypt_r interceptors for glibc
>  
>
>Can we just apply this downstream for now?  It blocks various folks from
>using the sanitizers in their projects.

+1

Re: libsanitizer: sync from master

[Bernhard Reutner-Fischer via Gcc]

On 28 April 2023 11:23:55 CEST, Florian Weimer via Fortran 
 wrote:
>* Martin Liška:

>But that's okay for me as well.

Even better.

[Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

[Bernhard Reutner-Fischer via Gcc]

[I was torn towards asking gcc@ only, individual i386 maintainers in
private or bluntly asking for help on gcc-patches or re-iterate through
ABI, so in an attempt to cut off years of latency i hereby ask all and
everybody for assistance. Stage4 means any chances are low, i know..
hence stage 1 material since it's not pressing in any foreseeable way]
Hello i386 maintainers

Recently, elsewhere, there was discussion about attribute regparm (and
stdcall) on functions with variable number of arguments in C.
Allegedly clang warns about these but GCC does not. I did not look at
clang.

gcc/doc/extend.texi currently states that:

---8<---
@cindex @code{regparm} function attribute, x86
[]
Functions that
take a variable number of arguments continue to be passed all of their
arguments on the stack.
[]
@cindex @code{sseregparm} function attribute, x86
[]
Functions that take a
variable number of arguments continue to pass all of their
floating-point arguments on the stack.
[]
@cindex @code{stdcall} function attribute, x86-32
[]
On x86-32 targets, the @code{stdcall} attribute causes the compiler to
assume that the called function pops off the stack space used to
pass arguments, unless it takes a variable number of arguments.
---8<---

which seems to suggest that all of attribute regparm/sseregparm/stdcall
are ignored on functions with variable number of arguments. I.e. the
ABI mandates that everything is passed on the stack.
[Right? ISTM that this is correct; Didn't follow ABI (tweaks) too
closely in the last decade, admittedly.. But i think this still holds.
Please correct me if i missed something?]

If this is correct, then ISTM that attributes
regparm/sseregparm/stdcall should be rejected on functions with
variable number of arguments also in GCC.

There seems to be (exact) struct function cfun->va_list_[fg]pr_size
for the real fpr and gpr save area sizes. But (unfortunately / of
course) they are layed out way later than parsing the attributes in
both the C++ and C FEs, so using those in ix86_handle_cconv_attribute
is not possible as there is no cfun readily available there yet. ²).

Hence i would propose to ¹):

gcc/ChangeLog:

* builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.
* config/i386/i386-options.cc (ix86_handle_cconv_attribute): Decline
regparm, stdcall and regparm attribute on functions with variable number
of arguments.

libitm/ChangeLog:

* libitm.h (_ITM_beginTransaction): Remove ITM_REGPARM.

gcc/testsuite/ChangeLog:

* gcc.dg/lto/trans-mem.h: Remove ITM_REGPARM.
* gcc.target/i386/attributes-error.c: Extend to cover
(regparm(3),stdcall) on vaargs functions.
* gcc.target/i386/attributes-error-sse.c: New test.

¹) as per attached
²) Unfortunately, the C FE does not readily provide a sensible locus
for the attributes in question but points input_location at that spot
of the beginning of the declaration of such a function. The C++ FE is
a little bit better in this regard:
[here i meant to verbatim emphasis discrepancy of the C++ and C FE
diagnostics for the abovementioned target tests, striking, isn't it, But
see yourselves.]
³) unreferenced, hence implied, where would on do this instead, more
helpful?
diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def
index 71f4db1f3da..4813509b9c3 100644
--- a/gcc/builtin-attrs.def
+++ b/gcc/builtin-attrs.def
@@ -400,7 +400,7 @@ DEF_ATTR_TREE_LIST (ATTR_TM_NORETURN_NOTHROW_LIST,
 DEF_ATTR_TREE_LIST (ATTR_TM_CONST_NOTHROW_LIST,
 		ATTR_TM_REGPARM, ATTR_NULL, ATTR_CONST_NOTHROW_LIST)
 DEF_ATTR_TREE_LIST (ATTR_TM_NOTHROW_RT_LIST,
-		ATTR_RETURNS_TWICE, ATTR_NULL, ATTR_TM_NOTHROW_LIST)
+		ATTR_RETURNS_TWICE, ATTR_NULL, ATTR_NOTHROW_LIST)
 
 /* Same attributes used for BUILT_IN_MALLOC except with TM_PURE thrown in.  */
 DEF_ATTR_TREE_LIST (ATTR_TMPURE_MALLOC_NOTHROW_LIST,
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index 3605c2c53fb..daea2394e1a 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options.cc
@@ -3679,6 +3679,12 @@ ix86_handle_cconv_attribute (tree *node, tree name, tree args, int,
 		   name, REGPARM_MAX);
 	  *no_add_attrs = true;
 	}
+  else if (FUNC_OR_METHOD_TYPE_P (*node) && stdarg_p (*node))
+	{
+	  warning (OPT_Wattributes, "%qE attribute ignored "
+		   "on function with variable number of arguments", name);
+	  *no_add_attrs = true;
+	}
 
   return NULL_TREE;
 }
@@ -3732,6 +3738,12 @@ ix86_handle_cconv_attribute (tree *node, tree name, tree args, int,
 	{
 	  error ("stdcall and thiscall attributes are not compatible");
 	}
+  if (FUNC_OR_METHOD_TYPE_P (*node) && stdarg_p (*node))
+	{
+	  warning (OPT_Wattributes, "%qE attribute ignored "
+		   "on function with variable number of arguments", name);
+	  *no_add_attrs = true;
+	}
 }
 
   /* Can combine cdecl with regparm and sseregparm.  */
@@ -3768

Re: [Patch, stage-1, RFC]: i386: attribute regparm/stdcall and vaargs

[Bernhard Reutner-Fischer via Gcc]

Hi Joseph!

On Tue, 30 Jan 2024 14:54:49 + (UTC)
Joseph Myers  wrote:

> On Tue, 30 Jan 2024, Bernhard Reutner-Fischer via Gcc wrote:
> 
> > * builtin-attrs.def (ATTR_TM_NOTHROW_RT_LIST): Use ATTR_NOTHROW_LIST
> > instead of ATTR_TM_NOTHROW_LIST, thus removing ATTR_TM_REGPARM.  
> 
> That doesn't make sense.  ATTR_TM_NOTHROW_RT_LIST is specifically a 
> transactional memory attribute list, but you're removing all transactional 
> memory attributes from it.  A list without the "*tm regparm" internal 
> attribute would have a different name.
> 

AFAICS there is no pre-existing attr list with just returns_twice and
nothrow. Would ATTR_NOTHROW_RT_LIST be more appropriate as name, and
should i move this up to before the format attribute lists, before
DEF_FORMAT_ATTRIBUTE?

Alternatively, there is an existing ATTR_RT_NOTHROW_LEAF_LIST
used by setjmp. But that would add leaf to _ITM_beginTransaction where
it was not marked leaf before. Would it be appropriate to use this for
_ITM_beginTransaction too, which behaves setjmp()ish AFAICS?

thanks