Re: [PATCH] PR 64256

[Jeff Law]

On 02/06/15 19:32, David Edelsohn wrote:

After a lot of investigation, I believe that I have learned why stabs
debugging on AIX disabled use of continuations.  GDB, IBM DBX and IBM
XLDB are able to work with stab string continuations produced by GCC.

I am enabling it using definitions that match the behavior of IBM XL
compilers to avoid any unexpected behavior and hopefully be able to
reproduce any future errors with native tools to expedite fixes.
XCOFF32 uses an unsigned short for the stabstring length for a maximum
length of 64K, but XLC limits the size to 16K.  XLC also uses '?' as a
continuation character instead of '\\'.  GDB accepts '?' as an
alternate continuation character.

Bootstrapped on powerpc-ibm-aix7.1.0.0.

Committed.

Thanks, David

 PR debug/2714
 PR bootstrap/64256
 * xcoffout.h (DBX_CONTIN_LENGTH): Define as 16384.
 (DBX_CONTIN_CHAR): Define.
Well, I thought I was going to have the oldest BZ fixed for this 
release, but you beat me by a mile.


Glad to see this resolved.

jeff

[PATCH] PR 64256

[David Edelsohn]

After a lot of investigation, I believe that I have learned why stabs
debugging on AIX disabled use of continuations.  GDB, IBM DBX and IBM
XLDB are able to work with stab string continuations produced by GCC.

I am enabling it using definitions that match the behavior of IBM XL
compilers to avoid any unexpected behavior and hopefully be able to
reproduce any future errors with native tools to expedite fixes.
XCOFF32 uses an unsigned short for the stabstring length for a maximum
length of 64K, but XLC limits the size to 16K.  XLC also uses '?' as a
continuation character instead of '\\'.  GDB accepts '?' as an
alternate continuation character.

Bootstrapped on powerpc-ibm-aix7.1.0.0.

Committed.

Thanks, David

PR debug/2714
PR bootstrap/64256
* xcoffout.h (DBX_CONTIN_LENGTH): Define as 16384.
(DBX_CONTIN_CHAR): Define.

Index: xcoffout.h
===
--- xcoffout.h  (revision 220500)
+++ xcoffout.h  (working copy)
@@ -161,9 +161,12 @@
 /* Do not emit any marker for XCOFF until assembler allows XFT_CV.  */
 #define NO_DBX_GCC_MARKER

-/* Do not break .stabs pseudos into continuations.  */
-#define DBX_CONTIN_LENGTH 0
+/* XCOFF32 maximum length is 64K; XLC limits to 16K.  */
+#define DBX_CONTIN_LENGTH 16384

+/* XLC uses '?' as continuation character.  */
+#define DBX_CONTIN_CHAR '?'
+
 /* Don't try to use the `x' type-cross-reference character in DBX data.

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

H.J.,
Where is this new patch?
  Jack

On Fri, Feb 6, 2015 at 8:55 PM, H.J. Lu  wrote:
> On Fri, Feb 6, 2015 at 5:51 PM, Jack Howarth  wrote:
>> H.J.,
>>  This patch also seems to be causing a huge number of regressions
>> in the g++ test suite due to linkage warnings on darwin of the form...
>>
>> ld: warning: direct access in Model::~Model() to global weak symbol
>> vtable for Model means the weak symbol cannot be overridden at
>> runtime. This was likely caused by different translation units being
>> compiled with different visibility settings.
>
> Can you try my new patch?
>
>> Can this change wait until stage1?
>> Jack
>>
>> On Fri, Feb 6, 2015 at 4:41 PM, H.J. Lu  wrote:
>>> On Fri, Feb 6, 2015 at 1:31 PM, Jack Howarth  
>>> wrote:
>>>> H.J.,
>>>> On x86_64-apple-darwin14, your patch applied to r220481 results in...
>>>>
>>>> FAIL: gcc.dg/visibility-22.c (test for excess errors)
>>>> FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo
>>>>
>>>> with...
>>>>
>>>> Executing on host:
>>>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>>>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>>>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
>>>>  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC  -lm
>>>> -m32  -o ./visibility-22.exe(timeout = 300)
>>>> spawn -ignore SIGHUP
>>>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>>>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>>>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
>>>> -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -lm -m32
>>>> -o ./visibility-22.exe^M
>>>> Undefined symbols for architecture i386:^M
>>>>   "_foo", referenced from:^M
>>>>   _main in ccMD1qjz.o^M
>>>>   _main in ccMD1qjz.o^M
>>>> ld: symbol(s) not found for architecture i386^M
>>>> collect2: error: ld returned 1 exit status^M
>>>> compiler exited with status 1
>>>> output is:
>>>> Undefined symbols for architecture i386:^M
>>>>   "_foo", referenced from:^M
>>>>   _main in ccMD1qjz.o^M
>>>>   _main in ccMD1qjz.o^M
>>>> ld: symbol(s) not found for architecture i386^M
>>>> collect2: error: ld returned 1 exit status^M
>>>>
>>>> FAIL: gcc.dg/visibility-22.c (test for excess errors)
>>>>
>>>> Executing on host:
>>>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>>>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>>>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
>>>>  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC -S
>>>> -m32  -o visibility-23.s(timeout = 300)
>>>> spawn -ignore SIGHUP
>>>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>>>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>>>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
>>>> -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -S -m32 -o
>>>> visibility-23.s^M
>>>> PASS: gcc.dg/visibility-23.c (test for excess errors)
>>>> FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo
>>>>
>>>
>>> Does Darwin support undefined hidden weak symbol?
>>> Can you compile and gcc/testsuite/gcc.dg/visibility-22.c
>>> with clang on Darwin?
>>>
>>> --
>>> H.J.
>
>
>
> --
> H.J.

[patch, libgfortran] [4.8/4.9/5 Regression] error reading (and writing) large text files in gfortran

[Jerry DeLisle]

With the attached patch I create a special version of fbuf_flush that is only 
called with list directed I/O.  There can be no tabbing back and forth so it is 
safe to flush the buffer whenever we want.  The bug occurs when the buffer keeps 
growing to no end until no more allocations can be made and the OS gives an error.


fbuf_flush can be called as much as one wants to, but to keep overhead low, I 
introduce a new version with an arbitrary limit.  If below the limit, just 
return doing no flushing.  When the limit is exceeded, fbuf is flushed.  The 
code to do this is duplicated from the original fbuf_flush so it is very safe 
and well tested.


I played with the allowable maximum position limit for flushing and ran some 
timing tests.  My machine here uses a solid state drive which may bias the 
results somewhat.  Others are welcome to test and see what values they get as 
well.  I settled on 524588 based on these results, favoring writing over reading 
a little.


The patch has zero impact on any other type of I/O including normal formatted 
I/O.  I also tested to confirm that formatted I/O does not have the problem.  It 
is flushed regularly in the main transfer loop.  As far as I can tell only list 
directed has the issue.


I get the following timings using the attached test program.

WRITING:
 Array Size-->   100 1
 Buf Limit

  16384 2.107   210.9
  32768 2.026   292.1
  65636 2.232   235.8
  5242881.958   193.5
 10485762.023   203.5


READING:
 Buf Limit

  16384 1.843   184.4
  32768 1.841   186.8
  65636 1.816   197.6
  5242881.879   186.5
 10485761.834   185.2

Regression tested on x86-64 Linux.

OK for trunk followed by backports?

I can not include a specific testsuite test case, it would take way too long to 
run.

Regards,

Jerry

2015-02-07  Jerry DeLisle  

PR libgfortran/60956
* io/fbuf.c (fbuf_flush_list): New function that only flushes
if current fbuf position exceeds a limit.
* io/fbuf.h: Declare the new function.
* io/io.h (enum unit_mode): Add two new modes.
* io/list_read.c (list_formatted_read_scalar): Call new function.
* io/write.c: Include fbuf.h. (list_formatted_write_scalar):
Call new function.
Index: fbuf.c
===
--- fbuf.c	(revision 220315)
+++ fbuf.c	(working copy)
@@ -171,7 +171,43 @@ fbuf_flush (gfc_unit * u, unit_mode mode)
 }
 
 
+/* The mode argument is LIST_WRITING for write mode and LIST_READING for
+   read.  This should only be used for list directed  I/O.
+   Return value is 0 for success, -1 on failure.  */
+
 int
+fbuf_flush_list (gfc_unit * u, unit_mode mode)
+{
+  int nwritten;
+
+  if (!u->fbuf)
+return 0;
+
+  if (u->fbuf->pos < 524288) /* Upper limit for list writing.  */
+return 0;
+
+  fbuf_debug (u, "fbuf_flush_list with mode %d: ", mode);
+
+  if (mode == LIST_WRITING)
+{
+  nwritten = swrite (u->s, u->fbuf->buf, u->fbuf->pos);
+  if (nwritten < 0)
+	return -1;
+}
+
+  /* Salvage remaining bytes for both reading and writing.  */ 
+  if (u->fbuf->act > u->fbuf->pos)
+memmove (u->fbuf->buf, u->fbuf->buf + u->fbuf->pos, 
+ u->fbuf->act - u->fbuf->pos);
+
+  u->fbuf->act -= u->fbuf->pos;
+  u->fbuf->pos = 0;
+
+  return 0;
+}
+
+
+int
 fbuf_seek (gfc_unit * u, int off, int whence)
 {
   if (!u->fbuf)
Index: fbuf.h
===
--- fbuf.h	(revision 220315)
+++ fbuf.h	(working copy)
@@ -59,6 +59,9 @@ internal_proto(fbuf_alloc);
 extern int fbuf_flush (gfc_unit *, unit_mode);
 internal_proto(fbuf_flush);
 
+extern int fbuf_flush_list (gfc_unit *, unit_mode);
+internal_proto(fbuf_flush_list);
+
 extern int fbuf_seek (gfc_unit *, int, int);
 internal_proto(fbuf_seek);
 
Index: io.h
===
--- io.h	(revision 220315)
+++ io.h	(working copy)
@@ -231,7 +231,7 @@ typedef enum
 unit_advance;
 
 typedef enum
-{READING, WRITING}
+{READING, WRITING, LIST_READING, LIST_WRITING}
 unit_mode;
 
 typedef enum
Index: list_read.c
===
--- list_read.c	(revision 220315)
+++ list_read.c	(working copy)
@@ -2210,6 +2210,7 @@ cleanup:
   free_line (dtp);
   hit_eof (dtp);
 }
+  fbuf_flush_list (dtp->u.p.current_unit, LIST_READING);
   return err;
 }
 
Index: write.c
===
--- write.c	(revision 220315)
+++ write.c	(working copy)
@@ -25,6 +25,7 @@ see the files COPYING3 and COPYING.RUNTIME respect
 .  */
 
 #include "io.h"
+#include "fbuf.h"
 #include "format.h"
 #include "unix.h"
 #include 
