Re: Follow-up-fix 2 to "[PATCH] Move PR84877 fix elsewhere (PR bootstrap/88450)"

[Hans-Peter Nilsson]

> Date: Tue, 30 Apr 2019 11:37:17 -0600
> From: Jeff Law 

> On 2/10/19 6:09 PM, Hans-Peter Nilsson wrote:
> > Here's the follow-up, getting rid of the observed
> > alignment-padding in execute/930126-1.c: the x parameter in f
> > spuriously being runtime-aligned to BITS_PER_WORD.  I separated
> > this change because this is an older issue, a change introduced
> > in r94104 where BITS_PER_WORD was chosen perhaps because we
> > expect register-sized writes into this area.  Here, we instead
> > align to a minimum of PREFERRED_STACK_BOUNDARY, but of course
> > gated on !  STRICT_ALIGNMENT.
> > 
> > Regtested cris-elf and x86_64-pc-linux-gnu.
> > 
> > Ok to commit?
> > 
> > gcc:
> > * function.c (assign_parm_setup_block): If not STRICT_ALIGNMENT,
> > instead of always BITS_PER_WORD, align the stacked
> > parameter to a minimum PREFERRED_STACK_BOUNDARY.
> Interestingly enough in the thread from 2005 Richard S suggests that he
> could have made increasing the alignment conditional on STRICT_ALIGNMENT
> but thought that with the size already being rounded up it wasn't worth
> it and that we could take advantage of the increased alignment elsewhere.
> 
> I wonder if we could just go back to that idea.  Leave the alignment as
> DECL_ALIGN for !STRICT_ALIGNMENT targets and bump it up for
> STRICT_ALIGNMENT targets?
> 
> So something like
> 
> align = STRICT_ALIGNMENT ? MAX (DECL_ALIGN (parm), BITS_PER_WORD) :
> DECL_ALIGN (parm)

That'd work for me, I think.  Testing in progress.  Thanks.
Almost obvious, but: is this ok; what you meant?

gcc:
* function.c (assign_parm_setup_block): Raise alignment of
stacked parameter only for STRICT_ALIGNMENT targets.

