Re: [PATCH v2 2/3] or1k: testsuite: initial support for openrisc

[Mike Stump]

On Oct 3, 2018, at 8:48 PM, Stafford Horne  wrote:
> 
> -mm-dd  Stafford Horne  
>   Richard Henderson  
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.c-torture/execute/20101011-1.c: Adjust for OpenRISC.
>   * gcc.dg/20020312-2.c: Likewise.
>   * gcc.dg/attr-alloc_size-11.c: Likewise.
>   * gcc.dg/builtin-apply2.c: Likewise.
>   * gcc.dg/nop.h: Likewise.
>   * gcc.dg/torture/stackalign/builtin-apply-2.c: Likewise.
>   * gcc.dg/tree-ssa/20040204-1.c: Likewise.
>   * gcc.dg/tree-ssa/reassoc-33.c: Likewise.
>   * gcc.dg/tree-ssa/reassoc-34.c: Likewise.
>   * gcc.dg/tree-ssa/reassoc-35.c: Likewise.
>   * gcc.dg/tree-ssa/reassoc-36.c: Likewise.
>   * lib/target-supports.exp
>   (check_effective_target_logical_op_short_circuit): Add or1k*-*-*.
>   * gcc.target/or1k/*: New.

Not sure this needs any extra review, but I did, so, Ok.

Re: [PATCH, rs6000] Fix expected error output for test case.

[Mike Stump]

On Oct 3, 2018, at 1:32 PM, Bill Seurer  wrote:
> 
> [PATCH, rs6000] Fix expected error output for test case.
> 
> Is this ok for trunk?

Ok.

Re: [PR 87339, testsuite] Fix failure of gcc.dg/warn-abs-1.c on some targets

[Mike Stump]

On Sep 24, 2018, at 11:45 AM, Martin Jambor  wrote:
> 
> the test added to check whether _Float128 types are handled correctly by
> the new warning about suspicious calls to abs-like functions fails on
> many platforms.  The patch below circumvents the problem by running on
> i686/x86_64 only.  I understand that the proper solution would be to
> come up with a deja-gnu predicate and skip-if it was not provided but I
> think that for one simple test that is a bit of an overkill and testing
> it on x86_64 will provide all the test coverage we need.
> 
> Tested on x86_64-linux and aarch64-linux, testing on i686-linux
> pending.  OK for trunk?

Ok.

Re: [PATCH 08/14] Add D2 Testsuite files.

[Mike Stump]

On Sep 21, 2018, at 2:38 PM, Iain Buclaw  wrote:
> 
> On 21 September 2018 at 22:54, Mike Stump  wrote:
>> On Sep 17, 2018, at 5:36 PM, Iain Buclaw  wrote:
>>> 
>>> This patch adds part of the D2 testsuite, which includes D source code
>>> files that are considered compilable; files that are considered
>>> uncompilable, but should not ICE; and files that should execute on
>>> targets with crash or assertion failures.
>> 
>> Ok.  [ not needed, you can self-review things like this no problem ]
>> 
>> I see you are sneaking in Alice in Wonderland...
>> 
> 
> I had forgotten about that test.  I recall another project written in
> D (Dustmite) ran into some trouble with Debian due to the Project
> Gutenberg small print, which they ended up removing.
> 
> The "small print" section in the text file says:
> 
>DISTRIBUTION UNDER "PROJECT GUTENBERG-tm"
>You may distribute copies of this etext electronically, or by
>disk, book or any other medium if you either delete this
>"Small Print!" and all other references to Project Gutenberg,
>or:
>[...]
> 
> I'll look into convincing upstream to also do the same.

Oh, if you know of any reason why a file cannot be distributed, you cannot 
check that in ever.  So, you must resolve any outstanding issues before 
committing.   So, if Gutenberg has restrictions on distribution, you have to 
resolve those first, before it hit git.

If it had hit git, please either remove such for now until resolved, or resolve 
any issues.  Thanks.

Re: [PATCH 10/14] Add GDC Testsuite files.

[Mike Stump]

On Sep 17, 2018, at 5:37 PM, Iain Buclaw  wrote:
> This patch adds a further number of tests, but were added as part of
> fixing gdc-specific bugs.

Ok.  Trivial, and self-review applicable.

Re: [PATCH 08/14] Add D2 Testsuite files.

[Mike Stump]

On Sep 17, 2018, at 5:36 PM, Iain Buclaw  wrote:
> 
> This patch adds part of the D2 testsuite, which includes D source code
> files that are considered compilable; files that are considered
> uncompilable, but should not ICE; and files that should execute on
> targets with crash or assertion failures.

Ok.  [ not needed, you can self-review things like this no problem ]

I see you are sneaking in Alice in Wonderland...

Re: [PATCH 10/14] Add GDC Testsuite files.

[Mike Stump]

On Sep 17, 2018, at 5:37 PM, Iain Buclaw  wrote:
> 
> This patch adds a further number of tests, but were added as part of
> fixing gdc-specific bugs.

Ok.  Trivial, and self-review applicable.

Re: [PATCH 13/14] Add D Phobos standard library and license.

[Mike Stump]

On Sep 19, 2018, at 1:49 PM, Iain Buclaw  wrote:
> 
> On 18 September 2018 at 02:38, Iain Buclaw  wrote:
>> This patch add the Phobos runtime library and license (Boost) files.
>> Phobos is the standard runtime library that comes with the D language
>> compiler.  The bulk of which is comprised mostly of generic algorithms
>> and high level primitives for D applications.
>> 
>> ftp://ftp.gdcproject.org/patches/v4/13-v4-d-phobos-library.patch
>> 
> 
> As far as I can tell, no one has made a comment on this yet.

So, the important review point here will be the license.  I'd expect Law to 
review it, and the SC to be involved as he requires it.  You can't just 
self-approve license things, that's the domain of the SC.  He'll wake up and 
look at this soon, don't worry.

Re: [PATCH 09/14] Add D2 Testsuite Dejagnu files.

[Mike Stump]

On Sep 19, 2018, at 1:36 PM, Iain Buclaw  wrote:
> 
> On 18 September 2018 at 02:36, Iain Buclaw  wrote:
>> 
>> This patch adds D language support to the GCC testsuite.
>> 
>> As well as generating the DejaGNU options for compile and link tests,
>> handles the conversion from DMD-style compiler options to GDC.
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00112.html
> 
> I take it from the comment in the last review, that I can self-approve
> this, and the other testsuite related patches.

If you're a maintainer for D...  :-)  Presently, you're not listed as 
maintainer.  If appointed, then you will modify MAINTAINERS and move your entry 
up and put D front end on the line.  In the time span between the two events 
I'd punt to the SC.  If you have been appointed, yes, that remains until you 
step down or the SC changes their mind or some other big event.  You can also 
ask for advice or ask for a review, even if you can approve.

Re: [PATCH 09/14] Add D2 Testsuite Dejagnu files.

[Mike Stump]

Ok.

Re: [PATCH 22/25] Add dg-require-effective-target exceptions

[Mike Stump]

On Sep 5, 2018, at 4:52 AM, a...@codesourcery.com wrote:
> There are a number of tests that fail because they assume that exceptions are
> available, but GCN does not support them, yet.

So, generally we don't goop up the testsuite with the day to day port stuff 
when it is being developed.  If the port is finished, and EH can't be done, 
this type of change is fine.  If someone plans on doing it in the next 5 years 
and the port is still being developed, there is likely little reason to do 
this.  People that track regressions do so by differencing, and that easily 
handles massive amounts of failures seamlessly.

So, my question would be, has is just not been worked on yet, or, is it 
basically impossible to ever do it?

Re: [PATCH][OBVIOUS] Close file on return from verify-intermediate

[Mike Stump]

On Sep 5, 2018, at 6:29 AM, Joey Ye  wrote:
> This is a fix to an obvious issue in gcov.exp, where proc verify-intermediate 
> returns without closing the open file.
> 
> This can be a possible fix to PR85871. gcov-8.C diffs to other gcov testcases 
> that it invokes verify-intermediate. Not closing an open file may result in 
> random failure quietly.
> 
> It is only a possible fix as I failed to reproduce the PR85871 random failure 
> in my local machine despite continuous testing of multiple days. So I cannot 
> verify if this patch fixes the regression either.
> 
> To verify, https://gcc.gnu.org/ml/gcc-testresults/ need to be watched whether 
> gcov-8 regression will disappear completely one month after this patch 
> committed to trunk.
> 
> Tested with make check with no new regressions.
> 
> OK to trunk?

Ok.

I'm hoping that this doesn't fix that issue, as this change should not cause 
any change to correctly written code.  if it does fix it, there is at least one 
more unfortunate thing that should be fixed that remains unidentified.

Re: [PATCH, Darwin, config] Arrange for configure to detect "otool".

[Mike Stump]

On Aug 30, 2018, at 8:45 AM, Iain Sandoe  wrote:
> 
> Currently, we fail to detect some Darwin assembler capabilities because the
> configure tests rely on a BINUTILS objdump, which isn’t generally available
> on Darwin.
> 
> Darwin uses a tool called "otool" to provide information about objects, and we
> should be able to extend or adapt config tests to use this.
> 
> libtool already ‘knows’ about otool, we just need to teach the GCC configury.
> 
> OK for trunk?

Ok once the sorting comment is resolved.

Re: [PATCH, testsuite] Stringify __USER_LABEL_PREFIX__ in pr85248.

[Mike Stump]

On Aug 21, 2018, at 7:20 AM, Iain Sandoe  wrote:
> 
> another missing stringify for _U_L_P_ 
> 
> OK?

Ok.
=

Re: [PATCH, Darwin] Do not run dsymutil automatically, when -save-temps is on the command line.

[Mike Stump]

On Aug 18, 2018, at 1:17 PM, Iain Sandoe  wrote:
> 
> The point of running dsymutil automatically from collect2 is that it
> (collect2, lto-wrapper, etc) might be generating or using compiler
> temporary files that will be deleted at the end of the link process.
> 
> dsymutil requires that it can see the objects actually used in the link
> since it actually picks up the debug info from those, rather than the
> linked exe.
> 
> When “-save-temps” is given, the objects should be preserved (if they
> are not, then that’s a bug) and therefore we don’t need to run dsymutil
> automatically.
> 
> The debug experience can be better with GDB + the original objects for
> some permutations of dsymutil / GDB.
> 
> Opinions? 

So, I think of -save-temps as a debugging thing, and as such, kinda don't want 
it to change anything.  I don't think people use this in production to manage 
their builds.

I think it's an over optimization.

Re: [PATCH, Darwin, drivers] Split DWARF is not supported on Darwin.

[Mike Stump]

On Aug 16, 2018, at 6:55 AM, Iain Sandoe  wrote:
> 
> The Darwin toolchains have a separate debug linker (dsymutil) so that the
> link-time penalty for debug data is not usually seen.  At present, it's not
> clear how we would support split DWARF on Darwin (or if it would bring
> any additional benefit over dsymutil).
> 
> This patch produces diagnostic output to note that it's not supported and
> disables it.  We also skip test cases that invoke -gsplit-dwarf.
> 
> NOTE that the tests failed because of PR81685 and this fix will need to
> be back-ported after the fix for 81685.
> 
> OK for trunk?

Ok.

> affected branches (7,8)?

Ok.

Re: [PATCH,testsuite, Darwin] Skip tests with pthread_barrier.

[Mike Stump]

On Aug 15, 2018, at 7:22 AM, Iain Sandoe  wrote:
> Darwin is stated to be SUSv6 compliant and, at that revision, pthread_barrier 
> is optional.
> It is not implemented on any version at least up to Darwin18.
> 
> This skips the tests currently attempted which use pthread_barrier.
> 
> OK for trunk?

Ok.

Re: [PATCH, testsuite] Fix PR78544 for Darwin.

[Mike Stump]

On Aug 15, 2018, at 6:20 AM, Iain Sandoe  wrote:
> 
> The fails on Darwin are because the section naming convention is different.
> 
> The patch adds Darwin-specific section attributes and a corresponding 
> target-specific scan-assembler clause.
> 
> OK for trunk?
> affected branches (7, 8)?

Ok.

[ just thinking out loud ] It might be nice to have a section name mapper that 
can convert section names from the rest of the world, into darwin style section 
names.  .text -> __TEXT,__text and so on, then some of this patch can be backed 
out as unnecessary. The point of the patch would be to increase the portability 
of code to the platform.  The other possibility would be for darwin to just add 
support for all the usual elf things and for those all to work.

Re: [PATCH] Fix P81033 for FDEs in partitioned code.

[Mike Stump]

On Aug 14, 2018, at 4:20 AM, Iain Sandoe  wrote:
> When function sub-sections are enabled, Darwin’s assembler needs the FDE 
> local start
> label for each sub-section to follow a linker-visible one so that the FDE 
> will be correctly
> associated with the code of the subsection.
> 
> The current code in final.c emits a linker-visible symbol, as needed by 
> several targets.
> However the local label used to define the FDE start precedes the 
> linker-visible one
> which, for Darwin causes it (the FDE start) to be associated with the 
> previous linker-
> visible symbol (or the section start if there isn’t one).  This applies 
> regardless of the 
> actual address of the label, for toolchain assemblers that have strict 
> interpretation of
> the Darwin sub-sections-via-symbols ABI.
> 
> The patch adds a new local label (analogous to the "LFBn” emitted for the 
> regular
> function starts) just after the linker-visible label emitted after switching 
> text section.
> The FDE second entry is made to point to this instead of the LcoldStartn one. 
>  This
> should be a no-op for targets using .cfi_ and for targets without 
> sub-sections-via-symbols.
> 
> Bootstrapped on x86_64 and i686 linux and on a number of Darwin platforms 
> (from 
> i686-darwin9 to x86_64-darwin17).
> 
> OK for trunk?
> open branches? (although it's a regression on 8, it’s a latent wrong-code on 
> all branches)

I'm fine with the darwin aspects of it, but I think it needs review/approval by 
final.c/dwarf people.

Re: [PATCH, Darwin] Remove unnecessary target hook.

[Mike Stump]

On Aug 13, 2018, at 1:55 PM, Iain Sandoe  wrote:
> For Darwin when we switch between text sections a linker-visible symbol is
> required to preserve the linker’s  “atom model”.  Some time ago we implemented
> TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS to provide this.
> 
> A suitable symbol is now emitted directly from final.c so the target hook 
> version
> needs to be removed to avoid multiple symbols at the same address.
> 
> OK for trunk?
> open branches?

Ok.

Re: [PATCH, Darwin, Obvious] Fix PR81685, by adding DWARF 5 section names.

[Mike Stump]

On Aug 14, 2018, at 4:38 AM, Iain Sandoe  wrote:
> Where possible (i.e. they are currently defined), I’ve synced the Darwin 
> names with the ones
> emitted by clang.

Thanks.

Re: dejagnu version update?

[Mike Stump]

On Aug 4, 2018, at 9:32 AM, 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 :)

Putting on my random engineer hat, does Centos 7 have a patch in it?  My system 
says 1.5.1.

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.  :-)

Ok to update to 1.5.3.

I'll pre-approve the patches to simplify and remove work arounds from the 
testsuite that cater to older versions.

If an RM wants to push the approval to sometime later (post a release branch 
creation point for example), let's give them a few days to request deferral.  I 
don't want to impact any next release in a way an RM doesn't want.  RM approval 
for back ports, I think we don't want to back port to a previous release, but 
I'm happy to defer to RM; if they want to do it.

Re: dejagnu version update?

[Mike Stump]

On Aug 4, 2018, at 9:32 AM, 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 :)

Putting on my random engineer hat, does Centos 7 have a patch in it?  My system 
says 1.5.1.

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.  :-)

Ok to update to 1.5.3.

I'll pre-approve the patches to simplify and remove work arounds from the 
testsuite that cater to older versions.

If an RM wants to push the approval to sometime later (post a release branch 
creation point for example), let's give them a few days to request deferral.  I 
don't want to impact any next release in a way an RM doesn't want.  RM approval 
for back ports, I think we don't want to back port to a previous release, but 
I'm happy to defer to RM; if they want to do it.

Re: [RFC, testsuite/guality] Use relative line numbers in gdb-test

[Mike Stump]

On Jun 28, 2018, at 12:39 PM, Tom de Vries  wrote:
> This patch adds a dg-final override that passes it's first argument to the
> gdb-test action.  This allows us to use relative line numbers in gdb-test.
> 
> Tested pr45882.c.
> 
> Any comments?

> 2018-06-28  Tom de Vries  
> 
>   * gcc.dg/guality/pr45882.c (foo): Use relative line numbers.
>   * lib/gcc-dg.exp (dg-final): New proc.
>   * lib/gcc-gdb-test.exp (gdb-test): Add and handle additional line number
>   argument.

I like it.  :-)  I'd approve it.  Anyone not like it?

Re: [RFC] Add gcc.dg-selftests/dg-final.exp

[Mike Stump]

On May 30, 2018, at 3:41 AM, Tom de Vries  wrote:
> 
> this patch tests the error behaviour of dg-final directives when called with 
> an
> incorrect number of arguments.

Seems reasonable.  Unless someone wanted to argue against it for some reason 
(not portable, takes too much time, hard to maintain, doesn't test features), 
I'd ok it.

Re: RFC: Disable asan tests under ulimit -v

[Mike Stump]

On Mar 23, 2018, at 11:52 AM, Jason Merrill  wrote:
> 
> asan doesn't work under ulimit -v, which I want to use on shared hosts
> to avoid causing trouble with runaway processes.  There doesn't seem
> to be a way within expect to access getrlimit/setrlimit, so in this
> patch I call out to the shell to test the current limit, and give up
> if I get back a number (rather than "unlimited" or an error message).
> 
> Thoughts?

I'd punt to the asan folks.  Seems reasonable if it doesn't work.

Re: [PATCH, GCC/testsuite] Fix FAIL display for some scan-*-times directives

[Mike Stump]

On Mar 13, 2018, at 10:12 AM, Thomas Preudhomme 
 wrote:
> 
> scan-assembler-times and scan-tree-dump-times dejagnu directives show a
> different output in the summary files depending on whether they PASS or
> FAIL. This means that dg-cmp-results would not show a regression because
> it would not see a connection between the two output.

> 2018-03-13  Thomas Preud'homme  
> 
>   * lib/scanasm.exp (scan-assembler-times): Move FAIL debug info into a
>   separate verbose message.
>   * lib/scandump.exp (scan-dump-times): Likewise.

> Is this ok for stage 4?

Yes, please.  If broken on release branches, should be safe (if you regression 
test it of course) to move back, if you want.

Re: [PATCH][darwin] Work around missing LTO debug support for Mach-O, PR82005

[Mike Stump]

On Mar 1, 2018, at 1:56 AM, Dominique d'Humières  wrote:
> 
>> Le 1 mars 2018 à 09:37, Richard Biener  a écrit :
>> 
>> In the PR Dominique says "With the patch the failures (-m32/-m64) went 
>> down from 1059 to 467" which is a nice improvement.  I'm not set up
>> to bootstrap on darwin but I expect Dominque did so.
> 
> Indeed!
> 
>> 
>> So - ok for trunk?
> 
> From my pov yes.

Yes.

Re: Please accept this commit for the trunk

[Mike Stump]

On Feb 8, 2018, at 12:36 PM, Segher Boessenkool <seg...@kernel.crashing.org> 
wrote:
> 
> On Wed, Feb 07, 2018 at 03:52:27PM -0800, Mike Stump wrote:
>> I dusted the pointed to patch off and check it in.  Let us know how it goes.
> 
> I wanted to test this on the primary and secondary powerpc targets as
> well, but okay.

I reviewed it, and it seemed to only trigger for darwin.  Certainly doesn't 
hurt to run a regression run and ensure that is the case.

>> Does this resolve all of PR84113?  If so, I can push the bug along.
> 
> It makes bootstrap work.  We don't know if it is correct otherwise.

So, would be nice if someone could run a regression test.  I'd do it by the 
version just before the breakage, and then drop in the patch, and test again.  
This minimizes all the other changes.

>> What PR was the attachment url from?
> 
> It is not from a PR, and it has never been sent to gcc-patches; it is
> from https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg02971.html
> (attachment #2).

Ah, that explains it.

Sounds like 1, 3 and 4 also likely need to go it to make things nice.  If 
someone could regression test and let us know, that's likely the gating factor.

Re: Please accept this commit for the trunk

[Mike Stump]

On Feb 5, 2018, at 8:42 AM, Douglas Mencken  wrote:
> 
> I’m about
> 
> “ [PATCH 2/4] [Darwin,PPC] Remove uses of LR in
> restore_world ” https://gcc.gnu.org/bugzilla/attachment.cgi?id=42304
> 
> look at bug #84113 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84113 for
> more info
> 
> “ One important question ’s yet: Why this patch has been ignored despite
> it’s been made just in time? ”

I dusted the pointed to patch off and check it in.  Let us know how it goes.

Does this resolve all of PR84113?  If so, I can push the bug along.

What PR was the attachment url from?

Thanks for your help.

2018-02-07  Iain Sandoe  

* config/rs6000/altivec.md (*restore_world): Remove LR use.
* config/rs6000/predicates.md (restore_world_operation): Adjust op
count, remove one USE.

Index: gcc/config/rs6000/altivec.md
===
--- gcc/config/rs6000/altivec.md(revision 257471)
+++ gcc/config/rs6000/altivec.md(working copy)
@@ -419,7 +419,6 @@
 (define_insn "*restore_world"
  [(match_parallel 0 "restore_world_operation"
   [(return)
-  (use (reg:SI LR_REGNO))
(use (match_operand:SI 1 "call_operand" "s"))
(clobber (match_operand:SI 2 "gpc_reg_operand" "=r"))])]
  "TARGET_MACHO && (DEFAULT_ABI == ABI_DARWIN) && TARGET_32BIT"
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 257471)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -1295,13 +1295,12 @@
   rtx elt;
   int count = XVECLEN (op, 0);
 
-  if (count != 59)
+  if (count != 58)
 return 0;
 
   index = 0;
   if (GET_CODE (XVECEXP (op, 0, index++)) != RETURN
   || GET_CODE (XVECEXP (op, 0, index++)) != USE
-  || GET_CODE (XVECEXP (op, 0, index++)) != USE
   || GET_CODE (XVECEXP (op, 0, index++)) != CLOBBER)
 return 0;
 

Re: [testsuite] Make lto.exp work with Tcl 8.4

[Mike Stump]

On Feb 5, 2018, at 9:54 AM, Richard Sandiford  
wrote:
> 
> "dict" was added in Tcl 8.5, but until a couple of weeks ago the
> testsuite has worked with 8.4.
> 
> This patch uses arrays instead, like we do for the caching in
> target-supports.exp.  It is a bit uglier than using dicts was,
> but hopefully not too bad...
> 
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Ok.

Re: [PATCH] PR52665 do not let .ident confuse assembler scan tests

[Mike Stump]

On Feb 2, 2018, at 5:25 AM, Bernhard Reutner-Fischer  
wrote:
> 
> Given the overwhelming silence this proposal has received, i take it
> for granted that folks are thrilled and even up until now speechless
> :)

> -fno-ident ok for stage1?
> What about -fno-file? Clever alternative suggestions? Don't care?

Sure.  We've had the bake time on the idea, no better solution has been 
proposed.  I think _solving_ the problem is a good thing, and that solution 
seems reasonable.

Re: [C++ PATCH] Deprecate ARM-era for scopes

[Mike Stump]

On Jan 23, 2018, at 4:18 AM, Nathan Sidwell  wrote:
> 
> As discussed (https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01778.html) this 
> patch deprecates the ARM-era for scope.

The code gives:

  if you use %<-fpermissive%> G++ will accept your code

I think we should no longer recommend a deprecated feature without at least 
stating it is deprecated in the hint?  Not too important, as if they actually 
use it, the compiler will spit out:

  this flexibility is deprecated and will be removed

if someone tried to use it, but thought I might mention it.

Re: [PATCH][GCC][Testsuite] Have dg-cmp-results reject log files.

[Mike Stump]

On Jan 23, 2018, at 2:31 AM, Tamar Christina  wrote:
> 
> This patch makes dg-cmp-results.sh reject the use of log files in the 
> comparison.

No please.  We like to run that script on log files from time to time for 
various reasons.  I'd rather fix anything that prevents that from working as 
expected.

> Often when given a log file dg-cmp-results will give incomplete/wrong output 
> and
> using log instead of sum is one autocomplete tab away.

Add a make target if you can't type the right command line?

Re: [C++] Deprecate old for-scope handling

[Mike Stump]

On Jan 19, 2018, at 2:53 PM, Nathan Sidwell  wrote:
> what do you think about deprecating the ARM-era for-scope handling

I endorse this idea.  :-)  20 years is enough for anyone to update their code, 
right?  :-)

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH, rs6000] Use $ instead of . for PC

[Mike Stump]

On Jan 19, 2018, at 6:06 PM, Bill Schmidt  wrote:
> 
> I'm having a lot of heartburn over this because my test machine is
> experiencing disk slowdowns, so it's taking me up to 4 hours to complete
> a bootstrap and regression test.

Ah, the joys of crosses, no bootstrap.  The gcc C testsuite runs in under 120 
seconds for me.  [ ducks ]

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

[Mike Stump]

On Dec 5, 2017, at 12:56 PM, Thomas Preudhomme  
wrote:
> 
> Thanks, I've tested after the two commits and it works both in tree and out 
> of tree. It'll simplify comparing in tree results Vs out of tree for us, 
> thanks a lot!
> 
> Would you consider a backport to stable branches if nobody complains after a 
> week?

Yeah, back port is Ok.

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

[Mike Stump]

On Dec 5, 2017, at 11:11 AM, Thomas Preudhomme  
wrote:
> 
> On 05/12/17 17:54, Andrew Pinski wrote:
>> On Tue, Dec 5, 2017 at 9:50 AM, Thomas Preudhomme
>>  wrote:
>>> Hi,
>>> 
>>> dump-noaddr test FAILS when $tmpdir is not the same as the directory
>>> where runtest is called from. Note that this does not happen when
>>> running make check because tmpdir is set to srcdir.
>>> 
>>> In that case, file mkdir will create the directory in the current
>>> directory while GCC is invoked from tmpdir and hence -dumpbase look
>>> for dump1 and dump2 relative to tmpdir. This patch forces dumpbase to
>>> be relative to tmpdir which will work in all case.
>>> 
>>> ChangeLog entry is as follows:
>>> 
>>> *** gcc/testsuite/ChangeLog ***
>>> 
>>> 2017-12-05  Thomas Preud'homme  
>>> 
>>> * gcc.c-torture/unsorted/dump-noaddr.x (dump_compare): Set dump base
>>> relative to tmpdir.
>>> 
>>> Testing: Successfully ran unsorted.exp via make check and out of tree
>>> testing using runtest from /test with tmpdir set in
>>> /test/site.exp to .
>>> 
>>> Is this ok for stage3?
>> https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01752.html
>> I don't remember where this discussion went last time.
>> Maybe this time there will be a resolution :).
> 
> FWIW, I agree with Matt, creating the dump in tmpdir makes more sense. I 
> think his patch can be simplified though because the compiler seems to be 
> invoked from tmpdir so it can at least be omitted from the -dumpbase.

Sounds reasonable.  I've added that on top of his patch and checked that in.  
Let us know if it works or not.

Re: [PATCH, GCC/testsuite] Fix dump-noaddr dumpbase

[Mike Stump]

On Dec 5, 2017, at 9:54 AM, Andrew Pinski  wrote:
> 
> On Tue, Dec 5, 2017 at 9:50 AM, Thomas Preudhomme
>  wrote:
>> Hi,
>> 
>> dump-noaddr test FAILS when $tmpdir is not the same as the directory
>> where runtest is called from. Note that this does not happen when
>> running make check because tmpdir is set to srcdir.
>> 
>> In that case, file mkdir will create the directory in the current
>> directory while GCC is invoked from tmpdir and hence -dumpbase look
>> for dump1 and dump2 relative to tmpdir. This patch forces dumpbase to
>> be relative to tmpdir which will work in all case.
>> 
>> ChangeLog entry is as follows:
>> 
>> *** gcc/testsuite/ChangeLog ***
>> 
>> 2017-12-05  Thomas Preud'homme  
>> 
>>* gcc.c-torture/unsorted/dump-noaddr.x (dump_compare): Set dump base
>>relative to tmpdir.
>> 
>> Testing: Successfully ran unsorted.exp via make check and out of tree
>> testing using runtest from /test with tmpdir set in
>> /test/site.exp to .
>> 
>> Is this ok for stage3?
> 
> https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01752.html
> I don't remember where this discussion went last time.

I approved his patch last time in:

  https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01752.html

I've not seen anyone argue against it.

> Maybe this time there will be a resolution :).

A resolution would be for someone to check in the approved patch, or ask for it 
to be installed.  :-o

I've checked it in.  It might not work for canadian crosses, but we can punt 
that to the next poor soul.

Give it a try and let us know if that cures the problem.  Feel free to just fix 
it, if you notice anything wrong.  I'm thinking it will cure all the problems 
people have seen.

Re: [PATCH] Fix hot/cold partitioning with -gstabs{,+} (PR debug/81307)

[Mike Stump]

On Nov 27, 2017, at 5:07 PM, Jim Wilson  wrote:
> There is also darwin9 support that apparently no one really cares about 
> anymore.

I'm fine with removing stabs support from the compiler.

Re: Add -std=c18 etc. option aliases

[Mike Stump]

On Nov 16, 2017, at 2:24 PM, Joseph Myers  wrote:
> 
> ISO C17 won't go to ballot until December, meaning publication of the
> standard won't be until 2018, leaving ambiguity as to whether people
> will end up referring to the standard as C17, as it's currently known
> and which corresponds to the __STDC_VERSION__ value, or C18 based on
> the publication date.

C++98 was similar.  The last draft was in 97, but, the actual ISO standard was 
98.   I think the ANSI version was done in 97.  The name 97 is never, ever 
used, and c++98 names it pretty well.  cplusplus has a 97 date on it.  If there 
was no major release with c17, I would ditch the c17 spelling and just change 
it to c18 now.  :-)  I know, kinda sucks, but, until published, it just doesn't 
exist.  This is why we use 0x, and other names that we can safely deprecate for 
c++.  Concerning iso9899:2017, naming an actual document that doesn't exist, 
strikes me as wrong.  I've advise against it.

Re: bitfield types

[Mike Stump]

On Nov 14, 2017, at 3:21 PM, Joseph Myers <jos...@codesourcery.com> wrote:
> 
> On Tue, 14 Nov 2017, Mike Stump wrote:
>> The testsuite/gcc.c-torture/execute/pr34971.c seems wrong to me.  The 
>> type of the expression x.b << 8 has size 8, a size 8 integral type is a 
>> 64-bit type.  If the result is a 64-bit type, then it's argument (x.b) 
>> was a 64-bit type.  In C++, we observed what they meant in the C 
> 
> A 64-bit type *with padding bits, not necessarily 64 value bits*.
> 
> See what I said in <https://gcc.gnu.org/ml/gcc/2017-10/msg00192.html>.

Ah, thanks.

> I don't know what if anything in C++ explicitly resolves the C90 DR#120
> issue and defines the results of storing not-exactly-representable values
> in a bit-field.

The text that you'd most be interest in, from C++98:d

2 If the destination type is unsigned, the resulting value is the  least
  unsigned integer congruent to the source integer (modulo 2n where n is
  the number of bits used to represent the unsigned type).  [Note: In  a
  two's  complement  representation,  this  conversion is conceptual and
  there is no change in the bit pattern (if there is no truncation).  ]

3 If the destination type is signed, the value is unchanged if it can be
  represented  in the destination type (and bit-field width); otherwise,
  the value is implementation-defined.

For enums:

4 If the value true or false is stored into a bit-field of type bool  of
  any  size (including a one bit bit-field), the original bool value and
  the value of the bit-field shall compare equal.  If the  value  of  an
  enumerator is stored into a bit-field of the same enumeration type and
  the number of bits in the bit-field is large enough to  hold  all  the
  values of that enumeration type, the original enumerator value and the
  value of the bit-field shall compare equal.

I think this makes it well defined and the same as C for the DR120 code.

bitfield types

[Mike Stump]

The testsuite/gcc.c-torture/execute/pr34971.c seems wrong to me.  The type of 
the expression x.b << 8 has size 8,  a size 8 integral type is a 64-bit type.  
If the result is a 64-bit type, then it's argument (x.b) was a 64-bit type.  In 
C++, we observed what they meant in the C language standard and ever so 
slightly clarified the language.  I don't think we viewed the semantics of C 
any different than what we wrote at the time.  The problem is that in C, sizeof 
bit-field doesn't work, but sizeof (bitfield << 0) does work.  For this to 
work, the size can't refer to the size in bits, so must refer to some other 
integral type.  The obvious one to use would be the smallest one that fits the 
size, or the underlying type.  In C++, we felt the underlying type was the 
right one.  The C standard does say that the type of the bitfield is what we 
call the underlying type in C++.  Because of this, the test case is wrong, and 
the C semantics are wrong.

Now, this is might be contentious to some, so, I wonder if a later C language 
DR or C language standard clarified this any?  Any language lawyer want to 
argue other semantics?

https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00723.html is fallout of the 
wrong semantics by the C front-end and the entire issue evaporates once the 
code-gen is fixed.

I did expect bit-fields to be well understood and implemented at this point and 
was kinda amused to see that isn't the case yet.  I'd be interested in survey 
results of all (long||long long) > int C compilers.  clang for example, does 
the right thing.

Re: [PATCH] Fixes for PR68356, PR81210, and PR81693

[Mike Stump]

On Nov 14, 2017, at 3:33 AM, Dominique d'Humières <domi...@lps.ens.fr> wrote:
> 
>> Le 13 nov. 2017 à 18:40, Mike Stump <mikest...@comcast.net> a écrit :
>> On Nov 12, 2017, at 6:58 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> 
>>> On Sun, Nov 12, 2017 at 6:22 AM, Dominique d'Humières
>>> <domi...@lps.ens.fr> wrote:
>>>> The following patch fixes PR68356, PR81210, and PR81693 on darwin.
>>>> ...
>>> 
>>> I wrote these tests.  These tests don't align stack to 16 bytes and
>>> should be skipped on Darwin.
>> 
>> So, sounds like something based on:
>> 
>> /* { dg-skip-if "sp not aligned to 16 bytes" { *-*-darwin } } */
>> 
>> then.  Ok with that change.
> 
> Thanks for the review.
> 
> Am I correct to understand that this apply to pr25967-*.c only?
> 
> I’ld like to keep the PR numbers. Is it OK?