@@ -1585,6 +1586,7 @@ list_formatted_write_scalar (st_parameter_dt *dt

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[H.J. Lu]

On Fri, Feb 6, 2015 at 5:51 PM, Jack Howarth  wrote:
> H.J.,
>  This patch also seems to be causing a huge number of regressions
> in the g++ test suite due to linkage warnings on darwin of the form...
>
> ld: warning: direct access in Model::~Model() to global weak symbol
> vtable for Model means the weak symbol cannot be overridden at
> runtime. This was likely caused by different translation units being
> compiled with different visibility settings.

Can you try my new patch?

> Can this change wait until stage1?
> Jack
>
> On Fri, Feb 6, 2015 at 4:41 PM, H.J. Lu  wrote:
>> On Fri, Feb 6, 2015 at 1:31 PM, Jack Howarth  
>> wrote:
>>> H.J.,
>>> On x86_64-apple-darwin14, your patch applied to r220481 results in...
>>>
>>> FAIL: gcc.dg/visibility-22.c (test for excess errors)
>>> FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo
>>>
>>> with...
>>>
>>> Executing on host:
>>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
>>>  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC  -lm
>>> -m32  -o ./visibility-22.exe(timeout = 300)
>>> spawn -ignore SIGHUP
>>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
>>> -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -lm -m32
>>> -o ./visibility-22.exe^M
>>> Undefined symbols for architecture i386:^M
>>>   "_foo", referenced from:^M
>>>   _main in ccMD1qjz.o^M
>>>   _main in ccMD1qjz.o^M
>>> ld: symbol(s) not found for architecture i386^M
>>> collect2: error: ld returned 1 exit status^M
>>> compiler exited with status 1
>>> output is:
>>> Undefined symbols for architecture i386:^M
>>>   "_foo", referenced from:^M
>>>   _main in ccMD1qjz.o^M
>>>   _main in ccMD1qjz.o^M
>>> ld: symbol(s) not found for architecture i386^M
>>> collect2: error: ld returned 1 exit status^M
>>>
>>> FAIL: gcc.dg/visibility-22.c (test for excess errors)
>>>
>>> Executing on host:
>>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
>>>  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC -S
>>> -m32  -o visibility-23.s(timeout = 300)
>>> spawn -ignore SIGHUP
>>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
>>> -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -S -m32 -o
>>> visibility-23.s^M
>>> PASS: gcc.dg/visibility-23.c (test for excess errors)
>>> FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo
>>>
>>
>> Does Darwin support undefined hidden weak symbol?
>> Can you compile and gcc/testsuite/gcc.dg/visibility-22.c
>> with clang on Darwin?
>>
>> --
>> H.J.



-- 
H.J.

Re: [doc, committed] fix typos in docs/comments for devirtualization optimizations

[Sandra Loosemore]

On 02/06/2015 06:19 PM, Gerald Pfeifer wrote:

Hi Sandra,

Index: gcc/ipa-devirt.c
===
  polymorphic (indirect) call
-   This is callgraph represention of virtual method call.  Every
+   This is callgraph representation of virtual method call.  Every
polymorphic call contains otr_type and otr_token taken from
original OBJ_TYPE_REF at callgraph construction time.

aren't some articles missing here?  "a callgraph representation
of a virtual method call"?


Yes.  (FWIW, Slavic languages don't have either definite or indefinite 
articles, and I've noticed that people who are native speakers of those 
languages often omit them in English as well  in user documentation 
I'd fix that but I'm less motivated to do it in code comments where the 
sense is clear otherwise.)


The other changes you suggest look fine to me, except this one:


   for (i = 0; BINFO_BASE_ITERATE (binfo, i, base_binfo); i++)
-/* Walking bases that have no virtual method is pointless
excercise.  */
+/* Walking bases that have no virtual method is pointless
exercise.  */
 if (polymorphic_type_binfo_p (base_binfo))

Shouldn't this just read "Walk bases..."?


No, "Walking" is a noun here.


I will be making and committing those changes, but would prefer
your second pair of eyes given that you have touched this recently.


-Sandra

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

H.J.,
 This patch also seems to be causing a huge number of regressions
in the g++ test suite due to linkage warnings on darwin of the form...

ld: warning: direct access in Model::~Model() to global weak symbol
vtable for Model means the weak symbol cannot be overridden at
runtime. This was likely caused by different translation units being
compiled with different visibility settings.

Can this change wait until stage1?
Jack

On Fri, Feb 6, 2015 at 4:41 PM, H.J. Lu  wrote:
> On Fri, Feb 6, 2015 at 1:31 PM, Jack Howarth  wrote:
>> H.J.,
>> On x86_64-apple-darwin14, your patch applied to r220481 results in...
>>
>> FAIL: gcc.dg/visibility-22.c (test for excess errors)
>> FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo
>>
>> with...
>>
>> Executing on host:
>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
>>  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC  -lm
>> -m32  -o ./visibility-22.exe(timeout = 300)
>> spawn -ignore SIGHUP
>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
>> -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -lm -m32
>> -o ./visibility-22.exe^M
>> Undefined symbols for architecture i386:^M
>>   "_foo", referenced from:^M
>>   _main in ccMD1qjz.o^M
>>   _main in ccMD1qjz.o^M
>> ld: symbol(s) not found for architecture i386^M
>> collect2: error: ld returned 1 exit status^M
>> compiler exited with status 1
>> output is:
>> Undefined symbols for architecture i386:^M
>>   "_foo", referenced from:^M
>>   _main in ccMD1qjz.o^M
>>   _main in ccMD1qjz.o^M
>> ld: symbol(s) not found for architecture i386^M
>> collect2: error: ld returned 1 exit status^M
>>
>> FAIL: gcc.dg/visibility-22.c (test for excess errors)
>>
>> Executing on host:
>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
>>  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC -S
>> -m32  -o visibility-23.s(timeout = 300)
>> spawn -ignore SIGHUP
>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
>> -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -S -m32 -o
>> visibility-23.s^M
>> PASS: gcc.dg/visibility-23.c (test for excess errors)
>> FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo
>>
>
> Does Darwin support undefined hidden weak symbol?
> Can you compile and gcc/testsuite/gcc.dg/visibility-22.c
> with clang on Darwin?
>
> --
> H.J.

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[H.J. Lu]

On Fri, Feb 6, 2015 at 1:51 PM, Jack Howarth  wrote:
> H.J.,
>  The clang compilers exhibit the same behavior on these test cases.
>
> Undefined symbols for architecture x86_64:
>   "_foo", referenced from:
>   _main in visibility-23-e1e564.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
> however if I also pass "-Wl,-undefined -Wl,dynamic_lookup" to the
> linker, both test
> compile and run.
>  FYI, the assembly from...
>
> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
> -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -S -m32 -o
> visibility-23.s

Can you give my updated patch:

https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=81a3a94c146950d489e30d07161f6df47959ae7a

a try?

Thanks.

-- 
H.J.

Re: [doc, committed] fix typos in docs/comments for devirtualization optimizations

[Gerald Pfeifer]

Hi Sandra,

Index: gcc/ipa-devirt.c
===
 polymorphic (indirect) call
-   This is callgraph represention of virtual method call.  Every
+   This is callgraph representation of virtual method call.  Every
   polymorphic call contains otr_type and otr_token taken from
   original OBJ_TYPE_REF at callgraph construction time.

aren't some articles missing here?  "a callgraph representation
of a virtual method call"?

/* The node of type inheritance graph.  For each type unique in
-   One Defintion Rule (ODR) sense, we produce one node linking all 
+   One Definition Rule (ODR) sense, we produce one node linking all 
   main variants of types equivalent to it, bases and derived types.  
*/


...in the One Definition Rule (ODR) sense... ?

-  /* All derrived types with virtual methods seen in unit;
- built only for main variants oftypes  */
+  /* All derived types with virtual methods seen in unit;
+ built only for main variants of types.  */
  vec GTY((skip)) derived_types;

Something missing here, too.  "in the unit"?

-/* Return TURE if type's constructors are all visible.  */
+/* Return TRUE if type's constructors are all visible.  */

"if a type's"?

-/* Dump ODR type T and all its derrived type.  INDENT specify indentation for
-   recusive printing.  */
+/* Dump ODR type T and all its derived types.  INDENT specifies indentation for
+   recursive printing.  */

"the indentation"?

-  /* Lookup BINFO with virtual table.  For normal types it is always last
+  /* Look up BINFO with virtual table.  For normal types it is always last
 binfo on stack.  */

"with" -> "within"?

"it is always the last"

  for (i = 0; BINFO_BASE_ITERATE (binfo, i, base_binfo); i++)
-/* Walking bases that have no virtual method is pointless excercise.  */
+/* Walking bases that have no virtual method is pointless exercise.  */
if (polymorphic_type_binfo_p (base_binfo))

Shouldn't this just read "Walk bases..."?

+ because the type is always known.  One of entries may be 
+ cxa_pure_virtual so look to at least two of them.  */


"One of the entries"

-  /* If there are no virtual tables refering the target alive,
- the only way the target can be called is an instance comming from other
- compilation unit; speculative devirtualization is build around an
+  /* If there are no live virtual tables referring the target,
+ the only way the target can be called is an instance coming from other
+ compilation unit; speculative devirtualization is built around an

"from a different compilation unit"


I will be making and committing those changes, but would prefer
your second pair of eyes given that you have touched this recently.

Gerald

Re: [PATCH/AARCH64] Fix 64893: ICE with vget_lane_u32 with C++ front-end at -O0

[Andrew Pinski]

On Mon, Feb 2, 2015 at 11:37 PM, Jakub Jelinek  wrote:
> On Mon, Feb 02, 2015 at 02:51:43PM -0800, Andrew Pinski wrote:
>> While trying to build the GCC 5 with GCC 5, I ran into an ICE when
>> building libcpp at -O0.  The problem is the C++ front-end was not
>> folding sizeof(a)/sizeof(a[0]) when passed to a function at -O0. The
>> C++ front-end keeps around sizeof until the gimplifier and there is no
>> way to fold the expressions that involve them.  So to work around the
>> issue we need to change __builtin_aarch64_im_lane_boundsi to accept an
>> extra argument and change the first two arguments to size_t type so we
>> don't get an extra cast there and do the division inside the compiler
>> itself.
>
> Relying on anything being folded at -O0 when the language does not guarantee
> it is going to be more and more of a problem.  So I think your patch is
> reasonable (of course, I'll defer this to target maintainers).
>
>> +  rtx totalsize = expand_normal (CALL_EXPR_ARG (exp, 0));
>> +  rtx elementsize = expand_normal (CALL_EXPR_ARG (exp, 1));
>> +  if (CONST_INT_P (totalsize) && CONST_INT_P (elementsize))
>> + {
>> +   rtx lane_idx = expand_normal (CALL_EXPR_ARG (exp, 2));
>> +  if (CONST_INT_P (lane_idx))
>> + aarch64_simd_lane_bounds (lane_idx, 0, UINTVAL (totalsize)/UINTVAL 
>> (elementsize), exp);
>
> Too long line?  Also, missing spaces around / .  And, ICE if
> somebody uses __builtin_aarch64_im_lane_boundsi (4, 0, 0);
> So you need to check and complain for zero elementsize too.

Good points, I don't know why I missed this.

>
>> +  else
>> + error ("%Klane index must be a constant immediate", exp);
>> + }
>>else
>> - error ("%Klane index must be a constant immediate", exp);
>> + sorry ("%Ktotal size and element size must be a constant immediate", 
>> exp);
>
> But why sorry?  If you say the builtin requires constant arguments, then it
> is not sorry, but error, it is not an unimplemented feature.

Because I originally thought that would be better than error but now
thinking this over, I was incorrect, it should be an error.
I will add a testcase for the __builtin_aarch64_im_lane_boundsi (4, 0,
0) case and retest the patch.

Thanks,
Andrew


>
> Jakub

Stepping down as global maintainer

[Diego Novillo]

It's been a long time since I did any significant work on GCC,
and it is unlikely that I'll be doing much for the foreseeable
future.

While I still have some understanding of the modules I used to
maintain, I don't think it is reasonable to have me making
decisions on them. It's been too long and I am not likely to have
a good understanding of these components anymore.

As such, I propose to become a write-after-approval maintainer
and relinquish all the other maintainer roles I had.

I'll be committing this to trunk.


Thanks. Diego.

diff --git a/MAINTAINERS b/MAINTAINERS
index 22a21ee..2cf1cc4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -31,7 +31,6 @@ Michael Meissner

 Jason Merrill  
 David S. Miller
 Joseph Myers   
-Diego Novillo  
 Bernd Schmidt  
 Ian Lance Taylor   
 Jim Wilson 
@@ -226,7 +225,6 @@ build machinery (*.in)  Alexandre Oliva
 
 build machinery (*.in) Ralf Wildenhues 
 docs co-maintainer Gerald Pfeifer  
 docs co-maintainer Joseph Myers
-docstring relicensing  Diego Novillo   
 docstring relicensing  Gerald Pfeifer  
 docstring relicensing  Joseph Myers
 predict.defJan Hubicka 
@@ -238,9 +236,7 @@ option handling Joseph Myers
 
 middle-end Jeff Law
 middle-end Roger Sayle 
 middle-end Ian Lance Taylor
-middle-end Diego Novillo   
 middle-end Richard Biener  
-tree-ssa   Diego Novillo   
 tree-ssa   Andrew MacLeod  
 PREDaniel Berlin   
 code sinking   Daniel Berlin   
@@ -299,10 +295,8 @@ libsanitizer, asan.c   Kostya Serebryany
 
 libsanitizer, asan.c   Dmitry Vyukov   
 loop optimizer Zdenek Dvorak   
 loop optimizer Daniel Berlin   
-LTODiego Novillo   
 LTORichard Biener  
 LTO plugin Cary Coutant
-Plugin Diego Novillo   
 Plugin Le-Chun Wu  
 register allocationPeter Bergner   
 register allocationKenneth Zadeck  
@@ -503,6 +497,7 @@ Adam Nemet

 Thomas Neumann 
 Dan Nicolaescu 
 James Norris   
+Diego Novillo  
 Dorit Nuzman   
 David O'Brien  
 Braden Obrzut  

Re: [patch] Fix invalid attributes in libstdc++

[Jonathan Wakely]

On 3 February 2015 at 13:49, Renlin Li  wrote:
> On 01/02/15 15:08, Jonathan Wakely wrote:
>>
>> I failed to CC gcc-patches on this patch ...
>>
>> On 29/01/15 13:02 +, Jonathan Wakely wrote:
>>
>> diff --git
>> a/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_attributes.cc
>> b/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_attributes.cc
>> new file mode 100644
>> index 000..c7ec27a
>> --- /dev/null
>> +++ b/libstdc++-v3/testsuite/17_intro/headers/c++200x/all_attributes.cc
>> @@ -0,0 +1,38 @@
>> +// Copyright (C) 2015 Free Software Foundation, Inc.
>> +//
>> +// This file is part of the GNU ISO C++ Library.  This library is free
>> +// software; you can redistribute it and/or modify it under the
>> +// terms of the GNU General Public License as published by the
>> +// Free Software Foundation; either version 3, or (at your option)
>> +// any later version.
>> +
>> +// This library is distributed in the hope that it will be useful,
>> +// but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +// GNU General Public License for more details.
>> +
>> +// You should have received a copy of the GNU General Public License
>> along
>> +// with this library; see the file COPYING3.  If not see
>> +// .
>> +
>> +// { dg-options "-std=gnu++11" }
>> +// { dg-do compile }
>> +
>> +// Ensure the library only uses the __name__ form for attributes.
>> +// Don't test 'const' and 'noreturn' because they are reserved anyway.
>> +#define abi_tag 1
>> +#define always_inline 1
>> +#define deprecated 1
>> +#define packed 1
>> +#define pure 1
>> +#define unused 1
>> +#define visibility 1
>> +
>> +#include  // TODO: this is missing from 
>> +#include// TODO: this is missing from 
>> +#include 
>> +
>> +
>>
> the test case fails to build on all arm target, giving the following
> message:
>
>
> src/gcc/libstdc++-v3/testsuite/17_intro/headers/c++2014/all_attributes.cc:28:16:
> error: expected ')' before numeric constant
>
> #define unused 1
>   ^
>
> Gcc has code using unused attribute without __name__ form. For example, we
> have the following code in gthr-default.h:
> #define GLIBCXX_UNUSED __attribute_((unused))

Yes, this is PR 64885. I'm on vacation but will fix the Gthreads
headers next week.

Re: [PATCH][libstdc++][Testsuite] isctype test fails for newlib.

[Jonathan Wakely]

Any idea why HP still sees the tests fail? See comment 8 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467#c8

[PATCH, committed] PR jit/64752 - Rewrite jit testsuite to eliminate use of "file"

[David Malcolm]

The jit testsuite attempted to test the gcc_jit_context_compile_to_file
API entrypoint by running "file" on the generated file, and comparing
the result against a regexp.

This approach is unfixable: some hosts won't have "file" installed, and
the output of "file" seems to vary enough from host to host that this
test can never be made sane.

For example, on i686 Fedora I get:
 FAIL: 'file' output on output-of-test-compile-to-assembler.c.s did not match: 
assembler source text
since the output was:
  output-of-test-compile-to-assembler.c.s: assembler source, ASCII text
and I've seen output (on ppc iirc) that read just "ASCII text"

The tests also weren't performing a functional verification.

The attached patch eliminates this use of "file", in favor of
sanity-checking the output more directly, introducing functions to
jit.exp:
 jit-verify-assembler
 jit-verify-object
 jit-verify-dynamic-library
alongside the existing jit-verify-executable, to verify that the .s, .o
or .so file generated by the test executable (via libgccjit)
can be used as expected.  For .s and .o it attempts to run the driver
again to build an executable, and then run it.  For .so it attempts to
build a simple executable that dlopens the .so file.

This presumably adds further host==target assumptions into the jit
testsuite, but that's already assumed, and I don't plan to tackle that
until GCC 6.

The patch also some extra checking to ensure that no errors occur
when calling gcc_jit_context_compile_to_file.

Tested via "make check-jit" on 3 architectures:

x86_64-unknown-linux-gnu:
  Before: 7571 passes, no failures
  After:  7602 passes, no failures

powerpc64-unknown-linux-gnu:
  Before: 7570 passes and 1 failure (PR jit/64752)
  After:  7602 passes, no failures.

s390x-ibm-linux-gnu:
  Before: 7570 passes and 1 failure (PR jit/64752)
  After:  7602 passes, no failures

Committed to trunk as r220494.

gcc/testsuite/ChangeLog:
PR jit/64752
* jit.dg/create-code-for-hello-world-executable.h: New file, taken
from jit.dg/test-compile-to-executable.c's create_code, with a
clarification of the output message.
* jit.dg/harness.h (CHECK_NO_ERRORS): Add test and __func__ to the
pass/fail message.
(test_jit): Use CHECK_NO_ERRORS when calling
gcc_jit_context_compile_to_file.
* jit.dg/jit.exp (jit-dg-test): Update grep for rename of
jit-verify-compile-to-file to jit-verify-output-file-was-created.
(jit-setup-compile-to-file): Likewise.  Add a verbose comment
about deletions that are attempted.
(jit-verify-compile-to-file): Rename to...
(jit-verify-output-file-was-created): ...this, and drop the
attempt to run "file" and verify the output.
(jit-verify-assembler): New function.
(jit-verify-object): New function.
(jit-verify-dynamic-library): New function.
* jit.dg/test-compile-to-assembler.c (create_code): Eliminate in
favor of an implementation from new file
create-code-for-hello-world-executable.h, which also adds a
"main".
(dg-final): Replace jit-verify-compile-to-file with
jit-verify-output-file-was-created, and invoke new function
jit-verify-assembler.
* jit.dg/test-compile-to-dynamic-library.c (create_code): Clarify
the output message.
(dg-final): Replace jit-verify-compile-to-file with
jit-verify-output-file-was-created, and invoke new function
jit-verify-dynamic-library.
* jit.dg/test-compile-to-executable.c (create_code): Eliminate in
favor of an implementation from new file
create-code-for-hello-world-executable.h, which also adds a
"main".
(dg-final): Replace jit-verify-compile-to-file with
jit-verify-output-file-was-created.  Strengthen the expected stdout
from the built executable.
* jit.dg/test-compile-to-object.c (create_code): Eliminate in
favor of an implementation from new file
create-code-for-hello-world-executable.h, which also adds a
"main".
(dg-final): Replace jit-verify-compile-to-file with
jit-verify-output-file-was-created, and invoke new function
jit-verify-object.
* jit.dg/verify-dynamic-library.c: New source file.
---
 .../create-code-for-hello-world-executable.h   | 101 +++
 gcc/testsuite/jit.dg/harness.h |   5 +-
 gcc/testsuite/jit.dg/jit.exp   | 187 +
 gcc/testsuite/jit.dg/test-compile-to-assembler.c   |  58 +--
 .../jit.dg/test-compile-to-dynamic-library.c   |   7 +-
 gcc/testsuite/jit.dg/test-compile-to-executable.c  | 103 +---
 gcc/testsuite/jit.dg/test-compile-to-object.c  |  58 +--
 gcc/testsuite/jit.dg/verify-dynamic-library.c  |  41 +
 8 files changed, 312 insertions(+), 248 deletions(-)
 create mode 100644 
gcc/testsuite/jit.dg/create-code-for-hello-world-ex

Re: [gofrontend-dev] [PATCH 1/2, libgo] Add support for missing reflection functions to gccgo for ppc64, ppc64le in gcc 4.9

[Ian Lance Taylor]

On Fri, Feb 6, 2015 at 12:36 PM, Lynn A. Boger
 wrote:
>
> I was told by the testers that this patch did not work.  The error message
> was:
>
>> panic: interface conversion: interface is nil, not error
>>
>> goroutine 1 [running]:
>> client.$nested1
>> /home/ubuntu/docker.mainline/src/github.com/docker/docker/api/
>> client/cli.go:66
>>
>> github_com_docker_docker_api_client.Cmd.pN45_github_com_docker_docker_api_client.DockerCli
>> /home/ubuntu/docker.mainline/src/github.com/docker/docker/api/
>> client/cli.go:84
>> main.main
>> /home/ubuntu/docker/docker/docker.go:126


That's easy to fix

Ian

Re: emit-rtl tidy

[David Edelsohn]

* config/rs6000/rs6000.c (rs6000_call_aix): Use get_current_sequence.

The rs6000 change is okay.

Thanks, David

[wwwdocs, committed] Add link to jit docs to onlinedocs/index.html

[David Malcolm]

The attached patch adds a link to the built HTML docs for libgccjit to
htdocs/onlinedocs/index.html.

Committed to CVS as obvious.
Index: htdocs/onlinedocs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/onlinedocs/index.html,v
retrieving revision 1.146
diff -u -p -r1.146 index.html
--- htdocs/onlinedocs/index.html	29 Jan 2015 08:26:06 -	1.146
+++ htdocs/onlinedocs/index.html	6 Feb 2015 22:26:51 -
@@ -972,6 +972,7 @@ existing release.
href="https://gcc.gnu.org/onlinedocs/libquadmath.ps.gz";>PostScript or https://gcc.gnu.org/onlinedocs/libquadmath-html.tar.gz";>an
HTML tarball)
+https://gcc.gnu.org/onlinedocs/jit/";>libgccjit documentation
 https://gcc.gnu.org/onlinedocs/docs-sources.tar.gz";>Texinfo
sources of all the manuals
   

[PATCH][PR rtl-optimization/42522] Incorrect simplification of ZERO_EXTRACT and SIGN_EXTRACT by cse

[Jeff Law]

This bug has gone latent on the trunk; however, the problem still
remains that cse will incorrectly simplify a ZERO/SIGN_EXTRACT in some
cases.

ZERO/SIGN_EXTRACT are somewhat special in that if they are extracting
from a memory operand, that memory operand will always have QImode
regardless of the size of the extracted field.

ie, the mode of the MEM in a ZERO/SIGN_EXTRACT does not really mean
anything and the ZERO/SIGN_EXTRACT can read bits beyond QImode.

So given a (mem:QI x) with an equivalence to (const_int 0) in the hash
tables.  If we have an extraction like

(zero_extract:SI (mem:QI x) (const_int 0) (const_int 24))

CSE will substitute (const_int 0) for the MEM in the extraction resulting in

(zero_extract:SI (const_int 0) (const_int 0) (const_int 24))

Which simplifies to (const_int 0)

For REGs, the mode is the same as the operand of the insv/extv pattern,
and may (or may not) more closely resemble reality depending on the target.

The safe thing to do in CSE is to lookup the ZERO/SIGN_EXTRACT as a whole.

Given the bug is latent and not currently a regression this will need to
wait for the next stage1 development cycle.
diff --git a/gcc/cse.c b/gcc/cse.c
index f7b477c..8ab48c4 100644
--- a/gcc/cse.c
+++ b/gcc/cse.c
@@ -3178,6 +3178,15 @@ fold_rtx (rtx x, rtx insn)
 {
 case MEM:
 case SUBREG:
+/* The first operand of a SIGN/ZERO_EXTRACT has a different meaning
+   than it would in other contexts.  Basically its mode does not
+   signify the size of the object read.  That information is carried
+   by size operand.If we happen to have a MEM of the appropriate
+   mode in our tables with a constant value we could simplify the
+   extraction incorrectly if we allowed substitution of that value
+   for the MEM.   */
+case ZERO_EXTRACT:
+case SIGN_EXTRACT:
   if ((new_rtx = equiv_constant (x)) != NULL_RTX)
 return new_rtx;
   return x;

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

H.J.,
 The clang compilers exhibit the same behavior on these test cases.

Undefined symbols for architecture x86_64:
  "_foo", referenced from:
  _main in visibility-23-e1e564.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

however if I also pass "-Wl,-undefined -Wl,dynamic_lookup" to the
linker, both test
compile and run.
 FYI, the assembly from...

/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -S -m32 -o
visibility-23.s

contains...

.text
.globl _main
_main:
LFB0:
pushl   %ebp
LCFI0:
movl%esp, %ebp
LCFI1:
subl$8, %esp
call___x86.get_pc_thunk.ax
L1$pb:
lealL_foo$non_lazy_ptr-L1$pb(%eax), %eax
movl(%eax), %eax
testl   %eax, %eax
je  L2
call_foo
L2:
movl$0, %eax
leave
LCFI2:
ret
LFE0:
.weak_reference _foo
.section __TEXT,__textcoal_nt,coalesced,pure_instructions
.weak_definition___x86.get_pc_thunk.ax
.private_extern ___x86.get_pc_thunk.ax
___x86.get_pc_thunk.ax:
LFB1:
movl(%esp), %eax
ret
LFE1:
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0
LSCIE1:
.long   0
.byte   0x1
.ascii "zR\0"
.byte   0x1
.byte   0x7c
.byte   0x8
.byte   0x1
.byte   0x10
.byte   0xc
.byte   0x5
.byte   0x4
.byte   0x88
.byte   0x1
.align 2
LECIE1:
LSFDE1:
.set L$set$1,LEFDE1-LASFDE1
.long L$set$1
LASFDE1:
.long   LASFDE1-EH_frame1
.long   LFB0-.
.set L$set$2,LFE0-LFB0
.long L$set$2
.byte   0
.byte   0x4
.set L$set$3,LCFI0-LFB0
.long L$set$3
.byte   0xe
.byte   0x8
.byte   0x84
.byte   0x2
.byte   0x4
.set L$set$4,LCFI1-LCFI0
.long L$set$4
.byte   0xd
.byte   0x4
.byte   0x4
.set L$set$5,LCFI2-LCFI1
.long L$set$5
.byte   0xc4
.byte   0xc
.byte   0x5
.byte   0x4
.align 2
LEFDE1:
LSFDE3:
.set L$set$6,LEFDE3-LASFDE3
.long L$set$6
LASFDE3:
.long   LASFDE3-EH_frame1
.long   LFB1-.
.set L$set$7,LFE1-LFB1
.long L$set$7
.byte   0
.align 2
LEFDE3:
.section __IMPORT,__pointers,non_lazy_symbol_pointers
.weak_reference _foo
L_foo$non_lazy_ptr:
.indirect_symbol _foo
.long   0
.subsections_via_symbols


On Fri, Feb 6, 2015 at 4:41 PM, H.J. Lu  wrote:
> On Fri, Feb 6, 2015 at 1:31 PM, Jack Howarth  wrote:
>> H.J.,
>> On x86_64-apple-darwin14, your patch applied to r220481 results in...
>>
>> FAIL: gcc.dg/visibility-22.c (test for excess errors)
>> FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo
>>
>> with...
>>
>> Executing on host:
>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
>>  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC  -lm
>> -m32  -o ./visibility-22.exe(timeout = 300)
>> spawn -ignore SIGHUP
>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
>> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
>> -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -lm -m32
>> -o ./visibility-22.exe^M
>> Undefined symbols for architecture i386:^M
>>   "_foo", referenced from:^M
>>   _main in ccMD1qjz.o^M
>>   _main in ccMD1qjz.o^M
>> ld: symbol(s) not found for architecture i386^M
>> collect2: error: ld returned 1 exit status^M
>> compiler exited with status 1
>> output is:
>> Undefined symbols for architecture i386:^M
>>   "_foo", referenced from:^M
>>   _main in ccMD1qjz.o^M
>>   _main in ccMD1qjz.o^M
>> ld: symbol(s) not found for architecture i386^M
>> collect2: error: ld returned 1 exit status^M
>>
>> FAIL: gcc.dg/visibility-22.c (test for excess errors)
>>
>> Executing on host:
>> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
>> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_ob

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[H.J. Lu]

On Fri, Feb 6, 2015 at 1:31 PM, Jack Howarth  wrote:
> H.J.,
> On x86_64-apple-darwin14, your patch applied to r220481 results in...
>
> FAIL: gcc.dg/visibility-22.c (test for excess errors)
> FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo
>
> with...
>
> Executing on host:
> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
>  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC  -lm
> -m32  -o ./visibility-22.exe(timeout = 300)
> spawn -ignore SIGHUP
> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
> -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -lm -m32
> -o ./visibility-22.exe^M
> Undefined symbols for architecture i386:^M
>   "_foo", referenced from:^M
>   _main in ccMD1qjz.o^M
>   _main in ccMD1qjz.o^M
> ld: symbol(s) not found for architecture i386^M
> collect2: error: ld returned 1 exit status^M
> compiler exited with status 1
> output is:
> Undefined symbols for architecture i386:^M
>   "_foo", referenced from:^M
>   _main in ccMD1qjz.o^M
>   _main in ccMD1qjz.o^M
> ld: symbol(s) not found for architecture i386^M
> collect2: error: ld returned 1 exit status^M
>
> FAIL: gcc.dg/visibility-22.c (test for excess errors)
>
> Executing on host:
> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
>  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC -S
> -m32  -o visibility-23.s(timeout = 300)
> spawn -ignore SIGHUP
> /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
> -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
> /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
> -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -S -m32 -o
> visibility-23.s^M
> PASS: gcc.dg/visibility-23.c (test for excess errors)
> FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo
>

Does Darwin support undefined hidden weak symbol?
Can you compile and gcc/testsuite/gcc.dg/visibility-22.c
with clang on Darwin?

-- 
H.J.

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

H.J.,
On x86_64-apple-darwin14, your patch applied to r220481 results in...

FAIL: gcc.dg/visibility-22.c (test for excess errors)
FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo

with...

Executing on host:
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC  -lm
-m32  -o ./visibility-22.exe(timeout = 300)
spawn -ignore SIGHUP
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -lm -m32
-o ./visibility-22.exe^M
Undefined symbols for architecture i386:^M
  "_foo", referenced from:^M
  _main in ccMD1qjz.o^M
  _main in ccMD1qjz.o^M
ld: symbol(s) not found for architecture i386^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
output is:
Undefined symbols for architecture i386:^M
  "_foo", referenced from:^M
  _main in ccMD1qjz.o^M
  _main in ccMD1qjz.o^M
ld: symbol(s) not found for architecture i386^M
collect2: error: ld returned 1 exit status^M

FAIL: gcc.dg/visibility-22.c (test for excess errors)

Executing on host:
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC -S
-m32  -o visibility-23.s(timeout = 300)
spawn -ignore SIGHUP
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -S -m32 -o
visibility-23.s^M
PASS: gcc.dg/visibility-23.c (test for excess errors)
FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo

Jack

On Fri, Feb 6, 2015 at 11:23 AM, H.J. Lu  wrote:
> If a hidden weak symbol isn't defined in the TU, we can't assume it will
> be defined in another TU at link time.  It makes a difference in code
> generation when compiling for PIC. If we assume that a hidden weak
> undefined symbol is local, the address checking may be optimized out and
> leads to the wrong code.  This means that a symbol with user specified
> visibility is local only if it is locally resolved or defined, not weak
> or not compiling for PIC.  When symbol visibility is specified in the
> source, we should always output symbol visibility even if symbol isn't
> local to the TU.
>
> If a global data symbol is defined in the TU, it is always local to the
> executable, regardless if it is a common symbol or not.  If we aren't
> compiling for shared library, locally defined global data symbol binds
> locally.
>
> Tested on Linux/x86-64.  OK for trunk?
>
> Thanks.
>
>
> H.J.
> ---
> gcc/
>
> PR rtl-optimization/32219
> * cgraphunit.c (varpool_node::finalize_decl): Set definition
> first before calling notice_global_symbol so that it is
> available to notice_global_symbol.
> * varasm.c (default_binds_local_p_1): Resolve defined data
> symbol locally if not building shared library.  Resolve symbol
> with user specified visibility locally only if it is locally
> resolved or defined, not weak or not compiling for PIC.
> (default_elf_asm_output_external): Always output visibility
> specified in the source.
>
> gcc/testsuite/
>
> PR rtl-optimization/32219
> * gcc.dg/visibility-22.c: New test.
> * gcc.dg/visibility-23.c: Likewise.
> * gcc.target/i386/pr32219-1.c: Likewise.
> * gcc.target/i386/pr32219-2.c: Likewise.
> * gcc.target/i386/pr32219-3.c: Likewise.
> * gcc.target/i386/pr32219-4.c: Likewise.
> * gcc.target/i386/pr32219-5.c: Likewise.
> * gcc.target/i386/pr32219-6.c: Likewise.
> * gcc.target/i386/pr32219-7.c: Likewise.
> * gcc.target/i386/pr32219-8.c: Likewise.
> * gcc.target/i386/pr64317.c: Expect GOTOFF relocation instead
> of GOT relocation.
> ---
>  gcc/cgraphunit.c  |  4 +++-
>  gcc/testsuite/gcc.dg/visibility-22.c  | 14 +
>  gcc/testsuite/gcc.dg/visibility-23.c  | 15 +
>  gcc/testsuite/gcc.target/i386/pr32219-1.c | 16 ++
>  gcc/testsuite/gcc.target/i386/pr32219-2.c | 16 ++
>  gcc/testsuite/gcc.target/i386/pr

Re: [PATCH] Fix another case of modified global_options after creation of optimization_default_node

[Jeff Law]

On 02/06/15 13:28, Jakub Jelinek wrote:

Hi!

As discussed in PR64340, the clearing of flag_ipa_ra is misplaced too,
because it isn't reflected in optimization_default_node.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2015-02-06  Jakub Jelinek  

* toplev.c (process_options): Change flag_ipa_ra before creating
optimization_{default,current}_node.

--- gcc/toplev.c.jj 2015-01-31 10:07:40.0 +0100
+++ gcc/toplev.c2015-02-06 17:20:11.778126431 +0100
@@ -1662,6 +1662,11 @@ process_options (void)
flag_sanitize &= ~SANITIZE_ADDRESS;
  }

