date:20190804

Re: [PATCH, Ada] Push -shared-libgcc where needed.

2019-08-04 Thread Iain Sandoe

Hi Eric,

> On 30 Jun 2019, at 10:54, Eric Botcazou  wrote:
> 
>> 2019-06-30  Iain Sandoe  
>> 
>>  * gnatlink.adb (Link_Step): Remove duplicate -static-libgcc switches.
>>  Push -shared-libgcc explicitly, when it is the target default (unless
>> overidden by the static flag).
>>  When the user has put an instance of shared/static-libgcc do not push
>>  a duplicate of this.
> 
> OK for mainline, thanks.

This patch has now been on mainline for some time without any apparent issue,
the problem is also present on the open branches, may I backport it?

thanks
Iain

Re: [PATCH, Ada, Darwin, PPC] PPC Darwin has stack check probes.

2019-08-04 Thread Iain Sandoe

> On 1 Jul 2019, at 22:57, Eric Botcazou  wrote:
> 
>> 2019-07-01  Iain Sandoe  
>> 
>>  * libgnat/system-darwin-ppc.ads: Set Stack_Check_Probes True for
>>  PPC Darwin.
> 
> OK, thanks.

This (PPC)Darwin-specific patch has been on mainline for some time now 
without issues, the problem is present on open branches, may I backport it?

thanks
Iain

[doc] install.texi - remove reference to age-old Tcl bug

2019-08-04 Thread Gerald Pfeifer

Tcl 8.6.1 was released more than half a decade ago, so not much of
a point still documenting this Tcl 8.6 GA regression.

Committed.  

Perhaps I'll backport to the GCC 9 branch as well.

Gerald

2019-08-04  Gerald Pfeifer  

* doc/install.texi (Prerequisites): Remove reference to Tcl 8.6
bug that was fixed in Tcl 8.6.1.

Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi(revision 274087)
+++ gcc/doc/install.texi(working copy)
@@ -442,10 +442,7 @@ Necessary when modifying @command{gperf} input fil
 @itemx Tcl
 
 Necessary to run the GCC testsuite; see the section on testing for
-details.  Tcl 8.6 has a known regression in RE pattern handling that
-make parts of the testsuite fail.  See
-@uref{http://core.tcl.tk/tcl/tktview/267b7e2334ee2e9de34c4b00d6e72e2f1997085f}
-for more information.  This bug has been fixed in 8.6.1.
+details.
 
 @item autogen version 5.5.4 (or later) and
 @itemx guile version 1.4.1 (or later)

[wwwdocs] www.sandpile.org has moved to https

2019-08-04 Thread Gerald Pfeifer

On the way pull the column out of the link text.

Committed.

Gerald

Index: readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.317
diff -u -r1.317 readings.html
--- readings.html   30 Jul 2019 22:14:15 -  1.317
+++ readings.html   4 Aug 2019 13:06:48 -
@@ -152,7 +152,7 @@
   x86 manuals and documentation:
 
   https://www.agner.org/optimize/";>https://www.agner.org/optimize/
-  http://www.sandpile.org";>www.sandpile.org:
+  https://www.sandpile.org";>www.sandpile.org:
   Christian Ludloff's technical x86 processor information.

[libstdc++,doc] A final(?) doxygen link fixed

2019-08-04 Thread Gerald Pfeifer

I hope with that we've caught everything (and that things are going
to remain stable for a while now).

Commmitted.

Gerald

2019-08-04  Gerald Pfeifer  

* doc/xml/manual/documentation_hacking.xml: doxygen.org is now
doxygen.nl.