Feel free to keep the PR, but, I'd close the other two as dups of the first, 
and then just list the first.  The issue is that all of these test cases are 1 
problem, so there should only be 1 PR.  HJ's comment applies to all test cases 
in your patch, and the problem appears to be the single non-16 byte stack on 
all of them.  Because of that alone, the test cases should be skipped for that 
one reason, no matter the existence of other reasons why that test case should 
be skipped.

Re: [PATCH] Fixes for PR68356, PR81210, and PR81693

[Mike Stump]

On Nov 12, 2017, at 6:58 AM, H.J. Lu  wrote:
> 
> On Sun, Nov 12, 2017 at 6:22 AM, Dominique d'Humières
>  wrote:
>> The following patch fixes PR68356, PR81210, and PR81693 on darwin.
>> 
>> --- ../_clean/gcc/testsuite/gcc.dg/torture/pr68264.c2016-01-28 
>> 00:30:03.0 +0100
>> +++ gcc/testsuite/gcc.dg/torture/pr68264.c  2017-11-11 
>> 17:16:58.0 +0100
>> @@ -1,4 +1,5 @@
>> /* { dg-do run } */
>> +/* { dg-xfail-run-if "PR68356 no math-errno on darwin" { "*-*-darwin*" } } 
>> */
>> /* { dg-add-options ieee } */
>> /* { dg-require-effective-target fenv_exceptions } */
>> 
>> --- ../_clean/gcc/testsuite/gcc.dg/torture/pr68037-1.c  2016-06-10 
>> 15:22:50.0 +0200
>> +++ gcc/testsuite/gcc.dg/torture/pr68037-1.c2017-11-11 
>> 18:43:16.0 +0100
>> @@ -1,4 +1,5 @@
>> /* { dg-do run { target i?86-*-* x86_64-*-* } } */
>> +/* { dg-xfail-run-if "PR81210" { *-*-darwin* && lp64 } } */
>> /* { dg-options "-mgeneral-regs-only" } */
>> 
>> extern void exit (int);
>> --- ../_clean/gcc/testsuite/gcc.dg/torture/pr68037-2.c  2016-06-10 
>> 15:22:50.0 +0200
>> +++ gcc/testsuite/gcc.dg/torture/pr68037-2.c2017-11-11 
>> 18:44:08.0 +0100
>> @@ -1,4 +1,5 @@
>> /* { dg-do run { target i?86-*-* x86_64-*-* } } */
>> +/* { dg-xfail-run-if "PR81210" { *-*-darwin* && lp64 } } */
>> /* { dg-options "-mgeneral-regs-only" } */
>> 
>> extern void exit (int);
>> --- ../_clean/gcc/testsuite/gcc.dg/torture/pr68037-3.c  2016-06-10 
>> 15:22:50.0 +0200
>> +++ gcc/testsuite/gcc.dg/torture/pr68037-3.c2017-11-11 
>> 18:49:10.0 +0100
>> @@ -1,4 +1,5 @@
>> /* { dg-do run { target i?86-*-* x86_64-*-* } } */
>> +/* { dg-xfail-run-if "PR81210" { *-*-darwin* && lp64 } { "-O1" "-O2" "-O3" 
>> "-Os" } } */
>> /* { dg-options "-mgeneral-regs-only" } */
>> 
>> #include 
>> --- ../_clean/gcc/testsuite/gcc.dg/torture/pr25967-1.c  2017-10-26 
>> 07:16:19.0 +0200
>> +++ gcc/testsuite/gcc.dg/torture/pr25967-1.c2017-11-11 
>> 19:36:30.0 +0100
>> @@ -1,4 +1,5 @@
>> /* { dg-do run { target i?86-*-* x86_64-*-* } } */
>> +/* { dg-xfail-run-if "PR81693" { "*-*-darwin*" } } */
>> /* { dg-options "-mgeneral-regs-only" } */
>> 
>> extern void exit (int);
>> --- ../_clean/gcc/testsuite/gcc.dg/torture/pr25967-2.c  2017-10-26 
>> 07:16:19.0 +0200
>> +++ gcc/testsuite/gcc.dg/torture/pr25967-2.c2017-11-11 
>> 19:36:02.0 +0100
>> @@ -1,4 +1,5 @@
>> /* { dg-do run { target i?86-*-* x86_64-*-* } } */
>> +/* { dg-xfail-run-if "PR81693" { *-*-darwin* && ilp32 } } */
>> /* { dg-options "-mgeneral-regs-only" } */
>> 
>> 
>> Is it OK?
> 
> I wrote these tests.  These tests don't align stack to 16 bytes and
> should be skipped on Darwin.