+ /* Disable use caller save optimization if profiler is active or port
+does not emit prologue and epilogue as RTL.  */
+  if (profile_flag || !HAVE_prologue || !HAVE_epilogue)
+flag_ipa_ra = 0;
OK if you could update that comment -- in particular "caller save" 
should be replaced with something more meaningful.


Disable use of IPA information for register allocation if profiler ... 
seems good to me.


jeff

Re: [PATCH] Fix thunk expansion (PR ipa/64896)

[Jan Hubicka]

> Hi!
> 
> As discussed in the PR, for functions that return an aggregate that is not
> aggregate_value_p (i.e. returned in registers), using RESULT_DECL is
> undesirable, that's not what we normally emit for user code.
> 
> So, this patch instead uses a temporary, which is optimized right now as
> much as similar user written code.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK,
thanks!
Honza
> 
> 2015-02-06  Jakub Jelinek  
> 
>   PR ipa/64896
>   * cgraphunit.c (cgraph_node::expand_thunk): If
>   restype is not is_gimple_reg_type nor the thunk_fndecl
>   returns aggregate_value_p, set restmp to a temporary variable
>   instead of resdecl.
> 
>   * g++.dg/ipa/pr64896.C: New test.
> 
> --- gcc/cgraphunit.c.jj   2015-01-29 21:38:21.0 +0100
> +++ gcc/cgraphunit.c  2015-02-06 13:18:44.870527405 +0100
> @@ -1609,11 +1609,16 @@ cgraph_node::expand_thunk (bool output_a
>   }
> else if (!is_gimple_reg_type (restype))
>   {
> -   restmp = resdecl;
> +   if (aggregate_value_p (resdecl, TREE_TYPE (thunk_fndecl)))
> + {
> +   restmp = resdecl;
>  
> -   if (TREE_CODE (restmp) == VAR_DECL)
> - add_local_decl (cfun, restmp);
> -   BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
> +   if (TREE_CODE (restmp) == VAR_DECL)
> + add_local_decl (cfun, restmp);
> +   BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
> + }
> +   else
> + restmp = create_tmp_var (restype, "retval");
>   }
> else
>   restmp = create_tmp_reg (restype, "retval");
> --- gcc/testsuite/g++.dg/ipa/pr64896.C.jj 2015-02-06 13:36:30.076680258 
> +0100
> +++ gcc/testsuite/g++.dg/ipa/pr64896.C2015-02-06 13:36:13.0 
> +0100
> @@ -0,0 +1,29 @@
> +// PR ipa/64896
> +// { dg-do compile }
> +// { dg-options "-O2" }
> +
> +struct A { int a, b; };
> +struct B { A c; int d; };
> +struct C { virtual B fn1 () const; };
> +struct D { B fn2 () const; int fn3 () const; C *fn4 () const; };
> +
> +int
> +D::fn3 () const
> +{
> +  fn4 ()->fn1 ();
> +}
> +
> +B
> +D::fn2 () const
> +{
> +  return B ();
> +}
> +
> +class F : C
> +{
> +  B
> +  fn1 () const
> +  {
> +return B ();
> +  }
> +};
> 
>   Jakub

[Patch, fortran] PR63744 accept duplicate use-rename

[Mikael Morin]

Hello,

we currently reject programs of the form
> 
> module m
> integer :: s
> end module m
> subroutine s
> use m, only: x => s, x => s
> end subroutine s

with an error stating that S is the name of the current program unit.
Interestingly, the duplicate rename is necessary to trigger it.

There doesn't seem to be a consensus as to whether it should be
accepted, but I think it should be.
Quoting Dominique's comment in the PR:
>  if
> 
>   use m, only: A => X
>   use m, only: B => X
> 
> is valid, I don't see why
> 
>   use m, only: A => X
>   use m, only: A => X
> 
> should not.
The problem is we check the original (symbol) name instead of the local
(symtree) name.
The fix is close to obvious, and should be safe for the branches (this
is a regression)
Regression tested on x86_64-linux. OK for trunk/4.9/4.8 ?

Mikael



2015-02-06  Mikael Morin  

PR fortran/63744
* module.c (check_for_ambiguous): Change argument type
from gfc_symbol to gfc_symtree.  Check local (symtree) name
instead of original (symbol) name.
(read_module): Update caller.

2015-02-06  Mikael Morin  

PR fortran/63744
gfortran.dg/use_rename_8.f90: New.

Index: module.c
===
--- module.c	(révision 220107)
+++ module.c	(copie de travail)
@@ -4795,19 +4795,21 @@ read_cleanup (pointer_info *p)
 /* It is not quite enough to check for ambiguity in the symbols by
the loaded symbol and the new symbol not being identical.  */
 static bool
-check_for_ambiguous (gfc_symbol *st_sym, pointer_info *info)
+check_for_ambiguous (gfc_symtree *st, pointer_info *info)
 {
   gfc_symbol *rsym;
   module_locus locus;
   symbol_attribute attr;
+  gfc_symbol *st_sym;
 
-  if (gfc_current_ns->proc_name && st_sym->name == gfc_current_ns->proc_name->name)
+  if (gfc_current_ns->proc_name && st->name == gfc_current_ns->proc_name->name)
 {
   gfc_error ("%qs of module %qs, imported at %C, is also the name of the "
-		 "current program unit", st_sym->name, module_name);
+		 "current program unit", st->name, module_name);
   return true;
 }
 
+  st_sym = st->n.sym;
   rsym = info->u.rsym.sym;
   if (st_sym == rsym)
 return false;
