Re: [PATCH] Fix assembler arguments for -m16

[Andreas Tobler]

On 06.11.16 21:38, Uros Bizjak wrote:

On Sun, Nov 6, 2016 at 5:48 PM, Gerald Pfeifer  wrote:

It appears this got stuck.

Uros, is this okay?  I can handle the commit if you approve.


Looks good to me, so OK if tested on non-glibc system.



Results w/o patch:
https://gcc.gnu.org/ml/gcc-testresults/2016-11/msg00627.html

Results with patch:
https://gcc.gnu.org/ml/gcc-testresults/2016-11/msg00672.html

Andreas


Thanks,
Uros.


Gerald

On Wed, 6 Jul 2016, Roger Pau Monne wrote:

At the moment the -m16 option only passes the "--32" parameter to the
assembler on glibc OSes, while on other OSes the assembler is called without
any specific flag. This is wrong and causes the assembler to fail. Fix it
by adding support for the -m16 option to x86-64.h.

2016-07-06  Roger Pau Monné  

  * x86-64.h: append --32 to the assembler options when -m16 is used
  even on non-glibc OSes.

---
Cc: h...@gcc.gnu.org
Cc: ger...@freebsd.org
---
This should be backported to all stable branches up to 4.9 (when -m16 was
introduced).

Please keep me on Cc since I'm not subscribed to the list, thanks.
---
 gcc/config/i386/x86-64.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/i386/x86-64.h b/gcc/config/i386/x86-64.h
index b0bf835..9e6c6eb 100644
--- a/gcc/config/i386/x86-64.h
+++ b/gcc/config/i386/x86-64.h
@@ -49,7 +49,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 #define WCHAR_TYPE_SIZE 32

 #undef ASM_SPEC
-#define ASM_SPEC "%{m32:--32} %{m64:--64} %{mx32:--x32}"
+#define ASM_SPEC "%{m16|m32:--32} %{m64:--64} %{mx32:--x32}"

 #undef ASM_OUTPUT_ALIGNED_BSS
 #define ASM_OUTPUT_ALIGNED_BSS(FILE, DECL, NAME, SIZE, ALIGN) \

Re: [PATCH] enhance buffer overflow warnings (and c/53562)

[Martin Sebor]

But obviously not all levels of the warning can/should be enabled
with -Wall/-Werror.  There are cases which are worth warning by default
(the case where we want to inform the user if you reach this stmt,
you'll get your program killed (will call __chk_fail)) is something
that ought like before be enabled by default; can have a warning
switch users can disable.
Then there is the case where there is a sure buffer overflow (not using
-D_FORTIFY_SOURCE, but still __bos (, 0) tells the buffer is too short,
and it is unconditional (no tricks with PHIs where one path has short
and another part has long size).  This is something that is useful
in -Wall.
The rest I'm very doubtful about even for -Wextra.


I've posted an updated patch that disables the warning for the cases
you were concerned about but I want to respond these two points.

GCC issues a number of different kinds of warnings under -Wall and
-Wextra for constructs that are strictly safe but that have been
known to cause bugs down the line.  Those warnings are helpful even
if some of their instances could be considered false positives.
I think the same is even more true for warnings that help detect
defects as serious as buffer overflows.


One thing is that for useful warnings users have to be able to do something
to quiet them.  For -Wmisleading-indentation you indent your code properly,
for -Wimplicit-fallthrough you add attributes or comments, etc.
But I really don't know what you want people to do to tell the compiler
the warning is a false positive.  Add asm ("" : "+g" (ptr)); to hide
everything from the compiler?  Too ugly, too unportable, pessimizing correct
code.


That's a valid question to ask.  There are a few portable ways to
suppress these warnings.  The latest patch doesn't warn on the
examples you posted above anymore but here's one where it does
warn where  _FORTIIFY_SOURCE did not before the patch.  The example
shows the code that triggers the warning (in function f) and how
the warning can be suppressed (in function g).

The code in f is questionable (and, in my view, would be even if
it called memcpy instead) and suggests that the programmer may
have made a mistake.  If the intent is to copy the string over
the whole struct then it's better written as in g (though using
memcpy would be more appropriate).

$ cat b.c && gcc -O2 -S -Wall -Wextra b.c
extern char* strcpy (char*, const char*);

const char* const s0 = "1234";
const char* const s1 = "12345";

struct S { char a[4]; char b[4]; };

void f (struct S *s, _Bool i)
{
   strcpy (s->a, i ? s1 : s0);
}

void g (struct S *s, _Bool i)
{
   strcpy ((char*)s, i ? s1 : s0);
}

b.c: In function ‘f’:
b.c:10:3: warning: strcpy writing 5 bytes into a region of size 4 
overflows the destination [-Wstringop-overflow=]

strcpy (s->a, i ? s1 : s0);
^~

Martin

Re: [PATCH, Darwin] Fix PR57438 by avoiding empty function bodies and trailing labels.

[Segher Boessenkool]

Hi Iain,

On Sun, Nov 06, 2016 at 12:13:16PM -0800, Iain Sandoe wrote:
> 2016-11-06  Iain Sandoe  
> 
>   PR target/57438
>   * config/i386/i386.c (ix86_code_end): Note that we emitted code where 
> the
>   function might otherwise appear empty for picbase thunks.
>   (ix86_output_function_epilogue): If we find a zero-sized function 
> assume that
>   reaching it is UB and trap.  If we find a trailing label append a nop.
>   * config/rs6000/rs6000.c (rs6000_output_function_epilogue): If we find
>   a zero-sized function assume that reaching it is UB and trap.  If we 
> find a
>   trailing label, append a nop.

These lines are too long.

> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index b0d2b64..326e2e9 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -30148,11 +30148,16 @@ rs6000_output_function_epilogue (FILE *file,
>  {
>  #if TARGET_MACHO
>macho_branch_islands ();
> -  /* Mach-O doesn't support labels at the end of objects, so if
> - it looks like we might want one, insert a NOP.  */
> +
> +  if (TARGET_MACHO)

Both #if and if?

> +/* Mach-O doesn't support labels at the end of objects, so if
> +   it looks like we might want one, take special action.
> +
> +   First, collect any sequence deleted debug labels.  */

"sequence of".

> +/* If we have:
> +   label:
> +  barrier
> +   That need to be guarded.  */

"then this needs to be guarded.", or similar?

> +/* up to now we've only seen notes or barriers.  */

Sentences start with a capital letter.

> + /* See if have a completely empty function body.  */

"we have"

> + while (insn && ! INSN_P (insn))
> +   insn = PREV_INSN (insn);
> + /* If we don't find any, we've got an empty function body; i.e.

"any insn"?

> +completely empty - without a return or branch.  GCC declares
> +that reaching __builtin_unreachable() means UB (but we want
> +finite-sized function bodies; to help the user out, let's trap
> +the case.  */

Zero is finite size; "non-empty function bodies"?

The rs6000 code looks fine, thanks; but please work on the text a bit :-)


Segher

[patch, fortran, committed] Fill in location in build_loc_call

[Thomas Koenig]

Hello world,

I have committed the attached patch as obvious and simple.
No test case because I don't have one :-)

I am planning some more work on the PR tracking these issues,
PR 78226.

Regards

Thomas

2016-11-06  Thomas Koenig  

PR fortran/78226
resolve.c (build_loc_call): Add location to return value.
Index: resolve.c
===
--- resolve.c	(Revision 241747)
+++ resolve.c	(Arbeitskopie)
@@ -8496,6 +8496,7 @@ build_loc_call (gfc_expr *sym_expr)
   loc_call->value.function.isym = gfc_intrinsic_function_by_id (GFC_ISYM_LOC);
   loc_call->value.function.actual = gfc_get_actual_arglist ();
   loc_call->value.function.actual->expr = sym_expr;
+  loc_call->where = sym_expr->where;
   return loc_call;
 }
 

New Spanish PO file for 'gcc' (version 6.2.0)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

http://translationproject.org/latest/gcc/es.po

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

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

[PATCH, Darwin] fix for PR67710 : Update 'as' specs and inputs to handle newer assembler versions.

[Iain Sandoe]

Hi Folks,

This is an updated solution, but on a patch from Rainer Orth (attached to 
pr67710).

A/ Newer versions of ld64 check the min_version command, and newer versions of 
the system assembler inserts this in response to "-mmacosx-version-min=" on the 
assembler line.
Unless one makes sensible versions, some object is bound to conflict.

B/ Additionally, there's a difference in behaviour between "as" and "ld" when 
presented with xx.yy.zz (ld truncates to xx.yy, as doesn't); net result is that 
one needs to pass a truncated version to "as".

So (if the assembler supports minversion commands)
(a) provide a truncated minversion (as asm_macosx_version_min, which is a 
driver-only var).
(b) pass this to "as"
(c) Update tests to determine 'HAVE_AS_MMACOSX_VERSION_MIN_OPTION' (Rainer's 
patch)
(d) For some reason the testcases are "run" (it's not obvious they need to be, 
they are checking compile-time issues)
  - anyway, to preserve the status quo, I've left them as exec.  However, the 
minimum version that can be code-gened
   for is target-dependent (there are no x86 versions before 10.4, for 
example).  To avoid conflicts where the "as" is assuming some minimum, I've set 
the testversion to 10.5 (which is supported by all the archs we have)
(e) We need to ensure that libgcc and crts are generated with a sufficiently 
old minversion not to conflict.

OK for trunk?
OK for open branches?
Iain

gcc/

2016-11-06  Iain Sandoe  
Rainer Orth  

target/PR67710
* config.in: Regenerate
* config/darwin-driver.c (darwin_driver_init): Emit a version string 
for the assembler.
* config/darwin.h(ASM_MMACOSX_VERSION_MIN_SPEC): New, new tests.
* config/darwin.opt(asm_macosx_version_min): New.
* config/i386/darwin.h: Handle ASM_MMACOSX_VERSION_MIN_SPEC.
* configure: Regenerate
* configure.ac: Check for mmacosx-version-min handling.

gcc/testsuite/

2016-11-06  Iain Sandoe  
Rainer Orth  

target/PR67710
*  gcc.dg/darwin-minversion-1.c: Update min version check.
*  gcc.dg/darwin-minversion-2.c: Likewise.
*  gcc.dg/darwin-minversion-3.c: Likewise.

libgcc/

2016-11-06  Iain Sandoe  
Rainer Orth  

target/PR67710
*  libgcc/config/t-darwin: Default builds to 10.5 codegen.


---
 gcc/config.in  |  7 ++
 gcc/config/darwin-driver.c | 28 -
 gcc/config/darwin.h| 21 ++--
 gcc/config/darwin.opt  |  3 +++
 gcc/config/i386/darwin.h   |  5 ++--
 gcc/configure  | 39 ++
 gcc/configure.ac   | 14 +++
 gcc/testsuite/gcc.dg/darwin-minversion-1.c |  4 +--
 gcc/testsuite/gcc.dg/darwin-minversion-2.c |  4 +--
 gcc/testsuite/gcc.dg/darwin-minversion-3.c |  4 +--
 libgcc/config/t-darwin |  4 +++
 11 files changed, 122 insertions(+), 11 deletions(-)

diff --git a/gcc/config/darwin-driver.c b/gcc/config/darwin-driver.c
index db8d72c..f80c9ed 100644
--- a/gcc/config/darwin-driver.c
+++ b/gcc/config/darwin-driver.c
@@ -73,7 +73,8 @@ darwin_find_version_from_kernel (void)
  component.  */
   if (major_vers - 4 <= 4)
 /* On 10.4 and earlier, the old linker is used which does not
-   support three-component system versions.  */
+   support three-component system versions.
+   FIXME: we should not assume this - a newer linker could be used.  */
 asprintf (_flag, "10.%d", major_vers - 4);
   else
 asprintf (_flag, "10.%d.%s", major_vers - 4, minor_vers);
@@ -294,4 +295,29 @@ darwin_driver_init (unsigned int *decoded_options_count,
  &(*decoded_options)[*decoded_options_count - 1]);
}
 }