So, sounds like something based on:

  /* { dg-skip-if "sp not aligned to 16 bytes" { *-*-darwin } } */

then.  Ok with that change.

Re: [PATCH] Fix pr81706 tests on darwin

[Mike Stump]

On Nov 12, 2017, at 6:05 AM, Dominique d'Humières  wrote:
> 
> The following patch fixes pr81706 tests on darwin
> 
> --- ../_clean/gcc/testsuite/gcc.target/i386/pr81706.c 2017-10-26 
> 07:16:18.0 +0200
> +++ gcc/testsuite/gcc.target/i386/pr81706.c   2017-11-11 16:02:36.0 
> +0100
> @@ -1,8 +1,8 @@
> /* PR libstdc++/81706 */
> /* { dg-do compile } */
> /* { dg-options "-O3 -mavx2 -mno-avx512f" } */
> -/* { dg-final { scan-assembler "call\[^\n\r]_ZGVdN4v_cos" } } */
> -/* { dg-final { scan-assembler "call\[^\n\r]_ZGVdN4v_sin" } } */
> +/* { dg-final { scan-assembler "call\[^\n\r]__?ZGVdN4v_cos" } } */
> +/* { dg-final { scan-assembler "call\[^\n\r]__?ZGVdN4v_sin" } } */
> 
> #ifdef __cplusplus
> extern "C" {
> --- ../_clean/gcc/testsuite/g++.dg/ext/pr81706.C  2017-10-26 
> 07:16:21.0 +0200
> +++ gcc/testsuite/g++.dg/ext/pr81706.C2017-11-09 21:41:36.0 
> +0100
> @@ -1,8 +1,8 @@
> // PR libstdc++/81706
> // { dg-do compile { target i?86-*-* x86_64-*-* } }
> // { dg-options "-O3 -mavx2 -mno-avx512f" }
> -// { dg-final { scan-assembler "call\[^\n\r]_ZGVdN4v_cos" } }
> -// { dg-final { scan-assembler "call\[^\n\r]_ZGVdN4v_sin" } }
> +// { dg-final { scan-assembler "call\[^\n\r]__?ZGVdN4v_cos" } }
> +// { dg-final { scan-assembler "call\[^\n\r]__?ZGVdN4v_sin" } }
> 
> #ifdef __cplusplus
> extern "C {
> 
> Is it OK?

Ok.

Re: [PATCH] avoid -Wstringop-truncation in Darwin bootstrap

[Mike Stump]

On Nov 10, 2017, at 12:36 PM, Martin Sebor  wrote:
> 
> The warning is included in -Wall

Ah, I missed that little detail the first time around.  -Wall is special in 
that we already just sanitize the source to pass it.  I assumed it was a 
non-wall flag someone added or wanted to add to the bootstrap.

Re: [PATCH] avoid -Wstringop-truncation in Darwin bootstrap

[Mike Stump]

On Nov 10, 2017, at 11:55 AM, Martin Sebor  wrote:
> A few not incorrect but not strictly intended (according to
> the function's original purpose) uses of strncpy trigger the
> new -Wstringop-truncation warning because they temporarily
> leave the copied string without a terminating nul.

If people want to tighten the language used in gcc itself, I'm fine with this.  
My take, I'd leave the review of that aspect of it to those that set the 
language gcc uses.

Re: [PATCH, GCC/testsuite] Fix retrieval of testname

[Mike Stump]

On Nov 9, 2017, at 10:00 AM, Thomas Preudhomme  
wrote:
> 
> When gcc-dg-runtest is used to run a test the test is run several times
> with different options. For clarity of the log, the test infrastructure
> then append the options to the testname. This means that all the code
> that must deal with the testcase itself (eg. removing the output files
> after the test has run) needs to remove the option name.

> Is this ok for trunk?

Ok.  Little scary the code is repeated so many time.  If someone wants to 
refactor it some, I could see the beauty in that.

Re: [libstdc++, patch] Fix build on APFS file system

[Mike Stump]

On Oct 18, 2017, at 7:51 AM, FX  wrote:
> 
> Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on 
> macOS 10.13 often fail (failure rate for “make -j2” to “make -j8” is about 
> 60% from my own builds and results reported by others): 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
> This is reproducible with several versions of GNU make.
> 
> Changing libstdc++’s makefile to mark install-headers with .NOTPARALLEL fixes 
> the issue. We've carried that patch in Homebrew (https://brew.sh) for a few 
> months now, and have had no report of build issues since then.
> 
> Bootstrapped and regtested on x86_64-apple-darwin17 (as well as other 
> platforms). OK to commit?

The patch seems like a rough bandaid to hide the real bug.  Better to identify 
the real bug.  If there is a missing dependency, then I'd like to think that 
adding the right dependency should resolve the issue.

Re: [patch] implement generic debug() functions for wide_int's

[Mike Stump]

On Oct 18, 2017, at 10:08 AM, Aldy Hernandez  wrote:
> 
> It looks like the generic debug() function for wide_int's is missing.

> OK for trunk?

Ok.

Re: [patch] avoid printing leading 0 in widest_int hex dumps

[Mike Stump]

On Oct 17, 2017, at 5:18 AM, Richard Sandiford  
wrote:
> 
> Aldy Hernandez  writes:
>> This produces confusing dumps to say the least

> That's the intended behaviour though.

>   0x0  -> (1 << 32) - 1 to infinite precision
>  (i.e. a positive value)
>   0x   -> -1

Another potential way around this would be to print the leading - when 
applicable and negate the number.  I don't have any strong opinions about this, 
but thought I would mention it.  This would then allow the trimming of the 
leading 0 without confusion.

Re: [openacc, testsuite, committed] Enable libgomp.oacc-*/declare-*.{c,f90} for non-nvidia devices

[Mike Stump]

On Oct 17, 2017, at 8:34 AM, Tom de Vries  wrote:
> 
>>> OK, if full testing is ok?
>> I believe this was fully intentional and the presence/absence of
>> explicit dg-do run can then be used to decide if it should loop through
>> options or not.
> 
> I don't see an explicit mention of ignoring dg-do-what-default in the 
> original submission

So, my guidance would be for fortran to behave generally speaking, like other 
languages and for this type of code to be predictable across languages and 
library components.  That's as far I can go, so, I'll have to punt the decision 
to domain experts to decide which direction they _want_ to go in.  If they 
don't know (or don't care or can't agree and want someone to break a tie), my 
inclination is to approve it.

Re: [PATCH, testsuite] Add dg-require-stack-size

[Mike Stump]

On Oct 16, 2017, at 3:16 AM, Tom de Vries  wrote:
> 
> I noticed gcc.dg/tree-ssa/ldist-27.c failing for nvptx due to a too large 
> stack size.

> OK for trunk?

Hum.  There is an existing mechanism (find-grep STACK_SIZE) in the tree to 
handle the same issue.  Did you consider using it?

I think I like the, trim the test case down solution better and STACK_SIZE can 
drive that.  Maybe a tree-saa person to weigh in on the test case.

But, if the optimization pass likes large things, certainly the patch is Ok.

Re: Allow non-wi wi

[Mike Stump]

> On Oct 6, 2017, at 2:35 AM, Richard Sandiford  
> wrote:
> 
> Richard Biener  writes:
>> On Tue, Oct 3, 2017 at 8:34 PM, Richard Sandiford
>>  wrote:
>>> This patch uses global rather than member operators for wide-int.h,
>>> so that the first operand can be a non-wide-int type.
>> 
>> Not sure why we had the in-class ones.  If we had some good arguments
>> they'd still stand.  Do you remember?
> 
> Not really, sorry.

No real good reason.  Copying double_int's style is most of the reason.  Just 
wanted to support the api clients used, and they, at the time, didn't require 
non-member versions.  If they had, we'd have done it outside.

Re: [GCC][PATCH][TESTSUITE][ARM][COMMITTED] Invert check to misalign in vect_hw_misalign (PR 78421)

[Mike Stump]

On Oct 6, 2017, at 5:48 AM, Tamar Christina  wrote:
> 
> I'm looking for permission to backport this patch to the gcc-7 branch to fix 
> the failing tests there as well.

Ok.

Re: [GCC][PATCH][TESTSUITE][ARM][COMMITTED] Invert check to misalign in vect_hw_misalign (PR 78421)

[Mike Stump]

On Sep 25, 2017, at 9:58 PM, Christophe Lyon  wrote:
> 
> Yes, thanks! I was missing the 'expr' part.
> 
> Here is what I have committed (r253187), to avoid further noise in the 
> results.

Yup, looks good.  Thanks.

Re: [GCC][PATCH][TESTSUITE][ARM][COMMITTED] Invert check to misalign in vect_hw_misalign (PR 78421)

[Mike Stump]

On Sep 23, 2017, at 10:52 AM, Christophe Lyon  
wrote:
> The attached patch would apply after reverting yours.
> I've applied it against r253072 (just before your patch) and the
> results are visible at:
> http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/253072-hw-misalign2/report-build-info.html
> 
> Do they match your expectations? It looks like a few testcases need to
> be adjusted,
> or new bugs are uncovered.
> 
> If the patch OK with a suitable ChangeLog entry?

So, I wasn't sure what you meant by the comment.  Below is an example of ! 
working.

% proc b {} { return 0 }
% set v [expr ![b]]
1
% set v [ expr !![b]]
0
% proc b {} { return 1 }
% set v [expr ![b]]
0
% set v [ expr !![b]]
1

Given that, if you want to use a simple set var value, you should just do that 
directly.  [b] is the placeholder for an [] expression, if you want to invert 
that.  v is the placeholder for the thing you want to set.  All the other bits 
should be used as given.  Given that code, I'd be interested in what you want 
to put in the comment, if any.

  set et_vect_hw_misalign_saved($et_index) [expr 
![check_effective_target_arm_vect_no_misalign]]

seems like what you want, does that work?

Re: [PATCH] PR target/80556

[Mike Stump]

On Sep 22, 2017, at 2:55 AM, Iain Sandoe  wrote:
> 
>> On 18 Sep 2017, at 22:08, Simon Wright  wrote:
>> 
>> On 18 Sep 2017, at 21:09, Iain Sandoe  wrote:
>>> 
> 
 If I propose this alternative patch, should it be a new post, or should I 
 continue this thread?
>>> 
>>> thanks for the patch.
>>> 
>>> The basic idea seems sound - as a workaround (as noted in comment #20 in 
>>> the PR, we should really rationalise the libgcc/crts stuff to reflect the 
>>> modern world, but these things take time...).
>>> 
>>> The patch as you have it would apply to every version of Darwin.
>>> 
>>> AFAICT from the published sources, i386 Darwin should be able to work with 
>>> the libgcc unwinder (and all earlier Darwin *have* to) - so I’ve proposed a 
>>> modified patch in the PR that makes the changes specific to m64 x86 and 
>>> doesn’t make any alteration for PPC and/or Darwin < 10.
>> 
>> That sounds like the right thing to do. I hadn't considered the older 
>> hardware/os issues (I only have kit back to macOS 10.11, Darwin 15).
> 
> So here’s the revised version with the comments slightly updated, checked 
> Darwin10,15,16 x86_64 and i386 in progress,
> OK if i386 succeeds?

Ok.

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 1/2] (header usage fix) remove unused system header includes

[Mike Stump]

I was hoping an RM would approve this as it seems just a hair beyond a normal 
darwin approval.  I'm fine with this, and it does help darwin.  Other ports 
should not care.

On Sep 18, 2017, at 10:30 AM, Jack Howarth  wrote:
> 
> Pinging for the final gcc 5.5 release.
> 
> On Mon, Aug 7, 2017 at 1:12 AM, Ryan Mounce  wrote:
>> 2017-08-05  Ryan Mounce  
>> 
>>cherry picked from trunk r235361
>>2016-04-22  Szabolcs Nagy  
>> 
>>* auto-profile.c: Remove  include.
>>* diagnostic.c: Remove  include.
>>* genmatch.c: Likewise.
>>* pretty-print.c: Likewise.
>>* toplev.c: Likewise
>>* c/c-objc-common.c: Likewise.
>>* cp/error.c: Likewise.
>>* fortran/error.c: Likewise.
>> ---
>> gcc/ChangeLog | 14 ++
>> gcc/auto-profile.c|  1 -
>> gcc/c/c-objc-common.c |  2 --
>> gcc/cp/error.c|  2 --
>> gcc/diagnostic.c  |  2 --
>> gcc/fortran/error.c   |  2 --
>> gcc/genmatch.c|  1 -
>> gcc/pretty-print.c|  2 --
>> gcc/toplev.c  |  2 --
>> 9 files changed, 14 insertions(+), 14 deletions(-)
>> 
>> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>> index 3b431ce83f4..f3280917ad8 100644
>> --- a/gcc/ChangeLog
>> +++ b/gcc/ChangeLog
>> @@ -1,3 +1,17 @@
>> +2017-08-05  Ryan Mounce  
>> +
>> +   Backport from mainline
>> +   2016-04-22  Szabolcs Nagy  
>> +
>> +   * auto-profile.c: Remove  include.
>> +   * diagnostic.c: Remove  include.
>> +   * genmatch.c: Likewise.
>> +   * pretty-print.c: Likewise.
>> +   * toplev.c: Likewise
>> +   * c/c-objc-common.c: Likewise.
>> +   * cp/error.c: Likewise.
>> +   * fortran/error.c: Likewise.
>> +
>> 2017-07-31  Jakub Jelinek  
>> 
>>PR sanitizer/81604
>> diff --git a/gcc/auto-profile.c b/gcc/auto-profile.c
>> index b8b02d174b4..a5e7225e338 100644
>> --- a/gcc/auto-profile.c
>> +++ b/gcc/auto-profile.c
>> @@ -21,7 +21,6 @@ along with GCC; see the file COPYING3.  If not see
>> #include "config.h"
>> #include "system.h"
>> 
>> -#include 
>> #include 
>> #include 
>> 
>> diff --git a/gcc/c/c-objc-common.c b/gcc/c/c-objc-common.c
>> index 344d4e2949c..c1ec601f93c 100644
>> --- a/gcc/c/c-objc-common.c
>> +++ b/gcc/c/c-objc-common.c
>> @@ -38,8 +38,6 @@ along with GCC; see the file COPYING3.  If not see
>> #include "langhooks.h"
>> #include "c-objc-common.h"
>> 
>> -#include   // For placement new.
>> -
>> static bool c_tree_printer (pretty_printer *, text_info *, const char *,
>>int, bool, bool, bool);
>> 
>> diff --git a/gcc/cp/error.c b/gcc/cp/error.c
>> index 0c8bd66a325..f502127f34f 100644
>> --- a/gcc/cp/error.c
>> +++ b/gcc/cp/error.c
>> @@ -44,8 +44,6 @@ along with GCC; see the file COPYING3.  If not see
>> #include "ubsan.h"
>> #include "internal-fn.h"
>> 
>> -#include // For placement-new.
>> -
>> #define pp_separate_with_comma(PP) pp_cxx_separate_with (PP, ',')
>> #define pp_separate_with_semicolon(PP) pp_cxx_separate_with (PP, ';')
>> 
>> diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
>> index c43162269ec..1c3815c9f3d 100644
>> --- a/gcc/diagnostic.c
>> +++ b/gcc/diagnostic.c
>> @@ -41,8 +41,6 @@ along with GCC; see the file COPYING3.  If not see
>> # include 
>> #endif
>> 
>> -#include  // For placement new.
>> -
>> #define pedantic_warning_kind(DC)  \
>>   ((DC)->pedantic_errors ? DK_ERROR : DK_WARNING)
>> #define permissive_error_kind(DC) ((DC)->permissive ? DK_WARNING : DK_ERROR)
>> diff --git a/gcc/fortran/error.c b/gcc/fortran/error.c
>> index 18e127f8748..2f76de50c9e 100644
>> --- a/gcc/fortran/error.c
>> +++ b/gcc/fortran/error.c
>> @@ -34,8 +34,6 @@ along with GCC; see the file COPYING3.  If not see
>> #include "diagnostic-color.h"
>> #include "tree-diagnostic.h" /* tree_diagnostics_defaults */
>> 
>> -#include  /* For placement-new */
>> -
>> static int suppress_errors = 0;
>> 
>> static bool warnings_not_errors = false;
>> diff --git a/gcc/genmatch.c b/gcc/genmatch.c
>> index 8f94ff09263..8f495616e2e 100644
>> --- a/gcc/genmatch.c
>> +++ b/gcc/genmatch.c
>> @@ -22,7 +22,6 @@ along with GCC; see the file COPYING3.  If not see
>> .  */
>> 
>> #include "bconfig.h"
>> -#include 
>> #include "system.h"
>> #include "coretypes.h"
>> #include "ggc.h"
>> diff --git a/gcc/pretty-print.c b/gcc/pretty-print.c
>> index 78d334eae88..6881d1aeabe 100644
>> --- a/gcc/pretty-print.c
>> +++ b/gcc/pretty-print.c
>> @@ -25,8 +25,6 @@ along with GCC; see the file COPYING3.  If not see
>> #include "pretty-print.h"
>> #include "diagnostic-color.h"
>> 
>> -#include // For placement-new.
>> -
>> #if HAVE_ICONV
>> #include 
>> #endif
>> diff --git a/gcc/toplev.c b/gcc/toplev.c
>> index 17d05121026..237e24ef34e 100644
>> 

Re: [PATCH 0/2] backport c++ header fixes to gcc-5-branch

[Mike Stump]

I was hoping an RM would approve this as it seems just a hair beyond a normal 
darwin approval.  I'm fine with this, and it does help darwin.  Other ports 
should not care.

On Sep 18, 2017, at 10:31 AM, Jack Howarth  wrote:
> 
> Pinging for the final gcc 5.5 release.
> 
> On Mon, Aug 7, 2017 at 1:12 AM, Ryan Mounce  wrote:
>> Fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
>> 
>> Bootstrap now succeeds using Xcode 9 toolchain.
>> 
>> Tested on macOS 10.13 beta, however same issue reported on macOS 10.12
>> with Xcode 9.
>> 
>> Ryan Mounce (2):
>>  (header usage fix) remove unused system header includes
>>  (header usage fix) include c++ headers in system.h
>> 
>> gcc/ChangeLog| 29 +
>> gcc/auto-profile.c   |  6 ++
>> gcc/c/c-objc-common.c|  2 --
>> gcc/config/sh/sh.c   |  2 +-
>> gcc/config/sh/sh_treg_combine.cc |  7 +++
>> gcc/cp/error.c   |  2 --
>> gcc/diagnostic.c |  2 --
>> gcc/fortran/error.c  |  2 --
>> gcc/fortran/trans-common.c   |  2 +-
>> gcc/genmatch.c   |  1 -
>> gcc/graphite-isl-ast-to-gimple.c |  2 +-
>> gcc/ipa-icf-gimple.c |  2 +-
>> gcc/ipa-icf.c|  2 +-
>> gcc/pretty-print.c   |  2 --
>> gcc/system.h | 12 
>> gcc/toplev.c |  2 --
>> 16 files changed, 51 insertions(+), 26 deletions(-)
>> 
>> --
>> 2.13.2 (Apple Git-90)
>> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [C++ PATCH] Renames/adjustments of 1z to 17

[Mike Stump]

On Sep 14, 2017, at 1:26 PM, Jakub Jelinek  wrote:
> 
> Given https://herbsutter.com/2017/09/06/c17-is-formally-approved/
> this patch makes -std=c++17 and -std=gnu++17 the documented options

> --- gcc/doc/invoke.texi.jj2017-09-12 21:57:57.0 +0200
> +++ gcc/doc/invoke.texi   2017-09-14 19:32:34.342959968 +0200
> @@ -1870,15 +1870,15 @@ GNU dialect of @option{-std=c++14}.
> This is the default for C++ code.
> The name @samp{gnu++1y} is deprecated.
> 
> -@item c++1z
> -The next revision of the ISO C++ standard, tentatively planned for
> -2017.  Support is highly experimental, and will almost certainly
> -change in incompatible ways in future releases.
> -
> -@item gnu++1z
> -GNU dialect of @option{-std=c++1z}.  Support is highly experimental,
> -and will almost certainly change in incompatible ways in future
> -releases.
> +@item c++17
> +@itemx c++1z
> +The 2017 ISO C++ standard plus amendments.
> +The name @samp{c++1z} is deprecated.
> +
> +@item gnu++17
> +@itemx gnu++1z
> +GNU dialect of @option{-std=c++17}.
> +The name @samp{gnu++17} is deprecated.

I'd be tempted to say leave all this, and march 1z -> 2a for the _next_ 
standard.  2020 or so is a good first stab at the date.

> -or an unspecified value strictly larger than @code{201402L} for the
> -experimental languages enabled by @option{-std=c++1z} and
> -@option{-std=gnu++1z}.
> +@code{201703L} for the 2017 C++ standard.

Likewise.


Anyway, the testsuite portion is obvious and I reviewed it for correctness and 
Ok.

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 6/13] D: Add D language support to GCC proper.