Index: doc/xml/manual/documentation_hacking.xml
===
--- doc/xml/manual/documentation_hacking.xml(revision 274087)
+++ doc/xml/manual/documentation_hacking.xml(working copy)
@@ -261,7 +261,7 @@
 
   
Prerequisite tools are Bash 2.0 or later,
-   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.doxygen.org";>Doxygen, and
+   http://www.w3.org/1999/xlink"; 
xlink:href="http://www.doxygen.nl";>Doxygen, and
the http://www.w3.org/1999/xlink"; 
xlink:href="http://www.gnu.org/software/coreutils/";>GNU
coreutils. (GNU versions of find, xargs, and possibly
sed and grep are used, just because the GNU versions make

[wwwdocs] Remove dysfunctional mirrors-usa.go-parts.com

2019-08-04 Thread Gerald Pfeifer

Thanks for carrying us for a while, Dan.

Committed.

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.255
diff -u -r1.255 mirrors.html
--- mirrors.html7 Oct 2018 12:40:52 -   1.255
+++ mirrors.html4 Aug 2019 13:24:38 -
@@ -39,7 +39,6 @@
 UK: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/";>ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/,
 thanks to mirror at mirrorservice.org
 US, San Francisco: https://bigsearcher.com/mirrors/gcc/";>https://bigsearcher.com/mirrors/gcc/,
 thanks to i...@bigsearcher.com
 US, San Jose: http://www.netgull.com/gcc/";>http://www.netgull.com, thanks to admin 
at netgull.com
-US: http://mirrors-usa.go-parts.com/gcc/";>http://mirrors-usa.go-parts.com/gcc,
 thanks to Dan Derebenskiy 
 US, Michigan: http://mirrors.concertpass.com/gcc/";>http://mirrors.concertpass.com/gcc/,
 thanks to ad...@mirrors.concertpass.com.

Darwin backports commited for 9.2

2019-08-04 Thread Iain Sandoe

Hi,

It seems that we’ve fixed quite a few testsuite issues over the last
months that exist on all the open branches.  This has made for quite
a large number of test-related backports.

General stuff is much smaller in content.

These were tested on i686,powerpc-darwin9, x86_64-darwin16, 18
powerpc64-linux-gnu, x86_64-linux-gnu.

The patches are unchanged from their trunk counterparts.

=
 
I’ve backported 

Darwin Objective-C specific 

r274014, 274015, 274050

Darwin fixincludes (resolving both build and test issues)

r274039, 274040

Darwin codegen or build fixes

r274012, 274017, 274043, 274044, 274045, 274057, 274048, 274049.

Darwin test or testsuite related.

r274016, 274041, 274042, 274046

Darwin testsuite

r274056 to 274088 and 274090 to 274093.

thanks
Iain

Re: [objective-c/c++, testsuite, committed, 1/3] Workaround for PR90709.

2019-08-04 Thread Iain Sandoe



> On 15 Jun 2019, at 15:08, Iain Sandoe  wrote:
> 
> Since we cannot parse the current NeXT headers, because of PR90709 and its
> dependents, we have a large amount of testsuite noise for Darwin platforms.
> In order to restore the usefulness of the testsuite, we are going add headers
> without the modern syntax elements that trigger the bug, and use these for
> test runs on newer Darwin.
> 
> The headers are imported from GNUStep, with some local modifications to make
> sure that __BLOCKS__ is honoured as a gate for Apple-style blocks closures.
> 
> CF-CFString.h, F-NS*.h are proxy headers that use the installed CoreFoundation
> or Foundation headers on systems <= Darwin12 and the GNUStep headers for 
> newer.
> 
> tested on a number of Darwin versions and x86_64-linux-gnu

I have backported this series to the 9 branch as r274095 (the patches are 
unchanged).

thanks
iain

Re: [PATCH] PR fortran/88227 -- Revenge of the BOZ

2019-08-04 Thread Paul Richard Thomas

Hi Steve,

This is OK.

Thanks for working on it.

Paul

On Thu, 1 Aug 2019 at 22:13, Steve Kargl
 wrote:
>
> Ping.
>
> --
> steve
>
> On Sun, Jul 28, 2019 at 04:41:02PM -0700, Steve Kargl wrote:
> > The attach patch fixes a problem with the conversion of a
> > BOZ literal constant to a REAL where the size of the REAL
> > exceeds the size of the largest INTEGER.  The problem can
> > be seen on 32-bit targets that provide support for REAL(10)
> > and/or REAL(16), or it can be seen with a multilib target
> > when using -m32 and REAL(10) and/or REAL(16).
> >
> > If needed, the patch converts an octal or hexidecimal string
> > to the equivalent binary string, and then converts the binary
> > string to a REAL.  In principle, bin2real() can convert to
> > REAL(4), REAL(8), REAL(10), and REAL(16), but I have elected
> > to use the old conversion method if the size of the largest
> > INTEGER exceeds the size the REAL(XXX) of interest.  A future
> > patch may remove the old method and make this new approach the
> > only way to convert a BOZ.
> >
> > I have attached a short test program.  There is no testcase
> > for testsuite.
> >
> > PLEASE TEST.
> >
> > 2019-07-28  Steven G. Kargl  
> >
> >   PR fortran/88227
> >   * check.c (oct2bin):  New function.  Convert octal string to binary.
> >   (hex2bin): New function.  Convert hexidecimal string to binary.
> >   (bin2real): New function.  Convert binary string to REAL.  Use
> >   oct2bin and hex2bin.
> >   (gfc_boz2real):  Use fallback conversion bin2real.
> >
> > --
> > Steve
>
> > Index: gcc/fortran/check.c
> > ===
> > --- gcc/fortran/check.c   (revision 273766)
> > +++ gcc/fortran/check.c   (working copy)
> > @@ -55,6 +55,7 @@ gfc_invalid_boz (const char *msg, locus *loc)
> >
> >
> >  /* Issue an error for an illegal BOZ argument.  */
> > +
> >  static bool
> >  illegal_boz_arg (gfc_expr *x)
> >  {
> > @@ -101,6 +102,167 @@ is_boz_constant (gfc_expr *a)
> >  }
> >
> >
> > +/* Convert a octal string into a binary string.  This is used in the
> > +   fallback conversion of an octal string to a REAL.  */
> > +
> > +static char *
> > +oct2bin(int nbits, char *oct)
> > +{
> > +  const char bits[8][5] = {
> > +"000", "001", "010", "011", "100", "101", "110", "111"};
> > +
> > +  char *buf, *bufp;
> > +  int i, j, n;
> > +
> > +  j = nbits + 1;
> > +  if (nbits == 64) j++;
> > +
> > +  bufp = buf = XCNEWVEC (char, j + 1);
> > +  memset (bufp, 0, j + 1);
> > +
> > +  n = strlen (oct);
> > +  for (i = 0; i < n; i++, oct++)
> > +{
> > +  j = *oct - 48;
> > +  strcpy (bufp, &bits[j][0]);
> > +  bufp += 3;
> > +}
> > +
> > +  bufp = XCNEWVEC (char, nbits + 1);
> > +  if (nbits == 64)
> > +strcpy (bufp, buf + 2);
> > +  else
> > +strcpy (bufp, buf + 1);
> > +
> > +  free (buf);
> > +
> > +  return bufp;
> > +}
> > +
> > +
> > +/* Convert a hexidecimal string into a binary string.  This is used in the
> > +   fallback conversion of a hexidecimal string to a REAL.  */
> > +
> > +static char *
> > +hex2bin(int nbits, char *hex)
> > +{
> > +  const char bits[16][5] = {
> > +"", "0001", "0010", "0011", "0100", "0101", "0110", "0111",
> > +"1000", "1001", "1010", "1011", "1100", "1101", "1110", ""};
> > +
> > +  char *buf, *bufp;
> > +  int i, j, n;
> > +
> > +  bufp = buf = XCNEWVEC (char, nbits + 1);
> > +  memset (bufp, 0, nbits + 1);
> > +
> > +  n = strlen (hex);
> > +  for (i = 0; i < n; i++, hex++)
> > +{
> > +  j = *hex;
> > +  if (j > 47 && j < 58)
> > + j -= 48;
> > +  else if (j > 64 && j < 71)
> > + j -= 55;
> > +  else if (j > 96 && j < 103)
> > + j -= 87;
> > +  else
> > + gcc_unreachable ();
> > +
> > +  strcpy (bufp, &bits[j][0]);
> > +  bufp += 4;
> > +   }
> > +
> > +   return buf;
> > +}
> > +
> > +
> > +/* Fallback conversion of a BOZ string to REAL.  */
> > +
> > +static void
> > +bin2real (gfc_expr *x, int kind)
> > +{
> > +  char buf[114], *sp;
> > +  int b, i, ie, t, w;
> > +  bool sgn;
> > +  mpz_t em;
> > +
> > +  i = gfc_validate_kind (BT_REAL, kind, false);
> > +  t = gfc_real_kinds[i].digits - 1;
> > +
> > +  /* Number of bits in the exponent.  */
> > +  if (gfc_real_kinds[i].max_exponent == 16384)
> > +w = 15;
> > +  else if (gfc_real_kinds[i].max_exponent == 1024)
> > +w = 11;
> > +  else
> > +w = 8;
> > +
> > +  if (x->boz.rdx == 16)
> > +sp = hex2bin (gfc_real_kinds[i].mode_precision, x->boz.str);
> > +  else if (x->boz.rdx == 8)
> > +sp = oct2bin (gfc_real_kinds[i].mode_precision, x->boz.str);
> > +  else
> > +sp = x->boz.str;
> > +
> > +  /* Extract sign bit. */
> > +  sgn = *sp != '0';
> > +
> > +  /* Extract biased exponent. */
> > +  memset (buf, 0, 114);
> > +  strncpy (buf, ++sp, w);
> > +  mpz_init (em);
> > +  mpz_set_str (em, buf, 2);
> > +  ie = mpz_get_si (em);
> > +
> > +  mpfr_init2 (x->value.real, t + 1);
> >

[wwwdocs] Update C++2a status

2019-08-04 Thread Marek Polacek

Update the page for WG21 Cologne meeting motions.

Most of the links are not working yet.

Applied to CVS.

Index: cxx-status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-status.html,v
retrieving revision 1.87
diff -u -r1.87 cxx-status.html
--- cxx-status.html 8 Jul 2019 17:45:16 -   1.87
+++ cxx-status.html 4 Aug 2019 14:16:41 -
@@ -112,7 +112,10 @@
   http://wg21.link/p0734r0";>P0734R0
 http://wg21.link/p0857r0";>P0857R0
http://wg21.link/p1084r2";>P1084R2
-   http://wg21.link/p1141r2";>P1141R2
+   http://wg21.link/p1141r2";>P1141R2
+   http://wg21.link/p0848r3";>P0848R3
+   http://wg21.link/p1616r1";>P1616R1
+   http://wg21.link/p1452r2";>P1452R2
TS with -fconcepts 

 
@@ -151,7 +154,9 @@
   http://wg21.link/p0515r3";>P0515R3
http://wg21.link/p0905r1";>P0905R1
http://wg21.link/p1120r0";>P1120R0
-   http://wg21.link/p1185r2";>P1185R2
+   http://wg21.link/p1185r2";>P1185R2
+   http://wg21.link/p1186r3";>P1186R3
+   http://wg21.link/p1630r1";>P1630R1
No 
__cpp_impl_three_way_comparison >= 201711 
 
@@ -252,14 +257,6 @@

 
 
-   Support for contract based programming in C++ 
-  http://wg21.link/p0542r5";>P0542R5
-  http://wg21.link/p1289r1";>P1289R1
-  http://wg21.link/p1323r2";>P1323R2
-   No (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88102";>PR 88102)
-   
-
-
explicit(bool) 
   http://wg21.link/p0892r2";>P0892R2
9 
@@ -296,7 +293,7 @@

 
 
-   Relaxations of constexpr restrictions 
+   Relaxations of constexpr restrictions 
   http://wg21.link/p1002r1";>P1002R1
9 

@@ -312,6 +309,21 @@

 
 
+  http://wg21.link/p1331r2";>P1331R2
+  No
+   
+
+
+  http://wg21.link/p1668r1";>P1668R1
+  No
+   
+
+
+  http://wg21.link/p0784r7";>P0784R7
+  No
+   
+
+
Feature test macros 
   http://wg21.link/p0941r2";>P0941R2
4.9 
(__cpp_ macros) 
@@ -319,10 +331,19 @@

 
 
-   Modules 
+   Modules 
   http://wg21.link/p1103r3";>P1103R3
-  No (Modules 
Wiki) 
-   
+  No (Modules Wiki) 
+   
+
+
+  http://wg21.link/p1766r1";>P1766R1
+
+
+  http://wg21.link/p1811r0";>P1811R0
+
+
+  http://wg21.link/p1703r1";>P1703R1
 
 
Coroutines 
@@ -351,6 +372,55 @@
 8 

 
+
+
+  Deprecate a[b,c]
+  http://wg21.link/p1161r3";>P1161R3
+   No (https://gcc.gnu.org/PR91338";>PR91338)
+  
+
+
+  Deprecating volatile
+  http://wg21.link/p1152r4";>P1152R4
+   No
+  
+
+
+  [[nodiscard("with reason")]]
+  http://wg21.link/p1301r4";>P1301R4
+   No
+  
+
+
+  using enum
+  http://wg21.link/p1099r5";>P1099R5
+   No
+  
+
+
+  Class template argument deduction for aggregates
+  http://wg21.link/p1816r0";>P1816R0
+   No
+  
+
+
+  Class template argument deduction for alias templates
+  http://wg21.link/p1814r0";>P1814R0
+   No
+  
+
+
+  Permit conversions to arrays of unknown bound
+  http://wg21.link/p0388r4";>P0388R4
+   No
+  
+
+
+  constinit
+  http://wg21.link/p1143r2";>P1143R2
+   No
+  
+
   
 
   C++17 Support in GCC

Re: [PATCH] PR fortran/88227 -- Revenge of the BOZ

2019-08-04 Thread Steve Kargl

On Sun, Aug 04, 2019 at 03:14:53PM +0100, Paul Richard Thomas wrote:
> Hi Steve,
> 
> This is OK.
> 
> Thanks for working on it.
> 
> Paul
> 

Thanks.  BTW, I started to read your SELECT RANK patch.
>From I read, it looks good.  When you're ready with a
final patch, feel free to ping me.

-- 
Steve

[wwwdocs] Further tweaks to C++2a status

2019-08-04 Thread Marek Polacek

Applied to CVS.

Index: cxx-status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx-status.html,v
retrieving revision 1.88
diff -u -r1.88 cxx-status.html
--- cxx-status.html 4 Aug 2019 14:19:27 -   1.88
+++ cxx-status.html 4 Aug 2019 15:42:24 -
@@ -277,7 +277,7 @@
 
Immediate functions (consteval) 
   http://wg21.link/p1073r3";>P1073R3
-   No (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335";>PR 88335)
+  No (https://gcc.gnu.org/PR88335";>PR88335)

 
 
@@ -300,7 +300,7 @@
 
 
   http://wg21.link/p1327r1";>P1327R1
-   No (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337";>PR 88337)
+  No (https://gcc.gnu.org/PR88337";>PR88337)

 
 
@@ -315,7 +315,7 @@
 
 
   http://wg21.link/p1668r1";>P1668R1
-  No
+  No (https://gcc.gnu.org/PR91346";>PR91346)

 
 
@@ -354,14 +354,14 @@
 
Parenthesized initialization of aggregates 
   http://wg21.link/p0960r3";>P0960R3
-   No 
+  No
__cpp_aggregate_paren_init >= 201902
 
 
Stronger Unicode requirements 
   http://wg21.link/p1041r4";>P1041R4
   http://wg21.link/p1139r2";>P1139R2
-   No 
+  No

 
 
@@ -376,49 +376,49 @@
 
   Deprecate a[b,c]
   http://wg21.link/p1161r3";>P1161R3
-   No (https://gcc.gnu.org/PR91338";>PR91338)
+  No (https://gcc.gnu.org/PR91338";>PR91338)
   
 
 
   Deprecating volatile
   http://wg21.link/p1152r4";>P1152R4
-   No
+  No
   
 
 
   [[nodiscard("with reason")]]
   http://wg21.link/p1301r4";>P1301R4
-   No
+  No
   
 
 
   using enum
   http://wg21.link/p1099r5";>P1099R5
-   No
+  No
   
 
 
   Class template argument deduction for aggregates
   http://wg21.link/p1816r0";>P1816R0
-   No
+  No
   
 
 
   Class template argument deduction for alias templates
   http://wg21.link/p1814r0";>P1814R0
-   No
+  No
   
 
 
   Permit conversions to arrays of unknown bound
   http://wg21.link/p0388r4";>P0388R4
-   No
+  No
   
 
 
   constinit
   http://wg21.link/p1143r2";>P1143R2
-   No
+  No

Re: Start implementing -frounding-math

2019-08-04 Thread Marc Glisse


Hello,

just posting the current version of this patch, in case people have 
comments.


Some changes: the inline asm is introduced during expansion, and the thing 
is controlled by a different flag (it should be controlled by the pragma, 
but that's starting to be too many pieces to implement at the same time, 
and I didn't want to cause a regression for people using -frounding-math 
in the case where it actually works). I also added an extra parameter, 
currently always 0, to specify some properties of the operation : the 
first one I am thinking of is "don't care about exceptions" since I only 
care about rounding, but that will require even more flags / pragmas to 
specify the variants we want...


For the inline asm, I hesitated between building a temporary GIMPLE_ASM 
just so I could pass it to the existing expansion, or "inlining" a 
simplified version. This version always goes through the stack, which 
matches well with the constraint "=m". One would have to modify the code 
to allow "=x". Using "=mx", the compiler does simplify things so we 
actually go through registers (it randomly leaves a dead store to the 
stack here or there, but not that many and it looks like an existing 
missed optimization), which makes me think it is not that important to 
write specific code to handle "=x".


Some possible future work:
- target hook to specify a constraint different from "=m"
- target hook to expand the functions and/or the opaque pass-through
- more operations (maybe comparisons, conversions, etc)
- lowering generic vector operations, so I can enable them in the front-end
- parsing the pragma
- optimizations (at least exact constant folding)
- constexpr? Disable in some contexts where a dynamic rounding mode makes 
less sense?

- C front-end
- Use caller's environment for always_inline callee? We would have to mark 
the call so we remember what the environment was, and it would be too late 
for some foldings, but we could still translate the operations that 
remain, which should be sufficient for the x86 *intrin.h files. To be safe 
we would have to assume fenv_access on for always_inline functions and 
only lower them to regular operations when we see the caller, but that 
might be too much.


--
Marc GlisseIndex: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt	(revision 274007)
+++ gcc/c-family/c.opt	(working copy)
@@ -1495,20 +1495,24 @@ C ObjC C++ ObjC++ Joined RejectNegative
 -fexec-charset=	Convert all strings and character constants to character set .
 
 fextended-identifiers
 C ObjC C++ ObjC++
 Permit universal character names (\\u and \\U) in identifiers.
 
 finput-charset=
 C ObjC C++ ObjC++ Joined RejectNegative
 -finput-charset=	Specify the default character set for source files.
 
+ffenv-access
+C++ ObjC++ Var(flag_fenv_access)
+Assume #pragma STDC FENV_ACCESS ON at the beginning of the translation unit (experimental and incomplete support).
+
 fextern-tls-init
 C++ ObjC++ Var(flag_extern_tls_init) Init(-1)
 Support dynamic initialization of thread-local variables in a different translation unit.
 
 fexternal-templates
 C++ ObjC++ Deprecated
 
 ffor-scope
 C++ ObjC++ Deprecated
 
Index: gcc/cp/call.c
===
--- gcc/cp/call.c	(revision 274007)
+++ gcc/cp/call.c	(working copy)
@@ -9137,21 +9137,33 @@ maybe_warn_class_memaccess (location_t l
high-level operations.  */
 
 tree
 build_cxx_call (tree fn, int nargs, tree *argarray,
 		tsubst_flags_t complain)
 {
   tree fndecl;
 
   /* Remember roughly where this call is.  */
   location_t loc = cp_expr_loc_or_loc (fn, input_location);
-  fn = build_call_a (fn, nargs, argarray);
+
+  if (flag_fenv_access && TREE_CODE (fn) == ADDR_EXPR
+  && (fndecl_built_in_p (TREE_OPERAND (fn, 0), BUILT_IN_SQRT)
+	  || fndecl_built_in_p (TREE_OPERAND (fn, 0), BUILT_IN_SQRTF)
+	  || fndecl_built_in_p (TREE_OPERAND (fn, 0), BUILT_IN_SQRTL)))
+{
+  fn = build_call_expr_internal_loc (loc, IFN_FENV_SQRT,
+	 TREE_TYPE (argarray[0]), 2,
+	 argarray[0], integer_zero_node);
+  TREE_SIDE_EFFECTS (fn) = 1;
+}
+  else
+fn = build_call_a (fn, nargs, argarray);
   SET_EXPR_LOCATION (fn, loc);
 
   fndecl = get_callee_fndecl (fn);
 
   /* Check that arguments to builtin functions match the expectations.  */
   if (fndecl
   && !processing_template_decl
   && fndecl_built_in_p (fndecl, BUILT_IN_NORMAL))
 {
   int i;
Index: gcc/cp/typeck.c
===
--- gcc/cp/typeck.c	(revision 274007)
+++ gcc/cp/typeck.c	(working copy)
@@ -5543,20 +5543,52 @@ cp_build_binary_op (const op_location_t
 	  if (TREE_TYPE (cop0) != orig_type)
 	cop0 = cp_convert (orig_type, op0, complain);
 	  if (TREE_TYPE (cop1) != orig_type)
 	cop1 = cp_convert (orig_type, op1, complain);
 	  instrument_expr = ubsan_instrument_division (location, cop0, cop1);
 	}
   else

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

2019-08-04 Thread Uros Bizjak

On Sat, Aug 3, 2019 at 7:26 PM Richard Biener  wrote:
>
> On Thu, 1 Aug 2019, Uros Bizjak wrote:
>
> > On Thu, Aug 1, 2019 at 11:28 AM Richard Biener  wrote:
> >
>  So you unconditionally add a smaxdi3 pattern - indeed this looks
>  necessary even when going the STV route.  The actual regression
>  for the testcase could also be solved by turing the smaxsi3
>  back into a compare and jump rather than a conditional move sequence.
>  So I wonder how you'd do that given that there's pass_if_after_reload
>  after pass_split_after_reload and I'm not sure we can split
>  as late as pass_split_before_sched2 (there's also a split _after_
>  sched2 on x86 it seems).
> 
>  So how would you go implement {s,u}{min,max}{si,di}3 for the
>  case STV doesn't end up doing any transform?
> >>>
> >>> If STV doesn't transform the insn, then a pre-reload splitter splits
> >>> the insn back to compare+cmove.
> >>
> >> OK, that would work.  But there's no way to force a jumpy sequence then
> >> which we know is faster than compare+cmove because later RTL
> >> if-conversion passes happily re-discover the smax (or conditional move)
> >> sequence.
> >>
> >>> However, considering the SImode move
> >>> from/to int/xmm register is relatively cheap, the cost function should
> >>> be tuned so that STV always converts smaxsi3 pattern.
> >>
> >> Note that on both Zen and even more so bdverN the int/xmm transition
> >> makes it no longer profitable but a _lot_ slower than the cmp/cmov
> >> sequence... (for the loop in hmmer which is the only one I see
> >> any effect of any of my patches).  So identifying chains that
> >> start/end in memory is important for cost reasons.
> >
> > Please note that the cost function also considers the cost of move
> > from/to xmm. So, the cost of the whole chain would disable the
> > transformation.
> >
> >> So I think the splitting has to happen after the last if-conversion
> >> pass (and thus we may need to allocate a scratch register for this
> >> purpose?)
> >
> > I really hope that the underlying issue will be solved by a machine
> > dependant pass inserted somewhere after the pre-reload split. This
> > way, we can split unconverted smax to the cmove, and this later pass
> > would handle jcc and cmove instructions. Until then... yes your
> > proposed approach is one of the ways to avoid unwanted if-conversion,
> > although sometimes we would like to split to cmove instead.
>
> So the following makes STV also consider SImode chains, re-using the
> DImode chain code.  I've kept a simple incomplete smaxsi3 pattern
> and also did not alter the {SI,DI}mode chain cost function - it's
> quite off for TARGET_64BIT.  With this I get the expected conversion
> for the testcase derived from hmmer.
>
> No further testing sofar.
>
> Is it OK to re-use the DImode chain code this way?  I'll clean things
> up some more of course.

Yes, the approach looks OK to me. It makes chain building mode
agnostic, and the chain building can be used for
a) DImode x86_32 (as is now), but maybe 64bit minmax operation can be added.
b) SImode x86_32 and x86_64 (this will be mainly used for SImode
minmax and surrounding SImode operations)
c) DImode x86_64 (also, mainly used for DImode minmax and surrounding
DImode operations)

> Still need help with the actual patterns for minmax and how the splitters
> should look like.

Please look at the attached patch. Maybe we can add memory_operand as
operand 1 and operand 2 predicate, but let's keep things simple for
now.

Uros.
Index: i386.md
===
--- i386.md (revision 274008)
+++ i386.md (working copy)
@@ -17721,6 +17721,27 @@
 std::swap (operands[4], operands[5]);
 })
 
+;; min/max patterns
+
+(define_code_attr smaxmin_rel [(smax "ge") (smin "le")])
+
+(define_insn_and_split "3"
+  [(set (match_operand:SWI48 0 "register_operand")
+   (smaxmin:SWI48 (match_operand:SWI48 1 "register_operand")
+  (match_operand:SWI48 2 "register_operand")))
+   (clobber (reg:CC FLAGS_REG))]
+  "TARGET_STV && TARGET_SSE4_1
+   && can_create_pseudo_p ()"
+  "#"
+  "&& 1"
+  [(set (reg:CCGC FLAGS_REG)
+   (compare:CCGC (match_dup 1)(match_dup 2)))
+   (set (match_dup 0)
+   (if_then_else:SWI48
+ ( (reg:CCGC FLAGS_REG)(const_int 0))
+ (match_dup 1)
+ (match_dup 2)))])
+
 ;; Conditional addition patterns
 (define_expand "addcc"
   [(match_operand:SWI 0 "register_operand")

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

2019-08-04 Thread Jakub Jelinek

On Sun, Aug 04, 2019 at 07:11:01PM +0200, Uros Bizjak wrote:
> Yes, the approach looks OK to me. It makes chain building mode
> agnostic, and the chain building can be used for
> a) DImode x86_32 (as is now), but maybe 64bit minmax operation can be added.
> b) SImode x86_32 and x86_64 (this will be mainly used for SImode
> minmax and surrounding SImode operations)
> c) DImode x86_64 (also, mainly used for DImode minmax and surrounding
> DImode operations)
> 
> > Still need help with the actual patterns for minmax and how the splitters
> > should look like.
> 
> Please look at the attached patch. Maybe we can add memory_operand as
> operand 1 and operand 2 predicate, but let's keep things simple for
> now.

Shouldn't it be used also for p{min,max}ud rather than just p{min,max}sd?
What about p{min,max}{s,u}{b,w,q}?  Some of those are already in SSE.

If the conversion of the chain fails, couldn't the STV pass split those
SImode etc. min/max patterns into code with branches, rather than turn it
into cmovs?

Jakub

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

2019-08-04 Thread Uros Bizjak

On Sun, Aug 4, 2019 at 7:23 PM Jakub Jelinek  wrote:
>
> On Sun, Aug 04, 2019 at 07:11:01PM +0200, Uros Bizjak wrote:
> > Yes, the approach looks OK to me. It makes chain building mode
> > agnostic, and the chain building can be used for
> > a) DImode x86_32 (as is now), but maybe 64bit minmax operation can be added.
> > b) SImode x86_32 and x86_64 (this will be mainly used for SImode
> > minmax and surrounding SImode operations)
> > c) DImode x86_64 (also, mainly used for DImode minmax and surrounding
> > DImode operations)
> >
> > > Still need help with the actual patterns for minmax and how the splitters
> > > should look like.
> >
> > Please look at the attached patch. Maybe we can add memory_operand as
> > operand 1 and operand 2 predicate, but let's keep things simple for
> > now.
>
> Shouldn't it be used also for p{min,max}ud rather than just p{min,max}sd?
> What about p{min,max}{s,u}{b,w,q}?  Some of those are already in SSE.

Sure, unsigned ops will also be added. I just went through the
Richard's patch and looked for RTXes that Richard's patch handles. I'm
not sure about HImode and QImode minmax operations. While these can be
added, we would need to re-run STV in HImode and QImode - I wonder if
it is worth.

> If the conversion of the chain fails, couldn't the STV pass split those
> SImode etc. min/max patterns into code with branches, rather than turn it
> into cmovs?

Since these patterns require SSE4.1, we are sure that we can split
back to cmov. But IMO, cmov/jcc issue is orthogonal to minmax
conversion and should be handled by some other machine-specific pass
that would
analyse cmove insertion and eventually split unwanted cmoves back to
jcc (based on some yet unknown metrics). Please note that there is no
definite proof that it is beneficial to convert cmoves to jcc for all
x86 targets.

Uros.

Re: [PATCH 1/2] rs6000: Debug regnums for TM registers

2019-08-04 Thread Segher Boessenkool

On Thu, May 02, 2019 at 06:24:10PM +, Segher Boessenkool wrote:
> Since GCC 8, we have output incorrect numbers for the transactional
> memory registers.
> 
> Also, we didn't output the correct DWARF register numbers for those.
> The number for sprN is 100+N.
> 
> This fixes both these issues.
> 
> Tested on powerpc64-linux (-m32,-m64} and on powerpc64le-linux.
> Committing.  I hope this (and the next patch) doesn't break targets
> using the old DWARF register numbers, I cannot easily test that; but
> it's stage 1.
> 
> This should be backported to GCC 8 and GCC 9 (9.2).

I did those backports now.


Segher

Re: [PATCH, Ada] Push -shared-libgcc where needed.

2019-08-04 Thread Eric Botcazou

> This patch has now been on mainline for some time without any apparent
> issue, the problem is also present on the open branches, may I backport it?

OK, thanks.

-- 
Eric Botcazou

Re: [PATCH, Ada, Darwin, PPC] PPC Darwin has stack check probes.

2019-08-04 Thread Eric Botcazou

> This (PPC)Darwin-specific patch has been on mainline for some time now
> without issues, the problem is present on open branches, may I backport it?

Yes, thanks.

-- 
Eric Botcazou

Re: [PATCH] More fixes for update_web_docs_svn for jit docs (PR jit/64257)

2019-08-04 Thread Gerald Pfeifer

On Wed, 4 Feb 2015, David Malcolm wrote:
>> That was my plan, yes. :-)  I just did that and manually ran
>> the script, and it seems to work.
> Thank you!

>> Still, do you think you can add a bit of error handling such
>> that an issue like the one we had (cf. 
>> https://gcc.gnu.org/ml/gccadmin/2015-q1/msg00077.html ) does
>> not kill the entire script?  A bit of resilience would be good.
> Something like the attached?  (completely untested, sorry)

Yes.

Given that this was a while ago (ahem), I went ahead, created a
ChangeLog entry, committed the patch on your behalf, updated the
version on gcc.gnu.org, and did a test run there.

Gerald


2019-08-05  David Malcolm  

* update_web_docs_svn: Proceed even if the invocation of
sphinx fails.

Index: update_web_docs_svn
===
--- update_web_docs_svn (revision 274098)
+++ update_web_docs_svn (working copy)
@@ -190,7 +190,7 @@ done
 #   /usr/bin/sphinx-1.0-build
 # so we need to override SPHINXBUILD with this when invoking "make".
 pushd gcc/gcc/jit/docs
-make SPHINXBUILD=/usr/bin/sphinx-1.0-build html
+make SPHINXBUILD=/usr/bin/sphinx-1.0-build html || true
 popd
 cp -a gcc/gcc/jit/docs/_build/html jit
 mkdir -p $DOCSDIR/jit

Re: [PATCH] Adding _Dependent_ptr type qualifier in C part 1/3

2019-08-04 Thread Paul E. McKenney

Good points!

On the type-qualifier interactions, here is an initial list.  Thoughts?

Thanx, Paul

_Alignas: Dependency-breaking optimizations would be avoided, and the
variable would be aligned as specified.

_Atomic: Dependency-breaking optimizations would be avoided, and the
variable would be accessed using C11 atomics.

const: This is not particularly useful for variables with static storage
duration because compile-time initialization does not require dependency
ordering, but then again, use of _Dependent_ptr on such variables is
suspect to begin with.  Otherwise, the const _Dependent_ptr variable
would normally be initialized from another _Dependent_ptr variable or
from a memory_order_consume load.  The variable would disallow further
stores and avoid breaking dependencies.

extern: Dependency-breaking optimizations would be avoided, and the
variable would be usable within other translation units.  This is
also an unusual addition to a _Dependent_ptr unless also accompanied by
_Thread_local because there are no known non-suspect multi-threaded-access
use cases for _Dependent_ptr.

register: Dependency-breaking optimizations would be avoided, and the
compiler would be given a hint to keep the variable in a register.

restrict: Dependency-breaking optimizations would be avoided, and the
compiler may assume that the pointed-to object is only accessed through
this pointer and through pointers derived from it.

static: Dependency-breaking optimizations would be avoided, and the
variable would be static.  This is also an unusual addition to a
_Dependent_ptr unless also accompanied by _Thread_local because there are
no known non-suspect multi-threaded-access use cases for _Dependent_ptr.

_Thread_local: The dependency-carrying variable is thread-local, and
avoids dependency-breaking optimizations.

volatile: All accesses would be executed as per the abstract machine,
and dependency-breaking optimizations would be avoided.

On Fri, Aug 02, 2019 at 08:30:49PM -0600, Martin Sebor wrote:
> On 8/1/19 9:26 AM, Paul McKenney wrote:
> >Excellent point, this discussion needs to be made official.
> >Please see attached for an initial draft of a working paper.
> >
> >Thoughts?
> 
> The draft is a start but it (obviously) needs a lot of work to cover
> the constraints and semantics so I'll just comment on the patch in
> a bit more detail.
> 
> Since the feature is being (or will be) proposed to WG14 and could
> change I would expect it to be only available under -std=c2x and
> disabled otherwise, so that code that makes use of it does so with
> the understanding that it's only experimental.  (I just noticed
> Akshat email with a tweak to the patch.  I'm not sure that issuing
> a pedantic warning and having the name in the implementation namepace
> is enough but others (the C FE maintainers) will know better.)
> 
> Other than that, I would also expect to see more extensive test
> coverage, at a minimum to exercise error detection (invalid uses,
> conversions, etc.).  For example, I see the code that rejects it
> but no tests for declaring, say, a _Dependent_ptr-qualified integer.
> What I don't think I see is code that rejects _Dependent_ptr-qualified
> function pointers (AFAIK, POINTER_TYPE_P evaluates to nonzero for both).
> Is that intended?  (And if so, what does it mean?)I also see that
> the new tests look for warnings but it's not clear to me that that's
> their intent or that the dg-warning directives are being used to
> "suppress" warnings for issues in the tests.  For instance, this
> is common:
> 
>   rcu_assign_pointer (gp,p);  /* { dg-warning
> "\\\[-Wincompatible-pointer-types]" } */
> 
> but neither gp nor p is a  _Dependent_ptr.  (I may be missing
> the purpose of the compile-only tests.  E.g., the only thing
> p0190r4_fig10.c seems to be exercising besides that the _Dependent_ptr
> qualifier is accepted is a couple of warnings, one of which is the one
> above.)  I would suggest to look at tests for other qualifiers for
> examples and model the new ones after those.
> 
> I'm also wondering how the new qualifier interacts with others like
> const.  Should all combinations of qualifiers be accepted and do
> they affect the semantics in any interesting way?  This is probably
> something to cover in the proposal.
> 
> Martin
> 
> >
> >  Thanx, Paul
> >
> >On Tue, Jul 30, 2019 at 12:46 PM Martin Sebor  wrote:
> >>
> >>On 7/30/19 1:13 AM, Akshat Garg wrote:
> >>>Hi,
> >>>This patch includes C front-end code for a type qualifier _Dependent_ptr.
> >>
> >>Just some very high-level comments/questions.  I only followed
> >>the _Dependent_ptr discussion from a distance and I'm likely
> >>missing some context so the first thing I looked for in this
> >>patch is documentation of the new qualifier.  Unless it's
> >>a proposed C2x feature that I missed I would expect to find it
> >>in section 6 - Extensions to th

PR91349, powerpc64--freebsd* defines _GNU_SOURCE

2019-08-04 Thread Alan Modra

rev 266496 (git ab6b1bb456) undefined some macros in rs6000/freebsd.h
but missed doing the same in rs6000/freebsd64.h.  Fixed by making the
obvious (and preapproved) patch.

PR target/91349
* config/rs6000/freebsd64.h (CPLUSPLUS_CPP_SPEC),
(LINK_GCC_C_SEQUENCE_SPEC): Undef.

diff --git a/gcc/config/rs6000/freebsd64.h b/gcc/config/rs6000/freebsd64.h
index 4951275c963..9367a6e40f3 100644
--- a/gcc/config/rs6000/freebsd64.h
+++ b/gcc/config/rs6000/freebsd64.h
@@ -17,6 +17,10 @@
along with GCC; see the file COPYING3.  If not see
.  */
 
+/* Undef gnu-user.h macros we don't want.  */
+#undef CPLUSPLUS_CPP_SPEC
+#undef LINK_GCC_C_SEQUENCE_SPEC
+
 /* Override the defaults, which exist to force the proper definition.  */
 
 #ifdef IN_LIBGCC2

-- 
Alan Modra
Australia Development Lab, IBM

Re: [PATCH v2] RISC-V: Promote type correctly for libcalls

2019-08-04 Thread Kito Cheng

Committed as r274107

Hi Jakub, Richard:

This patch is fix ABI bug for libcall on RISC-V, we've also tested on
gcc 8 and 9, it's ok for gcc 9 and 8?

Thanks.

On Fri, Aug 2, 2019 at 11:52 PM Jim Wilson  wrote:
>
> On Fri, Aug 2, 2019 at 12:11 AM Kito Cheng  wrote:
> > gcc/ChangeLog
> > * config/riscv/riscv.c (riscv_promote_function_mode): New.
> > (TARGET_PROMOTE_FUNCTION_MODE): Use riscv_promote_function_mode.
> > gcc/testsuite/ChangeLog
> > * gcc.target/riscv/promote-type-for-libcall.c: New.
>
> Thanks.  This looks good, and fails with gcc mainline without the patch.
>
> Jim

Re: [PATCH V5, rs6000] Support vrotr3 for int vector types

2019-08-04 Thread Kewen.Lin

Hi Segher,

on 2019/8/4 上午4:52, Segher Boessenkool wrote:
> Hi!
> 
> I somehow lost track of this email, sorry.
> 
> On Fri, Aug 02, 2019 at 04:59:44PM +0800, Kewen.Lin wrote:
>> As to the predicate name and usage, I checked the current vector shifts, 
>> they don't need to check const_vector specially (like right to left 
>> conversion), excepting for the one "vec_shr_", but it checks for
>> scalar const int.
> 
> I don't understand why we want to expand rotate-by-vector-of-immediates
> if we have no insns for that?  If you just use vint_operand, what happens
> then?
> 

You are right, if we just use vint_operand, the functionality should be the
same, the only small difference is the adjusted constant rotation number 
isn't masked, but it would be fine for functionality.

One example for ULL >r 8, with const vector handling, it gets
  xxspltib 33,56

Without the handling, it gets 
  xxsplitb 33,248

But I agree that it's trivial and unified it as below attached patch.

>> +/* { dg-options "-O3" } */
>> +/* { dg-require-effective-target powerpc_altivec_ok } */
> 
> If you use altivec_ok, you need to use -maltivec in the options, too.
> This test should probably work with -O2 as well; use that, if possible.
> 

Sorry, the test case depends on vectorization which isn't enabled at -O2
by default.

>> +/* { dg-require-effective-target powerpc_p8vector_ok } */
> 
> I don't think we need this anymore?  Not sure.
> 

I thought -mdejagnu-cpu=power8 can only ensure power8 cpu setting takes
preference, but can't guarantee the current driver supports power8
complication.  As your comments, I guess since gcc configuration don't
have without-cpu= etc., the power8 support should be always guaranteed?


Thanks,
Kewen

-

gcc/ChangeLog

2019-08-05  Kewen Lin  

* config/rs6000/vector.md (vrotr3): New define_expand.

gcc/testsuite/ChangeLog

2019-08-05  Kewen Lin  

* gcc.target/powerpc/vec_rotate-1.c: New test.
* gcc.target/powerpc/vec_rotate-2.c: New test.
* gcc.target/powerpc/vec_rotate-3.c: New test.
* gcc.target/powerpc/vec_rotate-4.c: New test.
diff --git a/gcc/config/rs6000/vector.md b/gcc/config/rs6000/vector.md
index 70bcfe02e22..886cbad1655 100644
--- a/gcc/config/rs6000/vector.md
+++ b/gcc/config/rs6000/vector.md
@@ -1260,6 +1260,19 @@
   "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
   "")
 
+;; Expanders for rotatert to make use of vrotl
+(define_expand "vrotr3"
+  [(set (match_operand:VEC_I 0 "vint_operand")
+   (rotatert:VEC_I (match_operand:VEC_I 1 "vint_operand")
+   (match_operand:VEC_I 2 "vint_operand")))]
+  "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
+{
+  rtx rot_count = gen_reg_rtx (mode);
+  emit_insn (gen_neg2 (rot_count, operands[2]));
+  emit_insn (gen_vrotl3 (operands[0], operands[1], rot_count));
+  DONE;
+})
+
 ;; Expanders for arithmetic shift left on each vector element
 (define_expand "vashl3"
   [(set (match_operand:VEC_I 0 "vint_operand")
diff --git a/gcc/testsuite/gcc.target/powerpc/vec_rotate-1.c 
b/gcc/testsuite/gcc.target/powerpc/vec_rotate-1.c
new file mode 100644
index 000..f035a578292
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/vec_rotate-1.c
@@ -0,0 +1,39 @@
+/* { dg-options "-O3" } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+
+/* Check vectorizer can exploit vector rotation instructions on Power, mainly
+   for the case rotation count is const number.
+
+   Check for instructions vrlb/vrlh/vrlw only available if altivec supported. 
*/
+
+#define N 256
+unsigned int suw[N], ruw[N];
+unsigned short suh[N], ruh[N];
+unsigned char sub[N], rub[N];
+
+void
+testUW ()
+{
+  for (int i = 0; i < 256; ++i)
+ruw[i] = (suw[i] >> 8) | (suw[i] << (sizeof (suw[0]) * 8 - 8));
+}
+
+void
+testUH ()
+{
+  for (int i = 0; i < 256; ++i)
+ruh[i] = (unsigned short) (suh[i] >> 9)
+| (unsigned short) (suh[i] << (sizeof (suh[0]) * 8 - 9));
+}
+
+void
+testUB ()
+{
+  for (int i = 0; i < 256; ++i)
+rub[i] = (unsigned char) (sub[i] >> 5)
+| (unsigned char) (sub[i] << (sizeof (sub[0]) * 8 - 5));
+}
+
+/* { dg-final { scan-assembler {\mvrlw\M} } } */
+/* { dg-final { scan-assembler {\mvrlh\M} } } */
+/* { dg-final { scan-assembler {\mvrlb\M} } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/vec_rotate-2.c 
b/gcc/testsuite/gcc.target/powerpc/vec_rotate-2.c
new file mode 100644
index 000..0a2a965ddcb
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/vec_rotate-2.c
@@ -0,0 +1,19 @@
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-options "-O3 -mdejagnu-cpu=power8" } */
+
+/* Check vectorizer can exploit vector rotation instructions on Power8, mainly
+   for the case rotation count is const number.
+
+   Check for vrld which is available on Power8 and above.  */
+
+#define N 256
+unsigned long long sud[N], rud[N];
+
+void
+testULL ()
+{
+  for (int i = 0; i < 256; ++i)
+rud[i] = (sud[i] >> 8) | (sud[i] << (sizeof (sud[0]) * 8 - 8));
+}
+
+/* { dg-fi

Re: [doc PATCH] document variable attribute alias

2019-08-04 Thread Sandra Loosemore


On 7/31/19 5:05 PM, Martin Sebor wrote:

It was pointed out recently in another forum that GCC doesn't
document attribute alias for variables.  It was also noted in
the same discussion that the semantics of accessing aliases
and their targets can have "surprising" effects because GCC
(as do other compilers) assumes that distinct declarations
with external linkage denote distinct entities.

The attached patch adds text to the manual describing attribute
alias for variables and pointing out the caveat of accessing
the same object using both the alias and the target.

Martin


One minor nit:


+@item alias ("@var{target}")
+@cindex @code{alias} variable attribute
+The @code{alias} variable attribute causes the declaration to be emitted
+as an alias for another symbol known as an @dfn{alias target}.  Except
+for top-level qualifiers the alias target must have the same type as
+the alias.  For instance, the following
+
+@smallexample
+int var_target;
+extern int __attribute__ ((alias ("var_target"))) var_alias;
+@end smallexample
+
+defines @code{var_alias} to be an alias for the @code{var_target} variable.



Please use @noindent on the continuation of the sentence after the @end 
smallexample.


OK with that fixed.

-Sandra

Re: [PATCH] Properly detect working jobserver in gcc driver.

2019-08-04 Thread Martin Liška

On 8/2/19 11:55 AM, Richard Biener wrote:
> On Fri, Aug 2, 2019 at 11:19 AM Martin Liška  wrote:
>>
>> On 8/2/19 11:15 AM, Jan Hubicka wrote:
 On Fri, Aug 2, 2019 at 10:50 AM Jakub Jelinek  wrote:
>
> On Fri, Aug 02, 2019 at 10:47:10AM +0200, Martin Liška wrote:
>>> Can you strace if other fds are opened and not closed in the spot you 
>>> had it
>>> before?  Advantage of doing it there is that it will not be done for 
>>> all the
>>> -E/-S/-c compilations when the linker is not spawned.
>>
>> I've used the same trick which you used and I'm attaching the output.
>> I believe it's fine, I can't see any opened fd by GCC.
>
> LGTM.

>>
>> Hi.
>>
 Btw, we discussed yesterday on the phone and the conclusion was to
 make -flto auto-detect a job-server (but not fall back to # of threads)
 and add -flto=auto to auto-detect a job-server and fall back to # of 
 threads.
 That basically makes -flto=jobserver the default behavior which means
 we should document -flto=1 as a way to override jobserver detection.
>>>
>>> And concerning to the yesterday discussion, my preference would still be
>>> -flto to first try presence of jobserver and default to number of
>>> threads otherwise. It seems like user friendly default to me and other
>>> tools with reasonable parallelism support usually behaves this way, too.
>>
>> I also like the default as Honza defined.
>>
>>>
>>> Sure one can use -flto=auto everywhere but then one needs to use
>>> different options for differnt compilers.  It would be nice to make
>>> -flto to do right hting for majority of users including those like me
>>> who cut&paste command lines from Make output and execute them by hand.
>>
>> Note that our ambition is to ideally backport the patches to our gcc9 
>> package.
>> The auto-detection of job-server with -flto is a behavior change that will 
>> happen
>> in the gcc9 package.
>>
>> To be honest I don't like the invention of 'auto' value for -flto command.
>> That would be useful just for gcc9 right now :/
> 
> Well.  We teached people they need to use -flto=N or -flto=jobserver to
> get parallelism.  Like we teached people they need to use -O2 to get
> any optimization.
> 
> Other compilers behave differently.  So what.
> 
> Auto-detecting threads is nice.  Suddenly trashing your system
> because you happen to invoke two links in parallel is not.
> Which is at least why changing this kind of behavior for 9.2 (or 9.3)
> vs. 9.1 is out of the question.  And I'm not sure it is OK for 10.
> 
> As with defaulting to use a job-server when present that's more
> reasonable.
> 
> For cut&pasting you then can use -flto=auto.
> 
> But it's just my opinion - I surely can adapt.

Hi.

Based on what was written, I feel OK with -flto=auto. I would
like to see jobserver detection to be only enabled with the 'auto'
option value. That will make it consistent in GCC 9.x branch.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

> 
> Richard.
> 
>> Martin
>>
>>>
>>> The fork bombing is IMO relatively rare and it was not what Jakub ran
>>> into (it was broken jobserv detection).
>>> After all whole distro built with Martin's orriginal approach of
>>> -flto= which forkbombs on every possible occasion.
>>>
>>> Said that, I could live with more conservative defaults.
>>> Honza
>>>
>>

>From 41f13e1890cc78292afb36a54982b097a3c6abdf Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 5 Aug 2019 06:44:25 +0200
Subject: [PATCH] Add -flto=auto option value.

gcc/ChangeLog:

2019-08-05  Martin Liska  

	* doc/invoke.texi: Document the option value.
	* lto-wrapper.c (run_gcc): Set auto_parallel
	only with -flto=auto.

gcc/testsuite/ChangeLog:

2019-08-05  Martin Liska  

	* g++.dg/lto/devirt-19_0.C: Add -flto=auto.
---
 gcc/doc/invoke.texi|  8 ++--
 gcc/lto-wrapper.c  | 18 --
 gcc/testsuite/g++.dg/lto/devirt-19_0.C |  2 +-
 3 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 7b3c77b8033..5ea56fbb23a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10396,8 +10396,7 @@ If you specify the optional @var{n}, the optimization and code
 generation done at link time is executed in parallel using @var{n}
 parallel jobs by utilizing an installed @command{make} program.  The
 environment variable @env{MAKE} may be used to override the program
-used.  The default value for @var{n} is automatically detected based
-on number of cores.
+used.
 
 You can also specify @option{-flto=jobserver} to use GNU make's
 job server mode to determine the number of parallel jobs. This
@@ -10406,6 +10405,11 @@ You must prepend a @samp{+} to the command recipe in the parent Makefile
 for this to work.  This option likely only works if @env{MAKE} is
 GNU make.
 
+One can also use @option{-flto=auto} to either use GNU make's
+job server m

[PATCH] Handle new operators with no arguments in DCE.

2019-08-04 Thread Martin Liška

On 8/2/19 11:34 PM, H.J. Lu wrote:
> On Tue, Jul 2, 2019 at 4:50 AM Martin Liška  wrote:
>>
>> Second part.
>>
>> Martin
> 
> This caused:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91334
> 

Hi.

I'm sending fix for the ICE. The issue is that we can end up
with a ctor without an argument (when not being used).

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
>From 76d215d59f32c5f6cbcb0a0ad4ecbfff8f181770 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Mon, 5 Aug 2019 06:55:45 +0200
Subject: [PATCH] Handle new operators with no arguments in DCE.

gcc/ChangeLog:

2019-08-05  Martin Liska  

	PR c++/91334
	* tree-ssa-dce.c (propagate_necessity): Handle new operators
	with not arguments.
	(eliminate_unnecessary_stmts): Likewise.

gcc/testsuite/ChangeLog:

2019-08-05  Martin Liska  

	PR c++/91334
	* g++.dg/torture/pr91334.C: New test.
---
 gcc/testsuite/g++.dg/torture/pr91334.C | 14 ++
 gcc/tree-ssa-dce.c | 22 --
 2 files changed, 30 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/torture/pr91334.C

diff --git a/gcc/testsuite/g++.dg/torture/pr91334.C b/gcc/testsuite/g++.dg/torture/pr91334.C
new file mode 100644
index 000..ba79d712b07
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr91334.C
@@ -0,0 +1,14 @@
+/* PR c++/91334.  */
+/* { dg-do compile } */
+
+#include 
+#include 
+
+struct A {
+  A() { throw 0; }
+  void* operator new(size_t size, double = 0.0) { return ::operator new(size);}
+  void operator delete(void* p, double) { exit(0); }
+  void operator delete(void* p) { abort(); }
+};
+
+int main() { try { new A; } catch(...) {} }
diff --git a/gcc/tree-ssa-dce.c b/gcc/tree-ssa-dce.c
index 80d5f5c30f7..afb7bd9dedc 100644
--- a/gcc/tree-ssa-dce.c
+++ b/gcc/tree-ssa-dce.c
@@ -810,6 +810,11 @@ propagate_necessity (bool aggressive)
 	  if (is_delete_operator
 	  || gimple_call_builtin_p (stmt, BUILT_IN_FREE))
 	{
+	  /* It can happen that a user delete operator has the pointer
+		 argument optimized out already.  */
+	  if (gimple_call_num_args (stmt) == 0)
+		continue;
+
 	  tree ptr = gimple_call_arg (stmt, 0);
 	  gimple *def_stmt;
 	  tree def_callee;
@@ -1323,13 +1328,18 @@ eliminate_unnecessary_stmts (void)
 		  || (is_gimple_call (stmt)
 		  && gimple_call_operator_delete_p (as_a  (stmt)
 	{
-	  tree ptr = gimple_call_arg (stmt, 0);
-	  if (TREE_CODE (ptr) == SSA_NAME)
+	  /* It can happen that a user delete operator has the pointer
+		 argument optimized out already.  */
+	  if (gimple_call_num_args (stmt) > 0)
 		{
-		  gimple *def_stmt = SSA_NAME_DEF_STMT (ptr);
-		  if (!gimple_nop_p (def_stmt)
-		  && !gimple_plf (def_stmt, STMT_NECESSARY))
-		gimple_set_plf (stmt, STMT_NECESSARY, false);
+		  tree ptr = gimple_call_arg (stmt, 0);
+		  if (TREE_CODE (ptr) == SSA_NAME)
+		{
+		  gimple *def_stmt = SSA_NAME_DEF_STMT (ptr);
+		  if (!gimple_nop_p (def_stmt)
+			  && !gimple_plf (def_stmt, STMT_NECESSARY))
+			gimple_set_plf (stmt, STMT_NECESSARY, false);
+		}
 		}
 	}
 
-- 
2.22.0

Re: [PATCH, Ada] Push -shared-libgcc where needed.

Re: [PATCH, Ada, Darwin, PPC] PPC Darwin has stack check probes.

[doc] install.texi - remove reference to age-old Tcl bug

[wwwdocs] www.sandpile.org has moved to https

[libstdc++,doc] A final(?) doxygen link fixed

[wwwdocs] Remove dysfunctional mirrors-usa.go-parts.com

Darwin backports commited for 9.2

Re: [objective-c/c++, testsuite, committed, 1/3] Workaround for PR90709.

Re: [PATCH] PR fortran/88227 -- Revenge of the BOZ

[wwwdocs] Update C++2a status

Re: [PATCH] PR fortran/88227 -- Revenge of the BOZ

[wwwdocs] Further tweaks to C++2a status

Re: Start implementing -frounding-math

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

Re: [PATCH][RFC][x86] Fix PR91154, add SImode smax, allow SImode add in SSE regs

Re: [PATCH 1/2] rs6000: Debug regnums for TM registers

Re: [PATCH, Ada] Push -shared-libgcc where needed.

Re: [PATCH, Ada, Darwin, PPC] PPC Darwin has stack check probes.

Re: [PATCH] More fixes for update_web_docs_svn for jit docs (PR jit/64257)

Re: [PATCH] Adding _Dependent_ptr type qualifier in C part 1/3

PR91349, powerpc64--freebsd* defines _GNU_SOURCE

Re: [PATCH v2] RISC-V: Promote type correctly for libcalls

Re: [PATCH V5, rs6000] Support vrotr3 for int vector types

Re: [doc PATCH] document variable attribute alias

Re: [PATCH] Properly detect working jobserver in gcc driver.

[PATCH] Handle new operators with no arguments in DCE.

27 matches

Site Navigation

Mail list logo

Footer information