+  /* Create and push the major version for assemblers that need it.  */
+  if (vers_string != NULL)
+{
+  char *asm_major = NULL;
+  char *first_period = strchr(vers_string, '.');
+  if (first_period != NULL)
+   {
+ char *second_period = strchr(first_period+1, '.');
+ if (second_period  != NULL)
+   asm_major = xstrndup (vers_string, second_period-vers_string);
+ else
+   asm_major = xstrdup (vers_string);
+}
+  /* Else we appear to have a weird macosx version with no major number.
+ Punt on this for now.  */
+  if (asm_major != NULL)
+{
+ ++*decoded_options_count;
+ *decoded_options = XRESIZEVEC (struct cl_decoded_option,
+*decoded_options,
+*decoded_options_count);
+ generate_option (OPT_asm_macosx_version_min_, asm_major, 1, CL_DRIVER,
+ 

Re: [PATCH fix PR71767 3/4 : Darwin sections] Fix PR71767 - adjust the sections used in response to ld64 version.

[Uros Bizjak]

On Sun, Nov 6, 2016 at 8:40 PM, Iain Sandoe  wrote:
> Hi Folks,
>
> (much) Older Darwin linkers needed separate sections marked "coalesce" to
> allow for weak symbol coalescing.  This has not been needed for some time
> and is now deprecated, newer assemblers warn if the old coalesced sections
> are used.  We need to switch to using the regular sections when a new enough 
> linker is available.
>
> There’s a small change to i386.c to make it possible to switch thunk output 
> between coalesced and “regular’ sections in response to the relevant linker 
> info.

Anything protected by "#if TARGET_MACHO" can be considered as Darwin
specific patch and thus under Darwin port maintainer's approval.

Uros.

> OK for trunk?
> OK for open branches?
> Iain
>
> gcc/
>
> 2016-11-06  Iain Sandoe  
>
>PR target/71767
> * config/darwin-sections.def (picbase_thunk_section): New.
> * config/darwin.c (darwin_init_sections): Set up picbase thunk 
> section.
> (darwin_rodata_section, darwin_objc2_section, machopic_select_section,
> darwin_asm_declare_constant_name, darwin_emit_weak_or_comdat,
> darwin_function_section): Don’t use coalesced with newer linkers.
> (darwin_override_options): Decide on usage of coalesed sections on the
> basis of the target linker version.
> * config/darwin.h (MIN_LD64_NO_COAL_SECTS): New.
> * config/darwin.opt  (mtarget-linker): New.
> * config/i386/i386.c (ix86_code_end): Do not force the thunks into a 
> coalesced
> section, instead use a thunks section.
>
>
> ---
>  gcc/config/darwin-sections.def |  5 +++
>  gcc/config/darwin.c| 77 
> +++---
>  gcc/config/darwin.h|  5 +++
>  gcc/config/darwin.opt  |  6 
>  gcc/config/i386/i386.c |  2 +-
>  5 files changed, 67 insertions(+), 28 deletions(-)
>
> diff --git a/gcc/config/darwin-sections.def b/gcc/config/darwin-sections.def
> index cbf3e41..8a7e985 100644
> --- a/gcc/config/darwin-sections.def
> +++ b/gcc/config/darwin-sections.def
> @@ -31,6 +31,11 @@ along with GCC; see the file COPYING3.  If not see
>  DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR,
>  ".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0)
>
> +/* We define a picbase thunks section separately, so that we can override the
> +   def to be '.text' for versions of ld64 that handle coalescing.  */
> +DEF_SECTION (picbase_thunk_section, SECTION_CODE|SECTION_NO_ANCHOR,
> +".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0)
> +
>  DEF_SECTION (text_hot_section, SECTION_CODE,
>  ".section __TEXT,__text_hot,regular,pure_instructions", 0)
>  DEF_SECTION (text_cold_section, SECTION_CODE,
> diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
> index 210c2da..baca46c 100644
> --- a/gcc/config/darwin.c
> +++ b/gcc/config/darwin.c
> @@ -97,6 +97,10 @@ int darwin_running_cxx;
>  /* Some code-gen now depends on OS major version numbers (at least).  */
>  int generating_for_darwin_version ;
>
> +/* For older linkers we need to emit special sections (marked 'coalesced') 
> for
> +   for weak or single-definition items.  */
> +static bool ld_uses_coal_sects = false;
> +
>  /* Section names.  */
>  section * darwin_sections[NUM_DARWIN_SECTIONS];
>
> @@ -220,6 +224,11 @@ darwin_init_sections (void)
>readonly_data_section = darwin_sections[const_section];
>exception_section = darwin_sections[darwin_exception_section];
>eh_frame_section = darwin_sections[darwin_eh_frame_section];
> +
> +  /* If our linker is new enough to coalesce weak symbols, then we
> + can just put picbase_thunks into the text section.  */
> +  if (! ld_uses_coal_sects )
> +darwin_sections[picbase_thunk_section] = text_section;
>  }
>
>  int
> @@ -1247,9 +1256,9 @@ darwin_mark_decl_preserved (const char *name)
>  }
>
>  static section *
> -darwin_rodata_section (int weak, bool zsize)
> +darwin_rodata_section (int use_coal, bool zsize)
>  {
> -  return (weak
> +  return (use_coal
>   ? darwin_sections[const_coal_section]
>   : (zsize ? darwin_sections[zobj_const_section]
>: darwin_sections[const_section]));
> @@ -1418,7 +1427,8 @@ darwin_objc2_section (tree decl ATTRIBUTE_UNUSED, tree 
> meta, section * base)
>  return darwin_sections[objc2_image_info_section];
>
>else if (!strncmp (p, "V2_EHTY", 7))
> -return darwin_sections[data_coal_section];
> +return ld_uses_coal_sects ? darwin_sections[data_coal_section]
> +  : data_section;
>
>else if (!strncmp (p, "V2_CSTR", 7))
>  return darwin_sections[objc2_constant_string_object_section];
> @@ -1517,21 +1527,23 @@ machopic_select_section (tree decl,
>  int reloc,
>  unsigned HOST_WIDE_INT align)
>  {
> -  bool zsize, one, weak, ro;
> +  bool 

Re: [PATCH] Fix assembler arguments for -m16

[Uros Bizjak]

On Sun, Nov 6, 2016 at 5:48 PM, Gerald Pfeifer  wrote:
> It appears this got stuck.
>
> Uros, is this okay?  I can handle the commit if you approve.

Looks good to me, so OK if tested on non-glibc system.

Thanks,
Uros.

> Gerald
>
> On Wed, 6 Jul 2016, Roger Pau Monne wrote:
>> At the moment the -m16 option only passes the "--32" parameter to the
>> assembler on glibc OSes, while on other OSes the assembler is called without
>> any specific flag. This is wrong and causes the assembler to fail. Fix it
>> by adding support for the -m16 option to x86-64.h.
>>
>> 2016-07-06  Roger Pau Monné  
>>
>>   * x86-64.h: append --32 to the assembler options when -m16 is used
>>   even on non-glibc OSes.
>>
>> ---
>> Cc: h...@gcc.gnu.org
>> Cc: ger...@freebsd.org
>> ---
>> This should be backported to all stable branches up to 4.9 (when -m16 was
>> introduced).
>>
>> Please keep me on Cc since I'm not subscribed to the list, thanks.
>> ---
>>  gcc/config/i386/x86-64.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/config/i386/x86-64.h b/gcc/config/i386/x86-64.h
>> index b0bf835..9e6c6eb 100644
>> --- a/gcc/config/i386/x86-64.h
>> +++ b/gcc/config/i386/x86-64.h
>> @@ -49,7 +49,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
>> If not, see
>>  #define WCHAR_TYPE_SIZE 32
>>
>>  #undef ASM_SPEC
>> -#define ASM_SPEC "%{m32:--32} %{m64:--64} %{mx32:--x32}"
>> +#define ASM_SPEC "%{m16|m32:--32} %{m64:--64} %{mx32:--x32}"
>>
>>  #undef ASM_OUTPUT_ALIGNED_BSS
>>  #define ASM_OUTPUT_ALIGNED_BSS(FILE, DECL, NAME, SIZE, ALIGN) \

[PATCH, Darwin] Fix PR57438 by avoiding empty function bodies and trailing labels.

[Iain Sandoe]

Hi Folks,

PR57438 has two manifestations - which arise from the same root cause.

A.
Empty function bodies causes two problems for Darwin's linker (i) zero-length 
FDEs and (ii) coincident label addresses that might point to items of differing 
weakness. 

B.
Trailing local labels can be problematic when they end a function because 
similarly they might apparently point to a following weak function, leading to 
the linker concluding that there's a pointer-diff to a weak symbol (which is 
not allowed).

Both conditions arise from __builtin_unreachable() lowering to a barrier and no 
more; GCC defines reaching code marked as unreachable as UB.

The solution for both is to emit some finite amount of code;
  in the case of A a trap is emitted,
  in the case of B a nop.

Both the X86 and PowerPC ports have code that is supposed to solve B, but which 
doesn’t seem to take into account the emitted barrier (I’m guessing output was 
amended after the code was added, and no test-case to catch the regression).

The patch updates the code - and also checks for completely empty functions 
(regardless of absent labels those will create an issue when the frame tables 
are emitted).

x86 has one extra wrinkle over powerpc; we emit pic load thunks, late and 
manually (as direct asm) but not late enough to avoid the code that is 
detecting empty functions - so we need to signal to that code that the function 
is not really “empty” even tho there’s no rtx.

OK for trunk?
OK for open branches?
Iain

gcc/

2016-11-06  Iain Sandoe  

PR target/57438
* config/i386/i386.c (ix86_code_end): Note that we emitted code where 
the
function might otherwise appear empty for picbase thunks.
(ix86_output_function_epilogue): If we find a zero-sized function 
assume that
reaching it is UB and trap.  If we find a trailing label append a nop.
* config/rs6000/rs6000.c (rs6000_output_function_epilogue): If we find
a zero-sized function assume that reaching it is UB and trap.  If we 
find a
trailing label, append a nop.

gcc/testsuite/

2016-11-06  Iain Sandoe  

PR target/57438
* gcc.dg/pr57438-1.c: New.
* gcc.dg/pr57438-2.c: New.


---
 gcc/config/i386/i386.c   |  88 --
 gcc/config/rs6000/rs6000.c   |  43 +++--
 gcc/testsuite/gcc.dg/pr57438-1.c |  15 +++
 gcc/testsuite/gcc.dg/pr57438-2.c | 194 +++
 4 files changed, 306 insertions(+), 34 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/pr57438-1.c
 create mode 100644 gcc/testsuite/gcc.dg/pr57438-2.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 9e9fe02..a60bc69 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -11866,6 +11866,9 @@ ix86_code_end (void)
   current_function_decl = decl;
   allocate_struct_function (decl, false);
   init_function_start (decl);
+  /* We're about to hide the function body from callees of final_* by
+emitting it directly; tell them we're a thunk, if they care.  */
+  cfun->is_thunk = true;
   first_function_block_is_cold = false;
   /* Make sure unwind info is emitted for the thunk if needed.  */
   final_start_function (emit_barrier (), asm_out_file, 1);
@@ -14562,36 +14565,65 @@ ix86_output_function_epilogue (FILE *file 
ATTRIBUTE_UNUSED, HOST_WIDE_INT)
   if (pic_offset_table_rtx
   && !ix86_use_pseudo_pic_reg ())
 SET_REGNO (pic_offset_table_rtx, REAL_PIC_OFFSET_TABLE_REGNUM);
-#if TARGET_MACHO
-  /* Mach-O doesn't support labels at the end of objects, so if
- it looks like we might want one, insert a NOP.  */
-  {
-rtx_insn *insn = get_last_insn ();
-rtx_insn *deleted_debug_label = NULL;
-while (insn
-  && NOTE_P (insn)
-  && NOTE_KIND (insn) != NOTE_INSN_DELETED_LABEL)
-  {
-   /* Don't insert a nop for NOTE_INSN_DELETED_DEBUG_LABEL
-  notes only, instead set their CODE_LABEL_NUMBER to -1,
-  otherwise there would be code generation differences
-  in between -g and -g0.  */
-   if (NOTE_P (insn) && NOTE_KIND (insn) == NOTE_INSN_DELETED_DEBUG_LABEL)
- deleted_debug_label = insn;
+
+  if (TARGET_MACHO)
+{
+  rtx_insn *insn = get_last_insn ();
+  rtx_insn *deleted_debug_label = NULL;
+
+  /* Mach-O doesn't support labels at the end of objects, so if
+ it looks like we might want one, take special action.
+First, Collect any sequence deleted debug labels.  */
+  while (insn
+&& NOTE_P (insn)
+&& NOTE_KIND (insn) != NOTE_INSN_DELETED_LABEL)
+   {
+ /* Don't insert a nop for NOTE_INSN_DELETED_DEBUG_LABEL
+notes only, instead set their CODE_LABEL_NUMBER to -1,
+otherwise there would be code generation differences
+in between -g and -g0.  */
+ if (NOTE_P (insn) && NOTE_KIND (insn)
+  

[PATCH fix PR71767 4/4 : testsuite] Fix testsuite fallout from section and linker sym visibility changes.

[Iain Sandoe]

Hi folks,

As per $SUBJECT.


OK for trunk (after the relevant patches are applied)?
OK for open branches (likewise)?

Iain

gcc/testsuite/

….   Dominique d'Humieres  
   Iain Sandoe  

   PR target/71767

* g++.dg/abi/key2.C: Adjust for changed Darwin sections and 
linker-visible symbols.
* g++.dg/torture/darwin-cfstring-3.C: Likewise.
* gcc.dg/const-uniq-1.c: Likewise.
* gcc.dg/torture/darwin-cfstring-3.c: Likewise.
* gcc.target/i386/pr70799-1.c: Likewise.

---
 gcc/testsuite/g++.dg/abi/key2.C  | 1 +
 gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C | 4 ++--
 gcc/testsuite/gcc.dg/const-uniq-1.c  | 2 +-
 gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c | 4 ++--
 gcc/testsuite/gcc.target/i386/pr70799-1.c| 2 +-
 5 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/g++.dg/abi/key2.C b/gcc/testsuite/g++.dg/abi/key2.C
index 0d1347a..c79b3b2 100644
--- a/gcc/testsuite/g++.dg/abi/key2.C
+++ b/gcc/testsuite/g++.dg/abi/key2.C
@@ -2,6 +2,7 @@
 // PR darwin/25908
 
 // { dg-do compile { target *-*-darwin* } }
+// { dg-options "-mtarget-linker 85.2" }
 // { dg-final { scan-assembler ".globl __ZTV1f\\n  .weak_definition 
__ZTV1f(\\n.section __DATA,__const_coal,coalesced)?\\n .align" } }
 // { dg-final { scan-assembler ".globl __ZTS1f\\n  .weak_definition 
__ZTS1f\\n .section __TEXT,__const_coal,coalesced" } }
 // { dg-final { scan-assembler ".globl __ZTI1f\\n  .weak_definition 
__ZTI1f(\\n.section __DATA,__const_coal,coalesced)?\\n .align" } }
diff --git a/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C 
b/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C
index 2d755ec..ee4b385 100644
--- a/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C
+++ b/gcc/testsuite/g++.dg/torture/darwin-cfstring-3.C
@@ -24,7 +24,7 @@ void foo(void) {
   s0 = s1;
 }
 
-/* { dg-final { scan-assembler "\\.long\[ 
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ 
\\t\]*\\.long\[ \\t\]+LC.*\n\[ \\t\]*\\.long\[ \\t\]+4\n" { target { 
*-*-darwin* && { ! lp64 } } } } } */
-/* { dg-final { scan-assembler "\\.long\[ 
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ 
\\t\]*\\.long\[ \\t\]+LC.*\n\[ \\t\]*\\.long\[ \\t\]+10\n" { target { 
*-*-darwin* && { ! lp64 } } } } } */
+/* { dg-final { scan-assembler "\\.long\[ 
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ 
\\t\]*\\.long\[ \\t\]+\[lL\]C.*\n\[ \\t\]*\\.long\[ \\t\]+4\n" { target { 
*-*-darwin* && { ! lp64 } } } } } */
+/* { dg-final { scan-assembler "\\.long\[ 
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ 
\\t\]*\\.long\[ \\t\]+\[lL\]C.*\n\[ \\t\]*\\.long\[ \\t\]+10\n" { target { 
*-*-darwin* && { ! lp64 } } } } } */
 /* { dg-final { scan-assembler 
".quad\t___CFConstantStringClassReference\n\t.long\t1992\n\t.space 
4\n\t.quad\t.*\n\t.quad\t4\n" { target { *-*-darwin* && {  lp64 } } } } } */
 /* { dg-final { scan-assembler 
".quad\t___CFConstantStringClassReference\n\t.long\t1992\n\t.space 
4\n\t.quad\t.*\n\t.quad\t10\n" { target { *-*-darwin* && {  lp64 } } } } } */
diff --git a/gcc/testsuite/gcc.dg/const-uniq-1.c 
b/gcc/testsuite/gcc.dg/const-uniq-1.c
index 2cb4f8a..0e0718b 100644
--- a/gcc/testsuite/gcc.dg/const-uniq-1.c
+++ b/gcc/testsuite/gcc.dg/const-uniq-1.c
@@ -20,4 +20,4 @@ int lookup2 (int i)
   return a[i+1];
 }
 
-/* { dg-final { scan-tree-dump-times "L\\\$?C\\\.*0" 2 "gimple" } } */
+/* { dg-final { scan-tree-dump-times "\[lL\]\\\$?C\\\.*0" 2 "gimple" } } */
diff --git a/gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c 
b/gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c
index 2d755ec..ee4b385 100644
--- a/gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c
+++ b/gcc/testsuite/gcc.dg/torture/darwin-cfstring-3.c
@@ -24,7 +24,7 @@ void foo(void) {
   s0 = s1;
 }
 
-/* { dg-final { scan-assembler "\\.long\[ 
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ 
\\t\]*\\.long\[ \\t\]+LC.*\n\[ \\t\]*\\.long\[ \\t\]+4\n" { target { 
*-*-darwin* && { ! lp64 } } } } } */
-/* { dg-final { scan-assembler "\\.long\[ 
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ 
\\t\]*\\.long\[ \\t\]+LC.*\n\[ \\t\]*\\.long\[ \\t\]+10\n" { target { 
*-*-darwin* && { ! lp64 } } } } } */
+/* { dg-final { scan-assembler "\\.long\[ 
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ 
\\t\]*\\.long\[ \\t\]+\[lL\]C.*\n\[ \\t\]*\\.long\[ \\t\]+4\n" { target { 
*-*-darwin* && { ! lp64 } } } } } */
+/* { dg-final { scan-assembler "\\.long\[ 
\\t\]+___CFConstantStringClassReference\n\[ \\t\]*\\.long\[ \\t\]+1992\n\[ 
\\t\]*\\.long\[ \\t\]+\[lL\]C.*\n\[ \\t\]*\\.long\[ \\t\]+10\n" { target { 
*-*-darwin* && { ! lp64 } } } } } */
 /* { dg-final { scan-assembler 
".quad\t___CFConstantStringClassReference\n\t.long\t1992\n\t.space 

[PATCH fix PR71767 3/4 : Darwin sections] Fix PR71767 - adjust the sections used in response to ld64 version.

[Iain Sandoe]

Hi Folks,

(much) Older Darwin linkers needed separate sections marked "coalesce" to
allow for weak symbol coalescing.  This has not been needed for some time
and is now deprecated, newer assemblers warn if the old coalesced sections
are used.  We need to switch to using the regular sections when a new enough 
linker is available.

There’s a small change to i386.c to make it possible to switch thunk output 
between coalesced and “regular’ sections in response to the relevant linker 
info.

OK for trunk?
OK for open branches?
Iain

gcc/

2016-11-06  Iain Sandoe  

   PR target/71767
* config/darwin-sections.def (picbase_thunk_section): New.
* config/darwin.c (darwin_init_sections): Set up picbase thunk section.
(darwin_rodata_section, darwin_objc2_section, machopic_select_section,
darwin_asm_declare_constant_name, darwin_emit_weak_or_comdat, 
darwin_function_section): Don’t use coalesced with newer linkers.
(darwin_override_options): Decide on usage of coalesed sections on the
basis of the target linker version.
* config/darwin.h (MIN_LD64_NO_COAL_SECTS): New.
* config/darwin.opt  (mtarget-linker): New.
* config/i386/i386.c (ix86_code_end): Do not force the thunks into a 
coalesced
section, instead use a thunks section.


---
 gcc/config/darwin-sections.def |  5 +++
 gcc/config/darwin.c| 77 +++---
 gcc/config/darwin.h|  5 +++
 gcc/config/darwin.opt  |  6 
 gcc/config/i386/i386.c |  2 +-
 5 files changed, 67 insertions(+), 28 deletions(-)

diff --git a/gcc/config/darwin-sections.def b/gcc/config/darwin-sections.def
index cbf3e41..8a7e985 100644
--- a/gcc/config/darwin-sections.def
+++ b/gcc/config/darwin-sections.def
@@ -31,6 +31,11 @@ along with GCC; see the file COPYING3.  If not see
 DEF_SECTION (text_coal_section, SECTION_CODE|SECTION_NO_ANCHOR,
 ".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0)
 
+/* We define a picbase thunks section separately, so that we can override the
+   def to be '.text' for versions of ld64 that handle coalescing.  */
+DEF_SECTION (picbase_thunk_section, SECTION_CODE|SECTION_NO_ANCHOR,
+".section __TEXT,__textcoal_nt,coalesced,pure_instructions", 0)
+
 DEF_SECTION (text_hot_section, SECTION_CODE,
 ".section __TEXT,__text_hot,regular,pure_instructions", 0)
 DEF_SECTION (text_cold_section, SECTION_CODE,
diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index 210c2da..baca46c 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -97,6 +97,10 @@ int darwin_running_cxx;
 /* Some code-gen now depends on OS major version numbers (at least).  */
 int generating_for_darwin_version ;
 
+/* For older linkers we need to emit special sections (marked 'coalesced') for
+   for weak or single-definition items.  */
+static bool ld_uses_coal_sects = false;
+
 /* Section names.  */
 section * darwin_sections[NUM_DARWIN_SECTIONS];
 
@@ -220,6 +224,11 @@ darwin_init_sections (void)
   readonly_data_section = darwin_sections[const_section];
   exception_section = darwin_sections[darwin_exception_section];
   eh_frame_section = darwin_sections[darwin_eh_frame_section];
+
+  /* If our linker is new enough to coalesce weak symbols, then we
+ can just put picbase_thunks into the text section.  */
+  if (! ld_uses_coal_sects )
+darwin_sections[picbase_thunk_section] = text_section;
 }
 
 int
@@ -1247,9 +1256,9 @@ darwin_mark_decl_preserved (const char *name)
 }
 
 static section *
-darwin_rodata_section (int weak, bool zsize)
+darwin_rodata_section (int use_coal, bool zsize)
 {
-  return (weak
+  return (use_coal
  ? darwin_sections[const_coal_section]
  : (zsize ? darwin_sections[zobj_const_section]
   : darwin_sections[const_section]));
@@ -1418,7 +1427,8 @@ darwin_objc2_section (tree decl ATTRIBUTE_UNUSED, tree 
meta, section * base)
 return darwin_sections[objc2_image_info_section];
 
   else if (!strncmp (p, "V2_EHTY", 7))
-return darwin_sections[data_coal_section];
+return ld_uses_coal_sects ? darwin_sections[data_coal_section]
+  : data_section;
 
   else if (!strncmp (p, "V2_CSTR", 7))
 return darwin_sections[objc2_constant_string_object_section];
@@ -1517,21 +1527,23 @@ machopic_select_section (tree decl,
 int reloc,
 unsigned HOST_WIDE_INT align)
 {
-  bool zsize, one, weak, ro;
+  bool zsize, one, weak, use_coal, ro;
   section *base_section = NULL;
 
   weak = (DECL_P (decl)
  && DECL_WEAK (decl)
  && !lookup_attribute ("weak_import", DECL_ATTRIBUTES (decl)));
 
-  zsize = (DECL_P (decl) 
+  zsize = (DECL_P (decl)
   && (TREE_CODE (decl) == VAR_DECL || TREE_CODE (decl) == CONST_DECL) 
   && tree_to_uhwi (DECL_SIZE_UNIT (decl)) == 0);
 
-  one = DECL_P (decl) 
+  one = DECL_P 

[PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Iain Sandoe]

Hi Folks,

This is an initial patch in a series that converts Darwin's configury to detect 
ld64 features, rather than the current process of hard-coding them on target 
system version.

This adds an option --with-ld64[=version] that allows the configurer to specify 
that the Darwin ld64 linker is in use.  If the version is given then that will 
be used to determine the capabilities of the linker in native and canadian 
crosses.  For Darwin targets this flag will default to "on", since such targets 
require an ld64-compatible linker.

If a DEFAULT_LINKER is set via --with-ld= then this will also be tested to see 
if it is ld64.

The ld64 version is determined (unless overridden by --with-ld64=version) and 
this is exported for use in setting a default value for -mtarget-linker (needed 
for run-time code-gen changes to section choices).

In this initial patch, support for -rdynamic is converted to be detected at 
config time, or by the ld64 version if that is explicitly given (as an example 
of usage).

OK for trunk?
OK for open branches?
Iain

gcc/

2016-11-06  Iain Sandoe  

   PR target/71767
* configure.ac (with-ld64): New arg-with.  gcc_ld64_version: New,
new test.  gcc_cv_ld64_export_dynamic: New, New test.
* configure: Regenerate.
* config.in: Likewise.
* darwin.h: Use LD64_HAS_DYNAMIC export. DEF_LD64: New, define.
* darwin10.h(DEF_LD64): Update for this target version.
* darwin12.h(LINK_GCC_C_SEQUENCE_SPEC): Remove rdynamic test.
(DEF_LD64): Update for this target version.
---
 gcc/config/darwin.h   | 16 ++-
 gcc/config/darwin10.h |  5 
 gcc/config/darwin12.h |  7 -
 gcc/configure.ac  | 74 +++
 4 files changed, 100 insertions(+), 2 deletions(-)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 045f70b..541bcb3 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -165,6 +165,12 @@ extern GTY(()) int darwin_ms_struct;
specifying the handling of options understood by generic Unix
linkers, and for positional arguments like libraries.  */
 
+#if LD64_HAS_EXPORT_DYNAMIC
+#define DARWIN_EXPORT_DYNAMIC " %{rdynamic:-export_dynamic}"
+#else
+#define DARWIN_EXPORT_DYNAMIC " %{rdynamic: %nrdynamic is not supported}"
+#endif
+
 #define LINK_COMMAND_SPEC_A \
"%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
 %(linker)" \
@@ -185,7 +191,9 @@ extern GTY(()) int darwin_ms_struct;
 %{!nostdlib:%{!nodefaultlibs:\
   %{%:sanitize(address): -lasan } \
   %{%:sanitize(undefined): -lubsan } \
-  %(link_ssp) %(link_gcc_c_sequence)\
+  %(link_ssp) \
+  " DARWIN_EXPORT_DYNAMIC " %= 10.6 mmacosx-version-min= -no_compact_unwind) \
-   %{rdynamic:-export_dynamic} %{!static:%{!static-libgcc: \
+   %{!static:%{!static-libgcc: \
   %:version-compare(>= 10.6 mmacosx-version-min= -lSystem) } } \

%{fno-pic|fno-PIC|fno-pie|fno-PIE|fapple-kext|mkernel|static|mdynamic-no-pic: \
   %:version-compare(>= 10.7 mmacosx-version-min= -no_pie) } %G %L"
 
 #undef DEF_MIN_OSX_VERSION
 #define DEF_MIN_OSX_VERSION "10.8"
+
+#ifndef LD64_VERSION
+#undef DEF_LD64
+#define DEF_LD64 "236.4"
+#endif
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 338956f..1783a39 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -274,6 +274,26 @@ AC_ARG_WITH(gnu-ld,
 gnu_ld_flag="$with_gnu_ld",
 gnu_ld_flag=no)
 
+# With ld64; try to support native and canadian crosses by allowing the
+# configurer to specify the minium ld64 version expected.
+AC_ARG_WITH(ld64,
+[AS_HELP_STRING([[--with-ld64[=VERS]]],
+[arrange to work with Darwin's ld64; assume that the version is >= VERS if 
given])],
+[case "${withval}" in
+no | yes)
+ld64_flag="${withval}"
+gcc_cv_ld64_version=
+;;
+*)
+ld64_flag=yes
+gcc_cv_ld64_version="${withval}";;
+esac],
+[gcc_cv_ld64_version=
+case $target in
+*darwin*) ld64_flag=yes;; # Darwin can only use a ld64-compatible linker.
+*) ld64_flag=no;;
+esac])
+
 # With pre-defined ld
 AC_ARG_WITH(ld,
 [AS_HELP_STRING([--with-ld], [arrange to use the specified ld (full 
pathname)])],
@@ -283,6 +303,8 @@ if test x"${DEFAULT_LINKER+set}" = x"set"; then
 AC_MSG_ERROR([cannot execute: $DEFAULT_LINKER: check --with-ld or env. 
var. DEFAULT_LINKER])
   elif $DEFAULT_LINKER -v < /dev/null 2>&1 | grep GNU > /dev/null; then
 gnu_ld_flag=yes
+  elif $DEFAULT_LINKER -v < /dev/null 2>&1 | grep ld64- > /dev/null; then
+ld64_flag=yes
   fi
   AC_DEFINE_UNQUOTED(DEFAULT_LINKER,"$DEFAULT_LINKER",
[Define to enable the use of a default linker.])
@@ -5254,6 +5276,58 @@ AC_DEFINE_UNQUOTED(LD_COMPRESS_DEBUG_OPTION, 
"$gcc_cv_ld_compress_debug_option",
 [Define to the linker option to enable compressed debug sections.])
 AC_MSG_RESULT($gcc_cv_ld_compress_debug)
 
+if test x"$ld64_flag" = x"yes"; then
+
+  # Set defaults for possibly untestable items.
+  

[PATCH fix PR71767 1/4 : ld64 atoms] Make PIC indirections and constant labels linker-visible.

[Iain Sandoe]

Hi Folks,

(in Darwin)  If we have a situation like:

global_weak_symbol:
  
Lnon_weak_local:
  

  ld64 will be unable to split this into two atoms (because the "L" makes
  the second symbol 'invisible').  This means that legitimate direct accesses
  to the second symbol will appear to be non-allowed direct accesses to an
  atom of type weak, global which are not allowed.

  To avoid this, we make the indirections have a leading 'l' (lower-case L)
  which has a special meaning: linker can see this and use it to determine
  atoms, but it is not placed into the final symbol table.

  The implementation here is somewhat heavy-handed in that it will also mark
  indirections to the __IMPORT,__pointers section the same way which is
  really unnecessary, since ld64 _can_ split those into atoms as they are
  fixed size.  FIXME: determine if this is a penalty worth extra code to
  figure out.

Similarly, with:

  .const
weak_global_constant:
  

LCxx:
  ...

 ld64 can't split the second, causing a warning when it's directly
accessed.  We solve this by making the two cases emit a linker-visible symbol 
(where the L becomes ‘l’).

TODO: there are also some cases in Objective-C meta-data that need similar 
treatment, but those need to be caught in the objc runtime lowering.

OK for trunk?
OK for open branches?
Iain

gcc/
2016-11-06  Iain Sandoe  

   PR target/71767
* config/darwin.c (imachopic_indirection_name): Make data section 
indirections
linker-visible.
* config/darwin.h (ASM_GENERATE_INTERNAL_LABEL): Make local constant
labels linker-visible.



---
 gcc/config/darwin.c | 37 +
 gcc/config/darwin.h |  9 -
 2 files changed, 41 insertions(+), 5 deletions(-)

diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index ff8600c..210c2da 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -474,7 +474,31 @@ indirection_hasher::equal (machopic_indirection *s, const 
char *k)
 }
 
 /* Return the name of the non-lazy pointer (if STUB_P is false) or
-   stub (if STUB_B is true) corresponding to the given name.  */
+   stub (if STUB_B is true) corresponding to the given name.
+
+  If we have a situation like:
+
+global_weak_symbol:
+  
+Lnon_weak_local:
+  
+
+  ld64 will be unable to split this into two atoms (because the "L" makes
+  the second symbol 'invisible').  This means that legitimate direct accesses
+  to the second symbol will appear to be non-allowed direct accesses to an
+  atom of type weak, global which are not allowed.
+
+  To avoid this, we make the indirections have a leading 'l' (lower-case L)
+  which has a special meaning: linker can see this and use it to determine
+  atoms, but it is not placed into the final symbol table.
+
+  The implementation here is somewhat heavy-handed in that it will also mark
+  indirections to the __IMPORT,__pointers section the same way which is
+  really unnecessary, since ld64 _can_ split those into atoms as they are
+  fixed size.  FIXME: determine if this is a penalty worth extra code to
+  fix.
+
+*/
 
 const char *
 machopic_indirection_name (rtx sym_ref, bool stub_p)
@@ -485,6 +509,7 @@ machopic_indirection_name (rtx sym_ref, bool stub_p)
   machopic_indirection *p;
   bool needs_quotes;
   const char *suffix;
+  char L_or_l = 'L';
   const char *prefix = user_label_prefix;
   const char *quote = "";
   tree id;
@@ -519,9 +544,13 @@ machopic_indirection_name (rtx sym_ref, bool stub_p)
   if (stub_p)
 suffix = STUB_SUFFIX;
   else
-suffix = NON_LAZY_POINTER_SUFFIX;
+{
+  suffix = NON_LAZY_POINTER_SUFFIX;
+  /* Let the linker see this.  */
+  L_or_l = 'l';
+}
 
-  buffer = XALLOCAVEC (char, strlen ("")
+  buffer = XALLOCAVEC (char, 2  /* strlen ("") or ("") */
   + strlen (prefix)
   + namelen
   + strlen (suffix)
@@ -529,7 +558,7 @@ machopic_indirection_name (rtx sym_ref, bool stub_p)
   + 1 /* '\0' */);
 
   /* Construct the name of the non-lazy pointer or stub.  */
-  sprintf (buffer, "&%sL%s%s%s%s", quote, prefix, name, suffix, quote);
+  sprintf (buffer, "&%s%c%s%s%s%s", quote, L_or_l, prefix, name, suffix, 
quote);
 
   if (!machopic_indirections)
 machopic_indirections = hash_table::create_ggc (37);
diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 98d2382..045f70b 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -716,9 +716,16 @@ extern GTY(()) section * 
darwin_sections[NUM_DARWIN_SECTIONS];
   { "weak_import", 0, 0, true, false, false,\
 darwin_handle_weak_import_attribute, false }
 
+/* Make local constant labels linker-visible, so that if one follows a
+   weak_global constant, ld64 will be able to separate the atoms.  */
 #undef ASM_GENERATE_INTERNAL_LABEL
 #define ASM_GENERATE_INTERNAL_LABEL(LABEL,PREFIX,NUM)  \
-  sprintf (LABEL, "*%s%ld", PREFIX, (long)(NUM))
+  do 

[PATCH fix PR71767 0/4] Background

[Iain Sandoe]

Hi Folks,

Including Jeff on the cc since we were discussing this on Friday (and it’s not 
100% clear who’s reviewing configury patches at present).
Including Uros, because there’s one minor change to i386/i386.c

PR71767 is " Endless stream of warnings when using GCC with -Wa,-q and Clang 
Integrated Assembler”.
** we are talking 40k testsuite fails, so this is a show-stopper for current 
toolchains.

Actually, what’s happened is that recent xcode tools have started to issue a 
warning about deprecated use of a mechanism to support coalesced symbols by 
using separate sections with specific attributes in the (ancient) days before 
the static linker supported them directly.  We need to catch up since 
deprecation will no doubt be followed by removal.

Essentially, now that the linker is capable of dealing with such things, the 
right solution is to emit them into the regular sections and drop the use of 
the coalesced ones.  This has been possible for some time, and Xcode is now 
flagging that it’s time to tidy up and drop the old mechanism.

However,

A. this is only true when the “binutils” (cctools + ld64) are sufficiently new 
to support it.
  - so the solution needs to be made to depend on the version of ld64 in use.

B. more importantly, it reveals some cases where the ld64 atom model*** will be 
violated when symbols are concatenated such that weak globals and non-weak 
locals can be confused.
 - we need to fix this before we can apply A

C. it makes a secondary variant of pr57438 fire more often (when switches 
contain trailing cases with __builtin_unreachable() resulting in trailing local 
symbols with jump-table references, that potentially have the same address as a 
following weak global).  That might seem improbable, but c++ with case 
statements with an unreachable default manage to hit it...
 - I’ll post for this separately, but noting it in passing.



*** The ld64 atom model summary;

Instead of using -ffunction-sections/-fdata-sections, Darwin’s linker has a 
different model of partitioning the input objects such that they might be 
rearranged to minimise displacements, and to identify dead code that may be 
stripped (in a similar manner to —gc-sections).

Input binaries to ld64 are automatically partitioned into “atoms”;
an atom is defined as “a section of code or data beginning with a 
linker-visible symbol and of non-zero size”.

These “atoms” have the properties of their initial symbol and may be rearranged 
and dead-stripped.

— the general problem is that we might have a situation where we have:
 
 visible-global-weak:
 ….

L:
  ….

  pic reference to L 

ld64 will split the object at “visible-global-weak” but it won’t see “L” 
and so the pic reference will appear to point into the visible-global-weak 
atom, [which is not allowed without indirection (to support interposing)].

Of course, that’s a false-positive complaint - but ld64 can’t see the other 
place to split.  

This is solved in other Darwin toolchains by making the “L” into “l” in such 
cases;  lower-case “l” is not hidden by the assembler, and thus the linker can 
see it and split the second section of code into its own ‘non-weak’ atom; 
everyone’s happy.  Of course, we don’t want to do this unnecessarily, since 
it’s inefficient from the PoV of extra symbols.

linker-visible symbols made this way will not be retained in the final linked 
entity (dso or exe).

So:

Patch 1:  implements the changes to modify L => l in the relevant places.

Patch 2: Adds configury to specify or detect that the linker is ld64 (or 
compatible) and to determine its version; there’s a fall-back to allow the 
version to be specified by someone doing a native or Canadian cross.

Patch 3: Is the actual fix that switches the section use to ‘regular’ for 
sufficiently modern ld64 (there’s a minor change to i386/i386.c)

Patch 4: (Mostly Dominique’s work) fixes up the testsuite fallout.

This has been tested across the Darwin patch - from powerpc-darwin9 - 
x86_64-apple-darwin16 and I did a bootstrap and check on x86_64-linux-gnu.

The patches could be applied one at a time - but N typically depends on N-1 - 
so the sequence of application needs to follow this.

Iain

Re: [PATCH, Fortran, v1] Restructure initialization of allocatable components

[Mikael Morin]

Le 03/11/2016 à 14:16, Andre Vehreschild a écrit :

@Dominique: Would you give it a go on your open patch collection? Maybe it
fixes one PR, but I am not very hopeful, because the patch is merely removing
complexity instead of doing new things.


Hello,

Since you asked:
I think the patch fixes pr60500.
The spurious warning was gone before, it seems, but it is your patch 
that fixed the wrong code causing it.


Mikael

Re: [PATCH] Fix -Wshadow warning in libiberty/cp-demangle.c

[Mark Wielaard]

On Sat, 2016-09-10 at 09:51 -0400, Eric Gallager wrote:
> On 9/10/16, Ian Lance Taylor  wrote:
> > I'm not sure about the patch to configure.ac/configure.  The last I
> > looked -Wshadow would warn if a local variable shadows a global
> > variable.  That can cause a pointless build break if some system
> > header file defines a global variable that happens to have the same
> > name as a local variable.  It's not a likely scenario but I don't see
> > a need to court a build breakage.
> >
> Maybe if the patch to add -Wshadow-local went in, the configure script
> could use that instead?

We now have -Wshadow=local. So the attached patch uses that for
libiberty. Is the attached patch OK to commit?

Thanks,

Mark
From f6f938e8053b6caf393c35c6f96c946073ca9373 Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Sun, 6 Nov 2016 17:36:06 +0100
Subject: [PATCH] libiberty: Add -Wshadow=local to warning flags (if
 supported).

libiberty/ChangeLog:

   * configure.ac (ac_libiberty_warn_cflags): Add -Wshadow=local.
   * configure: Regenerated.
---
diff --git a/libiberty/configure b/libiberty/configure
index 0f8e9b9..5c4dda5 100755
--- a/libiberty/configure
+++ b/libiberty/configure
@@ -4398,7 +4398,8 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 ac_libiberty_warn_cflags=
 save_CFLAGS="$CFLAGS"
 for real_option in -W -Wall -Wwrite-strings -Wc++-compat \
-			  -Wstrict-prototypes; do
+			  -Wstrict-prototypes \
+			  -Wshadow=local; do
   # Do the check with the no- prefix removed since gcc silently
   # accepts any -Wno-* option on purpose
   case $real_option in
diff --git a/libiberty/configure.ac b/libiberty/configure.ac
index 9d3f298..1aa0c7c 100644
--- a/libiberty/configure.ac
+++ b/libiberty/configure.ac
@@ -160,7 +160,8 @@ AC_SYS_LARGEFILE
 AC_PROG_CPP_WERROR
 
 ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wwrite-strings -Wc++-compat \
-			  -Wstrict-prototypes], [ac_libiberty_warn_cflags])
+			  -Wstrict-prototypes \
+			  -Wshadow=local], [ac_libiberty_warn_cflags])
 ACX_PROG_CC_WARNING_ALMOST_PEDANTIC([], [ac_libiberty_warn_cflags])
 
 AC_PROG_CC_C_O
-- 
1.8.3.1

Re: Possible patch for fortran/55086

[Louis Krupp]

Dominique,

(1) I'm not sure why the 'forall' gets a temporary.
(2) As far as I can tell, we get an ICE because the code that generates 
'forall' temporaries doesn't work well with substrings.  It's hard to test all 
possible combinations, and this one had been missed.

While the original program in the bug report might not have really needed a 
temporary, other programs will, and unless there's a way to avoid using 
temporaries for the combination of 'forall' and substrings, the code that 
generates temporaries will have to be fixed.  I'm suggesting 
'-fforce-forall-temp' as a way to make sure this code gets tested more 
thoroughly;  it's for one or two specific test files only, and not for general 
use.  I'd rather test code that will never be executed than leave code untested 
if there's even a small chance that it will be executed some day.

'gfortran --help -v' would list the option as '-fforce-forall-temp: Force 
creation of temporary to debug forall code'.  I can hide it completely if 
necessary.

As far as I know, my suggested patch doesn't generate any new temporaries 
unless -fforce-forall-temp is set.  I could be wrong.  It wouldn't be the first 
time.  I can take another look at that.

Louis



  On Sun, 06 Nov 2016 08:26:24 -0800 Dominique d'Humières 
 wrote  
 > > The problem was that forall could handle substring expressions, 
 > > but not if it had to create a temporary array.  I did my best 
 > > to fix this.  I left a couple of TODO comments in the code. 
 >  
 > Well, I don’t understand why the test needs a temporary for 
 >  
 >   forall (i1 = nl1:nu1) o(i1:i1) = i(i1:i1)   !  ICE 
 >  
 > If I am not mistaken this is equivalent to 
 >  
 >   o(nl1:nu1) = i(nl1:nu1) 
 >  
 > for which gfortran does not generate any temporary while it does for 
 >   forall (i1 = nl1:nu1) o(i1:i1) = o(nu1+1-i1:nu1+1-i1)  
 > where it is needed (looking at the dumps when compiling with 
 > -fdump-tree-original). 
 >  
 > Note that your patch generates a temporary which is not needed. 
 >  
 > At this point I have two questions: 
 > (1) why does gfortran want to create a temporary? 
 > (2) why does it fails? 
 >  
 > > Part of the issue is that forall doesn't usually create 
 > > a temporary, so that code doesn't get as much test coverage 
 > > as it probably should. 
 >  
 > In an ideal world, the compiler should create temporaries for assignment 
 > only when needed. AFAICR the coverage is rather good for usual assignments, 
 > I’ld be surprised if this were the case for FORALL. 
 >  
 > >  I added an option (-fforce-forall-temp) 
 > > to force forall to use a temporary, and I set that option 
 > > in a couple of the test files. 
 >  
 > I am not really fond of this option. At best, it could only be a work around 
 > missing temporaries. What would be more helpful would be to report temporary 
 > creations when compiling with -Warray-temporaries or -fcheck=array-temps. 
 >  
 > Thanks for working on the issue. 
 >  
 > Dominique 
 >  
 > > I would not be surprised if there were a better way to do this. 
 > > 
 > > When I tweak gfc_trans_forall_1() to force usage of a temporary 
 > > for all assignments, all tests pass with the exception 
 > > of forall_8.f90, and the whole point of that test is making 
 > > sure that this particular forall *doesn't* use a temporary. 
 > >   
 > > Louis Krupp 
 >  
 >  
 > 

[Darwin, configury] No longer expect to find cross-target headers on the host.

[Iain Sandoe]

Hi Folks,

This might make some configuration modes easier on modern Darwin (although 
hitting the problem used to be an unusual circumstance, it will likely become 
more common if we need to use build-sysroots - e.g. targeting a minimum OS X 
version of 10.6 on later versions).

Earlier Darwin (esp. Darwin8 and Darwin9) had FAT libraries and suitable header 
installations in /usr/include such that one could build a cross-toolchain 
(including cross-arch) using a common sysroot (including / for “current” 
version).

However this is no longer true on a number of levels.  A vanilla Darwin system 
has no headers installed in /usr and it's certainly not appropriate to try and 
find headers/libs for (say) x86-64-darwinNN X powerpc-darwin in /usr on any 
Darwin NN > 10 (even Darwin10 is incomplete in that it omits the ppc64 
multilib).  In the latter example, the catch-all in the current configury to 
mean that "foo-darwin" == “foo-version-on-this-system” breaks the cross case 
—target=powerpc-apple-darwin —host=some-system-later-than-darwin10.

While the trailing case entry is not darwin-specific, grep says that there are 
no instances of “NATIVE_CROSS” anywhere in the current GCC tree.

OK for trunk?
OK for open branches?
Iain

….   Iain Sandoe  

gcc/
* configure.ac (CROSS directory tests): Remove assumption that Darwin 
hosts
contain suitable target sysroots in “/“.
* configure: Regenerate.


---
 gcc/configure.ac | 21 -
 1 file changed, 21 deletions(-)

diff --git a/gcc/configure.ac b/gcc/configure.ac
index e5c9e9e..834605a 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -2033,27 +2033,6 @@ then
CROSS="-DCROSS_DIRECTORY_STRUCTURE"
ALL=all.cross
SYSTEM_HEADER_DIR=$build_system_header_dir
-   case "$host","$target" in
-   # Darwin crosses can use the host system's libraries and headers,
-   # because of the fat library support.  Of course, it must be the
-   # same version of Darwin on both sides.  Allow the user to
-   # just say --target=foo-darwin without a version number to mean
-   # "the version on this system".
-   *-*-darwin*,*-*-darwin*)
-   hostos=`echo $host | sed 's/.*-darwin/darwin/'`
-   targetos=`echo $target | sed 's/.*-darwin/darwin/'`
-   if test $hostos = $targetos -o $targetos = darwin ; then
-   CROSS=
-   SYSTEM_HEADER_DIR='$(NATIVE_SYSTEM_HEADER_DIR)'
-   with_headers=yes
-   fi
-   ;;
-
-   i?86-*-*,x86_64-*-* \
-   | powerpc*-*-*,powerpc64*-*-*)
-   CROSS="$CROSS -DNATIVE_CROSS" ;;
-   esac
-
case $target in
*-*-mingw*)
if test "x$with_headers" = x; then
-- 
2.8.1

Re: [PATCH] Fix assembler arguments for -m16

[Gerald Pfeifer]

It appears this got stuck.

Uros, is this okay?  I can handle the commit if you approve.

Gerald

On Wed, 6 Jul 2016, Roger Pau Monne wrote:
> At the moment the -m16 option only passes the "--32" parameter to the
> assembler on glibc OSes, while on other OSes the assembler is called without
> any specific flag. This is wrong and causes the assembler to fail. Fix it
> by adding support for the -m16 option to x86-64.h.
> 
> 2016-07-06  Roger Pau Monné  
> 
>   * x86-64.h: append --32 to the assembler options when -m16 is used
>   even on non-glibc OSes.
> 
> ---
> Cc: h...@gcc.gnu.org
> Cc: ger...@freebsd.org
> ---
> This should be backported to all stable branches up to 4.9 (when -m16 was
> introduced).
> 
> Please keep me on Cc since I'm not subscribed to the list, thanks.
> ---
>  gcc/config/i386/x86-64.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/config/i386/x86-64.h b/gcc/config/i386/x86-64.h
> index b0bf835..9e6c6eb 100644
> --- a/gcc/config/i386/x86-64.h
> +++ b/gcc/config/i386/x86-64.h
> @@ -49,7 +49,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
> If not, see
>  #define WCHAR_TYPE_SIZE 32
>  
>  #undef ASM_SPEC
> -#define ASM_SPEC "%{m32:--32} %{m64:--64} %{mx32:--x32}"
> +#define ASM_SPEC "%{m16|m32:--32} %{m64:--64} %{mx32:--x32}"
>  
>  #undef ASM_OUTPUT_ALIGNED_BSS
>  #define ASM_OUTPUT_ALIGNED_BSS(FILE, DECL, NAME, SIZE, ALIGN) \

[PATCH] libgcc/config/bfin: use the generic linker version information (PR74748)

[Waldemar Brodkorb]

Hi,

This commit makes the Blackfin platform use the generic linker version
information, rather than a completely duplicated file, specific for the
Blackfin architecture.

This is made possible using the newly introduced skip_underscore
variable of the mkmap-symver script.

This also allows to get a correct linker version file, with symbol names
matching the ones found in libgcc. Thanks to this, the necessary symbols
are marked "GLOBAL" instead of "LOCAL", which makes them visible at link
time, and solves a large number of "undefined reference"
issues. Indeed, the Blackfin specific linker version script had an extra
underscore in front of all symbols, which meant none of them matched the
symbols in libgcc, and therefore all libgcc symbols were marked as
"LOCAL", making them invisible for linking.

Signed-off-by: Thomas Petazzoni 
Tested-by: Waldemar Brodkorb 

 2016-11-06  Thomas Petazzoni 
 
PR gcc/74748
 * libgcc/config/bfin/libgcc-glibc.ver, libgcc/config/bfin/t-linux:
 use generic linker version information on Blackfin.

diff --git a/libgcc/config/bfin/libgcc-glibc.ver 
b/libgcc/config/bfin/libgcc-glibc.ver
index b1bd2df..2af3df7 100644
--- a/libgcc/config/bfin/libgcc-glibc.ver
+++ b/libgcc/config/bfin/libgcc-glibc.ver
@@ -16,1898 +16,8 @@
 # along with GCC; see the file COPYING3.  If not see
 # .
 
-GCC_3.0 {
-  # libgcc1 integer symbols
-  ___absvsi2
-  ___addvsi3
-  ___ashlsi3
-  ___ashrsi3
-  ___divsi3
-  ___lshrsi3
-  ___modsi3
-  ___mulsi3
-  ___mulvsi3
-  ___negvsi2
-  ___subvsi3
-  ___udivsi3
-  ___umodsi3
-
-  # libgcc1 floating point symbols
-  ___addsf3
-  ___adddf3
-  ___addxf3
-  ___addtf3
-  ___divsf3
-  ___divdf3
-  ___divxf3
-  ___divtf3
-  ___eqsf2
-  ___eqdf2
-  ___eqxf2
-  ___eqtf2
-  ___extenddfxf2
-  ___extenddftf2
-  ___extendsfdf2
-  ___extendsfxf2
-  ___extendsftf2
-  ___fixsfsi
-  ___fixdfsi
-  ___fixxfsi
-  ___fixtfsi
-  ___floatsisf
-  ___floatsidf
-  ___floatsixf
-  ___floatsitf
-  ___gesf2
-  ___gedf2
-  ___gexf2
-  ___getf2
-  ___gtsf2
-  ___gtdf2
-  ___gtxf2
-  ___gttf2
-  ___lesf2
-  ___ledf2
-  ___lexf2
-  ___letf2
-  ___ltsf2
-  ___ltdf2
-  ___ltxf2
-  ___lttf2
-  ___mulsf3
-  ___muldf3
-  ___mulxf3
-  ___multf3
-  ___negsf2
-  ___negdf2
-  ___negxf2
-  ___negtf2
-  ___nesf2
-  ___nedf2
-  ___nexf2
-  ___netf2
-  ___subsf3
-  ___subdf3
-  ___subxf3
-  ___subtf3
-  ___truncdfsf2
-  ___truncxfsf2
-  ___trunctfsf2
-  ___truncxfdf2
-  ___trunctfdf2
-
-  # libgcc2 DImode arithmetic (for 32-bit targets).
-  ___absvdi2
-  ___addvdi3
-  ___ashldi3
-  ___ashrdi3
-  ___cmpdi2
-  ___divdi3
-  ___ffsdi2
-  ___fixdfdi
-  ___fixsfdi
-  ___fixtfdi
-  ___fixxfdi
-  ___fixunsdfdi
-  ___fixunsdfsi
-  ___fixunssfsi
-  ___fixunssfdi
-  ___fixunstfdi
-  ___fixunstfsi
-  ___fixunsxfdi
-  ___fixunsxfsi
-  ___floatdidf
-  ___floatdisf
-  ___floatdixf
-  ___floatditf
-  ___lshrdi3
-  ___moddi3
-  ___muldi3
-  ___mulvdi3
-  ___negdi2
-  ___negvdi2
-  ___subvdi3
-  ___ucmpdi2
-  ___udivdi3
-  ___udivmoddi4
-  ___umoddi3
-
-  # libgcc2 TImode arithmetic (for 64-bit targets).
-  ___ashlti3
-  ___ashrti3
-  ___cmpti2
-  ___divti3
-  ___ffsti2
-  ___fixdfti
-  ___fixsfti
-  ___fixtfti
-  ___fixxfti
-  ___lshrti3
-  ___modti3
-  ___multi3
-  ___negti2
-  ___ucmpti2
-  ___udivmodti4
-  ___udivti3
-  ___umodti3
-  ___fixunsdfti
-  ___fixunssfti
-  ___fixunstfti
-  ___fixunsxfti
-  ___floattidf
-  ___floattisf
-  ___floattixf
-  ___floattitf
-
-  # Used to deal with trampoline initialization on some platforms
-  ___clear_cache
-
-  # EH symbols
-  __Unwind_DeleteException
-  __Unwind_Find_FDE
-  __Unwind_ForcedUnwind
-  __Unwind_GetGR
-  __Unwind_GetIP
-  __Unwind_GetLanguageSpecificData
-  __Unwind_GetRegionStart
-  __Unwind_GetTextRelBase
-  __Unwind_GetDataRelBase
-  __Unwind_RaiseException
-  __Unwind_Resume
-  __Unwind_SetGR
-  __Unwind_SetIP
-  ___deregister_frame
-  ___deregister_frame_info
-  ___deregister_frame_info_bases
-  ___register_frame
-  ___register_frame_info
-  ___register_frame_info_bases
-  ___register_frame_info_table
-  ___register_frame_info_table_bases
-  ___register_frame_table
-
-  # SjLj EH symbols
-  __Unwind_SjLj_Register
-  __Unwind_SjLj_Unregister
-  __Unwind_SjLj_RaiseException
-  __Unwind_SjLj_ForcedUnwind
-  __Unwind_SjLj_Resume
-}
-
-%inherit GCC_3.3 GCC_3.0
-GCC_3.3 {
-  __Unwind_FindEnclosingFunction
-  __Unwind_GetCFA
-  __Unwind_Backtrace
-  __Unwind_Resume_or_Rethrow
-  __Unwind_SjLj_Resume_or_Rethrow
-}
-
-%inherit GCC_3.3.1 GCC_3.3
-GCC_3.3.1 {
-  ___gcc_personality_sj0
-  ___gcc_personality_v0
-}
-
-%inherit GCC_3.3.2 GCC_3.3.1
-GCC_3.3.2 {
-}
-%inherit GCC_3.3.4 GCC_3.3.2
-GCC_3.3.4 {
-  ___unorddf2
-  ___unordsf2
-}
-
-%inherit GCC_3.4 GCC_3.3.4
-GCC_3.4 {
-  # bit scanning and counting built-ins
-  ___clzsi2
-  ___clzdi2
-  ___clzti2
-  ___ctzsi2
-  ___ctzdi2
-  ___ctzti2
-  ___popcountsi2
-  ___popcountdi2
-  

[PATCH] libgcc/mkmap-symver: support skip_underscore (PR74748)

[Waldemar Brodkorb]

Hi,

Some platforms, such as Blackfin, have a special prefix for assembly
symbols as opposed to C symbols. For this reason, a function named
"foo()" in C will in fact be visible as a symbol called "_foo" in the
ELF binary.

The current linker version script logic in libgcc doesn't take into
account this situation properly. The Blackfin specific
libgcc/config/bfin/libgcc-glibc.ver has an additional "_" in front of
every symbol so that it matches the output of "nm" (which gets parsed to
produce the final linker version script). But due to this additional
"_", ld no longer matches with the symbols since "ld" does the matching
with the original symbol name, not the one prefixed with "_".

Due to this, none of the symbols in libgcc/config/bfin/libgcc-glibc.ver
are actually matched with symbols in libgcc. This causes all libgcc
symbols to be left as "LOCAL", which causes lots of "undefined
reference" whenever some C or C++ code that calls a function of libgcc
is compiled.

To address this, this commit introduces a "skip_underscore" variable to
the mkmap-symver script. It tells mkmap-symver to ignore the leading
underscore from the "nm" output.

Note that this new argument is different from the existing
"leading_underscore" argument, which *adds* an additional underscore to
the generated linker version script.

Having this functionality paves the way to using the generic linker
version information for Blackfin, instead of using a custom one.

Signed-off-by: Thomas Petazzoni 
Tested-by: Waldemar Brodkorb 

2016-11-06  Thomas Petazzoni 

PR gcc/74748
* libgcc/mkmap-symver.awk: add support for skip_underscore


diff --git a/libgcc/mkmap-symver.awk b/libgcc/mkmap-symver.awk
index 266832a..30bb179 100644
--- a/libgcc/mkmap-symver.awk
+++ b/libgcc/mkmap-symver.awk
@@ -47,7 +47,11 @@ state == "nm" && ($1 == "U" || $2 == "U") {
 
 state == "nm" && NF == 3 {
   split ($3, s, "@")
-  def[s[1]] = 1;
+  if (skip_underscore)
+  symname = substr(s[1], 2);
+  else
+  symname = s[1];
+  def[symname] = 1;
   sawsymbol = 1;
   next;
 }

Thanks in advance,
 Waldemar

Re: Possible patch for fortran/55086

[Dominique d'Humières]

> The problem was that forall could handle substring expressions,
> but not if it had to create a temporary array.  I did my best
> to fix this.  I left a couple of TODO comments in the code.

Well, I don’t understand why the test needs a temporary for

  forall (i1 = nl1:nu1) o(i1:i1) = i(i1:i1)   !  ICE

If I am not mistaken this is equivalent to

  o(nl1:nu1) = i(nl1:nu1)

for which gfortran does not generate any temporary while it does for
  forall (i1 = nl1:nu1) o(i1:i1) = o(nu1+1-i1:nu1+1-i1) 
where it is needed (looking at the dumps when compiling with 
-fdump-tree-original).

Note that your patch generates a temporary which is not needed.

At this point I have two questions:
(1) why does gfortran want to create a temporary?
(2) why does it fails?

> Part of the issue is that forall doesn't usually create
> a temporary, so that code doesn't get as much test coverage
> as it probably should.

In an ideal world, the compiler should create temporaries for assignment only 
when needed. AFAICR the coverage is rather good for usual assignments, I’ld be 
surprised if this were the case for FORALL.

>  I added an option (-fforce-forall-temp)
> to force forall to use a temporary, and I set that option
> in a couple of the test files.

I am not really fond of this option. At best, it could only be a work around 
missing temporaries. What would be more helpful would be to report temporary 
creations when compiling with -Warray-temporaries or -fcheck=array-temps.

Thanks for working on the issue.

Dominique

> I would not be surprised if there were a better way to do this.
>
> When I tweak gfc_trans_forall_1() to force usage of a temporary
> for all assignments, all tests pass with the exception
> of forall_8.f90, and the whole point of that test is making
> sure that this particular forall *doesn't* use a temporary.
>  
> Louis Krupp

Re: [PATCH, Fortran, v1] Restructure initialization of allocatable components

[Andre Vehreschild]

Hi Steve, hi Paul, hi Dominique, hi all,

thanks for the reviews, Steve and Paul, thanks for the heavy testing, Dominique.
Committed as r241885.

Regards,
Andre
On Sat, 5 Nov 2016 10:46:46 +0100
Paul Richard Thomas  wrote:

> Dear Andre,
> 
> The patch looks fine to me. OK for trunk.
> 
> Cheers
> 
> Paul
> 
> On 4 November 2016 at 01:57, Steve Kargl
>  wrote:
> > On Thu, Nov 03, 2016 at 02:16:48PM +0100, Andre Vehreschild wrote:  
> >>
> >> Bootstraps and regtests fine on x86_64-linux/F23. Ok for trunk?
> >>
> >> @Dominique: Would you give it a go on your open patch collection? Maybe it
> >> fixes one PR, but I am not very hopeful, because the patch is merely
> >> removing complexity instead of doing new things.
> >>  
> >
> > Andre,
> >
> > I did not see anything that looked dubious.  I think
> > it is OK to commit, but you may want to see if Paul
> > has any comment.
> >
> > --
> > Steve  
> 
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 241884)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,26 @@
+2016-11-06  Andre Vehreschild  
+
+	* expr.c (is_non_empty_structure_constructor): New function to detect
+	non-empty structure constructor.
+	(gfc_has_default_initializer): Analyse initializers.
+	* resolve.c (cond_init): Removed.
+	(resolve_allocate_expr): Removed dead code.  Moved invariant code out
+	of the loop over all objects to allocate.
+	(resolve_allocate_deallocate): Added the invariant code remove from
+	resolve_allocate_expr.
+	* trans-array.c (gfc_array_allocate): Removed nullify of structure
+	components in favour of doing this in gfc_trans_allocate for both
+	scalars and arrays in the same place.
+	* trans-expr.c (gfc_trans_init_assign): Always using _vptr->copy for
+	class objects.
+	* trans-stmt.c (allocate_get_initializer): Get the initializer
+	expression for object allocated.
+	(gfc_trans_allocate): Nullify a derived type only, when no SOURCE=
+	or MOLD= is present preventing duplicate work.  Moved the creation
+	of the init-expression here to prevent code for conditions that
+	can not occur on freshly allocated object, like checking for the need
+	to free allocatable components.
+
 2016-11-06  Thomas Koenig  
 
 	PR fortran/78221
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c	(Revision 241884)
+++ gcc/fortran/expr.c	(Arbeitskopie)
@@ -4131,6 +4131,26 @@
 }
 
 
+/* Check whether an expression is a structure constructor and whether it has
+   other values than NULL.  */
+
+bool
+is_non_empty_structure_constructor (gfc_expr * e)
+{
+  if (e->expr_type != EXPR_STRUCTURE)
+return false;
+
+  gfc_constructor *cons = gfc_constructor_first (e->value.constructor);
+  while (cons)
+{
+  if (!cons->expr || cons->expr->expr_type != EXPR_NULL)
+	return true;
+  cons = gfc_constructor_next (cons);
+}
+  return false;
+}
+
+
 /* Check for default initializer; sym->value is not enough
as it is also set for EXPR_NULL of allocatables.  */
 
@@ -4145,7 +4165,9 @@
   {
 if (!c->attr.pointer && !c->attr.proc_pointer
 	 && !(c->attr.allocatable && der == c->ts.u.derived)
-	 && gfc_has_default_initializer (c->ts.u.derived))
+	 && ((c->initializer
+		  && is_non_empty_structure_constructor (c->initializer))
+		 || gfc_has_default_initializer (c->ts.u.derived)))
 	  return true;
 	if (c->attr.pointer && c->initializer)
 	  return true;
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(Revision 241884)
+++ gcc/fortran/resolve.c	(Arbeitskopie)
@@ -7048,36 +7048,7 @@
   return true;
 }
 
-static void
-cond_init (gfc_code *code, gfc_expr *e, int pointer, gfc_expr *init_e)
-{
-  gfc_code *block;
-  gfc_expr *cond;
-  gfc_code *init_st;
-  gfc_expr *e_to_init = gfc_expr_to_initialize (e);
 
-  cond = pointer
-? gfc_build_intrinsic_call (gfc_current_ns, GFC_ISYM_ASSOCIATED,
-	"associated", code->loc, 2, gfc_copy_expr (e_to_init), NULL)
-: gfc_build_intrinsic_call (gfc_current_ns, GFC_ISYM_ALLOCATED,
-	"allocated", code->loc, 1, gfc_copy_expr (e_to_init));
-
-  init_st = gfc_get_code (EXEC_INIT_ASSIGN);
-  init_st->loc = code->loc;
-  init_st->expr1 = e_to_init;
-  init_st->expr2 = init_e;
-
-  block = gfc_get_code (EXEC_IF);
-  block->loc = code->loc;
-  block->block = gfc_get_code (EXEC_IF);
-  block->block->loc = code->loc;
-  block->block->expr1 = cond;
-  block->block->next = init_st;
-  block->next = code->next;
-
-  code->next = block;
-}
-
 /* Resolve the expression in an ALLOCATE statement, doing the additional
checks to see whether the expression is OK or not.  The expression must
have a trailing array reference that gives the size of the 

Re: [PATCH] Fix PR driver/78206 by silently ignoring EPERM as well as ENOENT

[Iain Sandoe]

> On 6 Nov 2016, at 06:57, Jack Howarth  wrote:
> 
> On Sun, Nov 6, 2016 at 9:45 AM, Iain Sandoe  wrote:
>> 
>>> On 6 Nov 2016, at 06:04, Jack Howarth  wrote:
>>> 
>>> On Sun, Nov 6, 2016 at 8:36 AM, Jack Howarth  
>>> wrote:
 The use of an Apple sandbox with denied file access permissions into 
 /usr/local
 exposed that cc1 fails on errors of...
 
 cc1: error: /usr/local/include: Operation not permitted
 
 The commonly suggested solution of using --with-local-prefix= set to 
 something
 other than /usr/local is undeirable on darwin because that creates a 
 compiler
 which retains library searches in /usr/local/lib despite no longer 
 searching
 for headers in /usr/local/include (which makes it suspicable to 
 header/library
 mismatches during builds).
 
 The following trivial fix solves the issue by silently ignoring errors from
 denied permissions as well as non-existent dirs from the stat (cur->name, 
 )
 call in remove_dup() of gcc/incpath.c. Okay for gcc trunk and backports to
 gcc-5-branch and gcc-6-branch?
  Jack Howarth
>>> 
>>>   Perhaps it would be useful if I expounded a bit on the
>>> complexities that this
>>> PR introduces on darwin. Both MacPorts and now fink leverage the Apple 
>>> sandbox
>>> to avoid contaminating their builds with development files installed
>>> in /usr/local.
>>> However the FSF gcc compiler packages built still should allow end-users to
>>> build against /usr/local as normal outside of the packaging systems. On 
>>> darwin,
>>> it has been suggested that the sandbox build issues of FSF gcc be addressed 
>>> by
>>> using ---sysroot instead. Unfortunately that approach in not viable because 
>>> the
>>> Xcode developers no longer bundle the SDK of the prior OS in Xcode.app once
>>> a new OS is released. Thus using the SDK installed at / is the only
>>> option (since
>>> building against the next OS SDK on the prior OS is unsupported on darwin),
>>> and this nullifies the ability to use --sysroot to work around this issue.
>>> 
>>> I believe the proposed patch is a trivial and straightforward solution
>>> which allows
>>> darwin developers to package the FSF gcc compilers within an Apple sandbox
>>> while retaining the ability of the built compilers to behave as expect
>>> with regard
>>> to /usr/local outside of the Apple sandbox.
>> 
>> a. The patch seems reasonable on one level (if you don’t have permission to 
>> read the directory, then there’s no point in adding it to the search path).
>> 
>> b. However, ISTM that your configuration process should be pointing the 
>> compiler to a usable sysroot [which contains only directories to which the 
>> toolchain has suitable permissions].
>> 
>> c. It is clear that the situation is complex (for Darwin), we want users to 
>> be able to use either the xcode-provided sdk as the sysroot or an 
>> installation of the ‘command line tools’ (which effectively provides a 
>> sysroot in ‘/‘).
>> 
>> d.  One day we might be able to build enough of the sysroot to support the 
>> compiler without needing this (but we’re not there yet).
>> 
>> We cannot [AFAIU, INAL etc.] take the option of packaging the sysroot 
>> ourselves until (d) is achieved.
>> 
>> ===
>> 
>> So… I’m not sure we have a good way of achieving this completely 
>> automatically, in a user-transparent manner (yet) …  however, one way of 
>> achieving this in a not-to-painful manner, is to have a toolchain layout like
>> 
>> bin/
>> lib/
>> SDKs/
>>   native => symlink to either the XCode sysroot - or ‘/‘.
>> 
>> and to configure gcc  “—with-sysroot=/SDKs/native”
> 
> One can no longer safely assume that any place other than / has the
> appropriate development SDK for open source software on darwin. As
> Jeremy Huddleston Sequoia recently described the situation to me...
> 
> "Yeah, most OSS projects assume that the buildtime headers and
> libraries match the minimum deployment target.  They decide that if
> configure determines that openat(2) is available at build time, it can
> be unconditionally used by the program.
> 
> The Apple model is that the SDK contains availability markup that
> allows developers to specify older OS versions as a deployment target.
> Newer symbols get weakly bound, and developers need to check for their
> existence before usage.
> 
> Simply picking the 10.12 SDK when the developer/user has asked for the
> system-matched SDK is going to result in problems, as we've repeatedly
> seen when users try to build against the +1 SDK with software that
> doesn't know how to handle that properly."
> 
> You really can't safely depend on the Apple Xcode.app SDK any more.
> You will be okay one day and if you update your Xcode.app, will be
> broken (i.e. building against the wrong SDK) the next day.
> 
>> 
>> The end user would then need to amend/make 

Re: [PATCH] Fix PR driver/78206 by silently ignoring EPERM as well as ENOENT

[Jack Howarth]

On Sun, Nov 6, 2016 at 9:45 AM, Iain Sandoe  wrote:
>
>> On 6 Nov 2016, at 06:04, Jack Howarth  wrote:
>>
>> On Sun, Nov 6, 2016 at 8:36 AM, Jack Howarth  
>> wrote:
>>> The use of an Apple sandbox with denied file access permissions into 
>>> /usr/local
>>> exposed that cc1 fails on errors of...
>>>
>>> cc1: error: /usr/local/include: Operation not permitted
>>>
>>> The commonly suggested solution of using --with-local-prefix= set to 
>>> something
>>> other than /usr/local is undeirable on darwin because that creates a 
>>> compiler
>>> which retains library searches in /usr/local/lib despite no longer searching
>>> for headers in /usr/local/include (which makes it suspicable to 
>>> header/library
>>> mismatches during builds).
>>>
>>> The following trivial fix solves the issue by silently ignoring errors from
>>> denied permissions as well as non-existent dirs from the stat (cur->name, 
>>> )
>>> call in remove_dup() of gcc/incpath.c. Okay for gcc trunk and backports to
>>> gcc-5-branch and gcc-6-branch?
>>>   Jack Howarth
>>
>>Perhaps it would be useful if I expounded a bit on the
>> complexities that this
>> PR introduces on darwin. Both MacPorts and now fink leverage the Apple 
>> sandbox
>> to avoid contaminating their builds with development files installed
>> in /usr/local.
>> However the FSF gcc compiler packages built still should allow end-users to
>> build against /usr/local as normal outside of the packaging systems. On 
>> darwin,
>> it has been suggested that the sandbox build issues of FSF gcc be addressed 
>> by
>> using ---sysroot instead. Unfortunately that approach in not viable because 
>> the
>> Xcode developers no longer bundle the SDK of the prior OS in Xcode.app once
>> a new OS is released. Thus using the SDK installed at / is the only
>> option (since
>> building against the next OS SDK on the prior OS is unsupported on darwin),
>> and this nullifies the ability to use --sysroot to work around this issue.
>>
>> I believe the proposed patch is a trivial and straightforward solution
>> which allows
>> darwin developers to package the FSF gcc compilers within an Apple sandbox
>> while retaining the ability of the built compilers to behave as expect
>> with regard
>> to /usr/local outside of the Apple sandbox.
>
> a. The patch seems reasonable on one level (if you don’t have permission to 
> read the directory, then there’s no point in adding it to the search path).
>
> b. However, ISTM that your configuration process should be pointing the 
> compiler to a usable sysroot [which contains only directories to which the 
> toolchain has suitable permissions].
>
> c. It is clear that the situation is complex (for Darwin), we want users to 
> be able to use either the xcode-provided sdk as the sysroot or an 
> installation of the ‘command line tools’ (which effectively provides a 
> sysroot in ‘/‘).
>
> d.  One day we might be able to build enough of the sysroot to support the 
> compiler without needing this (but we’re not there yet).
>
> We cannot [AFAIU, INAL etc.] take the option of packaging the sysroot 
> ourselves until (d) is achieved.
>
> ===
>
> So… I’m not sure we have a good way of achieving this completely 
> automatically, in a user-transparent manner (yet) …  however, one way of 
> achieving this in a not-to-painful manner, is to have a toolchain layout like
>
>  bin/
>  lib/
>  SDKs/
>native => symlink to either the XCode sysroot - or ‘/‘.
>
> and to configure gcc  “—with-sysroot=/SDKs/native”

One can no longer safely assume that any place other than / has the
appropriate development SDK for open source software on darwin. As
Jeremy Huddleston Sequoia recently described the situation to me...

"Yeah, most OSS projects assume that the buildtime headers and
libraries match the minimum deployment target.  They decide that if
configure determines that openat(2) is available at build time, it can
be unconditionally used by the program.

The Apple model is that the SDK contains availability markup that
allows developers to specify older OS versions as a deployment target.
Newer symbols get weakly bound, and developers need to check for their
existence before usage.

Simply picking the 10.12 SDK when the developer/user has asked for the
system-matched SDK is going to result in problems, as we've repeatedly
seen when users try to build against the +1 SDK with software that
doesn't know how to handle that properly."

You really can't safely depend on the Apple Xcode.app SDK any more.
You will be okay one day and if you update your Xcode.app, will be
broken (i.e. building against the wrong SDK) the next day.

>
> The end user would then need to amend/make the symlink to point to “/" or the 
> xcode SDK at installation time.
>
> Alternately, you could default it to “/“ if you believe that the end users 
> are mostly going to be using the “command line tools” installtion - or you 
> 

Re: [PATCH] Fix PR driver/78206 by silently ignoring EPERM as well as ENOENT

[Iain Sandoe]

> On 6 Nov 2016, at 06:04, Jack Howarth  wrote:
> 
> On Sun, Nov 6, 2016 at 8:36 AM, Jack Howarth  wrote:
>> The use of an Apple sandbox with denied file access permissions into 
>> /usr/local
>> exposed that cc1 fails on errors of...
>> 
>> cc1: error: /usr/local/include: Operation not permitted
>> 
>> The commonly suggested solution of using --with-local-prefix= set to 
>> something
>> other than /usr/local is undeirable on darwin because that creates a compiler
>> which retains library searches in /usr/local/lib despite no longer searching
>> for headers in /usr/local/include (which makes it suspicable to 
>> header/library
>> mismatches during builds).
>> 
>> The following trivial fix solves the issue by silently ignoring errors from
>> denied permissions as well as non-existent dirs from the stat (cur->name, 
>> )
>> call in remove_dup() of gcc/incpath.c. Okay for gcc trunk and backports to
>> gcc-5-branch and gcc-6-branch?
>>   Jack Howarth
> 
>Perhaps it would be useful if I expounded a bit on the
> complexities that this
> PR introduces on darwin. Both MacPorts and now fink leverage the Apple sandbox
> to avoid contaminating their builds with development files installed
> in /usr/local.
> However the FSF gcc compiler packages built still should allow end-users to
> build against /usr/local as normal outside of the packaging systems. On 
> darwin,
> it has been suggested that the sandbox build issues of FSF gcc be addressed by
> using ---sysroot instead. Unfortunately that approach in not viable because 
> the
> Xcode developers no longer bundle the SDK of the prior OS in Xcode.app once
> a new OS is released. Thus using the SDK installed at / is the only
> option (since
> building against the next OS SDK on the prior OS is unsupported on darwin),
> and this nullifies the ability to use --sysroot to work around this issue.
> 
> I believe the proposed patch is a trivial and straightforward solution
> which allows
> darwin developers to package the FSF gcc compilers within an Apple sandbox
> while retaining the ability of the built compilers to behave as expect
> with regard
> to /usr/local outside of the Apple sandbox.

a. The patch seems reasonable on one level (if you don’t have permission to 
read the directory, then there’s no point in adding it to the search path).

b. However, ISTM that your configuration process should be pointing the 
compiler to a usable sysroot [which contains only directories to which the 
toolchain has suitable permissions].

c. It is clear that the situation is complex (for Darwin), we want users to be 
able to use either the xcode-provided sdk as the sysroot or an installation of 
the ‘command line tools’ (which effectively provides a sysroot in ‘/‘).

d.  One day we might be able to build enough of the sysroot to support the 
compiler without needing this (but we’re not there yet).

We cannot [AFAIU, INAL etc.] take the option of packaging the sysroot ourselves 
until (d) is achieved.

===

So… I’m not sure we have a good way of achieving this completely automatically, 
in a user-transparent manner (yet) …  however, one way of achieving this in a 
not-to-painful manner, is to have a toolchain layout like

 bin/
 lib/
 SDKs/
   native => symlink to either the XCode sysroot - or ‘/‘.

and to configure gcc  “—with-sysroot=/SDKs/native”

The end user would then need to amend/make the symlink to point to “/" or the 
xcode SDK at installation time.

Alternately, you could default it to “/“ if you believe that the end users are 
mostly going to be using the “command line tools” installtion - or you could 
make your installation script discover Xcode’s SDK and point to that if you 
believe that most users will have Xcode installed,

If you simply want “/“ to be the runtime-default sysroot, then 
—with-sysroot=/ --with-build-sysroot=/path/to/build/time/sysroot
should work, and if it doesn’t we should fix the configury machinery so that it 
does.

Iain

[PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

[Bernd Edlinger]

Hi!

This improves the stack usage on the sha512 test case for the case
without hardware fpu and without iwmmxt by splitting all di-mode
patterns right while expanding which is similar to what the shift-pattern
does.  It does nothing in the case iwmmxt and fpu=neon or vfp as well as
thumb1.

It reduces the stack usage from 2300 to near optimal 272 bytes (!).

Note this also splits many ldrd/strd instructions and therefore I will
post a followup-patch that mitigates this effect by enabling the ldrd/strd
peephole optimization after the necessary reg-testing.


Bootstrapped and reg-tested on arm-linux-gnueabihf.
Is it OK for trunk?


Thanks
Bernd.2016-11-02  Bernd Edlinger  

	PR target/77308
	* config/arm/arm.md (*arm_adddi3, *arm_subdi3): Split early except for
	TARGET_HARD_FLOAT.
	(anddi3, iordi3, xordi3): Split while expanding except for
	TARGET_HARD_FLOAT and TARGET_IWMMXT.
	(one_cmpldi2): Split while expanding except for TARGET_HARD_FLOAT.
	(*one_cmpldi2_insn): Moved the body of one_cmpldi2 here.

testsuite:
2016-11-02  Bernd Edlinger  

	PR target/77308
	* gcc.target/arm/pr77308-1.c: New test.

Index: gcc/config/arm/arm.md
===
--- gcc/config/arm/arm.md	(revision 241686)
+++ gcc/config/arm/arm.md	(working copy)
@@ -467,7 +467,7 @@
(clobber (reg:CC CC_REGNUM))]
   "TARGET_32BIT && !TARGET_NEON"
   "#"
-  "TARGET_32BIT && reload_completed
+  "TARGET_32BIT && (!TARGET_HARD_FLOAT || reload_completed)
&& ! (TARGET_NEON && IS_VFP_REGNUM (REGNO (operands[0])))"
   [(parallel [(set (reg:CC_C CC_REGNUM)
 		   (compare:CC_C (plus:SI (match_dup 1) (match_dup 2))
@@ -1271,7 +1271,7 @@
(clobber (reg:CC CC_REGNUM))]
   "TARGET_32BIT && !TARGET_NEON"
   "#"  ; "subs\\t%Q0, %Q1, %Q2\;sbc\\t%R0, %R1, %R2"
-  "&& reload_completed"
+  "&& (!TARGET_HARD_FLOAT || reload_completed)"
   [(parallel [(set (reg:CC CC_REGNUM)
 		   (compare:CC (match_dup 1) (match_dup 2)))
 	  (set (match_dup 0) (minus:SI (match_dup 1) (match_dup 2)))])
@@ -2257,7 +2257,24 @@
 	(and:DI (match_operand:DI 1 "s_register_operand" "")
 		(match_operand:DI 2 "neon_inv_logic_op2" "")))]
   "TARGET_32BIT"
-  ""
+  "
+  if (!TARGET_HARD_FLOAT && !TARGET_IWMMXT)
+{
+  rtx low  = simplify_gen_binary (AND, SImode,
+  gen_lowpart (SImode, operands[1]),
+  gen_lowpart (SImode, operands[2]));
+  rtx high = simplify_gen_binary (AND, SImode,
+  gen_highpart (SImode, operands[1]),
+  gen_highpart_mode (SImode, DImode,
+			 operands[2]));
+
+  emit_insn (gen_rtx_SET (gen_lowpart (SImode, operands[0]), low));
+  emit_insn (gen_rtx_SET (gen_highpart (SImode, operands[0]), high));
+
+  DONE;
+}
+  /* Otherwise expand pattern as above.  */
+  "
 )
 
 (define_insn_and_split "*anddi3_insn"
@@ -3130,7 +3147,24 @@
 	(ior:DI (match_operand:DI 1 "s_register_operand" "")
 		(match_operand:DI 2 "neon_logic_op2" "")))]
   "TARGET_32BIT"
-  ""
+  "
+  if (!TARGET_HARD_FLOAT && !TARGET_IWMMXT)
+{
+  rtx low  = simplify_gen_binary (IOR, SImode,
+  gen_lowpart (SImode, operands[1]),
+  gen_lowpart (SImode, operands[2]));
+  rtx high = simplify_gen_binary (IOR, SImode,
+  gen_highpart (SImode, operands[1]),
+  gen_highpart_mode (SImode, DImode,
+			 operands[2]));
+
+  emit_insn (gen_rtx_SET (gen_lowpart (SImode, operands[0]), low));
+  emit_insn (gen_rtx_SET (gen_highpart (SImode, operands[0]), high));
+
+  DONE;
+}
+  /* Otherwise expand pattern as above.  */
+  "
 )
 
 (define_insn_and_split "*iordi3_insn"
@@ -3311,7 +3345,24 @@
 	(xor:DI (match_operand:DI 1 "s_register_operand" "")
 		(match_operand:DI 2 "arm_xordi_operand" "")))]
   "TARGET_32BIT"
-  ""
+  "
+  if (!TARGET_HARD_FLOAT && !TARGET_IWMMXT)
+{
+  rtx low  = simplify_gen_binary (XOR, SImode,
+  gen_lowpart (SImode, operands[1]),
+  gen_lowpart (SImode, operands[2]));
+  rtx high = simplify_gen_binary (XOR, SImode,
+  gen_highpart (SImode, operands[1]),
+  gen_highpart_mode (SImode, DImode,
+			 operands[2]));
+
+  emit_insn (gen_rtx_SET (gen_lowpart (SImode, operands[0]), low));
+  emit_insn (gen_rtx_SET (gen_highpart (SImode, operands[0]), high));
+
+  DONE;
+}
+  /* Otherwise expand pattern as above.  */
+  "
 )
 
 (define_insn_and_split "*xordi3_insn"
@@ -5017,7 +5068,31 @@
   "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_VFP_DOUBLE"
   "")
 