[Mike Stump]

On Sep 11, 2017, at 9:34 AM, Jeff Law  wrote:
> 
> On 05/28/2017 03:15 PM, Iain Buclaw wrote:
>> This patch adds D language support to GCC itself.
>> 
>> ---
>> 
>> 
>> 06-d-gcc-proper.patch
>> 
>> 
>> gcc/ChangeLog
>> 
>>  * config/rs6000/rs6000.c (rs6000_output_function_epilogue):
>>  Support GNU D by using 0 as the language type.
>>  * dwarf2out.c (is_dlang): New function.
>>  (gen_compile_unit_die): Use DW_LANG_D for D.
>>  (declare_in_namespace): Return module die for D, instead of adding
>>  extra declarations into the namespace.
>>  (gen_namespace_die): Generate DW_TAG_module for D.
>>  (gen_decl_die, dwarf2out_decl): Handle CONST_DECLSs for D.
>>  * gcc.c (default_compilers): Add entries for ".d", ".dd" and ".di".This 
>> is fine when prereqs are approved.
> 
> jeff

ENOCOMMENT

Re: [doc,libgomp] Updates for www.openacc.org URLs

[Mike Stump]

On Sep 8, 2017, at 5:27 AM, Gerald Pfeifer  wrote:
> 
> I committed the patch below, but am wondering whether we really,
> really, really need as many instances of one and the same URL in 
> one section of the documentation?  Can we simplify this somehow?