@@ -5037,7 +5039,7 @@ read_module (void)
 	  if (st != NULL)
 	{
 	  /* Check for ambiguous symbols.  */
-	  if (check_for_ambiguous (st->n.sym, info))
+	  if (check_for_ambiguous (st, info))
 		st->ambiguous = 1;
 	  else
 		info->u.rsym.symtree = st;



! { dg-do compile }
!
! PR fortran/63744
! duplicate use rename used to be rejected when the target name
! was that of the current program unit 
!
! Original testcase from Roger Ferrer Ibanez 

MODULE MOO
INTEGER :: A, B, C, D, E, F, G, H, I
END MODULE MOO

SUBROUTINE S
USE MOO, ONLY: X => A, X => A
END SUBROUTINE S

SUBROUTINE T
USE MOO, ONLY: X => B
USE MOO, ONLY: X => B
END SUBROUTINE T

SUBROUTINE C
USE MOO, ONLY: C  ! { dg-error "is also the name of the current program unit" }
END SUBROUTINE C

SUBROUTINE D
USE MOO, ONLY: X => D
END SUBROUTINE D

SUBROUTINE E
USE MOO, ONLY: X => E, X => E
END SUBROUTINE E

SUBROUTINE F
USE MOO, ONLY: X => F
USE MOO, ONLY: X => F
END SUBROUTINE F

SUBROUTINE X
USE MOO, ONLY: X => G ! { dg-error "is also the name of the current program unit" }
END SUBROUTINE X

SUBROUTINE Y
USE MOO, ONLY: Y => H ! { dg-error "is also the name of the current program unit" }
END SUBROUTINE Y

SUBROUTINE Z
USE MOO, ONLY: Z => I, Z => I ! { dg-error "is also the name of the current program unit" }
END SUBROUTINE Z

[PATCH] Fix another case of modified global_options after creation of optimization_default_node

[Jakub Jelinek]

Hi!

As discussed in PR64340, the clearing of flag_ipa_ra is misplaced too,
because it isn't reflected in optimization_default_node.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2015-02-06  Jakub Jelinek  

* toplev.c (process_options): Change flag_ipa_ra before creating
optimization_{default,current}_node.

--- gcc/toplev.c.jj 2015-01-31 10:07:40.0 +0100
+++ gcc/toplev.c2015-02-06 17:20:11.778126431 +0100
@@ -1662,6 +1662,11 @@ process_options (void)
   flag_sanitize &= ~SANITIZE_ADDRESS;
 }
 
+ /* Disable use caller save optimization if profiler is active or port
+does not emit prologue and epilogue as RTL.  */
+  if (profile_flag || !HAVE_prologue || !HAVE_epilogue)
+flag_ipa_ra = 0;
+
   /* Enable -Werror=coverage-mismatch when -Werror and -Wno-error
  have not been set.  */
   if (!global_options_set.x_warnings_are_errors
@@ -1675,10 +1680,8 @@ process_options (void)
   optimization_default_node = build_optimization_node (&global_options);
   optimization_current_node = optimization_default_node;
 
- /* Disable use caller save optimization if profiler is active or port
-does not emit prologue and epilogue as RTL.  */
-  if (profile_flag || !HAVE_prologue || !HAVE_epilogue)
-flag_ipa_ra = 0;
+  /* Please don't change global_options after this point, those changes won't
+ be reflected in optimization_{default,current}_node.  */
 }
 
 /* This function can be called multiple times to reinitialize the compiler

Jakub

[PATCH] Update optimization_default_node in ada (PR middle-end/64340)

[Jakub Jelinek]

Hi!

As mentioned in the PR, the problem here is that the Ada FE needs to modify
global_options after toplevel.c (process_options), but as for LTO we now use
optimization_{default,current}_node for options of functions without
specifial optimization node, it means the changed options aren't reflected
in there.

Fixed thusly, bootstrapped/regtested on x86_64-linux, ok for trunk?

2015-02-06  Jakub Jelinek  

PR middle-end/64340
* gcc-interface/trans.c (gigi): Recreate optimization_default_node
and optimization_current_node after tweaking global_options.

--- gcc/ada/gcc-interface/trans.c.jj2015-01-12 18:56:10.0 +0100
+++ gcc/ada/gcc-interface/trans.c   2015-02-06 16:39:04.353363393 +0100
@@ -678,6 +678,11 @@ gigi (Node_Id gnat_root,
   if (No_Strict_Aliasing_CP)
 flag_strict_aliasing = 0;
 
+  /* Save the current optimization options again after the above possible
+ global_options changes.  */
+  optimization_default_node = build_optimization_node (&global_options);
+  optimization_current_node = optimization_default_node;
+
   /* Now translate the compilation unit proper.  */
   Compilation_Unit_to_gnu (gnat_root);
 

Jakub

[PATCH] Fix thunk expansion (PR ipa/64896)

[Jakub Jelinek]

Hi!

As discussed in the PR, for functions that return an aggregate that is not
aggregate_value_p (i.e. returned in registers), using RESULT_DECL is
undesirable, that's not what we normally emit for user code.

So, this patch instead uses a temporary, which is optimized right now as
much as similar user written code.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2015-02-06  Jakub Jelinek  

PR ipa/64896
* cgraphunit.c (cgraph_node::expand_thunk): If
restype is not is_gimple_reg_type nor the thunk_fndecl
returns aggregate_value_p, set restmp to a temporary variable
instead of resdecl.

* g++.dg/ipa/pr64896.C: New test.

--- gcc/cgraphunit.c.jj 2015-01-29 21:38:21.0 +0100
+++ gcc/cgraphunit.c2015-02-06 13:18:44.870527405 +0100
@@ -1609,11 +1609,16 @@ cgraph_node::expand_thunk (bool output_a
}
  else if (!is_gimple_reg_type (restype))
{
- restmp = resdecl;
+ if (aggregate_value_p (resdecl, TREE_TYPE (thunk_fndecl)))
+   {
+ restmp = resdecl;
 
- if (TREE_CODE (restmp) == VAR_DECL)
-   add_local_decl (cfun, restmp);
- BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
+ if (TREE_CODE (restmp) == VAR_DECL)
+   add_local_decl (cfun, restmp);
+ BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
+   }
+ else
+   restmp = create_tmp_var (restype, "retval");
}
  else
restmp = create_tmp_reg (restype, "retval");
--- gcc/testsuite/g++.dg/ipa/pr64896.C.jj   2015-02-06 13:36:30.076680258 
+0100
+++ gcc/testsuite/g++.dg/ipa/pr64896.C  2015-02-06 13:36:13.0 +0100
@@ -0,0 +1,29 @@
+// PR ipa/64896
+// { dg-do compile }
+// { dg-options "-O2" }
+
+struct A { int a, b; };
+struct B { A c; int d; };
+struct C { virtual B fn1 () const; };
+struct D { B fn2 () const; int fn3 () const; C *fn4 () const; };
+
+int
+D::fn3 () const
+{
+  fn4 ()->fn1 ();
+}
+
+B
+D::fn2 () const
+{
+  return B ();
+}
+
+class F : C
+{
+  B
+  fn1 () const
+  {
+return B ();
+  }
+};

Jakub

patch fixing a typo in LRA

[Vladimir Makarov]

  The following patch fixes a typo discovered recently:

https://gcc.gnu.org/ml/gcc/2015-02/msg00040.html

  The patch was bootstrapped and tested on x86/x86-64.

   Committed as rev.220488.

2015-02-06  Vladimir Makarov  

* lra.c (lra_emit_add): Fix a typo in using disp instead of base.

Index: lra.c
===
--- lra.c   (revision 220482)
+++ lra.c   (working copy)
@@ -475,7 +475,7 @@ lra_emit_add (rtx x, rtx y, rtx z)
  rtx insn = emit_add2_insn (x, disp);
  if (insn != NULL_RTX)
{
- insn = emit_add2_insn (x, disp);
+ insn = emit_add2_insn (x, base);
  if (insn != NULL_RTX)
ok_p = true;
}

Re: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Maciej W. Rozycki]

On Fri, 6 Feb 2015, Mike Stump wrote:

> Personally, the call form of bal in my book should be called call, and 
> the non-call form of it should be called bal, but, I realize it is 
> likely to late to do much about now.  If one went down this path, then 
> even changing it away from bal is wrong.  That’s the basis of why I 
> fired up the first email.  Maybe more a lament at this point.

 I'm confused, these all are conditional short-distance calls.  And I 
suspect that they were included in the original MIPS architecture for the 
very purpose of letting relocatable code find its own position in memory 
at the run time -- and the rest was added to maximise the benefit of the 
opcode(s) that had to be there anyway.

 And it's just, owing to how the architecture has been structured, that 
there are exactly two cases (of the 64 encodings available) where the 
condition is fixed to either `true' or `false', respectively.  And if 
anyhow, I'd call any assembly-language idiom of `BLTZAL $0, foo' just 
`MOVE $31, $pc' or maybe to avoid confusion `[D]ADDIU $31, $pc, 8'.

 Note that `foo' is never used in that operation (and that the MIPS16 and 
microMIPS, and now also r6 instruction sets actually have such direct 
operations that have a wider range of immediates available; although care 
has to be taken about them as they may have unusual alignment or other 
restrictions).

  Maciej

[PATCH, i386 testsuite]: Fix gcc.target/i386/pr64317.c

[Uros Bizjak]

Hello!

2015-02-06  Uros Bizjak  

* gcc.target/i386/pr64317.c: Compile for 32bit *-*-linux* targets.
(dg-options): Use -fpie instead of -fPIE -pie.

Tested on x86_64-linux-gnu {,m32}, committed to mainline SVN.

Uros.
Index: gcc.target/i386/pr64317.c
===
--- gcc.target/i386/pr64317.c   (revision 220481)
+++ gcc.target/i386/pr64317.c   (working copy)
@@ -1,5 +1,5 @@
-/* { dg-do compile { target { ia32 } } } */
-/* { dg-options "-O2 -fPIE -pie" } */
+/* { dg-do compile { target { *-*-linux* && ia32 } } } */
+/* { dg-options "-O2 -fpie" } */
 /* { dg-final { scan-assembler "addl\[ \\t\]+\[$\]_GLOBAL_OFFSET_TABLE_, %ebx" 
} } */
 /* { dg-final { scan-assembler "movl\[ \\t\]+c@GOT\[(\]%ebx\[)\]" } } */
 /* { dg-final { scan-assembler-not "movl\[ \\t\]+\[0-9]+\[(\]%esp\[)\], %ebx" 
} } */

Re: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Mike Stump]

On Feb 6, 2015, at 9:41 AM, Matthew Fortune  wrote:
> Mike Stump  writes:
>> On Feb 6, 2015, at 4:23 AM, Maciej W. Rozycki 
>> wrote:
>>> This consideration made me realise I've had a patch outstanding for
>>> some
>>> 10 years to convert all the `BAL x' instructions there to `BLTZAL $0,
>> x'.
>>> This has always been a good idea in case implementations recognised
>>> the special case and avoided involving branch prediction, and I
>>> believe it has become even more apparent with r6 calling it NAL.
>> 
>> Ick, no.
> 
> What part of this are you referring to?

The first part.  Ah, yes, I had mentally flipped the two cases.  I mistakingly 
thought you wanted to change all the BALs to BLTZAL, which you don’t want to 
do.  You only want to flip the non-calls to that form, which is perfectly 
reasonable.

Personally, the call form of bal in my book should be called call, and the 
non-call form of it should be called bal, but, I realize it is likely to late 
to do much about now.  If one went down this path, then even changing it away 
from bal is wrong.  That’s the basis of why I fired up the first email.  Maybe 
more a lament at this point.

[PATCH][4.9]Backport "Fix register corruption bug in ree"

[Renlin Li]

Hi all,

This is a backport patch for branch 4.9. You can find the original patch 
here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00356.html

And it has been commit on the trunk as r215205.

This fixes a few libstdc++-v3 test suite failures.
x86_64 bootstraps Okay, aarch64_be-none-elf libstdc++-v3 tested Okay.

Okay to commit on branch 4.9?

Regards,
Renlin Li

2015-02-06  Renlin Li  

Backport from mainline
2014-09-12  Wilco Dijkstra  

* gcc/ree.c (combine_reaching_defs): Ensure inserted copy don't change
the number of hard registers.
diff --git a/gcc/ree.c b/gcc/ree.c
index 67fc9c3..e9ff904 100644
--- a/gcc/ree.c
+++ b/gcc/ree.c
@@ -793,6 +793,14 @@ combine_reaching_defs (ext_cand *cand, const_rtx set_pat, ext_state *state)
   if (state->modified[INSN_UID (cand->insn)].kind != EXT_MODIFIED_NONE)
 	return false;
 
+  enum machine_mode dst_mode = GET_MODE (SET_DEST (PATTERN (cand->insn)));
+  rtx src_reg = get_extended_src_reg (SET_SRC (PATTERN (cand->insn)));
+
+  /* Ensure the number of hard registers of the copy match.  */
+  if (HARD_REGNO_NREGS (REGNO (src_reg), dst_mode)
+	  != HARD_REGNO_NREGS (REGNO (src_reg), GET_MODE (src_reg)))
+	return false;
+
   /* There's only one reaching def.  */
   rtx def_insn = state->defs_list[0];
 
@@ -842,7 +850,7 @@ combine_reaching_defs (ext_cand *cand, const_rtx set_pat, ext_state *state)
   start_sequence ();
   rtx pat = PATTERN (cand->insn);
   rtx new_dst = gen_rtx_REG (GET_MODE (SET_DEST (pat)),
- REGNO (XEXP (SET_SRC (pat), 0)));
+ REGNO (get_extended_src_reg (SET_SRC (pat;
   rtx new_src = gen_rtx_REG (GET_MODE (SET_DEST (pat)),
  REGNO (SET_DEST (pat)));
   emit_move_insn (new_dst, new_src);

Re: [debug-early] C++ clones and limbo DIEs

[Aldy Hernandez]

OK with that change.


Sweet!  Thanks for everything.

Though he's been silent, I bet Richi is secretly dancing :-).

Re: emit-rtl tidy

[Richard Henderson]

On 02/05/2015 04:18 PM, Alan Modra wrote:
> OK when stage1 opens?
> 
>   * function.h (struct emit_status): Delete x_first_insn, x_last_insn
>   and sequence_stack.  Add seq.
>   (seq_stack): Delete.
>   * function.c (prepare_function_start): Don't access x_last_insn.
>   * emit-rtl.h (get_current_sequence, get_topmost_sequence): New.
>   (get_insns, set_first_insn, get_last_insn, set_last_insn): Use them.
>   * emit_rtl.c (start_sequence, push_topmost_sequence,
>   pop_topmost_sequence, end_sequence, in_sequence_p, init_emit): Use 
>   sequence accessors.
>   (get_last_insn_anywhere, add_insn_after_nobb, add_insn_before_nobb,
>   remove_insn): Likewise.  Simplify.
>   * config/m32c/m32c.c (m32c_leaf_function_p): Use push_topmost_sequence
>   and pop_topmost_sequence.
>   (m32c_function_needs_enter): Use get_topmost_sequence.  Ignore
>   debug insns.
>   * config/rs6000/rs6000.c (rs6000_call_aix): Use get_current_sequence.

Looks good.


r~

Re: [PATCH], PR target/64205, Fix -mcpu=G5 breakage on PowerPC

[David Edelsohn]

On Fri, Feb 6, 2015 at 9:41 AM, Michael Meissner
 wrote:
> This patch fixes PR target/64205, which was caused due to my previous patch to
> add the -mupper-regs support for scalar floating point to occupy the VSX
> floating point registers that are overlaid on top of the traditional Altivec
> registers, starting with ISA 2.06 (power7).
>
> The problem was, I added secondary reload handlers for SDmode unconditionally.
> On systems before ISA 2.06, there are no stores and loads for 32-bit SDmode in
> a floating point register, and so you can't do normal secondary reload
> operations on this (you have to do a 64-bit store and a 32-bit load on the
> bottom bits).
>
> I have tested this with a full bootstrap on PowerPC 64-bit systems with no
> regressions.  In addition, I built a bootstrap compiler using the 
> --with-cpu=G5
> option and it succeeded.  Is it ok to install the patches in trunk, and in any
> branches that the upper regs patches were applied to?
>
> [gcc]
> 2015-02-06  Michael Meissner  
>
> PR target/64205
> * config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Do not
> add a general secondary reload handler for SDmode, unless we have
> both read/write support for SDmode.
>
> [gcc/testsuite]
> 2015-02-06  Michael Meissner  
>
> PR target/64205
> * gcc.target/powerpc/pr64205.c: New file.

Please clarify the comments in rs6000.c.  Too many double negatives
and ambiguous terms.

For example, "Use SDmode reload patterns if float load/store integer
word instructions are available."

Okay with an improved comment.

Thanks, David

Re: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Maciej W. Rozycki]

On Fri, 6 Feb 2015, Mike Stump wrote:

> > This consideration made me realise I've had a patch outstanding for some 
> > 10 years to convert all the `BAL x' instructions there to `BLTZAL $0, x'.  
> > This has always been a good idea in case implementations recognised the 
> > special case and avoided involving branch prediction, and I believe it has 
> > become even more apparent with r6 calling it NAL.
> 
> Ick, no.

 Hmm, have you hit `send' too quickly by any chance?  There's surely a 
further part missing from your post where you'd explain what you mean.

  Maciej

RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Matthew Fortune]

Mike Stump  writes:
> On Feb 6, 2015, at 4:23 AM, Maciej W. Rozycki 
> wrote:
> > This consideration made me realise I've had a patch outstanding for
> > some
> > 10 years to convert all the `BAL x' instructions there to `BLTZAL $0,
> x'.
> > This has always been a good idea in case implementations recognised
> > the special case and avoided involving branch prediction, and I
> > believe it has become even more apparent with r6 calling it NAL.
> 
> Ick, no.

What part of this are you referring to?

NAL (bizarre name or not) is the least intrusive way to obtain the PC on
MIPS <= R5. The use of BAL for this, albeit common, has a high risk of
affecting hardware optimisations like return predictors by introducing
a call that will never return.

This is a change that I am also planning to propagate to as many projects
as possible. If you can see a problem with using BLTZAL for this purpose
please could you explain as it may have been overlooked?

Thanks,
Matthew

Re: [debug-early] C++ clones and limbo DIEs

[Jason Merrill]

On 02/06/2015 11:42 AM, Aldy Hernandez wrote:

I was actually thinking of using dwarf2out_early_finish() to mop things up as 
we generate early (or stream out) other auxiliary tables (pubname_table, 
pubtype_table, file_table, etc).  More details on that later.  If so, can I 
leave it as is?


OK.


+  /* No one should depend on this, as it is a temporary debugging aid
+ to indicate the DECL for which this DIE was created for.  */
+  tree tmp_created_for;


Maybe add a FIXME comment to remove/#if this out at merge time?  I don't 
want to add an unnecessary pointer to every DIE in the released compiler.


OK with that change.

Jason

Re: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Mike Stump]

On Feb 6, 2015, at 4:23 AM, Maciej W. Rozycki  wrote:
> This consideration made me realise I've had a patch outstanding for some 
> 10 years to convert all the `BAL x' instructions there to `BLTZAL $0, x'.  
> This has always been a good idea in case implementations recognised the 
> special case and avoided involving branch prediction, and I believe it has 
> become even more apparent with r6 calling it NAL.

Ick, no.

Re: [PATCH] Fix DECL_ABSTRACT_P/BLOCK_ABSTRACT handling in dwarf2out.c (PR middle-end/64937)

[Aldy Hernandez]

Richard Biener  writes:

> Looks good to me. I wonder if this will also help Aldyh...

Hmmm, I ran into something very similar.  We solved it on the
debug-early branch by avoiding recursively setting DECL_ABSTRACT_P if
the parent was *not* DECL_ABSTRACT_P.  Like this:

@@ -18274,7 +18312,8 @@ dwarf2out_abstract_function (tree decl)
   current_function_decl = decl;
 
   was_abstract = DECL_ABSTRACT_P (decl);
-  set_decl_abstract_flags (decl, 1);
+  if (!was_abstract)
+set_decl_abstract_flags (decl, 1);
   dwarf2out_decl (decl);
   if (! was_abstract)

Does this help, or do you need to keep track of everything you changed?

I'll say it again, I think setting tree flags behind everyone's back as
we call dwarf2out_decl() _again_ seems like a broken design.  But I
think Jason mentioned that creating new tree instances for the different
variants was a no-go.  Anyways...

Aldy

Re: [debug-early] C++ clones and limbo DIEs

[Aldy Hernandez]

+&& DECL_CONTEXT (snode->decl)
+&& TREE_CODE (DECL_CONTEXT (snode->decl)) != FUNCTION_DECL)