-(define_insn_and_split "one_cmpldi2"
+(define_expand "one_cmpldi2"
+  [(set (match_operand:DI 0 "s_register_operand" "")
+	(not:DI (match_operand:DI 1 "s_register_operand" "")))]
+  "TARGET_32BIT"
+  "
+  if (!TARGET_HARD_FLOAT)
+{
+  rtx low  = simplify_gen_unary (NOT, SImode,
+ gen_lowpart (SImode, operands[1]),
+ SImode);
+  rtx high = simplify_gen_unary (NOT, SImode,
+ gen_highpart_mode (SImode, DImode,
+			

Re: [PATCH] Fix PR driver/78206 by silently ignoring EPERM as well as ENOENT

[Jack Howarth]

On Sun, Nov 6, 2016 at 8:36 AM, Jack Howarth  wrote:
> The use of an Apple sandbox with denied file access permissions into 
> /usr/local
> exposed that cc1 fails on errors of...
>
> cc1: error: /usr/local/include: Operation not permitted
>
> The commonly suggested solution of using --with-local-prefix= set to something
> other than /usr/local is undeirable on darwin because that creates a compiler
> which retains library searches in /usr/local/lib despite no longer searching
> for headers in /usr/local/include (which makes it suspicable to header/library
> mismatches during builds).
>
> The following trivial fix solves the issue by silently ignoring errors from
> denied permissions as well as non-existent dirs from the stat (cur->name, )
> call in remove_dup() of gcc/incpath.c. Okay for gcc trunk and backports to
> gcc-5-branch and gcc-6-branch?
>Jack Howarth

Perhaps it would be useful if I expounded a bit on the
complexities that this
PR introduces on darwin. Both MacPorts and now fink leverage the Apple sandbox
to avoid contaminating their builds with development files installed
in /usr/local.
However the FSF gcc compiler packages built still should allow end-users to
build against /usr/local as normal outside of the packaging systems. On darwin,
it has been suggested that the sandbox build issues of FSF gcc be addressed by
using ---sysroot instead. Unfortunately that approach in not viable because the
Xcode developers no longer bundle the SDK of the prior OS in Xcode.app once
a new OS is released. Thus using the SDK installed at / is the only
option (since
building against the next OS SDK on the prior OS is unsupported on darwin),
and this nullifies the ability to use --sysroot to work around this issue.

I believe the proposed patch is a trivial and straightforward solution
which allows
darwin developers to package the FSF gcc compilers within an Apple sandbox
while retaining the ability of the built compilers to behave as expect
with regard
to /usr/local outside of the Apple sandbox.
 Jack

[PATCH] Fix PR driver/78206 by silently ignoring EPERM as well as ENOENT

[Jack Howarth]

The use of an Apple sandbox with denied file access permissions into /usr/local
exposed that cc1 fails on errors of...

cc1: error: /usr/local/include: Operation not permitted

The commonly suggested solution of using --with-local-prefix= set to something
other than /usr/local is undeirable on darwin because that creates a compiler
which retains library searches in /usr/local/lib despite no longer searching
for headers in /usr/local/include (which makes it suspicable to header/library
mismatches during builds).

The following trivial fix solves the issue by silently ignoring errors from
denied permissions as well as non-existent dirs from the stat (cur->name, )
call in remove_dup() of gcc/incpath.c. Okay for gcc trunk and backports to
gcc-5-branch and gcc-6-branch?
   Jack Howarth


PR78206.patch
Description: Binary data

[patch, fortran, committed] Fix PR 78221

[Thomas Koenig]

Hello world,

I have committed the attached patch to the regression as obvious and
simple after regression-testing.  Will commit to gcc 6 in a
few days.

Regards

Thomas

2016-11-06  Thomas Koenig  

PR fortran/78221
* arith.c (gfc_complex2real):  Change gfc_warning_now to
gfc_warning.

2016-11-06  Thomas Koenig  

PR fortran/78221
* gfortran.dg/warn_conversion_9.f90:  New test.
Index: arith.c
===
--- arith.c	(Revision 241747)
+++ arith.c	(Arbeitskopie)
@@ -2369,10 +2369,10 @@ gfc_complex2real (gfc_expr *src, int kind)
   /* See if we discarded an imaginary part.  */
   if (mpfr_cmp_si (mpc_imagref (src->value.complex), 0) != 0)
 	{
-	  gfc_warning_now (w, "Non-zero imaginary part discarded "
-			   "in conversion from %qs to %qs at %L",
-			   gfc_typename(>ts), gfc_typename (>ts),
-			   >where);
+	  gfc_warning (w, "Non-zero imaginary part discarded "
+		   "in conversion from %qs to %qs at %L",
+		   gfc_typename(>ts), gfc_typename (>ts),
+		   >where);
 	  did_warn = true;
 	}
 
! { dg-do compile }
! { dg-options "-Wconversion" }
! PR 78221 - used to give a spurious warning
complex, parameter :: i = (0.,1.)
complex :: t
t = (i)
end

Re: [PATCH, vec-tails] Support loop epilogue vectorization

[Richard Biener]

On November 5, 2016 3:40:04 AM GMT+01:00, Jeff Law  wrote:
>On 11/02/2016 06:27 AM, Richard Biener wrote:
>> I'm still torn about all the rest of the stuff and question its
>> usability (esp. merging the epilogue with the main vector loop).
>> But it has already been approved ... oh well.
>Note that merging of the epilogue with the main vector loop may well be
>
>useful for SVE as well.  I'm hoping Richard S. will chime in on how to 
>best exploit SVE.

Possibly, but full exploitation of SVE requires a full vectorizer rewrite.  The 
only thing I can see us implementing is making the vector size fixed via 
versioning, that is, let the user specify -mvecsize=N and if that's not the 
case at runtime trap or execute a scalar variant.

Richard.

>Jeff

Re: [PATCH 5/5] [AARCH64] Add variant support to -m="native"and add thunderxt88p1.

[Andrew Pinski]

 /On Wed, Nov 2, 2016 at 3:54 AM, James Greenhalgh
 wrote:
> On Tue, Nov 01, 2016 at 11:08:53AM -0700, Andrew Pinski wrote:
>> On Tue, Nov 17, 2015 at 2:10 PM, Andrew Pinski  wrote:
>> > Since ThunderX T88 pass 1 (variant 0) is a ARMv8 part while pass 2 
>> > (variant 1)
>> > is an ARMv8.1 part, I needed to add detecting of the variant also for this
>> > difference. Also I simplify a little bit and combined the single core and
>> > arch detecting cases so it would be easier to add variant.
>>
>> Actually it is a bit more complex than what I said here, see below for
>> the full table of options and what are enabled/disabled now.
>>
>> > OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
>> > Tested -mcpu=native on both T88 pass 1 and T88 pass 2 to make sure it is
>> > deecting the two seperately.
>>
>>
>> Here is the final patch in this series updated; I changed the cpu name
>> slightly and made sure I updated invoke.texi too.
>>
>> The names are going to match the names in LLVM (worked with our LLVM
>> engineer here at Cavium about the names).
>> Here are the names recorded and
>> -mpcu=thunderx:
>> *Matches part num 0xA0 (reserved for ThunderX 8x series)
>> *T88 Pass 2 scheduling
>> *Hardware prefetching (software prefetching disabled)
>> *LSE enabled
>> *no v8.1
>
> This doesn't match the current LLVM proposal
> ( https://reviews.llvm.org/D24540 ) which enables full ARMv8.1-A support
> for -mcpu=thunderx.
>
>> -mcpu=thunderxt88:
>> *Matches part num 0xA1
>> *T88 Pass 2 scheduling
>> *software prefetching enabled
>> *LSE enabled
>> *no v8.1
>>
>> -mcpu=thunderxt88p1 (only for GCC):
>> *Matches part num 0xA1, variant 0
>> *T88 Pass 1 scheduling
>> *software prefetching enabled
>> *no LSE enabled
>> *no v8.1
>>
>> -mcpu=thunderxt81 and -mcpu=thunderxt83:
>> *Matches part num 0xA2/0xA3
>> *T88 Pass 2 scheduling
>> *Hardware prefetching (software prefetching disabled)
>> *LSE enabled
>> *v8.1
>
> This looks like what has been added to LLVM as -mcpu=thunderx.

Yes I Know as I tried to mention we came up with this set after both
submission happened; next time both myself and my LLVM team will will
come to an agreement on names before posting to both LLVM and GCC.

>
>> I have not hooked up software vs hardware prefetching and the
>> scheduler parts (the next patch will do part of that); both ARMv8.1-a
>> and LSE parts are hooked up as those parts are only in
>> aarch64-cores.def.
>>
>> OK?  Bootstrapped and tested on ThunderX T88 and ThunderX T81
>> (aarch64-linux-gnu).
>>
>> Index: common/config/aarch64/aarch64-common.c
>> ===
>> --- common/config/aarch64/aarch64-common.c(revision 241727)
>> +++ common/config/aarch64/aarch64-common.c(working copy)
>> @@ -145,7 +145,7 @@ struct arch_to_arch_name
>> the default set of architectural feature flags they support.  */
>>  static const struct processor_name_to_arch all_cores[] =
>>  {
>> -#define AARCH64_CORE(NAME, X, IDENT, ARCH_IDENT, FLAGS, COSTS, IMP, PART) \
>> +#define AARCH64_CORE(NAME, X, IDENT, ARCH_IDENT, FLAGS, COSTS, IMP, PART, 
>> VARIANT) \
>>{NAME, AARCH64_ARCH_##ARCH_IDENT, FLAGS},
>>  #include "config/aarch64/aarch64-cores.def"
>>{"generic", AARCH64_ARCH_8A, AARCH64_FL_FOR_ARCH8},
>> Index: config/aarch64/aarch64-cores.def
>> ===
>> --- config/aarch64/aarch64-cores.def  (revision 241727)
>> +++ config/aarch64/aarch64-cores.def  (working copy)
>> @@ -21,7 +21,7 @@
>>
>> Before using #include to read this file, define a macro:
>>
>> -  AARCH64_CORE(CORE_NAME, CORE_IDENT, SCHEDULER_IDENT, ARCH_IDENT, 
>> FLAGS, COSTS, IMP, PART)
>> +  AARCH64_CORE(CORE_NAME, CORE_IDENT, SCHEDULER_IDENT, ARCH_IDENT, 
>> FLAGS, COSTS, IMP, PART, VARIANT)
>>
>> The CORE_NAME is the name of the core, represented as a string constant.
>> The CORE_IDENT is the name of the core, represented as an identifier.
>> @@ -39,39 +39,45 @@
>> PART is the part number of the CPU.  On a GNU/Linux system it can be
>> found in /proc/cpuinfo.  For big.LITTLE systems this should use the
>> macro AARCH64_BIG_LITTLE where the big part number comes as the first
>> -   argument to the macro and little is the second.  */
>> +   argument to the macro and little is the second.
>> +   VARIANT is the variant of the CPU.  In a GNU/Linux system it can found
>> +   in /proc/cpuinfo.  If this is -1, this means it can match any variant.  
>> */
>>
>>  /* V8 Architecture Processors.  */
>>
>>  /* ARM ('A') cores. */
>> -AARCH64_CORE("cortex-a35",  cortexa35, cortexa53, 8A,  AARCH64_FL_FOR_ARCH8 
>> | AARCH64_FL_CRC, cortexa35, 0x41, 0xd04)
>> -AARCH64_CORE("cortex-a53",  cortexa53, cortexa53, 8A,