Curious that they don't link to 
https://www.openacc.org/sites/default/files/inline-files/OpenACC_2_0_specification.pdf
 for that actual document.  The generic link to the top matter can be in the 
first paragraph.  It would be nice if all the links could be links to the 
actual section, something like 
https://www.openacc.org/sites/default/files/inline-files/OpenACC_2_0_specification.pdf#page=31,
 but I guess that would be a little bit of work.  :-)  Not sure this is what 
you wanted to hear.

Re: [PATCH v2] Python testcases to check DWARF output

[Mike Stump]

On Sep 4, 2017, at 2:22 AM, Pierre-Marie de Rodat  wrote:
> 
> I would like to ping for the patch I submitted at 
> . Thank you in 
> advance!

I've included the dwarf people on the cc list.  Seems like they may have an 
opinion on the direction or the patch itself.  I was fine with the patch from 
the larger testsuite perspective.

Re: [TESTSUITE]Use strncpy instead of strcpy in testsuite/gcc.dg/memcmp-1.c

[Mike Stump]

On Aug 30, 2017, at 8:31 AM, Renlin Li  wrote:
> memcpy is better than strncpy in this case.
> Here is the updated patch.

Ok.

Re: [PATCH] [docs] Explain how to use multiple file-name patterns in RUNTESTFLAGS