I think this should be !decl_function_context (snode->decl), in case
there's a class or BLOCK between the symbol and its enclosing function.


Done, also for the iteration through reachable functions.




 dwarf2out_type_decl (tree decl, int local)
+  /* ?? Technically, we shouldn't need this hook at all, as all
+ symbols (and by consequence their types) will be outputed from
+ finalize_compilation_unit.


Note that we also want to emit debug info about some types that are not
referenced by symbols, such as when a type is used in a cast.


Fair enough.  I've removed the comment.


+/* Perform any cleanups needed after the early debug generation pass
+   has run.  */
+
+static void
+dwarf2out_early_finish (void)


Since this is also called from dwarf2out_finish, let's call it something
more descriptive, say, flush_limbo_dies?


I was actually thinking of using dwarf2out_early_finish() to mop things 
up as we generate early (or stream out) other auxiliary tables 
(pubname_table, pubtype_table, file_table, etc).  More details on that 
later.  If so, can I leave it as is?


How is this version?  No regressions on guality.  Target libraries build 
fine.


Aldy
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index d1e1f74..7e1305c 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -10657,10 +10657,7 @@ c_write_global_declarations_1 (tree globals)
  here, and start the TV_PHASE_DBGINFO timer.  Is it worth it, or
  would it convolute things?  */
   for (decl = globals; decl; decl = DECL_CHAIN (decl))
-{
-  check_global_declaration_1 (decl);
-  debug_hooks->early_global_decl (decl);
-}
+check_global_declaration_1 (decl);
   /* ?? Similarly here. Stop TV_PHASE_DBGINFO and start
  TV_PHASE_DEFERRED again.  */
 }
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index fed1a3e..3b57dfe 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -2326,6 +2326,16 @@ symbol_table::finalize_compilation_unit (void)
   if (flag_dump_passes)
 dump_passes ();
 
+  /* Generate early debug for global symbols.  Any local symbols will
+ be handled by either handling reachable functions further down
+ (and by consequence, locally scoped symbols), or by generating
+ DIEs for types.  */
+  symtab_node *snode;
+  FOR_EACH_SYMBOL (snode)
+if (TREE_CODE (snode->decl) != FUNCTION_DECL
+   && !decl_function_context (snode->decl))
+  (*debug_hooks->early_global_decl) (snode->decl);
+
   /* Gimplify and lower all functions, compute reachability and
  remove unreachable nodes.  */
   analyze_functions ();
@@ -2336,6 +2346,17 @@ symbol_table::finalize_compilation_unit (void)
   /* Gimplify and lower thunks.  */
   analyze_functions ();
 
+  /* Emit early debug for reachable functions, and by consequence,
+ locally scoped symbols.  */
+  struct cgraph_node *cnode;
+  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (cnode)
+if (!decl_function_context (cnode->decl))
+  (*debug_hooks->early_global_decl) (cnode->decl);
+
+  /* Clean up anything that needs cleaning up after initial debug
+ generation.  */
+  (*debug_hooks->early_finish) ();
+
   /* Finally drive the pass manager.  */
   compile ();
 
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 691688b..96740e8e 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -4333,11 +4333,10 @@ dump_tu (void)
 }
 }
 
-/* Issue warnings for globals in NAME_SPACE (unused statics, etc) and
-   generate debug information for said globals.  */
+/* Issue warnings for globals in NAME_SPACE (unused statics, etc).  */
 
 static int
-emit_debug_for_namespace (tree name_space, void* data ATTRIBUTE_UNUSED)
+check_statics_for_namespace (tree name_space, void* data ATTRIBUTE_UNUSED)
 {
   cp_binding_level *level = NAMESPACE_LEVEL (name_space);
   vec *statics = level->static_decls;
@@ -4346,9 +4345,6 @@ emit_debug_for_namespace (tree name_space, void* data 
ATTRIBUTE_UNUSED)
 
   check_global_declarations (vec, len);
 
-  for (tree t = level->names; t; t = TREE_CHAIN(t))
-debug_hooks->early_global_decl (t);
-
   return 0;
 }
 
@@ -4737,15 +4733,10 @@ c_parse_final_cleanups (void)
  generate initial debug information.  */
   timevar_stop (TV_PHASE_PARSING);
   timevar_start (TV_PHASE_DBGINFO);
-  walk_namespaces (emit_debug_for_namespace, 0);
+  walk_namespaces (check_statics_for_namespace, 0);
   if (vec_safe_length (pending_statics) != 0)
-{
-  check_global_declarations (pending_statics->address (),
-pending_statics->length ());
-  emit_debug_global_declarations (pending_statics->address (),
- pending_statics->length (),
- EMIT_DEBUG_EARLY);
-}
+check_global_declarations (pending_statics->address (),
+  pending_statics->length ());
 
   perform_deferred_noexcept_checks ();
 
diff --git

Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

[H.J. Lu]

On Thu, Feb 5, 2015 at 2:05 PM, Sriraman Tallam  wrote:
> On Thu, Feb 5, 2015 at 11:59 AM, Richard Henderson  wrote:
>> On 02/05/2015 11:01 AM, H.J. Lu wrote:
>>> Can you elaborate why it depends on COPY relocation?  There
>>> is no COPY relocation on x86-64.
>>
>> Ho hum, we appear to have switched topics mid-thread.
>>
>> I agree that we cannot override a weak symbol in the executable with even a
>> non-weak symbol in a shared library.
>
> Hi HJ,
>
>Is your patch supposed to fix weak symbols too?  Will
> SYMBOL_REF_LOCAL_P evaluate to true for weak defined symbols with this
> patch?  I tested this in gcc-4_9 and it didnt seem to do that.

A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00410.html

-- 
H.J.

[PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[H.J. Lu]

If a hidden weak symbol isn't defined in the TU, we can't assume it will
be defined in another TU at link time.  It makes a difference in code
generation when compiling for PIC. If we assume that a hidden weak
undefined symbol is local, the address checking may be optimized out and
leads to the wrong code.  This means that a symbol with user specified
visibility is local only if it is locally resolved or defined, not weak
or not compiling for PIC.  When symbol visibility is specified in the
source, we should always output symbol visibility even if symbol isn't
local to the TU.

If a global data symbol is defined in the TU, it is always local to the
executable, regardless if it is a common symbol or not.  If we aren't
compiling for shared library, locally defined global data symbol binds
locally.

Tested on Linux/x86-64.  OK for trunk?

Thanks.


H.J.
---
gcc/

PR rtl-optimization/32219
* cgraphunit.c (varpool_node::finalize_decl): Set definition
first before calling notice_global_symbol so that it is
available to notice_global_symbol.
* varasm.c (default_binds_local_p_1): Resolve defined data
symbol locally if not building shared library.  Resolve symbol
with user specified visibility locally only if it is locally
resolved or defined, not weak or not compiling for PIC.
(default_elf_asm_output_external): Always output visibility
specified in the source.

gcc/testsuite/

PR rtl-optimization/32219
* gcc.dg/visibility-22.c: New test.
* gcc.dg/visibility-23.c: Likewise.
* gcc.target/i386/pr32219-1.c: Likewise.
* gcc.target/i386/pr32219-2.c: Likewise.
* gcc.target/i386/pr32219-3.c: Likewise.
* gcc.target/i386/pr32219-4.c: Likewise.
* gcc.target/i386/pr32219-5.c: Likewise.
* gcc.target/i386/pr32219-6.c: Likewise.
* gcc.target/i386/pr32219-7.c: Likewise.
* gcc.target/i386/pr32219-8.c: Likewise.
* gcc.target/i386/pr64317.c: Expect GOTOFF relocation instead
of GOT relocation.
---
 gcc/cgraphunit.c  |  4 +++-
 gcc/testsuite/gcc.dg/visibility-22.c  | 14 +
 gcc/testsuite/gcc.dg/visibility-23.c  | 15 +
 gcc/testsuite/gcc.target/i386/pr32219-1.c | 16 ++
 gcc/testsuite/gcc.target/i386/pr32219-2.c | 16 ++
 gcc/testsuite/gcc.target/i386/pr32219-3.c | 17 +++
 gcc/testsuite/gcc.target/i386/pr32219-4.c | 17 +++
 gcc/testsuite/gcc.target/i386/pr32219-5.c | 16 ++
 gcc/testsuite/gcc.target/i386/pr32219-6.c | 16 ++
 gcc/testsuite/gcc.target/i386/pr32219-7.c | 17 +++
 gcc/testsuite/gcc.target/i386/pr32219-8.c | 17 +++
 gcc/testsuite/gcc.target/i386/pr64317.c   |  2 +-
 gcc/varasm.c  | 35 ++-
 13 files changed, 185 insertions(+), 17 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/visibility-22.c
 create mode 100644 gcc/testsuite/gcc.dg/visibility-23.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-4.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-5.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-6.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-7.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-8.c

diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index a2650f7..e1a6e41 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -792,8 +792,10 @@ varpool_node::finalize_decl (tree decl)
 
   if (node->definition)
 return;
-  notice_global_symbol (decl);
+  /* Set definition first before calling notice_global_symbol so that
+ it is available to notice_global_symbol.  */
   node->definition = true;
+  notice_global_symbol (decl);
   if (TREE_THIS_VOLATILE (decl) || DECL_PRESERVE_P (decl)
   /* Traditionally we do not eliminate static variables when not
 optimizing and when not doing toplevel reoder.  */
diff --git a/gcc/testsuite/gcc.dg/visibility-22.c 
b/gcc/testsuite/gcc.dg/visibility-22.c
new file mode 100644
index 000..30087de
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/visibility-22.c
@@ -0,0 +1,14 @@
+/* PR target/32219 */
+/* { dg-do run } */
+/* { dg-require-visibility "" } */
+/* { dg-options "-fPIC" { target fpic } } */
+
+extern void foo () __attribute__((weak,visibility("hidden")));
+int
+main()
+{
+  if (foo)
+foo ();
+  return 0;
+}
+
diff --git a/gcc/testsuite/gcc.dg/visibility-23.c 
b/gcc/testsuite/gcc.dg/visibility-23.c
new file mode 100644
index 000..070493f
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/visibility-23.c
@@ -0,0 +1,15 @@
+/* PR target/32219 */
+/* { dg-do compile } */
+/* { dg-require-visibility "" } */
+/* { dg-final { scan-hidden "foo" } } */
+/* { dg-

Re: [libgo] Remove Solaris 11.1+ zone_net_addr_t treatment

[Ian Lance Taylor]

On Mon, Nov 3, 2014 at 8:59 AM, Rainer Orth  
wrote:
>
> The recent godump changes broke Solaris 11.1+ bootstrap in libgo:
> before, gen-sysinfo.so had
>
> type _zone_net_addr_t struct { zna_family uint16; zna_plen uint16; zna_addru 
> struct { znau_addr6 _in6_addr; }; }
>
> which was filtered out by mksysinfo.sh due to the use of _in6_addr.
>
> After the change, there's now
>
> type _zone_net_addr_t struct { zna_family uint16; zna_plen uint16; zna_addru 
> struct { znau_addr6 [16]byte; Godump_0_align [0]uint32; }; }
>
> instead, not filtered, but added a second time by the _zone_net_addr_t
> code in mksysinfo.sh, which leads to redefinition warnings/errors.
>
> Simply removing the old _zone_net_addr_t fragment fixes this and
> restores bootstrap.
>
> Bootstrapped without regressions on i386-pc-solaris2.1[01], ok for
> mainline?


I just got back to this.  Committed to mainline.  Thanks.

Ian

RE: [PATCH,WWWDOCS] MIPS changes for GCC 5.0

[Moore, Catherine]

> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Thursday, February 05, 2015 5:24 AM
> To: Moore, Catherine
> Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
> Subject: RE: [PATCH,WWWDOCS] MIPS changes for GCC 5.0
> 
> Moore, Catherine  writes:
> > Hi Matthew,
> >
> > I made a few edits.  I removed the markup in the process, so that will
> > need to be added back.
> > See the text at the end.
> 
> Thanks Catherine. Good call to remove the markup while reviewing. I've
> done one more pass on this to have the same phrasing used where similar
> points are being made. I also added a comment about link compatibility for
> FP64.  Updated text is at the end.
> 
This looks good now.

> >
> > > -Original Message-
> > > From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> > > Sent: Wednesday, February 04, 2015 11:46 AM
> > > To: Moore, Catherine
> > > Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
> > > Subject: [PATCH,WWWDOCS] MIPS changes for GCC 5.0
> > >
> > > Hi Catherine,
> > >
> > > I've made a first pass at writing up the MIPS changes for GCC 5.0.
> > > Could you take a read and see what needs some more work?
> > >
> > > Thanks,
> > > Matthew
> > >
> > > Index: htdocs/gcc-5/changes.html
> > >
> ==
> > > =
> > > RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
> > > retrieving revision 1.77
> > > diff -r1.77 changes.html
> > > 562a563,614
> > > > MIPS
> > > >   
> > > > MIPS Releases 3 and 5 are now directly supported using
> > > > -
> > > mips32r3,
> > > > -mips64r3, -mips32r5 and -mips64r5 instead of relying
> > > > on the
> > > Release
> > > > 2 options.
> > > > Support for the Imagination P5600 processor has been added
> > using
> > > > -march=p5600.
> > > > 
> > > > Support for the Cavium Networks Octeon3 processor has been
> > > > added
> > > using
> > > > -march=octeon3.
> > > > MIPS Release 6 is now supported using -mips32r6 and
> > > > -
> > > mips64r6
> > > > .
> > > > The previous o32 64-bit floating-point register support
> > > > has
> > been
> > > > obsoleted and removed.  This was previously enabled using
> > > > -
> > > mfp64
> > > >  which has been re-purposed for the new ABI extensions
> > > described
> > > > below.
> > > > New o32 ABI extensions have been added to enable software
> > > > to
> > > transition
> > > > away from the original layout of double-precision
> > > > floating-point
> > registers.
> > > > 
> > > >   The first of these extensions is o32 FPXX which places
> > restrictions
> > > >   on code-generation to never access the upper 32-bits of
> > > > double-
> > > precision
> > > >   registers via odd-numbered single-precision registers.  By
> > default the
> > > >   odd-numbered single-precision registers are not used at all
> > with this
> > > >   extension.  o32 FPXX code is link compatible with all other
> > o32
> > > >   double-precision ABI variants and will execute correctly in
> > all hardware
> > > >   FPU modes.  Enable o32 FPXX using -mabi=32
> > > > -mfpxx
> > for
> > > >   MIPS II onwards.
> > > >   The second extension is o32 FP64A which requires 64-bit
> > > >   floating-point registers and places a mandatory restriction
> > > > on
> > the use of
> > > >   odd-numbered single-precision registers.  o32 FP64A is link
> > compatible
> > > >   with all other o32 double-precision ABI variants.  Enable
> > > > o32
> > FP64A
> > > >   using -mabi=32 -mfp64 -mno-odd-spreg for
> > > > MIPS32R2
> > > onwards.
> > > >   
> > > >   Finally, the o32 FP64 extension which also requires 64-bit
> > > >   floating-point registers but permits the use of all single-
> > precision
> > > >   registers.  Enable o32 FP64 using -mfp64 for
> > MIPS32R2
> > > >   onwards.
> > > > 
> > > > All new ABI variants can be enabled by default using configure
> > time
> > > > options --with-fp-32=[32|xx|64] and
> > > > --with(out)-odd-sp-reg-32.  It is strongly
> > > > recommended
> > > that
> > > > all vendors begin to set o32 FPXX as default ABI to be able to
> > run the
> > > > generated code on MIPSR5 cores alongside future MIPS SIMD
> > > > (MSA)
> > > code and
> > > > MIPSR6 cores.
> > > > When using binutils 2.25 GCC will now pass options like
> > > > -msoft-float and -msingle-float to
> > > > the
> > > assembler.
> > > > This change can affect inline assembly code that is built as
> > soft-float but
> > > > contains hard-float instructions.  In such cases the code must
> > > > be
> > > amended
> > > > to use appropriate .set directives to override
> > > > the
> > global
> > > > assembler options.
> > > >   
> > > >
> >
> > MIPS Releases 3 and 5 are now directly supported.  Use the
> > command-line options -mips32r3, -mips64r3, -mips32r5 and -mips64r5 to

RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Moore, Catherine]

> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Thursday, February 05, 2015 3:52 PM
> Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
> > 
> I've put your patch inline below and switched to plain text. I suspect your
> post was bounced by gcc-patches.
> 
> I'm OK with this change but I'd like Catherine to comment before committing.
> It seems a shame to duplicate the block of code but it is probably just as 
> ugly
> to define a macro for the la/dla instruction.

The patch itself is OK, although I agree with other's comments about the 
unfortunate duplication of code.
Petar,  would you please add your testcase to the gcc testsuite and repost the 
patch.
Thanks,
Catherine

> 
> For future reference, it is best not to include changelog content in a patch
> but instead just paste into the email. Also the ChangeLog you need for this
> change is gcc/ChangeLog (as confusing as that may be at first).
> 
> Thanks,
> Matthew
> 
> > From: Petar Jovanovic [mailto:petar.jovano...@rt-rk.com]
> > Sent: 05 February 2015 19:28
> > To: gcc-patches@gcc.gnu.org; 'Maciej W. Rozycki'; Matthew Fortune
> > Subject: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
> >
> > v2:
> > - add ChangeLog entry
> > - use DLA instead of LA for n64
> >
> > PTAL. Thanks.
> >
> > Regards,
> > Petar
> 
> ---
>  ChangeLog  |  5 +
>  gcc/config/mips/mips.h | 23 +++
>  2 files changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/ChangeLog b/ChangeLog
> index 5c61c66..3a15f4a 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,8 @@
> +2015-02-05  Petar Jovanovic  
> +
> + * config/mips/mips.h (CRT_CALL_STATIC_FUNCTION): Fix the macro
> to use
> + la/jalr instead of jal.
> +
>  2015-02-02  Janis Johnson  
> 
>   * MAINTAINERS (Various Maintainers: testsuite): Remove myself.
> diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index
> ec69ed5..4bd83f5 100644
> --- a/gcc/config/mips/mips.h
> +++ b/gcc/config/mips/mips.h
> @@ -3034,11 +3034,11 @@ while (0)
>   nop\n\
>  1:   .cpload $31\n\
>   .set reorder\n\
> - jal " USER_LABEL_PREFIX #FUNC "\n\
> + la $25, " USER_LABEL_PREFIX #FUNC "\n\
> + jalr $25\n\
>   .set pop\n\
>   " TEXT_SECTION_ASM_OP);
> -#elif ((defined _ABIN32 && _MIPS_SIM == _ABIN32) \
> -   || (defined _ABI64 && _MIPS_SIM == _ABI64))
> +#elif (defined _ABIN32 && _MIPS_SIM == _ABIN32)
>  #define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC)   \
> asm (SECTION_OP "\n\
>   .set push\n\
> @@ -3048,7 +3048,22 @@ while (0)
>   nop\n\
>  1:   .set reorder\n\
>   .cpsetup $31, $2, 1b\n\
> - jal " USER_LABEL_PREFIX #FUNC "\n\
> + la $25, " USER_LABEL_PREFIX #FUNC "\n\
> + jalr $25\n\
> + .set pop\n\
> + " TEXT_SECTION_ASM_OP);
> +#elif (defined _ABI64 && _MIPS_SIM == _ABI64)
> +#define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC)   \
> +   asm (SECTION_OP "\n\
> + .set push\n\
> + .set nomips16\n\
> + .set noreorder\n\
> + bal 1f\n\
> + nop\n\
> +1:   .set reorder\n\
> + .cpsetup $31, $2, 1b\n\
> + dla $25, " USER_LABEL_PREFIX #FUNC "\n\
> + jalr $25\n\
>   .set pop\n\
>   " TEXT_SECTION_ASM_OP);
>  #endif
> --
> 1.8.2.1

[PATCH], PR target/64205, Fix -mcpu=G5 breakage on PowerPC

[Michael Meissner]

This patch fixes PR target/64205, which was caused due to my previous patch to
add the -mupper-regs support for scalar floating point to occupy the VSX
floating point registers that are overlaid on top of the traditional Altivec
registers, starting with ISA 2.06 (power7).

The problem was, I added secondary reload handlers for SDmode unconditionally.
On systems before ISA 2.06, there are no stores and loads for 32-bit SDmode in
a floating point register, and so you can't do normal secondary reload
operations on this (you have to do a 64-bit store and a 32-bit load on the
bottom bits).

I have tested this with a full bootstrap on PowerPC 64-bit systems with no
regressions.  In addition, I built a bootstrap compiler using the --with-cpu=G5
option and it succeeded.  Is it ok to install the patches in trunk, and in any
branches that the upper regs patches were applied to?

[gcc]
2015-02-06  Michael Meissner  

PR target/64205
* config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Do not
add a general secondary reload handler for SDmode, unless we have
both read/write support for SDmode.

[gcc/testsuite]
2015-02-06  Michael Meissner  

PR target/64205
* gcc.target/powerpc/pr64205.c: New file.


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 220460)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -2849,8 +2849,15 @@ rs6000_init_hard_regno_mode_ok (bool glo
  reg_addr[DDmode].reload_load = CODE_FOR_reload_dd_di_load;
  reg_addr[SFmode].reload_store= CODE_FOR_reload_sf_di_store;
  reg_addr[SFmode].reload_load = CODE_FOR_reload_sf_di_load;
- reg_addr[SDmode].reload_store= CODE_FOR_reload_sd_di_store;
- reg_addr[SDmode].reload_load = CODE_FOR_reload_sd_di_load;
+
+ /* If we don't have the load/store integer instructions, don't use
+the general reload mechanisms for SDmode, which must be handled
+specially.  */
+ if (TARGET_NO_SDMODE_STACK)
+   {
+ reg_addr[SDmode].reload_store = CODE_FOR_reload_sd_di_store;
+ reg_addr[SDmode].reload_load  = CODE_FOR_reload_sd_di_load;
+   }
 
  if (TARGET_VSX_TIMODE)
{
@@ -2903,8 +2910,15 @@ rs6000_init_hard_regno_mode_ok (bool glo
  reg_addr[DDmode].reload_load = CODE_FOR_reload_dd_si_load;
  reg_addr[SFmode].reload_store= CODE_FOR_reload_sf_si_store;
  reg_addr[SFmode].reload_load = CODE_FOR_reload_sf_si_load;
- reg_addr[SDmode].reload_store= CODE_FOR_reload_sd_si_store;
- reg_addr[SDmode].reload_load = CODE_FOR_reload_sd_si_load;
+
+ /* If we don't have the load/store integer instructions, don't use
+the general reload mechanisms for SDmode, which must be handled
+specially.  */
+ if (TARGET_NO_SDMODE_STACK)
+   {
+ reg_addr[SDmode].reload_store = CODE_FOR_reload_sd_si_store;
+ reg_addr[SDmode].reload_load  = CODE_FOR_reload_sd_si_load;
+   }
 
  if (TARGET_VSX_TIMODE)
{
Index: gcc/testsuite/gcc.target/powerpc/pr64205.c
===
--- gcc/testsuite/gcc.target/powerpc/pr64205.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/pr64205.c  (revision 0)
@@ -0,0 +1,17 @@
+/* { dg-do compile { target { powerpc*-*-* && ilp32 } } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=G5" } } */
+/* { dg-options "-O2 -mcpu=G5 -maltivec -m32" } */
+
+union ieee754r_Decimal32
+{
+  _Decimal32 sd;
+  unsigned int cc0;
+};
+
+unsigned int
+__decoded32 (_Decimal32 a)
+{
+union ieee754r_Decimal32 d;
+d.sd = a;
+return d.cc0;
+}

[PATCH][5 regression][PR target/64889/] Fix incorrect setting of RTX_FRAME_RELATED_P on H8/300 port

[Jeff Law]

The H8/300 port is setting RTX_FRAME_RELATED_P on random insns outside 
the prologue/epilogue.  That is causing dwarf2cfi heartburn as seen by 
PR64889 (and its dup 64602).


This patch avoids setting RTX_FRAME_RELATED_P on those random insns. 
The H8/300 port can now build libssp properly (64602).  Given this bug 
shows up in a standard build, I am not including a separate testcase for it.


Built gcc, & newlib on the h8300, then ran the gcc testsuite for 
h8300-elf-sim{,-mh/-mint32,-ms/-mint32} with no regressions.


Installed on the trunk.

jeff
commit 2bae6e680faeb2ae31ea9cb7ebeffc073f9617c1
Author: Jeff Law 
Date:   Fri Feb 6 07:15:51 2015 -0700

PR target/64889
* config/h8300/h8300.c (push): New argument "in_prologue".
Pass "in_prologue" along to "F".
(h8300_push_pop): Corresponding changes.
(h8300_expand_prologue): Likewise.
(h8300_swap_into_er6): Likewise.  Do not set RTX_FRAME_RELATED_P.

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 3a5d7a2..41a824d 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2015-02-06  Jeff Law  
+
+   PR target/64889
+   * config/h8300/h8300.c (push): New argument "in_prologue".
+   Pass "in_prologue" along to "F".
+   (h8300_push_pop): Corresponding changes.
+   (h8300_expand_prologue): Likewise.
+   (h8300_swap_into_er6): Likewise.  Do not set RTX_FRAME_RELATED_P.
+   
 2015-02-06  Jakub Jelinek  
 
PR rtl-optimization/64957
@@ -11,6 +20,7 @@
* tree-ssa-loop-ivopts.c (get_shiftadd_cost): Use the mininum of costs
of shift-add and (add + shift) operations.  Rename local variable.
 
+
 2015-02-05  Jeff Law  
 
PR target/17306
diff --git a/gcc/config/h8300/h8300.c b/gcc/config/h8300/h8300.c
index ea90052..4e9110e 100644
--- a/gcc/config/h8300/h8300.c
+++ b/gcc/config/h8300/h8300.c
@@ -619,7 +619,7 @@ compute_saved_regs (void)
 /* Emit an insn to push register RN.  */
 
 static rtx
-push (int rn)
+push (int rn, bool in_prologue)
 {
   rtx reg = gen_rtx_REG (word_mode, rn);
   rtx x;
@@ -630,7 +630,7 @@ push (int rn)
 x = gen_push_h8300hs_advanced (reg);
   else
 x = gen_push_h8300hs_normal (reg);
-  x = F (emit_insn (x), true);
+  x = F (emit_insn (x), in_prologue);
   add_reg_note (x, REG_INC, stack_pointer_rtx);
   return x;
 }
@@ -683,7 +683,7 @@ h8300_push_pop (int regno, int nregs, bool pop_p, bool 
return_p)
   if (pop_p)
pop (regno);
   else
-   push (regno);
+   push (regno, false);
   return;
 }
 
@@ -868,7 +868,7 @@ h8300_expand_prologue (void)
   if (frame_pointer_needed)
 {
   /* Push fp.  */
-  push (HARD_FRAME_POINTER_REGNUM);
+  push (HARD_FRAME_POINTER_REGNUM, true);
   F (emit_move_insn (hard_frame_pointer_rtx, stack_pointer_rtx), true);
 }
 
@@ -2757,7 +2757,7 @@ h8sx_emit_movmd (rtx dest, rtx src, rtx length,
 void
 h8300_swap_into_er6 (rtx addr)
 {
-  rtx insn = push (HARD_FRAME_POINTER_REGNUM);
+  rtx insn = push (HARD_FRAME_POINTER_REGNUM, false);
   if (frame_pointer_needed)
 add_reg_note (insn, REG_CFA_DEF_CFA,
  plus_constant (Pmode, gen_rtx_MEM (Pmode, stack_pointer_rtx),
@@ -2786,7 +2786,6 @@ h8300_swap_out_of_er6 (rtx addr)
 emit_move_insn (addr, hard_frame_pointer_rtx);
 
   insn = pop (HARD_FRAME_POINTER_REGNUM);
-  RTX_FRAME_RELATED_P (insn) = 1;
   if (frame_pointer_needed)
 add_reg_note (insn, REG_CFA_DEF_CFA,
  plus_constant (Pmode, hard_frame_pointer_rtx,

Re: [PATCH] maintainer-scripts: Fix 404s in "Show Source" in jit docs

[Gerald Pfeifer]

On Thursday 2015-02-05 22:49, David Malcolm wrote:
> Tested locally with a suitably hacked up script to work on this
> machine; with this patch the "Show Sources" links work within the
> files installed to /www/gcc/htdocs.
> 
> OK for trunk?
> 
> maintainer-scripts/ChangeLog:
>   * update_web_docs_svn: When copying up files for the built jit
>   documentation, also copy up .txt files.

Sure thing.  You should just consider yourself the maintainer of
this aspect and simply go ahead with changes like this.

Gerald

Re: [debug-early] C++ clones and limbo DIEs

[Jason Merrill]

On 02/05/2015 08:15 PM, Aldy Hernandez wrote:

Absolutely nothing, basically  because #if 0 would have been too obvious.  It 
was actually there to test if you were on your game.  You passed


Yay?


The attached patch still passes the guality tests with no regressions. My 
apologies for the lack of ChangeLog entries.  I've given up on them, especially 
on multiple iterations.  And it seems I'll have to rewrite them at merge time 
anyhow.


That makes total sense to me.


+   && DECL_CONTEXT (snode->decl)
+   && TREE_CODE (DECL_CONTEXT (snode->decl)) != FUNCTION_DECL)


I think this should be !decl_function_context (snode->decl), in case 
there's a class or BLOCK between the symbol and its enclosing function.



 dwarf2out_type_decl (tree decl, int local)
+  /* ?? Technically, we shouldn't need this hook at all, as all
+ symbols (and by consequence their types) will be outputed from
+ finalize_compilation_unit.


Note that we also want to emit debug info about some types that are not 
referenced by symbols, such as when a type is used in a cast.



+/* Perform any cleanups needed after the early debug generation pass
+   has run.  */
+
+static void
+dwarf2out_early_finish (void)


Since this is also called from dwarf2out_finish, let's call it something 
more descriptive, say, flush_limbo_dies?


Jason

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[H.J. Lu]

On Fri, Feb 6, 2015 at 5:30 AM, H.J. Lu  wrote:
> On Fri, Feb 6, 2015 at 5:18 AM, Markus Trippelsdorf
>  wrote:
>> On 2015.02.06 at 05:10 -0800, H.J. Lu wrote:
>>> On Fri, Feb 6, 2015 at 4:56 AM, Markus Trippelsdorf
>>>  wrote:
>>> > On 2015.02.05 at 12:57 -0800, H.J. Lu wrote:
>>> >>
>>> >> We should pass handle, not file, to release_input_file.
>>> >> I checked it in as an obvious fix.
>>> >
>>> > This commit causes:
>>> >
>>> >  % echo "int main () {}" | gcc -fuse-ld=gold -flto -x c++ -
>>> > ld.gold: internal error in remove_writer, at token.h:132
>>> > collect2: error: ld returned 1 exit status
>>> >
>>>
>>> ld.bfd closes fd without release_input_file being called
>>> and ld.gold leaks file descriptors if release_input_file
>>> isn't called.  We can either fix gold:
>>>
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=17896
>>>
>>> or revert the PR lto/64837 fix.
>>
>> Given that LTO would be completely broken with any gold version in
>> gcc-5, a revert seems to be the only viable option.
>>
>
> Fine with me and reopen PR lto/64837.
>

Done with r220477.


-- 
H.J.

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[H.J. Lu]

On Fri, Feb 6, 2015 at 5:18 AM, Markus Trippelsdorf
 wrote:
> On 2015.02.06 at 05:10 -0800, H.J. Lu wrote:
>> On Fri, Feb 6, 2015 at 4:56 AM, Markus Trippelsdorf
>>  wrote:
>> > On 2015.02.05 at 12:57 -0800, H.J. Lu wrote:
>> >>
>> >> We should pass handle, not file, to release_input_file.
>> >> I checked it in as an obvious fix.
>> >
>> > This commit causes:
>> >
>> >  % echo "int main () {}" | gcc -fuse-ld=gold -flto -x c++ -
>> > ld.gold: internal error in remove_writer, at token.h:132
>> > collect2: error: ld returned 1 exit status
>> >
>>
>> ld.bfd closes fd without release_input_file being called
>> and ld.gold leaks file descriptors if release_input_file
>> isn't called.  We can either fix gold:
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=17896
>>
>> or revert the PR lto/64837 fix.
>
> Given that LTO would be completely broken with any gold version in
> gcc-5, a revert seems to be the only viable option.
>

Fine with me and reopen PR lto/64837.


-- 
H.J.

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[Markus Trippelsdorf]

On 2015.02.06 at 05:10 -0800, H.J. Lu wrote:
> On Fri, Feb 6, 2015 at 4:56 AM, Markus Trippelsdorf
>  wrote:
> > On 2015.02.05 at 12:57 -0800, H.J. Lu wrote:
> >>
> >> We should pass handle, not file, to release_input_file.
> >> I checked it in as an obvious fix.
> >
> > This commit causes:
> >
> >  % echo "int main () {}" | gcc -fuse-ld=gold -flto -x c++ -
> > ld.gold: internal error in remove_writer, at token.h:132
> > collect2: error: ld returned 1 exit status
> >
> 
> ld.bfd closes fd without release_input_file being called
> and ld.gold leaks file descriptors if release_input_file
> isn't called.  We can either fix gold:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=17896
> 
> or revert the PR lto/64837 fix.

Given that LTO would be completely broken with any gold version in
gcc-5, a revert seems to be the only viable option. 

-- 
Markus

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[H.J. Lu]

On Fri, Feb 6, 2015 at 4:56 AM, Markus Trippelsdorf
 wrote:
> On 2015.02.05 at 12:57 -0800, H.J. Lu wrote:
>>
>> We should pass handle, not file, to release_input_file.
>> I checked it in as an obvious fix.
>
> This commit causes:
>
>  % echo "int main () {}" | gcc -fuse-ld=gold -flto -x c++ -
> ld.gold: internal error in remove_writer, at token.h:132
> collect2: error: ld returned 1 exit status
>

ld.bfd closes fd without release_input_file being called
and ld.gold leaks file descriptors if release_input_file
isn't called.  We can either fix gold:

https://sourceware.org/bugzilla/show_bug.cgi?id=17896

or revert the PR lto/64837 fix.

-- 
H.J.

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[Markus Trippelsdorf]

On 2015.02.05 at 12:57 -0800, H.J. Lu wrote:
> 
> We should pass handle, not file, to release_input_file.
> I checked it in as an obvious fix.

This commit causes:

 % echo "int main () {}" | gcc -fuse-ld=gold -flto -x c++ -
ld.gold: internal error in remove_writer, at token.h:132
collect2: error: ld returned 1 exit status

-- 
Markus

RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Maciej W. Rozycki]

On Fri, 6 Feb 2015, Matthew Fortune wrote:

> >  Native systems have  for such ABI dependencies, including
> > stuff to set up $gp.  Perhaps we could reuse these bits, the licence I
> > think allows us to.
> 
> That's a good idea. Perhaps I should take that on as part of some cleanup
> of the MIPS backend in the next stage1. I'm looking to rework how the
> ISA_HAS logic works so perhaps there would be value in doing this mostly in
> a header that can also be used for assembly programmers. That would naturally
> mean we get all the other nice assembly macros available in the backend of
> GCC too.

 This consideration made me realise I've had a patch outstanding for some 
10 years to convert all the `BAL x' instructions there to `BLTZAL $0, x'.  
This has always been a good idea in case implementations recognised the 
special case and avoided involving branch prediction, and I believe it has 
become even more apparent with r6 calling it NAL.

 I'll see if I can submit it to glibc soon -- as you may have been aware 
10 years ago wasn't exactly the most friendly period in glibc maintenance 
and hence I wasn't very prompt with patch submissions.

  Maciej

[Haifa Scheduler] Fix latent bug in macro-fusion/instruction grouping

[James Greenhalgh]

Hi,

While trying to force some particular conditions out of the scheduler
on a private branch, I was toying with some very aggressive
macro-fusion patterns. In doing so, I hit on a latent bug which can
cause miscompilation.

The exact conditions for the bug seem to be:

We go in to macro fusion with a previous pattern which can be rewritten
as a function of the current pattern. That is to say, we have something
like:

  x21 = f00f
  x1 = load (x21 + 16)
  x21 = x21 + 8

Which could be rewritten as:

  x21 = f00f
  x21 = x21 + 8
  x1 = load (x21 + 8)

If we choose to fuse the instructions, we set the SCHED_GROUP_P
flag on x21 = 21 + 8.

recompute_todo_spec will potentially apply the rewriting above, and
will apply it regardless of SCHED_GROUP_P. It also will not clear
the flag, so we end up pulling the fused instruction to the head of
the wrong scheduling group.

After scheduling, this gives the code:

  x21 = x21 + 8
  x21 = f00f
  x1 = load (x21 + 8)

Which is clearly bogus. To show this concretely with scheduler dumps
(with some additional debug information):

;;   ==
;;   -- basic block 8 from 339 to 344 -- after reload
;;   ==

;;  | insn | prio |
;;  |  339 |3 | x21=x19+low(`*.LANCHOR0')  ca57_sx1|ca57_sx2
;;  |  341 |2 | x21=x21+0x8ca57_sx1|ca57_sx2
;;  |  342 |1 | x1=[x21+0x10]  ca57_load_model
;;  |  204 |0 | x21=x21+0x8ca57_sx1|ca57_sx2
;;  |  344 |0 | pc={(x1==0)?L4717:pc}  ca57_bx
;;   --- forward dependences: 

;;   --- Region Dependences --- b 8 bb 0
;;  insn  codebb   dep  prio  cost   reservation
;;    --   ---       ---
;;  339   739 8 0 3 2   ca57_sx1|ca57_sx2   : 344 341m
;;  34187 8 1 2 2   ca57_sx1|ca57_sx2   : 344 342m
;;  34240 8 1 1 5   ca57_load_model : 344m 204
;;   +  20487 8 1 0 2   ca57_sx1|ca57_sx2   : 344
;;  34417 8 4 0 0   ca57_bx :

;;  Looking at: insn 204
;;   Can rewrite predecessor of :: 204 :: from:

  (mem/f/c:DI (plus:DI (reg/f:DI 21 x21 [1023])
  (const_int 16 [0x10])) [3 MEM[(struct _Rb_tree_node_baseD.35435 * 
*)&_ZN12_GLOBAL__N_120section_workload_mapED.48605 + 16B]+0 S8 A64])

;;  TO

  (mem/f/c:DI (plus:DI (reg/f:DI 21 x21 [1023])
  (const_int 8 [0x8])) [3 MEM[(struct _Rb_tree_node_baseD.35435 * 
*)&_ZN12_GLOBAL__N_120section_workload_mapED.48605 + 16B]+0 S8 A64])

;;  dependencies resolved: insn 204
;;  tick updated: insn 204 into ready
;;  Ready list after queue_to_ready:  204:42:prio=0  339:39:prio=3
;;  Ready list after ready_sort:  204:42:prio=0  339:39:prio=3
;;  Ready list (t =   0):204:42:prio=0  339:39:prio=3
;;  max_issue among 2 insns:  204:42:prio=0  339:39:prio=3

I'm fairly sure that it can't trigger on trunk with any of the
patterns in the AArch64/i386 back ends, and I can't give a reduced
testcase showing the bug (miscompilation of proprietary code :( ).

My fix is simply to clear the SCHED_GROUP_P flag if we do a rewrite
as above, this seems sensible, but it may not be - I don't know this
code, and I might be pessimising (or worse, breaking) code which
requires fusion between the re-ordered instructions.

I've bootstrapped the patch on x86_64 and aarch64-none-linux-gnu
with no issues.

Does this look sensible? I'm fairly sure my analysis of the bug is
sound, but I could imagine other possible fixes to the same issue.
I guess the most obvious would be to not allow the rewriting at all
for instructions with SCHED_GROUP_P set.

Thanks,
James

---
2015-02-06  James Greenhalgh  

* haifa-sched.c (recompute_todo_spec): After applying a
replacement and cancelling a dependency, also clear the
SCHED_GROUP_P flag.
diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 75d2421..730a8db 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -1293,6 +1293,10 @@ recompute_todo_spec (rtx_insn *next, bool for_backtrack)
 		  apply_replacement (dep, true);
 		}
 	  DEP_STATUS (dep) |= DEP_CANCELLED;
+	  /* Also cancel any scheduler grouping, or we can
+		 end up falsely claiming we are independent of
+		 previous instructions.  */
+	  SCHED_GROUP_P (next) = 0;
 	}
 	}
   return 0;

Re: [PATCH] doc/invoke.texi: clarify default setting of VTA

[Alexander Monakov]

Ping?

On Fri, 30 Jan 2015, Alexander Monakov wrote:

> Hello,
> 
> Recently on gcc-help@ one of the users asked whether they need to set
> -fvar-tracking-assignments on the command line by hand.  The documentation may
> be clearer in that this flag has a useful value by default, like 
> -fvar-tracking
> (i.e. GCC's behavior is to take the value of flag_var_tracking, unless there's
> an override on the command line).
> 
> OK to commit?
> 
> I also see that introductory text says that the option list mentions negated
> forms when they are supposed to be usually used on the command line, which
> means that var-tracking paragraphs should in fact use
> -fno-var-tracking[-assignments], because normally users will only need the
> negative forms?
> 
> 2015-01-30  Alexander Monakov  
> 
>   * doc/invoke.texi (-fvar-tracking-assignments): Clarify that VTA is
>   enabled by default together with var-tracking.
> 
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 2d3c4f7..3ffba2e 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -7093,6 +7093,8 @@ optimizing.  Use of @option{-gdwarf-4} is recommended 
> along with it.
>  
>  It can be enabled even if var-tracking is disabled, in which case
>  annotations are created and maintained, but discarded at the end.
> +By default, this flag is enabled together with @option{-fvar-tracking},
> +except when selective scheduling is enabled.
>  
>  @item -fvar-tracking-assignments-toggle
>  @opindex fvar-tracking-assignments-toggle
> 
> 

[committed] Fix recent simplify_binary_operation_1 bug (PR rtl-optimization/64957)

[Jakub Jelinek]

Hi!

The
  /* Given (xor (ior (xor A B) C) D), where B, C and D are
 constants, simplify to (xor (ior A C) (B&~C)^D), canceling
 out bits inverted twice and not set by C.  Similarly, given
 (xor (and (xor A B) C) D), simplify without inverting C in
 the xor operand: (xor (and A C) (B&C)^D).
  */
comment describes the intended optimization correctly, but unfortunately
the code diverges from it, using (xor (and A C) (B&~C)^D)
for the second and (xor (ior A C) (B&C)^D) for the first one.

Fixed thusly, committed as obvious after bootstrapping/regtesting it on
x86_64-linux and i686-linux.

2015-02-06  Jakub Jelinek  

PR rtl-optimization/64957
PR debug/64817
* simplify-rtx.c (simplify_binary_operation_1): Use ~cval for
IOR rather than for AND.

* gcc.c-torture/execute/pr64957.c: New test.

--- gcc/simplify-rtx.c.jj   2015-02-04 15:24:20.0 +0100
+++ gcc/simplify-rtx.c  2015-02-06 09:41:31.139326554 +0100
@@ -2731,9 +2731,9 @@ simplify_binary_operation_1 (enum rtx_co
  HOST_WIDE_INT xcval;
 
  if (op == IOR)
-   xcval = cval;
- else
xcval = ~cval;
+ else
+   xcval = cval;
 
  return simplify_gen_binary (XOR, mode,
  simplify_gen_binary (op, mode, a, c),
--- gcc/testsuite/gcc.c-torture/execute/pr64957.c.jj2015-02-06 
09:43:12.595616710 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr64957.c   2015-02-06 
09:43:26.361384715 +0100
@@ -0,0 +1,23 @@
+/* PR rtl-optimization/64957 */
+
+__attribute__((noinline, noclone)) int
+foo (int b)
+{
+  return (((b ^ 5) | 1) ^ 5) | 1;
+}
+
+__attribute__((noinline, noclone)) int
+bar (int b)
+{
+  return (((b ^ ~5) & ~1) ^ ~5) & ~1;
+}
+
+int
+main ()
+{
+  int i;
+  for (i = 0; i < 16; i++)
+if (foo (i) != (i | 1) || bar (i) != (i & ~1))
+  __builtin_abort ();
+  return 0;
+}

Jakub

Re: [PATCH, fortran, committed] PR60289 was: PR fortran/60255 Deferred character length + PR60289 Also deferred char len.

[Andre Vehreschild]

Hi Paul,

thanks for the review.

Committed as r220474.

Regards,
Andre

On Thu, 5 Feb 2015 15:15:02 +0100
Paul Richard Thomas  wrote:

> Dear Andre,
> 
> That's fine to commit to trunk.
> 
> Thanks for the patch
> 
> Paul
> 
> On 30 January 2015 at 11:19, Andre Vehreschild  wrote:
> > Hi Paul,
> >
> > thanks for the review. Meanwhile I reread the patch myself and figured, that
> > the comment in the second patch-block was ill-placed and formulated. I
> > therefore changed it to look like this now:
> >
> > diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
> > index 52caaa4..24fab5c 100644
> > --- a/gcc/fortran/trans-stmt.c
> > +++ b/gcc/fortran/trans-stmt.c
> > @@ -5166,7 +5166,16 @@ gfc_trans_allocate (gfc_code * code)
> >   se_sz.expr = gfc_evaluate_now (se_sz.expr, &se.pre);
> >   gfc_add_block_to_block (&se.pre, &se_sz.post);
> >   /* Store the string length.  */
> > - tmp = al->expr->ts.u.cl->backend_decl;
> > + if ((expr->symtree->n.sym->ts.type == BT_CLASS
> > + || expr->symtree->n.sym->ts.type == BT_DERIVED)
> > + && expr->ts.u.derived->attr.unlimited_polymorphic)
> > +   /* For unlimited polymorphic entities get the backend_decl
> > of
> > +  the _len component for that.  */
> > +   tmp = gfc_class_len_get (gfc_get_symbol_decl (
> > +  expr->symtree->n.sym));
> > + else
> > +   /* Else use what is stored in the charlen->backend_decl.  */
> > +   tmp = al->expr->ts.u.cl->backend_decl;
> >   gfc_add_modify (&se.pre, tmp, fold_convert (TREE_TYPE (tmp),
> >   se_sz.expr));
> >tmp = TREE_TYPE (gfc_typenode_for_spec
> > (&code->ext.alloc.ts));
> >
> > I still hope this is ok for commit. As a newbie, I don't want to mess it up
> > in the beginning and therefore ask one more time for permission.
> >
> > On Thu, 29 Jan 2015 20:13:49 +
> > Paul Richard Thomas  wrote:
> >
> >> I must apologise. I have been working so hard on my own projects that
> >> I failed completely to notice that your patch had not been applied.
> >
> > No problem. Hadn't I been asked, I would have forgotten about it, too. I am
> > working on a bunch of class-array issues starting with pr60322 currently. I
> > hope to be able to submit a patch for it today.
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
> 
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans-stmt.c	(Revision 220473)
+++ gcc/fortran/trans-stmt.c	(Arbeitskopie)
@@ -5167,7 +5167,16 @@
 	  se_sz.expr = gfc_evaluate_now (se_sz.expr, &se.pre);
 	  gfc_add_block_to_block (&se.pre, &se_sz.post);
 	  /* Store the string length.  */
-	  tmp = al->expr->ts.u.cl->backend_decl;
+	  if ((expr->symtree->n.sym->ts.type == BT_CLASS
+		  || expr->symtree->n.sym->ts.type == BT_DERIVED)
+		  && expr->ts.u.derived->attr.unlimited_polymorphic)
+		/* For unlimited polymorphic entities get the backend_decl of
+		   the _len component for that.  */
+		tmp = gfc_class_len_get (gfc_get_symbol_decl (
+	   expr->symtree->n.sym));
+	  else
+		/* Else use what is stored in the charlen->backend_decl.  */
+		tmp = al->expr->ts.u.cl->backend_decl;
 	  gfc_add_modify (&se.pre, tmp, fold_convert (TREE_TYPE (tmp),
 			  se_sz.expr));
   tmp = TREE_TYPE (gfc_typenode_for_spec (&code->ext.alloc.ts));
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(Revision 220473)
+++ gcc/fortran/resolve.c	(Arbeitskopie)
@@ -6933,7 +6933,9 @@
   goto failure;
 }
 
-  if (code->ext.alloc.ts.type == BT_CHARACTER && !e->ts.deferred)
+  /* Check F08:C632.  */
+  if (code->ext.alloc.ts.type == BT_CHARACTER && !e->ts.deferred
+  && !UNLIMITED_POLY (e))
 {
   int cmp = gfc_dep_compare_expr (e->ts.u.cl->length,
   code->ext.alloc.ts.u.cl->length);
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 220473)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,17 @@
+
+2015-01-29  Andre Vehreschild  , Janus Weil  
+
+	PR fortran/60289
+	Initial patch by Janus Weil
+	* resolve.c (resolve_allocate_expr): Add check for comp. only when 
+	target is not unlimited polymorphic.
+	* trans-stmt.c (gfc_trans_allocate): Assign correct value to _len
+	component of unlimited polymorphic entities.
+
+2015-01-29  Andre Vehreschild  
+
+	* gfortran.dg/unlimited_polymorphic_22.f90: New test.
+
 2015-02-05  Tobias Burnus  
 
 	PR fortran/64943
Index: gcc/testsuite/gfortran.dg/unlimited_polymorphic_22.f90

Re: [Patch, WWWDOCS] gcc-5/changes.html: Mention that C FE can be build as libcc1.so

[Jakub Jelinek]

On Fri, Feb 06, 2015 at 10:44:20AM +0100, Tobias Burnus wrote:
> I think it is useful to know that one can build libcc1.so - also as
> advertisement. Thus, I propose to include something like the quip in
> the attachment.
> 
> GDB uses it in version 7.9, which is not yet released but already
> branched off.
> 
> OK?  - Other suggestions or comments?

Well, I would certainly not describe libcc1.so as C front end built as a
library, there is no FE code in it; it is a library to invoke gcc with
a special plugin, and I doubt it can be easily used for anything but GDB.

> Index: htdocs/gcc-5/changes.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
> retrieving revision 1.78
> diff -u -p -r1.78 changes.html
> --- htdocs/gcc-5/changes.html 5 Feb 2015 13:52:05 -   1.78
> +++ htdocs/gcc-5/changes.html 6 Feb 2015 08:20:50 -
> @@ -237,6 +237,10 @@ calloc (size_t x, size_t y)
>   -Wno-discarded-qualifiers.
>  The C front end now generates more precise caret diagnostics.
>  The -pg option now only affects the current file in a LTO build.
> +The C front end can now also be build as library, which is for 
> instance
> + used by  +
> href="https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gdb/NEWS;hb=gdb-7.9-branch";
> + >gdb 7.9 for compiling source code used for code injection.
>
>  
>  C++


Jakub

RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Matthew Fortune]

Maciej W. Rozycki  writes:
> On Thu, 5 Feb 2015, Matthew Fortune wrote:
> 
> > I'm OK with this change but I'd like Catherine to comment before
> committing.
> > It seems a shame to duplicate the block of code but it is probably just
> as
> > ugly to define a macro for the la/dla instruction.
> 
>  Native systems have  for such ABI dependencies, including
> stuff to set up $gp.  Perhaps we could reuse these bits, the licence I
> think allows us to.

That's a good idea. Perhaps I should take that on as part of some cleanup
of the MIPS backend in the next stage1. I'm looking to rework how the
ISA_HAS logic works so perhaps there would be value in doing this mostly in
a header that can also be used for assembly programmers. That would naturally
mean we get all the other nice assembly macros available in the backend of
GCC too.

Thanks,
Matthew

RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Maciej W. Rozycki]

On Thu, 5 Feb 2015, Matthew Fortune wrote:

> I'm OK with this change but I'd like Catherine to comment before committing.
> It seems a shame to duplicate the block of code but it is probably just as
> ugly to define a macro for the la/dla instruction.

 Native systems have  for such ABI dependencies, including 
stuff to set up $gp.  Perhaps we could reuse these bits, the licence I 
think allows us to.

  Maciej

RE: [MIPS] fix CRT_CALL_STATIC_FUNCTION macro

[Maciej W. Rozycki]

On Thu, 5 Feb 2015, Petar Jovanovic wrote:

> > > This is a follow-up to a change [1] in glibc. It fixes the issue [2] 
> > > when jal can not reach a target in different region.
> > Is it not a problem that can be solved with rearranging the order of
> sections in output?
> 
> Is not this more clean solution to it? Otherwise we need to make sure that
> __do_global_ctors_aux and call to it from _init () are in the same region.

 I think you're right, JAL is not a PC-relative jump, so whether the 
target is in range or not will depend solely on the load address of the 
executable rather than the distance between a jump and its target.

 I also think it's best to include such observations right away along a 
patch submission so that reviewers do not have to wonder if the problem 
has been well understood and alternatives considered in cases like here 
where you clearly cause performance loss and code size growth.

 I have no further comments on your change; while I cannot approve it v2 
looks reasonable to me.  Thanks for your submission.

  Maciej

Re: [Patch, WWWDOCS] gcc-5/changes.html: Mention that C FE can be build as libcc1.so

[James Greenhalgh]

On Fri, Feb 06, 2015 at 09:44:20AM +, Tobias Burnus wrote:
> I think it is useful to know that one can build libcc1.so - also as
> advertisement. Thus, I propose to include something like the quip in
> the attachment.
> 
> GDB uses it in version 7.9, which is not yet released but already
> branched off.
> 
> OK?  - Other suggestions or comments?
> 
> 
> Tobias

> Index: htdocs/gcc-5/changes.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
> retrieving revision 1.78
> diff -u -p -r1.78 changes.html
> --- htdocs/gcc-5/changes.html 5 Feb 2015 13:52:05 -   1.78
> +++ htdocs/gcc-5/changes.html 6 Feb 2015 08:20:50 -
> @@ -237,6 +237,10 @@ calloc (size_t x, size_t y)
>   -Wno-discarded-qualifiers.
>  The C front end now generates more precise caret diagnostics.
>  The -pg option now only affects the current file in a LTO build.
> +The C front end can now also be build as library, which is for 
> instance
> + used by  +
> href="https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gdb/NEWS;hb=gdb-7.9-branch";
> + >gdb 7.9 for compiling source code used for code injection.

Sorry to meddle, but how about:

  The C front end can now be built and used as a library (libcc1.so).
  This will be used by GDB 7.9 to compile source code
  used for code injection.

Thanks,
James

[Patch, WWWDOCS] gcc-5/changes.html: Mention that C FE can be build as libcc1.so

[Tobias Burnus]

I think it is useful to know that one can build libcc1.so - also as
advertisement. Thus, I propose to include something like the quip in
the attachment.

GDB uses it in version 7.9, which is not yet released but already
branched off.

OK?  - Other suggestions or comments?


Tobias
Index: htdocs/gcc-5/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.78
diff -u -p -r1.78 changes.html
--- htdocs/gcc-5/changes.html	5 Feb 2015 13:52:05 -	1.78
+++ htdocs/gcc-5/changes.html	6 Feb 2015 08:20:50 -
@@ -237,6 +237,10 @@ calloc (size_t x, size_t y)
 	-Wno-discarded-qualifiers.
 The C front end now generates more precise caret diagnostics.
 The -pg option now only affects the current file in a LTO build.
+The C front end can now also be build as library, which is for instance
+	used by https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gdb/NEWS;hb=gdb-7.9-branch";
+	>gdb 7.9 for compiling source code used for code injection.
   
 
 C++

[PATCH] libssp should not use /dev/random on Windows

[Georg Koppen]

Hi,

inline is a patch to avoid using /dev/random on Windows in ssp.c. If it
is getting used there might be a local malicious process supplying fake
random values (e.g. via C:\dev\random) rendering SSP useless.

Comments/review are much appreciated. The patch is against the 4.9 branch:

From 372698ef051b776cc30e9ebd2aac7291c19ff506 Mon Sep 17 00:00:00 2001
From: Erinn Clark 
Date: Wed, 12 Mar 2014 16:09:10 +0100
Subject: [PATCH] Don't use /dev/random on Windows, because it is not a
thing.
 Apart from that some process might be able to supply fake
 random data with e.g. c:\dev\urandom rendering SSP useless.

This patch was written by skruffy, thanks!
---
 libssp/ssp.c |   16 
 1 file changed, 16 insertions(+)

diff --git a/libssp/ssp.c b/libssp/ssp.c
index 96adf17..38e3ec8 100644
--- a/libssp/ssp.c
+++ b/libssp/ssp.c
@@ -55,6 +55,7 @@ see the files COPYING3 and COPYING.RUNTIME
respectively.  If not, see
 /* Native win32 apps don't know about /dev/tty but can print directly
to the console using  "CONOUT$"   */
 #if defined (_WIN32) && !defined (__CYGWIN__)
+#include 
 # define _PATH_TTY "CONOUT$"
 #else
 # define _PATH_TTY "/dev/tty"
@@ -75,6 +76,20 @@ __guard_setup (void)
   if (__stack_chk_guard != 0)
 return;

+#if defined (_WIN32) && !defined (__CYGWIN__)
+  HCRYPTPROV hprovider = 0;
+  if (CryptAcquireContext(&hprovider, NULL, NULL, PROV_RSA_FULL,
+  CRYPT_VERIFYCONTEXT | CRYPT_SILENT))
+{
+  if (CryptGenRandom(hprovider, sizeof (__stack_chk_guard),
+  (BYTE *)&__stack_chk_guard) &&  __stack_chk_guard != 0)
+{
+   CryptReleaseContext(hprovider, 0);
+   return;
+}
+  CryptReleaseContext(hprovider, 0);
+}
+#else
   fd = open ("/dev/urandom", O_RDONLY);
   if (fd != -1)
 {
@@ -85,6 +100,7 @@ __guard_setup (void)
 return;
 }

+#endif
   /* If a random generator can't be used, the protector switches the guard
  to the "terminator canary".  */
   p = (unsigned char *) &__stack_chk_guard;
-- 
1.7.10.4

Georg



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Fix DECL_ABSTRACT_P/BLOCK_ABSTRACT handling in dwarf2out.c (PR middle-end/64937)

[Jakub Jelinek]

On Fri, Feb 06, 2015 at 09:44:40AM +0100, Richard Biener wrote:
> Looks good to me. I wonder if this will also help Aldyh...
> 
> I also wonder what it takes to make dwarf2out use DECL_ABSTRACT_P ||
> force_abstract with maintaining that new state and whether that would be
> both cheaper and cleaner?

I think that wouldn't be so easy, because we don't make DECL_ABSTRACT_P
all decls we see.  In particular we leave out e.g. externs, and handle
differently some non-localized vars. vs. local ones.  I think a global flag
couldn't handle this.

Jakub

Re: [PATCH] Fix DECL_ABSTRACT_P/BLOCK_ABSTRACT handling in dwarf2out.c (PR middle-end/64937)

[Richard Biener]

On February 5, 2015 4:42:50 PM CET, Jakub Jelinek  wrote:
>Hi!
>
>On the following testcase we fail -fcompare-debug, because in .LASAN0
>initializer we get a NOP_EXPR optimized away only in one of the cases.
>The reason is that cgraph* is looking at DECL_ABSTRACT_P flag of
>__PRETTY_FUNCTION__ and that flag is different between -g and -g0.
>The DECL_ABSTRACT_P is normally set by the FE on some decls (common to
>-g
>and -g0), but then dwarf2out_abstract_function can set/reset it in a
>weird
>way, leaving it in different state from what it has been in initially.
>
>The dwarf2out.c code pretty much assumes that if some decl is
>DECL_ABSTRACT_P, then all the blocks in it and all the VAR_DECLs in
>BLOCK_VARS and parameters etc. will necessarily be equal to that, but
>that
>is usually not the case.
>
>So, this patch changes it, so that it always reverts it to the original
>state (temporarily it is set as before).
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, additionally
>I've
>checked the debug info of cc1* and various *.so* libraries created
>during
>gcc bootstrap and the patch doesn't result in any debug info
>differences.
>Ok for trunk?

Looks good to me. I wonder if this will also help Aldyh...

I also wonder what it takes to make dwarf2out use DECL_ABSTRACT_P || 
force_abstract with maintaining that new state and whether that would be both 
cheaper and cleaner?

Thanks,
Richard.

>2015-02-05  Jakub Jelinek  
>
>   PR middle-end/64937
>   * dwarf2out.c (set_block_abstract_flags, set_decl_abstract_flags):
>   Replace setting argument with abstract_vec, always set BLOCK_ABSTRACT
>   or DECL_ABSTRACT_P flags to 1 rather than to setting, and if it wasn't
>   1 before, push it to abstract_vec.
>   (dwarf2out_abstract_function): Adjust caller.  Don't call
>   set_decl_abstract_flags second time, instead clear BLOCK_ABSTRACT or
>   DECL_ABSTRACT_P flags for all abstract_vec elts.
>
>   * g++.dg/asan/pr64937.C: New test.
>
>--- gcc/dwarf2out.c.jj 2015-02-04 23:36:33.0 +0100
>+++ gcc/dwarf2out.c2015-02-05 13:19:41.401748148 +0100
>@@ -18062,7 +18062,7 @@ gen_type_die_for_member (tree type, tree
>/* Forward declare these functions, because they are mutually recursive
>   with their set_block_* pairing functions.  */
> static void set_decl_origin_self (tree);
>-static void set_decl_abstract_flags (tree, int);
>+static void set_decl_abstract_flags (tree, vec &);
> 
>/* Given a pointer to some BLOCK node, if the BLOCK_ABSTRACT_ORIGIN for
>the
>given BLOCK node is NULL, set the BLOCK_ABSTRACT_ORIGIN for the node so
>@@ -18135,59 +18135,72 @@ set_decl_origin_self (tree decl)
> }
> }
> >
>-/* Given a pointer to some BLOCK node, and a boolean value to set the
>-   "abstract" flags to, set that value into the BLOCK_ABSTRACT flag
>for
>-   the given block, and for all local decls and all local sub-blocks
>-   (recursively) which are contained therein.  */
>+/* Given a pointer to some BLOCK node, set the BLOCK_ABSTRACT flag to
>1
>+   and if it wasn't 1 before, push it to abstract_vec vector.
>+   For all local decls and all local sub-blocks (recursively) do it
>+   too.  */
> 
> static void
>-set_block_abstract_flags (tree stmt, int setting)
>+set_block_abstract_flags (tree stmt, vec &abstract_vec)
> {
>   tree local_decl;
>   tree subblock;
>   unsigned int i;
> 
>-  BLOCK_ABSTRACT (stmt) = setting;
>+  if (!BLOCK_ABSTRACT (stmt))
>+{
>+  abstract_vec.safe_push (stmt);
>+  BLOCK_ABSTRACT (stmt) = 1;
>+}
> 
>   for (local_decl = BLOCK_VARS (stmt);
>local_decl != NULL_TREE;
>local_decl = DECL_CHAIN (local_decl))
> if (! DECL_EXTERNAL (local_decl))
>-  set_decl_abstract_flags (local_decl, setting);
>+  set_decl_abstract_flags (local_decl, abstract_vec);
> 
>   for (i = 0; i < BLOCK_NUM_NONLOCALIZED_VARS (stmt); i++)
> {
>   local_decl = BLOCK_NONLOCALIZED_VAR (stmt, i);
>  if ((TREE_CODE (local_decl) == VAR_DECL && !TREE_STATIC (local_decl))
> || TREE_CODE (local_decl) == PARM_DECL)
>-  set_decl_abstract_flags (local_decl, setting);
>+  set_decl_abstract_flags (local_decl, abstract_vec);
> }
> 
>   for (subblock = BLOCK_SUBBLOCKS (stmt);
>subblock != NULL_TREE;
>subblock = BLOCK_CHAIN (subblock))
>-set_block_abstract_flags (subblock, setting);
>+set_block_abstract_flags (subblock, abstract_vec);
> }
> 
>-/* Given a pointer to some ..._DECL node, and a boolean value to set
>the
>-   "abstract" flags to, set that value into the DECL_ABSTRACT_P flag
>for the
>-   given decl, and (in the case where the decl is a FUNCTION_DECL)
>also
>-   set the abstract flags for all of the parameters, local vars, local
>-   blocks and sub-blocks (recursively) to the same setting.  */
>+/* Given a pointer to some ..._DECL node, set DECL_ABSTRACT_P flag on
>it
>+   to 1 and if it wasn't 1 before, push to abstract_vec vector.
>+   In the case where the decl is a FUNCTION_DECL also set the ab

Re: [PATCH]Keep location info when expand complex component-wise load/store.

[Andrew Pinski]

On Thu, Feb 5, 2015 at 3:22 AM, Renlin Li  wrote:
> Hi all,
>
> location information is missing when rewrite complex component-wise
> load/store.
>
> This patch add the location info to fix the recently gcc.dg/uninit-13.c and
> gcc.dg/uninit-17.c failures on arm target. The compiler warns uninitialised
> usage at the variable's declaration location instead of the place where it's
> used, because the location information is missing when the rtx is rewritten.
>
> arm-none-eabi test Okay, x86-64 native bootstrap Okay.
> Okay for trunk?
>
> gcc/ChangeLog:
>
> 2015-02-05  Renlin Li 
>
> * tree-ssa-forwprop.c (execute): Keep location info while rewrite
> complex rtx.
> * tree-ssa.c (execute_update_addresses_taken): Likewise.


s/rtx/gimple/ :)

Thanks,
Andrew

Re: [patch, doc] copy-edit inline asm sections

[Jeff Law]

On 02/05/15 10:13, Sandra Loosemore wrote:

It looks to me like that, when the rewrite of the inline asm sections
was committed last May (r210273), there was general agreement that it
needed additional copy-editing to fix markup problems and the like. But,
nobody ever followed up to do that.

Here's my attempt.  In addition to fixing markup and capitalization,
I've moved things around a little bit to improve the flow, and rephrased
a few things that I thought were awkward or confusing.  I propose to
commit this in a few days unless somebody tells me meanwhile that I've
broken something  there's no doubt a lot more that could be done to
improve this section further, but I hope this is at least an incremental
improvement.

-Sandra


2015-02-05  Sandra Loosemore  

 gcc/
 * doc/extend.texi (Function Attributes [naked]): Copy-edit.
 (Using Assembly Language with C): Expand introduction.
 (Basic Asm): Copy-edit.
 (Extended Asm): Likewise.
 (Global Reg Vars): Likewise.
 (Local Reg Vars): Likewise.

OK.
jeff

Re: [PATCH] Fix PR ipa/64858

[Jeff Law]

On 01/30/15 05:29, Martin Liška wrote:

Hi.

Attached patch handles situation where remove_unreachable_nodes is
called before
IPA ICF registers removal hooks. As a result, a deleted callgraph node
is touched.

Tested on x86_64-linux-pc without a new regression seen.
Ready for trunk?

Thanks,
Martin

0001-IPA-ICF-Fix-late-initialization-of-callgraph-hooks.patch


 From 3be6518536de93b9e5397a4f65cb7e07422efbbb Mon Sep 17 00:00:00 2001
From: mliska
Date: Fri, 30 Jan 2015 12:25:22 +0100
Subject: [PATCH] IPA ICF: Fix late initialization of callgraph hooks.

gcc/testsuite/ChangeLog:

2015-01-30  Martin Liska

* g++.dg/ipa/pr64858.C: New test.

gcc/ChangeLog:

2015-01-30  Martin Liska

* ipa-icf.c (sem_item_optimizer::register_hooks): Register hooks
just if not yet registered.
(ipa_icf_generate_summary): Register callgraph hooks.

OK.
jeff