Index: gcc/function.c
===
--- gcc/function.c  (revision 27)
+++ gcc/function.c  (working copy)
@@ -2912,7 +2912,11 @@ assign_parm_setup_block (struct assign_p
   size_stored = CEIL_ROUND (size, UNITS_PER_WORD);
   if (stack_parm == 0)
 {
-  SET_DECL_ALIGN (parm, MAX (DECL_ALIGN (parm), BITS_PER_WORD));
+  HOST_WIDE_INT parm_align
+   = (STRICT_ALIGNMENT
+  ? MAX (DECL_ALIGN (parm), BITS_PER_WORD) : DECL_ALIGN (parm));
+
+  SET_DECL_ALIGN (parm, parm_align);
   if (DECL_ALIGN (parm) > MAX_SUPPORTED_STACK_ALIGNMENT)
{
  rtx allocsize = gen_int_mode (size_stored, Pmode);

PS. A preferable solution would IMHO involve hookifying
parameter padding and alignment as separate entities.  Maybe
later, perhaps even after PR84877 is fixed, or that bug risk
dying from perceived misprioritized attention.  (Amazing how
easy it is to "overalign" here, and hard to align "there"!)

brgds, H-P

Re: [PATCH] Eliminates phi on branch for CMP result

[Jiufu Guo]

Jeff Law  writes:

> On 5/8/19 6:20 AM, Richard Biener wrote:
>> On Wed, 8 May 2019, Jiufu Guo wrote:
>> 
>> The main thing the transform does is tail-duplicate the PHI block,
>> if we'd just do that followup transforms would do the rest.
> One might even claim this is really a transformation for cfg cleanups.
> If we ignore the PHI what we have is a unconditional jump to a
> conditional jump.  The obvious way to optimize that is to replace the
> unconditional jump with a copy of the conditional jump.
>

>> Btw, I wonder if on RTL basic-block reordering (which also does
>> some tail duplication) could be a place to do such transform?
>> Or is it too late to do the desired cleanups after that?
>> Possibly since we're after RA.IIRC we've had code in jump.c to do this in 
>> the past.  It may have
> morphed through the years, but I'm pretty sure we've done this kind of
> thing on a low level before.

Yes, RTL basic-block reordering duplicate the conditional jump and
replace unconditional jump with it:
   17: %9:DI=%9:DI^0x1
   19: %9:DI=zero_extend(%9:QI)
   58: pc=L31
   59: barrier
--->
   17: %9:DI=%9:DI^0x1
   19: %9:DI=zero_extend(%9:QI)
   33: %0:CC=cmp(%9:DI,0)
  REG_DEAD %9:DI
   34: pc={(%0:CC!=0)?L90:pc}
  REG_DEAD %0:CC
  REG_BR_PROB 354334804

While, the conditional jump is still using GPR even the GPR(%9:DI) is
result of a CMP instruction. Because moving CMP result to GPR is
generated when tranforming gimple to rtl. 

To elimiate the instructions which moving result of CMP to GPR, I'm
wondering maybe we could do a combine(or a peephole) after bbro to let
the condition jump directly using the result of CMP.

Jiufu Guo.

> jeff

Re: [PATCH] fortran: C++ support for generating C prototypes

[Thomas König]

Hi Janne,

I do not think we need to add header guards.

The headers, as we emit them, contain prototypes only, so repeated inclusions
Should be harmless.

So. the potential disadvantage would be a teeny bit of compilation time vs the 
chance of header macro collision and resulting wrong code.

Filenames can be duplicates,
and eventually the responsibility should be the user‘s.

Finally, I want people to read the comment about this not being recommended 

RE: [PATCH] Implement P0966 std::string::reserve should not shrink

[Andrew Luo]

It's been a while, but thought I'd check in again now that GCC 9 has been 
branched, and master is now on GCC 10.

I've merged my changes with the latest code and attached a diff... Let me know 
if there's any thoughts on this.

Thanks,

-Andrew

-Original Message-
From: gcc-patches-ow...@gcc.gnu.org  On Behalf 
Of Andrew Luo
Sent: Wednesday, January 23, 2019 5:15 PM
To: Jonathan Wakely 
Cc: libstd...@gcc.gnu.org; gcc-patches@gcc.gnu.org
Subject: RE: [PATCH] Implement P0966 std::string::reserve should not shrink

Here's an updated diff.  Still a work in progress, ran the tests for 
strings/capacity in both modes, passing now.  I am running all the tests in 
both modes as well, but will take a while to get results.  In the meanwhile I 
thought I'd send this out...

Also, that code works on all released versions of libc++.  Only in the past 
month or so was that overload added, also for a (slightly flawed) 
implementation of P0966.  Anyways, I removed the #ifs - I get your point that 
there's no need to preserve backwards compatibility with non-comforming code, 
and I think any issues with reserve specifically will be rather rare (and easy 
to fix).  (Although, I should point out that push_back is not overloaded if you 
select -std=c++98, only -std=c++11 or later, but that's besides the point).

Thanks,

-Andrew

-Original Message-
From: Jonathan Wakely 
Sent: Wednesday, January 23, 2019 3:26 AM
To: Andrew Luo 
Cc: libstd...@gcc.gnu.org
Subject: Re: [PATCH] Implement P0966 std::string::reserve should not shrink

On 23/01/19 00:44 +, Andrew Luo wrote:
>Thanks for the input.  I will make the suggested changes.
>
>I didn't add a changelog entry yet (which I was planning to do - just wanted 
>to send this out before to get some feedback on the code first).

Understood, I'm just making sure you're aware of the process.

>I will also take care of the copyright assignment (should I send an email to 
>g...@gcc.gnu.org or are you the maintainer that is taking care of this 
>contribution?)...

That will probably be me. I'll send you the form to start the copyright 
assignment.

>Next patch I will send to both libstdc++ and gcc-patches as well.  Somehow I 
>missed that.

Thanks.

>One possibility to avoid changing the behavior for pre-C++2a code is to put 
>the check in a "#if __cplusplus > 201703L" block and force reserve(size_type) 
>to be inline (if we want to go this route, I think the helper function 
>_M_request_capacity would have to stay, as reserve could shrink in C++17 mode 
>or earlier). 

>Other than that, with my current patch, reserve() still works as previously, 
>however reserve(0) has changed (I don't know how common it was to use 
>reserve(0) instead of simply reserve())...

Well as you noted, your patch made it a no-op (more below).


>As for the split of reserve - wouldn't this kind of code break in previous 
>-std modes:
>
>auto f(&::std::string::reserve); // Ambiguous post C++17

Already undefined, as you noted in the later reply. More on that below.


>As for deprecation, I will add it to the no-arg overload.  Regarding giving 
>the deprecation notice for all dialects, technically speaking, it was only 
>deprecated in C++2a so should someone receive that deprecation message if they 
>are compiling with -std=c++98, for example?  I don't know what the general 
>policies around this are for GCC/libstdc++.

Yes, you're right it's only deprecated for C++2a. My thinking was that if it's 
going away at some point in future then it's useful to get a warning saying so, 
period.

But we don't do that for std::auto_ptr in C++98 even though it's deprecated in 
C++11. So maybe only add the attribute for C++2a, which means it can use C++11 
attribute syntax:

#if__cplusplus > 201703L
[[deprecated("use shrink_to_fit() instead")]] #endif


On 23/01/19 03:41 +, Andrew Luo wrote:
>Actually, reserve() doesn't currently work as reserve(0) previously, I 
>missed a line there (should have shrink_to_fit() in the body...)

Oh, I missed that the proposal says the new overload is a shrink-to-fit request 
rather than no-op.

Calling shrink_to_fit() won't work for C++98 mode, because it isn't declared. 
It could be a no-op for C++98 (it's only a non-binding request after all), or 
we could add a new _M_shrink function that
shrink_to_fit() and reserve() call.  I'm still reluctant to add a new exported 
function (which means four new symbols) for a deprecated feature that already 
exists as shrink_to_fit() but maybe that's the best option.

>Also, how do you run the tests for the COW string?  I ran make check in the 
>libstdc++-v3 folder and everything passes...

make check RUNTESTFLAGS=--target_board=unix/-D_GLIBCXX_USE_CXX11_ABI=0

And you can add other options, e.g. to check in C++98 mode:

RUNTESTFLAGS=--target_board=unix/-D_GLIBCXX_USE_CXX11_ABI=0/-std=gnu++98

See https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.run
for more info.

On 23/01/19 06:17 +, Andrew Luo wrote:

Re: [PATCH] fortran: C++ support for generating C prototypes

[Jakub Jelinek]

On Sun, May 12, 2019 at 10:36:09PM +0300, Janne Blomqvist wrote:
> On Sun, May 12, 2019 at 11:29 AM Janne Blomqvist
>  wrote:
> >
> > On Sun, May 12, 2019 at 11:06 AM Thomas Koenig  
> > wrote:
> > > (I thought for a second about guarding about double inclusion, but
> > > including prototypes twice is harmless, and this should be the
> > > user's responsibility).
> >
> > I thought about adding include guards as well, but the problem is that
> > we don't know which name the end user wants to save the output as.
> 
> But, we can of course use the source file name instead of the usual
> header name for the include guard. Like in the attached patch. Ok for

There are many characters that can appear in filenames and can't appear in
macro names, /, <, >, :, ;, many others.  Either you need to replace them
all with _ but then you risk collisions, or add some way how to encode the
characters you can't put in directly (say _7b etc.), or instead use
_GFORTRAN_GUARD_

Jakub

Re: [PATCH] fortran: C++ support for generating C prototypes

[Janne Blomqvist]

On Sun, May 12, 2019 at 11:29 AM Janne Blomqvist
 wrote:
>
> On Sun, May 12, 2019 at 11:06 AM Thomas Koenig  wrote:
> > (I thought for a second about guarding about double inclusion, but
> > including prototypes twice is harmless, and this should be the
> > user's responsibility).
>
> I thought about adding include guards as well, but the problem is that
> we don't know which name the end user wants to save the output as.

But, we can of course use the source file name instead of the usual
header name for the include guard. Like in the attached patch. Ok for
trunk and 9?



-- 
Janne Blomqvist


0001-Add-include-guards-for-generated-C-prototypes.patch
Description: Binary data

[Darwin, libgcc, comitted] Allow vec save asm to build with modern assembler.

[Iain Sandoe]

Some of the newer assemblers for Darwin check that the CPU type is consistent 
with the file type and fail to build when they don’t match.

Fixed thus for trunk
thanks
Iain

libgcc/

2019-05-12  Iain Sandoe  

* config/rs6000/darwin-vecsave.S: Set .machine appropriately.


Index: libgcc/config/rs6000/darwin-vecsave.S
===
--- libgcc/config/rs6000/darwin-vecsave.S   (revision 271110)
+++ libgcc/config/rs6000/darwin-vecsave.S   (working copy)
@@ -31,8 +31,14 @@
(4 bytes) to do the operation; for Vector regs, 2 instructions are
required (8 bytes.).   */
 
+/* With some assemblers, we need the correct machine directive to get the
+   right CPU type / subtype in the file header.  */
+#if__ppc64__
+   .machine ppc64
+#else
.machine ppc7400
-.text
+#endif
+   .text
.align 2
 
 .private_extern saveVEC

Re: [PATCH, X86] Fix PR82920 (code part).

[Iain Sandoe]

> On 10 May 2019, at 22:22, Uros Bizjak  wrote:
> 
> On Fri, May 10, 2019 at 11:03 PM Iain Sandoe  wrote:
>> 

>> PR82920 is about CET fails on Darwin.
>> 
>> Initially, this was expected to be just a testsuite issue, however it turns 
>> out that the indirection thunks code has inconsistent handling of the output 
>> of labels.  Thus some of the output is missing the leading “_” on Darwin, 
>> which breaks ABI and won’t link.
>> 
>> Since most of the tests are scan-asms that check for what’s expected, they 
>> currently pass on Darwin but will begin failing when the codegen is fixed.  
>> Thus there is  larger, but mechanical, testsuite change needed to deal with 
>> this.   I will post that if anyone’s interested, but otherwise will just 
>> apply it once the codgen fix is agreed.
>> 
>> The patch factors out some common code that writes out the jumps and uses 
>> the regular output scheme that accounts for __USER_LABEL_PREFIX__.
>> 
>> I will note in passing that there’s very little PIC test coverage for the 
>> indirection thunks code, although Darwin is PIC-only for m64 - Linux has 
>> only a few tests.
>> 
>> OK for trunk?
> 
> OK for trunk if the patch doesn't regress x86_64-linux.

tested on x86_64-linux-gnu and x86_64-darwin (m32 and m64 in both cases).
Applied to trunk.

Many thanks to Dominique for working though some of the many testsuite changes 
needed.
There’s a second set of test changes needed to fix the PR completely, but those 
are disjoint
to the ones below which result from the codegen changes.

thanks
Iain

gcc/

2019-05-12  Iain Sandoe  

PR target/82920
* config/i386/i386.c (ix86_output_jmp_thunk_or_indirect): New.
(ix86_output_indirect_branch_via_reg): Use output mechanism
accounting for __USER_LABEL_PREFIX__.
(ix86_output_indirect_branch_via_push): Likewise.
(ix86_output_function_return): Likewise.
(ix86_output_indirect_function_return): Likewise.

gcc/testsuite/

2019-05-12  Iain Sandoe  
Dominique d'Humieres  

PR target/82920
* gcc.target/i386/indirect-thunk-1.c: Adjust scan-asms for Darwin,
do not use -fno-pic on Darwin.
* gcc.target/i386/indirect-thunk-2.c: Likewise.
* gcc.target/i386/indirect-thunk-3.c: Likewise.
* gcc.target/i386/indirect-thunk-4.c: Likewise.
* gcc.target/i386/indirect-thunk-7.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-1.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-2.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-3.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-4.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-5.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-6.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-7.c: Likewise.
* gcc.target/i386/indirect-thunk-attr-8.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-1.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-2.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-3.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-4.c: Likewise.
* gcc.target/i386/indirect-thunk-extern-7.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-1.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-2.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-3.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-4.c: Likewise.
* gcc.target/i386/indirect-thunk-inline-7.c: Likewise.
* gcc.target/i386/indirect-thunk-register-1.c: Likewise.
* gcc.target/i386/indirect-thunk-register-2.c: Likewise.
* gcc.target/i386/indirect-thunk-register-3.c: Likewise.
* gcc.target/i386/indirect-thunk-register-4.c: Likewise.
* gcc.target/i386/ret-thunk-1.c: Likewise.
* gcc.target/i386/ret-thunk-10.c: Likewise.
* gcc.target/i386/ret-thunk-11.c: Likewise.
* gcc.target/i386/ret-thunk-12.c: Likewise.
* gcc.target/i386/ret-thunk-13.c: Likewise.
* gcc.target/i386/ret-thunk-14.c: Likewise.
* gcc.target/i386/ret-thunk-15.c: Likewise.
* gcc.target/i386/ret-thunk-16.c: Likewise.
* gcc.target/i386/ret-thunk-2.c: Likewise.
* gcc.target/i386/ret-thunk-22.c: Likewise.
* gcc.target/i386/ret-thunk-23.c: Likewise.
* gcc.target/i386/ret-thunk-24.c: Likewise.
* gcc.target/i386/ret-thunk-3.c: Likewise.
* gcc.target/i386/ret-thunk-4.c: Likewise.
* gcc.target/i386/ret-thunk-5.c: Likewise.
* gcc.target/i386/ret-thunk-6.c: Likewise.
* gcc.target/i386/ret-thunk-7.c: Likewise.
* gcc.target/i386/ret-thunk-8.c: Likewise.
* gcc.target/i386/ret-thunk-9.c: Likewise.




pr82920-code-part.diff
Description: pr82920-code-part.diff


pr82920-testsuite-1.diff
Description: pr82920-testsuite-1.diff

New Swedish PO file for 'gcc' (version 9.1.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators.  The file is available at:

https://translationproject.org/latest/gcc/sv.po

(This file, 'gcc-9.1.0.sv.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

https://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

https://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: [C++ PATCH, PING^2] PR60531 - Wrong error about unresolved overloaded function

[Harald van Dijk]

ping again

On 26/04/2019 19:58, Harald van Dijk wrote:

ping

On 13/04/2019 10:01, Harald van Dijk wrote:

Hi,

For PR60531, GCC wrongly rejects function templates with explicitly
specified template arguments as overloaded. They are resolved by
resolve_nondeduced_context, which is normally called by
cp_default_conversion through decay_conversion, but the latter have
extra effects making them unusable here. Calling the former directly
does work.

Bootstrapped on x86_64-pc-linux-gnu on top of r270264 with
--enable-languages=all; make check shows no regressions.

Does this look okay?

This is my first code contribution to GCC, please let me know if
anything is missing. I have not signed any copyright disclaimer or
copyright assignment;  says that is not necessary
for small changes, which I trust this is. If it is needed after all,
please let me know what specifically will be required.

Cheers,
Harald van Dijk

 PR c++/60531
 * typeck.c (cp_build_binary_op): See if overload can be resolved.
 (cp_build_unary_op): Ditto.

 * g++.dg/template/operator15.C: New test.

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 03b14024738..e1ffe88ce2c 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -4384,10 +4384,6 @@ cp_build_binary_op (const op_location_t ,
    /* True if both operands have arithmetic type.  */
    bool arithmetic_types_p;

-  /* Apply default conversions.  */
-  op0 = orig_op0;
-  op1 = orig_op1;
-
    /* Remember whether we're doing / or %.  */
    bool doing_div_or_mod = false;

@@ -4397,6 +4393,10 @@ cp_build_binary_op (const op_location_t ,
    /* Tree holding instrumentation expression.  */
    tree instrument_expr = NULL_TREE;

+  /* Apply default conversions.  */
+  op0 = resolve_nondeduced_context (orig_op0, complain);
+  op1 = resolve_nondeduced_context (orig_op1, complain);
+
    if (code == TRUTH_AND_EXPR || code == TRUTH_ANDIF_EXPR
    || code == TRUTH_OR_EXPR || code == TRUTH_ORIF_EXPR
    || code == TRUTH_XOR_EXPR)
@@ -6204,11 +6204,13 @@ cp_build_unary_op (enum tree_code code, tree xarg, bool 
noconvert,
    if (!arg || error_operand_p (arg))
  return error_mark_node;

+  arg = resolve_nondeduced_context (arg, complain);
+
    if ((invalid_op_diag
 = targetm.invalid_unary_op ((code == UNARY_PLUS_EXPR
  ? CONVERT_EXPR
  : code),
-   TREE_TYPE (xarg
+   TREE_TYPE (arg
  {
    if (complain & tf_error)
  error (invalid_op_diag);
diff --git a/gcc/testsuite/g++.dg/template/operator15.C 
b/gcc/testsuite/g++.dg/template/operator15.C
new file mode 100644
index 000..755442266bb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/operator15.C
@@ -0,0 +1,6 @@
+// PR c++/60531
+
+template < class T > T foo ();
+
+bool b1 = foo == foo;
+int (*fp1)() = +foo;

Fwd: [Patch] Fix assembler invocation on sparc-sun-solaris2

[Bence Csókás]

Hi!
I tried building a cross-compiler for `sparc-sun-solaris2`, but the
resulting GCC executable wouldn't compile anything, always failing
with: "as: unrecognized option '-m32'". After extensive research, I
found that `as` takes `--32`/`--64`, instead of `-m32`/`-m64`. The
patched GCC now does compile.
Bence Csókás

Changes:
2019-05-11 Bence Csókás GPG
1D6907136D516DA11BEF87EBF12C5C5021171108
* gcc/config/sparc/sol2.h: Fixing `as` parameterization
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

diff --git a/gcc/config/sparc/sol2.h b/gcc/config/sparc/sol2.h
index 93404757054..d1d0bb1f99d 100644
- --- a/gcc/config/sparc/sol2.h
+++ b/gcc/config/sparc/sol2.h
@@ -63,9 +63,9 @@ along with GCC; see the file COPYING3.  If not see
 
 #ifndef USE_GAS
 #undef ASM_ARCH32_SPEC
- -#define ASM_ARCH32_SPEC "-m32"
+#define ASM_ARCH32_SPEC "--32"
 #undef ASM_ARCH64_SPEC
- -#define ASM_ARCH64_SPEC "-m64"
+#define ASM_ARCH64_SPEC "--64"
 #endif
 
 /* Both Sun as and GNU as understand -K PIC.  */
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEHWkHE21RbaEb74fr8SxcUCEXEQgFAlzYMe0ACgkQ8SxcUCEX
EQh0EA/9Ghh/7BpAzkCbvo7wG7CXCeW5jYtt+pKVPSz85AE9R59eLITSSqBii744
i60RjxMCt05Gl2IcC8Z3p88U0YSG3uR3+o8f4m1GnjpqFhdX+6cPnuXPM6y9PDGU
+qarL5WfYhh83GEOiR6ksRVLLexW0/XJEIFB/IDioW66b0Cn7iK3fkCuxGhs+xwx
6v3pFhiOimi+KYTNU/1uwnFrOKVbM7dWBxQjIpwbbBAIwKqQa9G6A0urm3xWLekY
VXTfPDBRP7eEcKMhmLYpw0v0OG+/8zO7rCrdCAyR1WaumA8xtqMiYrqFanNduX0G
6UB+K6R2a9yd8+JP9tHIJILHL05mI62dZKzTAr2fyOwYd1TVVimo+CBKFK/RMw1u
HKm/XGuMJ59BPKnKw3cB2utkuUBdSDQOkTDrHy5+jPM9157LicjMCrRuWjy3nV37
lhB15DlXU1RLU4lN+1veOpBV4Ajc/PKhsxGUEey0s5+ZfjSY8Px9R8P/Gvfn9ax2
728VOcMNL0NVWTBBrSW4w3RQ72LTe38jOv3Hd6zJCyk1gUX5lBJBvoj645miZP77
Nq7ZcuAKhYFTafPFfp3U42niiqs6XvLcj1L2GkfIeTtJ7YqG7ZKhbcRVY9E/Q0dt
6povk4qrMq7DkpRGZyJ4bb27L5egHngbfa1rm4InbM8HSpDtwc8=
=uHds
-END PGP SIGNATURE-
diff --git a/gcc/config/sparc/sol2.h b/gcc/config/sparc/sol2.h
index 93404757054..d1d0bb1f99d 100644
--- a/gcc/config/sparc/sol2.h
+++ b/gcc/config/sparc/sol2.h
@@ -63,9 +63,9 @@ along with GCC; see the file COPYING3.  If not see
 
 #ifndef USE_GAS
 #undef ASM_ARCH32_SPEC
-#define ASM_ARCH32_SPEC "-m32"
+#define ASM_ARCH32_SPEC "--32"
 #undef ASM_ARCH64_SPEC
-#define ASM_ARCH64_SPEC "-m64"
+#define ASM_ARCH64_SPEC "--64"
 #endif
 
 /* Both Sun as and GNU as understand -K PIC.  */

Re: malloc cannot alias preexisting pointers

[Marc Glisse]

On Sun, 12 May 2019, Richard Sandiford wrote:


Marc Glisse  writes:

Hello,

this patch lets gcc know that if a pointer existed before the call to
malloc, the result of malloc cannot alias it. This is a bit ad hoc and
fragile. A small improvement would be, when the 2 statements are in the
same bb but in the wrong order, to check if there is any statement in
between that might prevent from reordering them. But that's more
complicated, and the patch as it is already does help.

I expect people may not like the call to a function from
tree-ssa-loop-niter too much, but it is convenient. And if someone
improves it, they will likely have to rewrite something not quite
equivalent to stmt_dominates_stmt_p.


It has linear complexity for statements in the same block though.


Ah, true. I should anyway test that the second statement is malloc 
(cheaper) before checking for domination, but even then that could be used 
to create a quadratic behavior :-(



(reassoc_stmt_dominates_stmt_p avoids that, but relies on uids
being up-to-date.)


This function is called from all over the place. Unless there is a simple 
test to check if uids are safe to use (reassoc_in_progress?), that's going 
to be a problem. I find it surprising that this information is so hard to 
get to... Stopping stmt_dominates_stmt_p after walking 128 statements 
doesn't feel like a great solution. But without controlling the pass where 
this happens, I don't see any good solution. It would be great if that 
non-aliasing property could be recorded in the points-to information, then 
I could set it from a pass I control, but I somehow got the impression 
that it wouldn't work. Maybe I should try to understand PTA better to make 
sure.


--
Marc Glisse

Re: malloc cannot alias preexisting pointers

[Richard Sandiford]

Marc Glisse  writes:
> Hello,
>
> this patch lets gcc know that if a pointer existed before the call to 
> malloc, the result of malloc cannot alias it. This is a bit ad hoc and 
> fragile. A small improvement would be, when the 2 statements are in the 
> same bb but in the wrong order, to check if there is any statement in 
> between that might prevent from reordering them. But that's more 
> complicated, and the patch as it is already does help.
>
> I expect people may not like the call to a function from 
> tree-ssa-loop-niter too much, but it is convenient. And if someone 
> improves it, they will likely have to rewrite something not quite 
> equivalent to stmt_dominates_stmt_p.

It has linear complexity for statements in the same block though.
(reassoc_stmt_dominates_stmt_p avoids that, but relies on uids
being up-to-date.)

> The testcase uses libstdc++ quite a bit. I thought about putting it in the 
> libstdc++ testsuite, but it does not know scan-tree-dump, and in the 
> assembly it may be too late, memcpy may get expanded to something 
> target-specific. So it is in g++.dg. I could write a more artificial 
> testcase, but the behavior of std::vector is really what I want to test...
>
> Bootstrap+regtest on x86_64-pc-linux-gnu.
>
> 2019-05-13  Marc Glisse  
>
> gcc/
>   * tree-ssa-loop-niter.c (stmt_dominates_stmt_p): Handle NULL
>   basic block.
>   * tree-ssa-alias.c: Include tree-ssa-loop-niter.h.
>   (ptr_derefs_may_alias_p): Detect malloc and an older pointer.
>
> gcc/testsuite/
>   * g++.dg/tree-ssa/ldist-2.C: New file.

[committed] Accept code attributes as rtx codes in .md files

[Richard Sandiford]

The recent AArch64 absolute difference patterns had to go through
some hoops to pair max/min rtx codes with the same signedness.
I also need to pair signed/unsigned codes with sign/zero extension
for some SVE ACLE patterns.

This patch therefore supports <...> as rtx codes, like we already
do for modes.

Tested on aarch64-linux-gnu with and without SVE.  Applied as r271107
(treating the aarch64-simd.md change as obvious).

Richard


2019-05-12  Richard Sandiford  

gcc/
* doc/md.texi: Document use of code attributes in rtx patterns.
* read-md.h (rtx_reader::rtx_alloc_for_name): New member function.
* read-rtl.c (find_code): Split out search loops into...
(maybe_find_code): ...this new function.
(check_code_iterator): Make the error message more informative.
(check_code_attribute): New function.
(rtx_reader::rtx_alloc_for_name): Likewise.
(rtx_reader::read_rtx_code): Use rtx_alloc_for_name.
* config/aarch64/predicates.md (aarch64_smin, aarch64_umin): Delete.
* config/aarch64/aarch64-simd.md (*aarch64_abd_3): Use
 directly as an rtx code instead of via a match_operator.
* config/aarch64/aarch64-sve.md (aarch64_abd_3): Likewise.
(abd_3): Update accordingly.

Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi 2019-03-08 18:14:25.581010702 +
+++ gcc/doc/md.texi 2019-05-12 12:25:55.898144554 +0100
@@ -10979,6 +10979,27 @@ Other attributes are defined using:
 (define_code_attr @var{name} [(@var{code1} "@var{value1}") @dots{} 
(@var{coden} "@var{valuen}")])
 @end smallexample
 
+Instruction patterns can use code attributes as rtx codes, which can be
+useful if two sets of codes act in tandem.  For example, the following
+@code{define_insn} defines two patterns, one calculating a signed absolute
+difference and another calculating an unsigned absolute difference:
+
+@smallexample
+(define_code_iterator any_max [smax umax])
+(define_code_attr paired_min [(smax "smin") (umax "umin")])
+(define_insn @dots{}
+  [(set (match_operand:SI 0 @dots{})
+(minus:SI (any_max:SI (match_operand:SI 1 @dots{})
+  (match_operand:SI 2 @dots{}))
+  (:SI (match_dup 1) (match_dup 2]
+  @dots{})
+@end smallexample
+
+The signed version of the instruction uses @code{smax} and @code{smin}
+while the unsigned version uses @code{umax} and @code{umin}.  There
+are no versions that pair @code{smax} with @code{umin} or @code{umax}
+with @code{smin}.
+
 Here's an example of code iterators in action, taken from the MIPS port:
 
 @smallexample
Index: gcc/read-md.h
===
--- gcc/read-md.h   2019-03-08 18:15:36.692740380 +
+++ gcc/read-md.h   2019-05-12 12:25:55.898144554 +0100
@@ -337,6 +337,7 @@ struct mapping;
   ~rtx_reader ();
 
   bool read_rtx (const char *rtx_name, vec *rtxen);
+  rtx rtx_alloc_for_name (const char *);
   rtx read_rtx_code (const char *code_name);
   virtual rtx read_rtx_operand (rtx return_rtx, int idx);
   rtx read_nested_rtx ();
Index: gcc/read-rtl.c
===
--- gcc/read-rtl.c  2019-03-08 18:15:33.664751891 +
+++ gcc/read-rtl.c  2019-05-12 12:25:55.902144542 +0100
@@ -194,22 +194,31 @@ static const compact_insn_name compact_i
   { NOTE, "cnote" }
 };
 
-/* Implementations of the iterator_group callbacks for codes.  */
+/* Return the rtx code for NAME, or UNKNOWN if NAME isn't a valid rtx code.  */
 
-static int
-find_code (const char *name)
+static rtx_code
+maybe_find_code (const char *name)
 {
-  int i;
-
-  for (i = 0; i < NUM_RTX_CODE; i++)
+  for (int i = 0; i < NUM_RTX_CODE; i++)
 if (strcmp (GET_RTX_NAME (i), name) == 0)
-  return i;
+  return (rtx_code) i;
 
-  for (i = 0; i < (signed)ARRAY_SIZE (compact_insn_names); i++)
+  for (int i = 0; i < (signed)ARRAY_SIZE (compact_insn_names); i++)
 if (strcmp (compact_insn_names[i].name, name) == 0)
   return compact_insn_names[i].code;
 
-  fatal_with_file_and_line ("unknown rtx code `%s'", name);
+  return UNKNOWN;
+}
+
+/* Implementations of the iterator_group callbacks for codes.  */
+
+static int
+find_code (const char *name)
+{
+  rtx_code code = maybe_find_code (name);
+  if (code == UNKNOWN)
+fatal_with_file_and_line ("unknown rtx code `%s'", name);
+  return code;
 }
 
 static void
@@ -1306,7 +1315,37 @@ check_code_iterator (struct mapping *ite
   for (v = iterator->values->next; v != 0; v = v->next)
 if (strcmp (GET_RTX_FORMAT (bellwether), GET_RTX_FORMAT (v->number)) != 0)
   fatal_with_file_and_line ("code iterator `%s' combines "
-   "different rtx formats", iterator->name);
+   "`%s' and `%s', which have different "
+   "rtx formats", iterator->name,
+   

Re: [PATCH] fortran: C++ support for generating C prototypes

[Thomas Koenig]

Am 12.05.19 um 10:29 schrieb Janne Blomqvist:

Thanks, committed as r271106. I prefixed the macros with __GFORTRAN_,
as that seems clearer to users where those come from as gfc seems used
mostly in the compiler internals.


Sounds good.


Any opinions whether it should be committed to 9 as well?


Well, we just introduced this feature :-)  Your change makes it
more useful, and it's not like gcc-9 has a long history
with the current format.

So, OK from my side for gcc-9 as well.

I just hope that using this option will not keep people from
using the standard C interop feature...

Next task would be to generate prototypes for extended
C interop (but not today).

Regards

Thomas

Re: [PATCH] fortran: C++ support for generating C prototypes

[Janne Blomqvist]

On Sun, May 12, 2019 at 11:06 AM Thomas Koenig  wrote:
>
> Am 12.05.19 um 00:02 schrieb Jakub Jelinek:
> > Is it correct to use macros in user namespace?  Shouldn't they be say __
> > prefixed, or even have __GFC_ or __GFORTRAN_ in them?
>
> I think Jakub has a point there -- something like __GFC_DOUBLE_COMPLEX
> would probably be better.
>
> So, OK with that change.

Thanks, committed as r271106. I prefixed the macros with __GFORTRAN_,
as that seems clearer to users where those come from as gfc seems used
mostly in the compiler internals.

Any opinions whether it should be committed to 9 as well?

> (I thought for a second about guarding about double inclusion, but
> including prototypes twice is harmless, and this should be the
> user's responsibility).

I thought about adding include guards as well, but the problem is that
we don't know which name the end user wants to save the output as.

-- 
Janne Blomqvist

Re: [PATCH] fortran: C++ support for generating C prototypes

[Thomas Koenig]

Am 12.05.19 um 00:02 schrieb Jakub Jelinek:

Is it correct to use macros in user namespace?  Shouldn't they be say __
prefixed, or even have __GFC_ or __GFORTRAN_ in them?


I think Jakub has a point there -- something like __GFC_DOUBLE_COMPLEX
would probably be better.

So, OK with that change.

(I thought for a second about guarding about double inclusion, but
including prototypes twice is harmless, and this should be the
user's responsibility).

Regards

Thomas