[Mike Stump]

On Aug 22, 2017, at 11:53 AM, Daniel Santos  wrote:
> 
> OK, the problem is at line 4014 of gcc/Makefile.in:
> 
>  $(MAKE) TESTSUITEDIR="$(TESTSUITEDIR)"
> RUNTESTFLAGS="$(RUNTESTFLAGS)" \
>check-parallel-$* \

So, this is typical of sh scripting.  Most kids don't quote and know how to 
quote in other than trivial cases.  It is one of the reasons why scripting is 
both better and worse.  sh from day 1 should have had a quote function that 
would quote the operand, it doesn't.  If it did, we'd put $(quote ...) in there 
instead of "..." and it would just work.

> I presume that the solution would be to re-escape the contents of
> RUNTESTFLAGS.

Yes.  The annoyance factor is so high, that no one ever does.  Feel free rot 
ignore the problem.

Re: [PATCH] [docs] Explain how to use multiple file-name patterns in RUNTESTFLAGS

[Mike Stump]

On Aug 22, 2017, at 10:44 AM, Daniel Santos  wrote:
> 
> OK, how's this one?

Ok.

Re: Remove the frame size argument from function_prologue/epilogue

[Mike Stump]

On Aug 21, 2017, at 4:12 AM, Richard Sandiford  
wrote:
> 
> Later patches will add support for frame sizes that are a run-time
> invariant but not a compile-time constant.

I'm assuming dwarf and C++ exceptions will remain working.  :-)

Re: [PATCH] [docs] Explain how to use multiple file-name patterns in RUNTESTFLAGS

[Mike Stump]

On Aug 22, 2017, at 10:32 AM, Daniel Santos  wrote:
> 
>>  I would suggest "escaped or quoted."
>> The whole argument to RUNTESTFLAGS can be quoted in either single
>> or double quotes and, AFAICT, so can the space-separated test
>> names within it.
> 
> Well, mysteriously, double quotes do not work.

Did you try the obvious:

"\"pdf pdf\" pdf"

?  I think it should work fine.

Re: [PATCH] [docs] Explain how to use multiple file-name patterns in RUNTESTFLAGS

[Mike Stump]

On Aug 22, 2017, at 8:58 AM, Martin Sebor  wrote:
> 
> On 08/21/2017 07:41 PM, Daniel Santos wrote:
>> It took me a while to figure out how to do this so I figured that it should 
>> be
>> in the docs.  OK for trunk?

Oh, yeah, with the correction mentioned, Ok.

Re: [PATCH] [docs] Explain how to use multiple file-name patterns in RUNTESTFLAGS

[Mike Stump]

> On Aug 22, 2017, at 8:58 AM, Martin Sebor  wrote:
> 
> On 08/21/2017 07:41 PM, Daniel Santos wrote:
>> It took me a while to figure out how to do this so I figured that it should 
>> be
>> in the docs.  OK for trunk?
>> 
>>  * doc/install.texi: Add more details on selecting multiple tests.
> 
> Thank you!  It had taken me some time to figure this out.
> 
>> +The file-matching expression following @var{filename}@command{.exp=} is 
>> treated
>> +as a series of whitespace-delimited glob expressions so that multiple 
>> patterns
>> +may be passed, although any whitespace must either be escaped or surrounded 
>> by
>> +tick marks if multiple expressions are desired. For example,

> Do you mean single quotes?  I would suggest "escaped or quoted."


Yes, I agree.  Please, no tick, slightly too informal.

Re: [PATCH] Fix building of cross compiler (PR target/81753).

[Mike Stump]

On Aug 15, 2017, at 6:35 AM, Martin Liška  wrote:
> 
> Simple fix for the PR where we wrongly combine extra_objs.

> Ready to install the patch?

Ok.

>   PR target/81753
>   * config.gcc: Respect previously set extra_objs in case
>   of darwin target.

Re: [testsuite, i386] Require -static support in gcc.dg/pie-static-[12].c (PR testsuite/81793)

[Mike Stump]

On Aug 12, 2017, at 9:03 AM, Rainer Orth  wrote:
> 
> The new gcc.dg/pie-static-[12].c testcases FAIL on several systems:
> 
> * Solaris 11.4 has PIE support, but lacks static libc, libm
> 
> * Linux without the static libc, libm installed
> 
> The following patch fixes this by requiring both PIE and -static
> support.
> 
> Tested with the appropriate runtest invocations on i386-pc-solaris2.11
> and x86_64-pc-linux-gnu (where the tests come up as UNSUPPORTED; I don't
> have a Linux system with static libc/libm installed), installed on
> mainline.
> 
> The tests also FAIL on Darwin/x86_64, but the failure mode is different:
> for -static, the executable is linked with -lcrt0.o (done this way to
> locate crt0.o in the linker's search path, cf. config/darwin.h
> (STARTFILE_SPEC)), but neither on Darwin 11 nor on Darwin 17 could I
> find where crt0.o would come from, so I've left this part alone.

darwin isn't exactly like other systems.  There is no crt0.o and static is more 
special than you can imagine.  There was once 1 program that did a static link, 
but one was exceptionally special.

Indeed, one way to implement it would be as a request option, and then ignore 
the parts that don't make sense for the platform.  In that case, -static-libgcc 
and friends might be the end semantics.

Re: [PATCH][testsuite] Add check_effective_target_autoincdec

[Mike Stump]

On Aug 9, 2017, at 5:50 AM, Richard Earnshaw (lists)  
wrote:
> 
> On 09/08/17 12:37, Wilco Dijkstra wrote:
>> Richard Earnshaw wrote:
>>> Except that I think this would be better done as an 'effective target'
>>> test; something like
>>> 
>>> dg-require-effective-target autoincdec
>> 
>> Right I figured out how to do this - not trivial as it needs a secret flag 
>> in the
>> glob call - if anyone knows a better way of doing this I'd like to know!
>> 
>> 
>> Add check_effective_target_autoincdec that returns true if a target
>> runs the auto_inc_dec optimization pass.
>> 
>> OK for commit?
>> 
> 
> LGTM.  Please give Mike 24 hours to respond, before committing.

Ok.  I'm happy for things like this to just go in on port or front-end review 
alone.  It's a pretty standard sort of change, dare say, kinda trivial.

Re: [PATCH 0/2] Python testcases to check DWARF output

[Mike Stump]

On Jul 27, 2017, at 2:07 AM, Pierre-Marie de Rodat  wrote:
> On 07/27/2017 09:52 AM, Richard Biener wrote:
>>> I'm fine with the direction if a reviewer wants to go in that
>>> direction.  I wish python didn't have a built-in speed penalty,
>>> that's the only downside I don't like about it.  Aside from that,
>>> even switching all of the testsuite to be python based isn't a
>>> terrible idea.
>> But is it worse than TCL?

python is likely 2x faster than tcl, if you have one instance per testsuite 
run.  The problem is, for the work required, it's cheaper to do the work once 
to cut over to a new language.  I'd rather switch to some other language that 
can come closer to the speed of compiled C code, yet in the scripting family.  
I don't have a pointer to a better solution than python at this time.  I'd not 
be opposed to switching to python, it should be faster, just as safe, a bit 
easier for new people to code in, and more people who know it and use it.  I 
think python is funner to code in than tcl.  Cutting the entire testsuite over 
at once, might well be more than any one person can contribute, but, we could 
cut over subtrees, as people donate time; if people want to go in that 
direction.  This can't be a 1 person decision, but rather a consensus building 
type decision.  What do others think?

> Good point. Actually for Python there are ways to make it faster. If we can 
> somehow manage to have a limited set of Python interpreter instances (instead 
> of one per test), we could use pypy, which is very good I heard to make long 
> running instances fast.

Yes.  One instance would help ensure the performance is good.  I don't have a 
firm grasp of startup time to know just how critical it is.  Also, I don't have 
a good grasp on memory pressures that python would create, say, compared to how 
we use tcl.

Re: RFC [testsuite] Obey --load-average

[Mike Stump]

On Aug 2, 2017, at 10:34 PM, Daniel Santos  wrote:
> 
> I'm working on a patch to modify the testsuite to obey the
> --load-average value if one is passed to make.

The code seems like a reasonable approach.  Love to see numbers and test 
scenarios so that others can tell if you've covered their use case.  -j 100 is 
different from -j 4.  People can help chip in numbers, if they have senarios 
that are less represented.

I don't usually share or use -l, so I don't think I can help test it.  I do 
wonder if it might be better to use a higher -j (I use -j somewhere between 24 
and 50) and use a load limit, even in my situation.

The only concern would be that of portability.  Seems reasonable to let it in 
and fix up any issues found after the fact.  I like how you ensure low impact 
when -l isn't used.

Minor nit, tollerance -> tolerance.

Re: [PATCH v2 9/13] D: D2 Testsuite Dejagnu files.

[Mike Stump]

On Jun 24, 2017, at 10:52 AM, Iain Buclaw  wrote:
> Added a few extra comments for procedures, altering dmd2dg to write
> out flags converted to dejagnu in-place, instead on newlines.
> 
> In the other testsuite patch, added new tests to accompany fixes that
> have been made since the last patch.

Ok.  From here on out, you can self-approve the usual and customary testsuite 
changes as you become maintainer for the front-end.

If you want any extra testsuite reviews, you can always ask.

Re: [PATCH 0/2] Python testcases to check DWARF output

[Mike Stump]

On Jul 26, 2017, at 9:00 AM, Pierre-Marie de Rodat  wrote:
> At the last GNU Cauldron, Richard Biener and I talked about DWARF output
> testing. Except for guality tests, which are disabled on several
> targets, the only way tests check the DWARF is scanning the annotated
> assembly (-dA), making it hard to write reliable tests.

> Anyway, Richard and I discussed about doing something similar in-tree,
> and here is a candidate set of patches to achieve that

I'm fine with the direction if a reviewer wants to go in that direction.  I 
wish python didn't have a built-in speed penalty, that's the only downside I 
don't like about it.  Aside from that, even switching all of the testsuite to 
be python based isn't a terrible idea.

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 12/17] Add server.h and server.c

[Mike Stump]

On Jul 26, 2017, at 7:50 AM, David Malcolm  wrote:
> 
> On Wed, 2017-07-26 at 23:35 +0900, Oleg Endo wrote:
>> On Mon, 2017-07-24 at 16:05 -0400, David Malcolm wrote:
>>> 
>>> +
>>> +You should have received a copy of the GNU General Public License
>>> +along with GCC; see the file COPYING3.  If not see
>>> +.  */
>>> +
>>> +#ifndef GCC_SERVER_H
>>> +#define GCC_SERVER_H
>>> +
>>> +/* Wrapper aroung "int" for file descriptors.  */
>>~~~^
>>  around :)
> 
> Thanks; fixed in my working copy.
> 
> Someone pointed out to me privately that instead/as well as serving on
> a port, we could be launched as a subprocess by the IDE, and serve the
> RPC over stdin/stdout; this would be simpler for IDEs to cope with.  I
> may have a look at supporting that for the next version.

The security threat modeling I think is nicer if you read and write 
stdin/stdout.  Once you open a port, you open a security hole.  By not having 
holes by design, we avoid most of this space, which I see as a good thing.



smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 1/2] simplify-rtx: The truncation of an IOR can have all bits set (PR81423)

[Mike Stump]

On Jul 25, 2017, at 3:10 PM, Segher Boessenkool  
wrote:
> 
> On Tue, Jul 25, 2017 at 12:30:13PM +0100, Kyrill Tkachov wrote:
>> We sometimes use the __mode__ attribute to force certain sizes in C types.
>> For example: typedef int ditype __attribute__ ((mode (DI)));
>> Maybe you can do this to force the right sizes. I don't know if there are 
>> any targets
>> that don't support DImode ops though :)
> 
> DImode isn't necessarily the same size on all targets, a byte isn't
> always eight bits.

As a practical matter, presently a byte is always eight bits and a DI is always 
8 bytes in gcc.  :-)

Pretending otherwise is a fool's errand.  We like to kid ourselves that a 
character isn't always 8 bits, but the first person to want to do that will 
discover the lie it is.



smime.p7s
Description: S/MIME cryptographic signature

Re: Deprecate DBX/stabs?

[Mike Stump]

On Jul 21, 2017, at 9:03 AM, Jim Wilson  wrote:
> There is also the matter of SDB_DEBUG which is still supported, and is
> no longer used by anyone, as we have already deprecated all of the
> COFF targets that were using it.  SDB support for C++ is even worse
> than the DBX support.  This should be no problem to deprecate and
> remove.  We could perhaps even just drop it without bothering to
> deprecate it first.

I think that's reasonable.  I haven't used adb and sdb in years.  :-)

Re: Deprecate DBX/stabs?

[Mike Stump]

On Jul 21, 2017, at 6:07 AM, Nathan Sidwell  wrote:
> 
> [darwin, cygwin, rx maintainers, you might have an opinion]

darwin going forward is a DWARF platform, so, shouldn't be a heartache for real 
folks.  For ancient machines, ancient compilers might be a requirement.  
Generally, I like keeping things; but cleanups and removals are a part of life, 
and eventually the old should be removed. I'd not stand in the way of such 
removal.  If we were within 5 years of such a transition point, I'd argue to 
keep it for at least 5 years.  But, the switch for darwin was Oct 26th, 2007.  
10 years I think is a nice cutover point for first tier things.  Beyond 10, and 
I'd say, you are dragging your feet.  If _all_ the code for DBX were in my port 
file, I'd be tempted to keep it indefinitely.  It's not, so, that's not 
possible/reasonable.

Iain, do you still have the G5s?  :-)  Do they run 8 or 9?  What do you think?  
Seem reasonable?

The 64_BIT x86 darwin question likely can be be flipped to default to dwarf; 
so, even that isn't an issue.

Re: PING: [PATCH v2 0/2] [testsuite, libgcc] PR80759 Fix FAILs on Solaris and Darwin

[Mike Stump]

On Jul 17, 2017, at 9:16 AM, Daniel Santos  wrote:
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00025.html

> Mike or Iain,
> Can one of you review changes for Darwin please?

Ok.

Re: [PATCH][PING] Improve extraction of changed file in contrib/mklog

[Mike Stump]

On Jul 17, 2017, at 12:22 AM, Yuri Gribov  wrote:
> 
> Currently mklog will fail to analyze lines like this in patches:
> diff -rupN gcc/gcc/testsuite/lib/profopt.exp
> gcc-compare-checks/gcc/testsuite/lib/profopt.exp
> (it fails with "Error: failed to parse diff for ... and ...").
> 
> This patch fixes it. Ok for trunk?

Ok.

Re: [PATCH] Print relative names in UNSUPPORTED AutoFDO tests

[Mike Stump]

On Jul 9, 2017, at 12:00 PM, Yuri Gribov  wrote:
> 
> This patch fixes AutoFDO Dejagnu tests to print relative filenames
> instead of absolute ones when AutoFDO is unsupported. This is to
> prevent spurious differences in dg-cmp-results.sh, like this:
>  NA->UNSUPPORTED:
> /home/yugr/src/gcc-57371/gcc/testsuite/g++.dg/bprob/g++-bprob-1.C
> -fauto-profile
>  UNSUPPORTED->NA:
> /home/yugr/src/gcc/gcc/testsuite/g++.dg/bprob/g++-bprob-1.C
> -fauto-profile
> 
> Ok for trunk?

Ok.

Seeing the change in test case name would be useful.  It should have 
g++.dg/bprob/g++-bprob-1.C in the name, not just g++-bprob-1.C.

Re: [PATCH] Ignore random output from Asan tests in dg-cmp-results

[Mike Stump]

On Jul 10, 2017, at 2:21 PM, Mike Stump <mikest...@comcast.net> wrote:
> 
> Someone with such a system will have to drill down into why. 

Found it, fixed in dejagnu 1.5.3, just use a newer dejagnu, 1.5.3 or later 
should be fine.

Apparently, I should have just checked it _first_.  I didn't expect the fix to 
lie there.

Re: [PATCH] Ignore random output from Asan tests in dg-cmp-results

[Mike Stump]

On Jul 10, 2017, at 2:44 AM, Yuri Gribov  wrote:
> 
> On Mon, Jul 10, 2017 at 10:32 AM, Thomas Preudhomme
>  wrote:
>> Hi Yuri,
>> 
>> On 09/07/17 20:06, Yuri Gribov wrote:
>>> 
>>> Hi,
>>> 
>>> Currently dg-cmp-results fails to compare fails in Asan tests because
>>> their output includes failing process id:
>>> NA->FAIL: c-c++-common/asan/bitfield-1.c   -O0  output pattern test,
>>> is ==18161==ERROR
>>> FAIL->NA: c-c++-common/asan/bitfield-1.c   -O0  output pattern test,
>>> is ==26667==ERROR
>>> 
>>> This patch fixes this. I also did some fairly standard refactoring to
>>> improve stability and get rid of code dup.
>> 
>> 
>> I'm not familiar with asan but why not fix asan tests to not print the pid
>> instead?
> 
> The error message is printed by Asan runtime, not by tests themselves.
> Asan maintainers are typically unwilling to change output format of
> their messages as there may already be users who rely on it (e.g.
> using specific regexes in their scripts, etc.).

They don't have to change it.  There is a driver for asan tests in 
lib/asan-dg.exp that I believe has the code in it that causes this, and where 
the fix likely would be.

Indeed, in trunk, I see:

  fail "$testname output pattern test"

so, this looks like a local change in your tree.  Where does do the failing 
tests come from?  Change the failure line to fail "is_this_it", and see if the 
output is then deterministic; if so, you've identified the line.  Next, show us 
what is in your tree for that line; and we can tell you how it is wrong.

In this case, it feels like:

r205799 | rsandifo | 2013-12-09 00:04:57 -0800 (Mon, 09 Dec 2013) | 4 lines

gcc/testsuite/
* lib/asan-dg.exp (asan-gtest): Remove expected output from the
pass/fail line and add it to the log instead.


fixes the issue, but, for that to be the case, you'd have to have some really 
old unmaintained branch, or a bad copy of the file were the updates weren't 
also taken.  I've checked the results list, and certainly:

  https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg00858.html

has the bad line, so  clearly something causes it.  [ searching ]

jit.exp has:

fail "${executable-name} output pattern test, is ${output}, should 
match $texttmp"

bad, bad, bad line.  Try fixing this to just be:

fail "${executable-name} output pattern test"

Not sure why fixes from 2013 never made it into that file.  If so, also update 
the pass line.

But, this raises the next interesting question.  Is this is jit test?  If not, 
jit is supposed to _undo_ all of it's changes to the environment.  I think it 
is leaking this routine into future unrelated test cases?  The jit people would 
have to chime in.  In the full log, if you run with -v, do you see:

  jit-run-executable:

just above the test case?  If so, and this isn't a jit test case, will confirm 
leakage.  If you run just the single .exp file this comes from, you can also 
tell if this is just leakage.  By running the single .exp file, (not jit.exp), 
if the output is then stable, then it is jit.exp likely leaking.

When I run with -j35, I don't see the ", " version of the test case name:

testsuite/gcc18/gcc.log:PASS: gcc.dg/pr67786.c output pattern test

in a check-gcc, but others do see the ", " version of the same test case:

FAIL: gcc.dg/pr67786.c output pattern test, is , should match 15

from https://gcc.gnu.org/ml/gcc-testresults/2017-07/msg00858.html.  One can run 
one in isolation like this:

$ make RUNTESTFLAGS='dg.exp=pr67786.c' check-gcc

$ grep 'output pattern' testsuite/gcc/gcc.log
PASS: gcc.dg/pr67786.c output pattern test

Someone with such a system will have to drill down into why.  Bill Seurer seems 
able to reliably see the problem as well, so you're not alone.  He is running 
dejagnu 1.5, I'm running 1.5.3, not sure if it is dejagnu related.  What 
version are you running?  You could try 1.5.3 and see if that fixes it.

My builds are without jit enabled.  Are you building with jit on?  What do you 
see for pr67786 in the full testsuite run?  When you run as above?

Re: [PATCH] Ignore random output from Asan tests in dg-cmp-results

[Mike Stump]

On Jul 9, 2017, at 12:06 PM, Yuri Gribov  wrote:
> 
> Currently dg-cmp-results fails to compare fails in Asan tests because
> their output includes failing process id:
> NA->FAIL: c-c++-common/asan/bitfield-1.c   -O0  output pattern test,
> is ==18161==ERROR
> FAIL->NA: c-c++-common/asan/bitfield-1.c   -O0  output pattern test,
> is ==26667==ERROR
> 
> This patch fixes this. I also did some fairly standard refactoring to
> improve stability and get rid of code dup.
> 
> Ok for trunk?

I'd rather have this sorted out upstream of the compare utility.

Re: [PATCH] gcc/doc: list what version each attribute was introduced in

[Mike Stump]

On Jul 7, 2017, at 10:01 AM, Jeff Law  wrote:
> 
> On 07/06/2017 07:25 AM, Daniel P. Berrange wrote:
>> There are several hundred named attribute keys that have been
>> introduced over many GCC releases. Applications typically need
>> to be compilable with multiple GCC versions, so it is important
>> for developers to know when GCC introduced support for each
>> attribute.

> Keying on version #s is generally a terrible way to make your code
> portable.

> It's far better to actually *test* what your particular compiler
> compiler supports

So, if someone wanted to explore ways to make code that uses these better; a 
possibility might be to use __has_builtin a la clang:

  https://clang.llvm.org/docs/LanguageExtensions.html

It also has __has_feature and __has_extension.  At least it seems reasonably 
complete, and then people can feature test specific bits on a fine grained 
basis.

It doesn't solve history (without a re-release of old versions), but, it can 
provide a framework for solving the problem for the future.

Re: [PATCH] PR target/80556

[Mike Stump]

On Jun 9, 2017, at 6:57 AM, Simon Wright  wrote:
> 
> This PR was raised because of a bootstrap failure on Darwin.

> A question: I've checked for x86_64-apple-darwin*, is this OK or
> should it be more restrictive?

That seems ok.

Ok.

If anyone sees any fallout from this, please speak up.  I'm hoping this isn't a 
back port candidate.

Re: [Patch testsuite]

[Mike Stump]

On Jun 26, 2017, at 1:56 PM, Dominique d'Humières <domi...@lps.ens.fr> wrote:
> 
>> Le 26 juin 2017 à 20:35, Mike Stump <mikest...@comcast.net> a écrit :
>> On Jun 26, 2017, at 2:26 AM, Dominique d'Humières <domi...@lps.ens.fr> wrote:
>>> 
>>> Is it OK to commit the following patch (darwin only)?
>> 
>> Ok.  As for [0-9a-f]*ing the numbers, at least 1 of test cases should retain 
>> the actual number check.  I'm fine with the resting being an RE, if someone 
>> wants to do that.
> 
> Which test case should retain the actual number check? and could elaborate 
> why? These tests are fragile and the RE have already been changed in the past.

This was commentary on the other comment about using REs instead.  You can 
ignore it, if you want.  As for which test case, I'd have to closely examine 
them to determine that.  I've not done that.  Technically, you want to check 
all the ones that have items in them that aren't reflected in other test cases 
that check the value.

Re: [Patch testsuite]

[Mike Stump]

On Jun 26, 2017, at 11:35 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
> 
> Mike Stump <mikest...@comcast.net> writes:
> 
>> On Jun 26, 2017, at 2:34 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> 
>> wrote:
>>> 
>>>> Is it OK to commit the following patch (darwin only)?
>>> 
>>> this patch needs a ChangeLog entry (and preferably a description of the
>>> problem you're fixing ;-)
>> 
>> Actually, the CL isn't required, testsuite is special that way.
> 
> I believe it is,

That's way I sent the email.  It's been this way for a very long time.  I don't 
recall participating in a consensus building exercise where we changed the 
requirement, maybe I was sleeping?  If you have a pointer to a thread where we 
changed it, that'd be fine.  I'm happy to update my notion if we changed it.  
The doc page says:

  There is no established convention on when ChangeLog entries are to be made 
for testsuite changes

so, certainly no one reflected any such change in the web pages yet.  I'd 
rather consensus build rather than you or I just passing an edict.  Last time 
we spoke about ChangeLogs, the direction was to eliminate them entirely in 
preference to the git checkin comments, so, not sure we'd go in that direction 
today.

Re: [Patch testsuite]

[Mike Stump]

On Jun 26, 2017, at 2:26 AM, Dominique d'Humières  wrote:
> 
> Is it OK to commit the following patch (darwin only)?

Ok.  As for [0-9a-f]*ing the numbers, at least 1 of test cases should retain 
the actual number check.  I'm fine with the resting being an RE, if someone 
wants to do that.

Re: [Patch testsuite]

[Mike Stump]

On Jun 26, 2017, at 2:34 AM, Rainer Orth  wrote:
> 
>> Is it OK to commit the following patch (darwin only)?
> 
> this patch needs a ChangeLog entry (and preferably a description of the
> problem you're fixing ;-)

Actually, the CL isn't required, testsuite is special that way.

Re: [PATCH v2 9/13] D: D2 Testsuite Dejagnu files.

[Mike Stump]

On Jun 24, 2017, at 10:52 AM, Iain Buclaw  wrote:
> 
> On 28 May 2017 at 23:16, Iain Buclaw  wrote:
>> This patch adds D language support to the GCC testsuite.
>> 
>> As well as generating the DejaGNU options for compile and link tests,
>> handles the conversion from DMD-style compiler options to GDC.
>> 
>> ---
> 
> Added a few extra comments for procedures, altering dmd2dg to write
> out flags converted to dejagnu in-place, instead on newlines.
> 
> In the other testsuite patch, added new tests to accompany fixes that
> have been made since the last patch.

Ok.

Re: [committed] Fix -fstack-check with really big frames on aarch64

[Mike Stump]

On Jun 22, 2017, at 10:21 AM, Jeff Law  wrote:
> 
> This time with the test.  Just #includes 20031023-1.c with a suitable dg
> directive to ensure we compile with -fstack-check.
> 
> I won't be surprised if other targets fail this test.  It's a really big
> stack frame :-)

The int16 people are going to hate you!  :-)  Checking, oh, wait, no, they 
should be fine.

> index 000..4058eb58709
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/stack-check-1.c
> @@ -0,0 +1,2 @@
> +/* { dg-additional-options "-fstack-check" } */
> +#include "20031023-1.c"

Aren't you missing:

  /* { dg-require-effective-target untyped_assembly } */

?

Re: [PATCH][RFA] Fix -fstack-check with really big frames on aarch64

[Mike Stump]

On Jun 22, 2017, at 8:32 AM, Jeff Law  wrote:
> 
> Sure.  I'll do something with 20031023-1.c to ensure it or an equivalent
> is compiled with -fstack-check.  That isn't totally unexpected.   I
> would have also been receptive to adding -fstack-check to the torture flags.

Ouch.  Though stack checking might be important, the feature is very, very 
narrow, and once tested, if unlike to ever break or interact badly with other 
work.  I'd rather people default it to on, run the entire suite, fix all bugs 
(with test cases added for all the bugs), then turn it back off.  Additional 
torture passes are expensive; we use them for things that do regress, that are 
important, that have thousands of moving parts to keep them working.  O2, -g 
are good examples for things that by their nature, likely will always be best 
served by torture options.  Now, if you want to focus on security for 1-3 
months, add it, fix all the bugs, then turn it off; it would be a great way to 
get all the bugs filed, if you want.

Re: [PATCH, GCC/contrib] Fix variant selection in dg-cmp-results.sh

[Mike Stump]

On Jun 21, 2017, at 8:30 AM, Thomas Preudhomme  
wrote:
> 
> Commit r249422 to dg-cmp-results.sh broke the variant selection feature

> 2017-06-21  Thomas Preud'homme  
> 
>   * dg-cmp-results.sh: Restore filtering on target variant.
> 
> 
> Tested on a file with multiple variants which now gives sane results.
> 
> Is this ok for trunk?

Ok.

Re: [PATCH, contrib] Support multi-tool sum files in dg-cmp-results.sh

[Mike Stump]

On Jun 20, 2017, at 8:31 AM, Thomas Preudhomme  
wrote:
> 
> 2017-06-14  Thomas Preud'homme  
> 
>   * dg-cmp-results.sh: Keep test result lines rather than throwing
>   header and summary to support sum files with multiple tools.
> 
> 
> Is this still ok?

Ok.