Re: [PATCH, x86, libgcc] PR target/83917 Correct debug for -mcall-ms2sysv-xlogues stubs

[Jakub Jelinek]

On Sat, Jan 20, 2018 at 06:01:16PM -0600, Daniel Santos wrote:
> As far as adding tests, I guess I would need to dig into
> lib/gcc-gdb-test.exp to figure out how to do that.

The gdb-test infrastructure allows essentially
b linenumber
p something
p somethingother

Not sure if it would work if instead of using a number of linenumber
you'd use the symbol for these snippets or symbol+number,
plus you are interested not in printing values of variables there, but
about sensible backtraces. 

Probably gdb's testsuite is better suited for that.

Jakub

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

[Eric Gallager]

On 1/19/18, Nathan Sidwell  wrote:
> Jason,
> what do you think about deprecating the ARM-era for-scope handling that
> allows:
>void f ()
>{
>  for (int i = 0;;);
>  i = 2;
>}
>
> we noisily accept that in c++98 mode with -fpermissive.  It wasn't even
> well formed then.  Implementing this has some unique requirements in the
> name-lookup machinery, which I ran into again today.
>
> Option A: rip out now because it's a c++98 ARM-compatibility crutch
> Option B: deprecate in gcc-8 and remove in gcc-9.
>

I support Option B because it's good to let people know ahead of time
about impending removals of things

> nathan
>
> --
> Nathan Sidwell
>

[SH][committed] Fix PR 80870

[Oleg Endo]

Hi,

The following fixed PR 80870.
For whatever reason one of the source files in config/sh was still
including  and  directly...

Committed as r256926 (trunk), r256928 (GCC 7), r256929 (GCC 6).

Cheers,
Oleg

gcc/ChangeLog:
PR target/80870
* config/sh/sh_optimize_sett_clrt.cc:
Use INCLUDE_ALGORITHM and INCLUDE_VECTOR instead of direct includes.Index: gcc/config/sh/sh_optimize_sett_clrt.cc
===
--- gcc/config/sh/sh_optimize_sett_clrt.cc	(revision 256924)
+++ gcc/config/sh/sh_optimize_sett_clrt.cc	(working copy)
@@ -20,6 +20,8 @@
 #define IN_TARGET_CODE 1
 
 #include "config.h"
+#define INCLUDE_ALGORITHM
+#define INCLUDE_VECTOR
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
@@ -29,9 +31,6 @@
 #include "cfgrtl.h"
 #include "tree-pass.h"
 
-#include 
-#include 
-
 /*
 This pass tries to eliminate unnecessary sett or clrt instructions in cases
 where the ccreg value is already known to be the same as the constant set
Index: gcc/config/sh/sh_optimize_sett_clrt.cc
===
--- gcc/config/sh/sh_optimize_sett_clrt.cc	(revision 256924)
+++ gcc/config/sh/sh_optimize_sett_clrt.cc	(working copy)
@@ -18,6 +18,8 @@
 .  */
 
 #include "config.h"
+#define INCLUDE_ALGORITHM
+#define INCLUDE_VECTOR
 #include "system.h"
 #include "coretypes.h"
 #include "backend.h"
@@ -27,9 +29,6 @@
 #include "cfgrtl.h"
 #include "tree-pass.h"
 
-#include 
-#include 
-
 /*
 This pass tries to eliminate unnecessary sett or clrt instructions in cases
 where the ccreg value is already known to be the same as the constant set

Re: Compilation warning in simple-object-xcoff.c

[Ian Lance Taylor via gcc-patches]

On Sat, Jan 20, 2018 at 4:47 AM, Eli Zaretskii  wrote:
>> Date: Thu, 18 Jan 2018 05:25:20 +0200
>> From: Eli Zaretskii 
>> CC: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org,   
>> gdb-patc...@sourceware.org
>>
>> > From: DJ Delorie 
>> > Cc: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org, 
>> > gdb-patc...@sourceware.org
>> > Date: Wed, 17 Jan 2018 15:47:49 -0500
>> >
>> > Eli Zaretskii  writes:
>> >
>> > > DJ, would the following semi-kludgey workaround be acceptable?
>> >
>> > It would be no worse than what we have now, if the only purpose is to
>> > avoid a warning.
>> >
>> > Ideally, we would check to see if we're discarding non-zero values from
>> > that offset, and not call the callback with known bogus data.  I suppose
>> > the usefulness of that depends on how often you'll encounter 4Gb+ xcoff64
>> > files on mingw32 ?
>>
>> The answer to that question is "never", AFAIU.
>
> So can the patch I proposed be applied, please?

I committed the patch.

Ian

[wwwdocs][committed] Mention GCC 7 changes for SH and RX

[Oleg Endo]

Hi,

Somehow I never managed to commit the attached patch.
Better late than never.

Cheers,
Oleg? gcc7_rx_sh_update.patch
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.96
diff -r1.96 changes.html
1065c1065,1067
< 
---
> RX
> Basic support for atomic built-in function has been added.  It is currently
> implemented by flipping interrupts off and on as needed.
1067c1069,1094
< 
---
> SH
> 
>   Support for SH5/SH64 has been removed.
>   Improved utilization of delay slots on SH2A.
>   Improved utilization of zero-displacement conditional branches.
>   The following deprecated options have been removed
> 
>   -mcbranchdi
>   -mcmpeqdi
>   -minvalid-symbols
>   -msoft-atomic
>   -mspace
>   -madjust-unroll
> 
>   
>   Support for the following SH2A instructions has been added
> 
>   mov.b  @-Rm,R0
>   mov.w  @-Rm,R0
>   mov.l  @-Rm,R0
>   mov.b  R0,@Rn+
>   mov.w  R0,@Rn+
>   mov.l  R0,@Rn+
> 
>   
> 

Re: [PATCH, x86, libgcc] PR target/83917 Correct debug for -mcall-ms2sysv-xlogues stubs

[Daniel Santos]

On 01/19/2018 05:35 PM, Jakub Jelinek wrote:
> On Fri, Jan 19, 2018 at 05:33:10PM -0600, Daniel Santos wrote:
>> When stepping through tail-call restore stubs the debugger has to assume
>> that rsp - 8 is the CFA, although it is not.  This is because I did not
>> explicitly add any .cfi directives.  This patch adds them to the
>> tail-call restore stubs, but this is new territory for me, so I would
>> appreciate feedback.
>>
>> I've reg-tested on x86_64, but I still need to test on Solaris and
>> Darwin.  OK to commit after those tests?
> I think you can't assume that the assembler supports .cfi_* directives.
> While e.g. libgcc/config/i386/morestack.S uses them unconditionally,
> it is guarded with:
> if test "$libgcc_cv_cfi" = "yes"; then
> tmake_file="${tmake_file} t-stack i386/t-stack-i386"
> fi

Ah hah! That explains a lot.  Yeah, I wasn't thinking all assemblers
would support it but I saw them in the Solaris assembler manual and
figured that they were maybe more widely supported than I had thought.

> in config.host.  E.g. cygwin.S has:
> #ifdef HAVE_GAS_CFI_SECTIONS_DIRECTIVE
> .cfi_sections   .debug_frame
> # define cfi_startproc().cfi_startproc
> # define cfi_endproc()  .cfi_endproc
> # define cfi_adjust_cfa_offset(X)   .cfi_adjust_cfa_offset X
> # define cfi_def_cfa_register(X).cfi_def_cfa_register X
> # define cfi_register(D,S)  .cfi_register D, S
> # ifdef __x86_64__
> #  define cfi_push(X)   .cfi_adjust_cfa_offset 8; .cfi_rel_offset X, 0
> #  define cfi_pop(X).cfi_adjust_cfa_offset -8; .cfi_restore X
> # else
> #  define cfi_push(X)   .cfi_adjust_cfa_offset 4; .cfi_rel_offset X, 0
> #  define cfi_pop(X).cfi_adjust_cfa_offset -4; .cfi_restore X
> # endif
> #else
> # define cfi_startproc()
> # define cfi_endproc()
> # define cfi_adjust_cfa_offset(X)
> # define cfi_def_cfa_register(X)
> # define cfi_register(D,S)
> # define cfi_push(X)
> # define cfi_pop(X)
> #endif /* HAVE_GAS_CFI_SECTIONS_DIRECTIVE */
> perhaps you need something similar or commonize that (though, without
> .cfi_sections, you want the default).
>
>   Jakub

Thanks.  I like the idea of commonizing the macros for consistency.

As far as adding tests, I guess I would need to dig into
lib/gcc-gdb-test.exp to figure out how to do that.

Daniel

Re: [PATCH] C/C++: Add -Waddress-of-packed-member

[H.J. Lu]

On Sat, Jan 20, 2018 at 9:50 AM, H.J. Lu  wrote:
> On Sat, Jan 20, 2018 at 8:31 AM, H.J. Lu  wrote:
>> On Fri, Jan 19, 2018 at 7:57 PM, Martin Sebor  wrote:
>>> On 01/19/2018 10:14 AM, Martin Sebor wrote:

>>
>>> After reading the Clang code review for the warning
>>> (https://reviews.llvm.org/D20561) and experimenting with a few
>>> more test cases I noticed some additional false negatives that
>>> I think would be worthwhile diagnosing:
>>>
>>>   struct A {
>>> int i;
>>>   } __attribute__ ((packed));
>>>
>>>   int f (struct A *p)
>>>   {
>>> return *>i;
>>>   }
>>
>> I now got
>>
>> [hjl@gnu-tools-1 pr51628]$ cat a1.i
>> struct A {
>>   int i;
>> } __attribute__ ((packed));
>>
>> int f (struct A *p)
>> {
>>   return *>i;
>> }
>> [hjl@gnu-tools-1 pr51628]$ make a1.s
>> /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
>> -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -S a1.i
>> a1.i: In function ‘f’:
>> a1.i:7:10: warning: taking address of packed member of ‘struct A’ may
>> result in an unaligned pointer value [-Waddress-of-packed-member]
>>return *>i;
>>   ^~
>> [hjl@gnu-tools-1 pr51628]$
>
>
> It is wrong to warn "*>i;" since GCC always converts to "p->i;".  Unless
> we want to warn
>
> [hjl@gnu-tools-1 pr51628]$ cat g5.i
> struct A {
>   int i;
> } __attribute__ ((packed));
>
> int f (struct A *p)
> {
>   return p->i;
> }
>
> we shouldn't warn:
>
> [hjl@gnu-tools-1 pr51628]$ cat a1.i
> struct A {
>   int i;
> } __attribute__ ((packed));
>
> int f (struct A *p)
> {
>   return *>i;
> }
> [hjl@gnu-tools-1 pr51628]$
>
> There is no unaligned load here.  I am testing a new patch.
>

Here is the updated patch.  Tested on x86-64 and i686.


-- 
H.J.
From e4fb83119762ac8aaa0cd1095e273f5c70e9d4a3 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Fri, 12 Jan 2018 21:12:05 -0800
Subject: [PATCH] C/C++: Add -Waddress-of-packed-member
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When address of packed member of struct or union is taken, it may result
in an unaligned pointer value.  This patch adds -Waddress-of-packed-member
to check alignment at pointer assignment and warn unaligned address as
well as unaligned pointer:

$ cat x.i
struct pair_t
{
  char c;
  int i;
} __attribute__ ((packed));

extern struct pair_t p;
int *addr = 
$ gcc -O2 -S x.i
x.i:8:13:  warning: taking address of packed member of 'struct pair_t' may result in an unaligned pointer value [-Waddress-of-packed-member]
 int *addr = 
 ^
$ cat c.i
struct B { int i; };
struct C { struct B b; } __attribute__ ((packed));

long* g8 (struct C *p) { return p; }
$ gcc -O2 -S c.i -Wno-incompatible-pointer-types
c.i: In function ‘g8’:
c.i:4:33: warning: taking value of packed 'struct C *' may result in an unaligned pointer value [-Waddress-of-packed-member]
 long* g8 (struct C *p) { return p; }
 ^
$

This warning is enabled by default.  Since read_encoded_value_with_base
in unwind-pe.h has

  union unaligned
{
  void *ptr;
  unsigned u2 __attribute__ ((mode (HI)));
  unsigned u4 __attribute__ ((mode (SI)));
  unsigned u8 __attribute__ ((mode (DI)));
  signed s2 __attribute__ ((mode (HI)));
  signed s4 __attribute__ ((mode (SI)));
  signed s8 __attribute__ ((mode (DI)));
} __attribute__((__packed__));
  _Unwind_Internal_Ptr result;

and GCC warns:

gcc/libgcc/unwind-pe.h:210:37: warning: taking address of packed member of 'union unaligned' may result in an unaligned pointer value [-Waddress-of-packed-member]
result = (_Unwind_Internal_Ptr) u->ptr;
^
we need to add GCC pragma to ignore -Waddress-of-packed-member.

gcc/c/

	PR c/51628
	* doc/invoke.texi: Document -Wno-address-of-packed-member.

gcc/c-family/

	PR c/51628
	* c-common.h (warn_for_address_of_packed_member): New.
	* c-warn.c (check_address_of_packed_member): New function.
	(warn_for_address_of_packed_member): Likewise.
	* c.opt: Add -Wno-address-of-packed-member.

gcc/c/

	PR c/51628
	* c-typeck.c (warn_for_pointer_of_packed_member): New function.
	(convert_for_assignment): Call warn_for_address_of_packed_member
	and warn_for_pointer_of_packed_member.

gcc/cp/

	PR c/51628
	* call.c (convert_for_arg_passing): Call
	warn_for_address_of_packed_member.
	* typeck.c (convert_for_assignment): Likewise.

gcc/testsuite/

	PR c/51628
	* c-c++-common/pr51628-1.c: New test.
	* c-c++-common/pr51628-2.c: Likewise.
	* c-c++-common/pr51628-3.c: Likewise.
	* c-c++-common/pr51628-4.c: Likewise.
	* c-c++-common/pr51628-5.c: Likewise.
	* c-c++-common/pr51628-6.c: Likewise.
	* c-c++-common/pr51628-7.c: Likewise.
	* c-c++-common/pr51628-8.c: Likewise.
	* c-c++-common/pr51628-9.c: Likewise.
	* c-c++-common/pr51628-10.c: Likewise.
	* c-c++-common/pr51628-11.c: Likewise.
	* c-c++-common/pr51628-12.c: Likewise.
	* c-c++-common/pr51628-13.c: 

Re: [PATCH] PR fortran/83900 -- follow-up to set type

[Jerry DeLisle]

On 01/20/2018 12:19 PM, Steve Kargl wrote:
> The attache patch is a follow-up to my patch for
> PR fortran/83900, which removed a bogus assert.
> This allowed gfc_simplify_matmul to do its job,
> except it did not properly set the type of the
> result.  The attach fixes that issue. 
> 
> Regression tested on x86_64-*-freebsd.
> OK to commit?
> 
> 
> 2018-01-20  Steven G. Kargl  
> 
>   PR fortran/83900
> * simplify.c (gfc_simplify_matmul): Set return type correctly.
> 
> 2018-01-20  Steven G. Kargl  
> 
>   PR fortran/83900
>   * gfortran.dg/matmul_18.f90: New test.
> 

OK, thanks for fix.

Jerry

[PATCH] PR fortran/83900 -- follow-up to set type

[Steve Kargl]

The attache patch is a follow-up to my patch for
PR fortran/83900, which removed a bogus assert.
This allowed gfc_simplify_matmul to do its job,
except it did not properly set the type of the
result.  The attach fixes that issue. 

Regression tested on x86_64-*-freebsd.
OK to commit?


2018-01-20  Steven G. Kargl  

PR fortran/83900
* simplify.c (gfc_simplify_matmul): Set return type correctly.

2018-01-20  Steven G. Kargl  

PR fortran/83900
* gfortran.dg/matmul_18.f90: New test.

-- 
Steve
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c	(revision 256912)
+++ gcc/fortran/simplify.c	(working copy)
@@ -4590,9 +4590,23 @@ gfc_simplify_matmul (gfc_expr *matrix_a, gfc_expr *mat
   || !is_constant_array_expr (matrix_b))
 return NULL;
 
-  result = gfc_get_array_expr (matrix_a->ts.type,
-			   matrix_a->ts.kind,
-			   _a->where);
+  /* MATMUL should do mixed-mode arithmetic.  Set the result type.  */
+  if (matrix_a->ts.type != matrix_b->ts.type)
+{
+  gfc_expr e;
+  e.expr_type = EXPR_OP;
+  gfc_clear_ts ();
+  e.value.op.op = INTRINSIC_NONE;
+  e.value.op.op1 = matrix_a;
+  e.value.op.op2 = matrix_b;
+  gfc_type_convert_binary (, 1);
+  result = gfc_get_array_expr (e.ts.type, e.ts.kind, _a->where);
+}
+  else
+{
+  result = gfc_get_array_expr (matrix_a->ts.type, matrix_a->ts.kind,
+   _a->where);
+}
 
   if (matrix_a->rank == 1 && matrix_b->rank == 2)
 {
Index: gcc/testsuite/gfortran.dg/matmul_18.f90
===
--- gcc/testsuite/gfortran.dg/matmul_18.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/matmul_18.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do run }
+program p
+   integer, parameter :: a(3,2) = 1
+   real, parameter :: b(2,3) = 2
+   real d(3,3)
+   d = 4
+   if (any(d /= matmul(a,b))) call abort
+end

Re: [PATCH] C/C++: Add -Waddress-of-packed-member

[H.J. Lu]

On Sat, Jan 20, 2018 at 8:31 AM, H.J. Lu  wrote:
> On Fri, Jan 19, 2018 at 7:57 PM, Martin Sebor  wrote:
>> On 01/19/2018 10:14 AM, Martin Sebor wrote:
>>>
>
>> After reading the Clang code review for the warning
>> (https://reviews.llvm.org/D20561) and experimenting with a few
>> more test cases I noticed some additional false negatives that
>> I think would be worthwhile diagnosing:
>>
>>   struct A {
>> int i;
>>   } __attribute__ ((packed));
>>
>>   int f (struct A *p)
>>   {
>> return *>i;
>>   }
>
> I now got
>
> [hjl@gnu-tools-1 pr51628]$ cat a1.i
> struct A {
>   int i;
> } __attribute__ ((packed));
>
> int f (struct A *p)
> {
>   return *>i;
> }
> [hjl@gnu-tools-1 pr51628]$ make a1.s
> /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -S a1.i
> a1.i: In function ‘f’:
> a1.i:7:10: warning: taking address of packed member of ‘struct A’ may
> result in an unaligned pointer value [-Waddress-of-packed-member]
>return *>i;
>   ^~
> [hjl@gnu-tools-1 pr51628]$


It is wrong to warn "*>i;" since GCC always converts to "p->i;".  Unless
we want to warn

[hjl@gnu-tools-1 pr51628]$ cat g5.i
struct A {
  int i;
} __attribute__ ((packed));

int f (struct A *p)
{
  return p->i;
}

we shouldn't warn:

[hjl@gnu-tools-1 pr51628]$ cat a1.i
struct A {
  int i;
} __attribute__ ((packed));

int f (struct A *p)
{
  return *>i;
}
[hjl@gnu-tools-1 pr51628]$

There is no unaligned load here.  I am testing a new patch.

-- 
H.J.

Re: [PATCH, rs6000] Requested cleanups for BE handling of -mno-speculate-indirect-jumps

[Segher Boessenkool]

Hi!

On Fri, Jan 19, 2018 at 09:46:27PM -0600, Bill Schmidt wrote:
> Segher had previously requested some cleanups in 
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01605.html.
> Due to time pressures, I delayed those, but they are ready now.  Here they 
> are,
> bootstrapped and tested on powerpc64le-linux-gnu and powerpc64-linux-gnu.  Is
> this okay for trunk?  I don't intend to backport these.

This is fine for trunk, with one fix (see below).  You may want to hold
off on it until the 7 backports are done, but that's up to you.

> 2018-01-19  Bill Schmidt  
> 
>   * config/rs6000/rs6000.md (*call_indirect_nonlocal_sysv):
>   Simplify the clause that sets the length attribute.
>   (*call_value_indirect_nonlocal_sysv): Likewise.
>   (*sibcall_nonlocal_sysv): Clean up code block; simplify the
>   clause that sets the length attribute.
>   (*sibcall_value_nonlocal_sysv): Likewise.


>   /* Can use CR0 since it is volatile across sibcalls.  */
> - return \"crset eq\;beq%T0-\;b $\";
> + return "crset eq;beq%T0-;b $";

This should still use \; .

>   /* Can use CR0 since it is volatile across sibcalls.  */
> - return \"crset eq\;beq%T1-\;b $\";
> + return "crset eq;beq%T1-;b $";

Same here.

Thanks for the patch,


Segher

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

[Ximin Luo]

Boris Kolpackov:
> Ximin Luo  writes:
>> Boris Kolpackov:
>>
>>> This does feel like we are trying to fix the issue in the wrong place.
>>> Also, won't such broken packages normally store all options (including
>>> -I) rather than just CFLAGS? And if the answer is no, then perhaps you
>>> could put -ffile-prefix-map into CPPFLAGS instead of CFLAGS? Kind of
>>> even feels right seeing that it affects the preprocessor.
>>>
>>
>> The broad issue affects -fdebug-prefix-map as well, not just __FILE__.
> 
> -ffile-prefix-map is the "common" option that (currently)
> takes care of both debug and macro remapping (and should we
> add any new -f*-prefix-map, those as well).
> 
>> Such packages are not "broken"; GCC itself stores command-line
>> arguments in DW_AT_producer and as mentioned there was a bug to
>> special-case filtering -fdebug-prefix-map out of that.
>>
>> Now we'll have to add exceptions for -ffile-prefix-map and all
>> the other flags you added, and everything else that might be
>> added in future.
> 
> -ffile-prefix-map and -fmacro-prefix-map are already excluded.
> And there is a note at the appropriate place in source code to
> exclude any new -f*-prefix-map should they be added.
> 

Fair enough, I didn't look at your entire patch. But don't you think stripping 
the whole value is unnecessary? One advantage of the ENV: approach is that we 
can remove this filtering, and then the =$to part can be present in 
DW_AT_producer, indicating the fact that the flag was indeed used, and what the 
$to value was. That would be helpful for debugging actually.

> You also haven't answered my question about -I: don't the
> projects that embed CFLAGS also embed CPPFLAGS (and thus
> -I's with absolute/varying paths)? And if the answer is
> no, then can't you use the same approach to make
> -ffile-prefix-map a non-issue?
> 

-I to an absolute path is not that common for system / distro-built stuff. In 
the cases that it occurs, indeed it could and should be fixed by the package 
buildsystem, e.g. by stripping a prefix when they add -I flags to CFLAGS. But 
that's a separate issue from what we're talking about here.

One major use-case for this flag, is to be set for all builds by the 
distribution. (Setting it per-package would be much much more work.) In this 
case, even if the build is using relative paths for -I and setting $PWD to an 
relative path for __FILE__ (and this behaviour is not explicitly mentioned in 
any standard), as long as they save CFLAGS/CPPFLAGS their build would not be 
reproducible.

I don't think it would be fair to impose this behaviour on packages, even if 
they are doing *everything else correctly* for reproducibility purposes.

For example this one, the unreproducibility diff exists because we temporarily 
reverted to an unpatched dpkg (i.e. it sets -fdebug-prefix-map rather than 
using the envvar supported by our patched GCC):

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/freeradius.html

(Then there are other programs that like to put cflags/cppflags in their --help 
text for debugging purposes, etc.)

It does *everything else right* but the presence of that system-wide flag 
causes it to be unreproducible. If GCC does not support an envvar or other 
similar method to pass in this flag, then these packages are the ones that 
suffer.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Re: [PATCH] C/C++: Add -Waddress-of-packed-member

[H.J. Lu]

On Fri, Jan 19, 2018 at 7:57 PM, Martin Sebor  wrote:
> On 01/19/2018 10:14 AM, Martin Sebor wrote:
>>
>> On 01/14/2018 07:29 AM, H.J. Lu wrote:
>>>
>>> When address of packed member of struct or union is taken, it may result
>>> in an unaligned pointer value.  This patch adds
>>> -Waddress-of-packed-member
>>> to warn it:
>>>
>>> $ cat x.i
>>> struct pair_t
>>> {
>>>   char c;
>>>   int i;
>>> } __attribute__ ((packed));
>>>
>>> extern struct pair_t p;
>>> int *addr = 
>>> $ gcc -O2 -S x.i
>>> x.i:8:13: warning: initialization of 'int *' from address of packed
>>> member of 'struct pair_t' may result in an unaligned pointer value
>>> [-Waddress-of-packed-member]
>>>  int *addr = 
>>>  ^
>>> $
>>>
>>> This warning is enabled by default.
>>
>>
>> I like this enhancement.  It would be useful for data types,
>> packed or not, such as casting int* to long*.
>>
>> I noticed some differences from Clang for the test case below.
>> It seems that GCC should warn on all the cases Clang does.
>>
>> Also, since converting the address of a struct to that of its
>> first member is common (especially in C and when the member
>> itself is a struct) I wonder if the warning should trigger
>> for those conversions as well.
>>
>> struct A {
>>   int i;
>> } __attribute__ ((packed));
>>
>> long* f8 (struct A *p) { return >i; }   // Clang only
>> int* f4 (struct A *p) { return >i; }// Clang, GCC
>> short* f2 (struct A *p) { return >i; }  // Clang only
>> char* f1 (struct A *p) { return >i; }
>> void* f0 (struct A *p) { return >i; }
>>
>> struct B { int i; };
>> struct C { struct B b; } __attribute__ ((packed));
>>
>> long* g8 (struct C *p) { return p; }// should warn?
>> int* g4 (struct C *p) { return >b; } // Clang only
>>
>> int* h4 (struct C *p) { return >b.i; }   // Clang only
>>

With my current patch, I got

[hjl@gnu-tools-1 pr51628]$ cat m1.c
struct A {
  int i;
} __attribute__ ((packed));

long* f8 (struct A *p) { return >i; }   // Clang only
int* f4 (struct A *p) { return >i; }// Clang, GCC
short* f2 (struct A *p) { return >i; }  // Clang only
char* f1 (struct A *p) { return >i; }
void* f0 (struct A *p) { return >i; }

struct B { int i; };
struct C { struct B b; } __attribute__ ((packed));

long* g8 (struct C *p) { return p; }// should warn?
int* g4 (struct C *p) { return >b; } // Clang only

int* h4 (struct C *p) { return >b.i; }   // Clang only
[hjl@gnu-tools-1 pr51628]$ make m1.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -S m1.c
m1.c: In function ‘f8’:
m1.c:5:33: warning: returning ‘int *’ from a function with
incompatible return type ‘long int *’ [-Wincompatible-pointer-types]
 long* f8 (struct A *p) { return >i; }   // Clang only
 ^
m1.c:5:33: warning: taking address of packed member of ‘struct A’ may
result in an unaligned pointer value [-Waddress-of-packed-member]
m1.c: In function ‘f4’:
m1.c:6:32: warning: taking address of packed member of ‘struct A’ may
result in an unaligned pointer value [-Waddress-of-packed-member]
 int* f4 (struct A *p) { return >i; }// Clang, GCC
^
m1.c: In function ‘f2’:
m1.c:7:34: warning: returning ‘int *’ from a function with
incompatible return type ‘short int *’ [-Wincompatible-pointer-types]
 short* f2 (struct A *p) { return >i; }  // Clang only
  ^
m1.c:7:34: warning: taking address of packed member of ‘struct A’ may
result in an unaligned pointer value [-Waddress-of-packed-member]
m1.c: In function ‘f1’:
m1.c:8:33: warning: returning ‘int *’ from a function with
incompatible return type ‘char *’ [-Wincompatible-pointer-types]
 char* f1 (struct A *p) { return >i; }
 ^
m1.c: In function ‘g8’:
m1.c:14:33: warning: returning ‘struct C *’ from a function with
incompatible return type ‘long int *’ [-Wincompatible-pointer-types]
 long* g8 (struct C *p) { return p; }// should warn?
 ^
m1.c:14:33: warning: taking pointer of packed ‘struct C *’ may result
in an unaligned pointer value [-Waddress-of-packed-member]
m1.c: In function ‘g4’:
m1.c:15:32: warning: returning ‘struct B *’ from a function with
incompatible return type ‘int *’ [-Wincompatible-pointer-types]
 int* g4 (struct C *p) { return >b; } // Clang only
^
m1.c:15:32: warning: taking address of packed member of ‘struct C’ may
result in an unaligned pointer value [-Waddress-of-packed-member]
m1.c: In function ‘h4’:
m1.c:17:32: warning: taking address of packed member of ‘struct C’ may
result in an unaligned pointer value [-Waddress-of-packed-member]
 int* h4 (struct C *p) { return >b.i; }   // Clang only
^~~
[hjl@gnu-tools-1 pr51628]$

> After reading the Clang code review for the warning
> (https://reviews.llvm.org/D20561) and experimenting with a 

Re: [PATCH PR82604]Fix regression in ftree-parallelize-loops

[Bin.Cheng]

On Fri, Jan 19, 2018 at 5:42 PM, Bin Cheng  wrote:
> Hi,
> This patch is supposed to fix regression caused by loop distribution when
> ftree-parallelize-loops.  The reason is distributed memset call can't be
> understood/analyzed in data reference analysis, as a result, parloop can
> only parallelize the innermost 2-level loop nest.  Before distribution
> change, parloop can parallelize the innermost 3-level loop nest, i.e,
> more parallelization.
> As commented in the PR, ideally, loop distribution should be able to
> distribute memset call for 3-level loop nest.  Unfortunately this requires
> sophisticated work proving equality between tree expressions which gcc
> is not good at now.
> Another fix is to improve data reference analysis so that memset call
> can be supported.  We don't know how big this change is and it's definitely
> not GCC 8 task.
>
> So this patch fixes the regression in a bit hacking way.  It first enables
> 3-level loop nest distribution when flag_tree_parloops > 1.  Secondly, it
> supports 3-level loop nest distribution for ZERO-ing stmt which can only
> be distributed as a loop (nest) of memset, but can't be distributed as a
> single memset.  The overall effect is ZERO-ing stmt will be distributed
> to one loop deeper than now, so parloop can parallelize as before.
>
> Bootstrap and test on x86_64 and AArch64 ongoing.  Is it OK if no errors?
Test finished without error.  Also I checked
-ftree-parallelize-loops=6 on AArch64 and can confirm the regression
is resolved.

Thanks,
bin
>
> Thanks,
> bin
> 2018-01-19  Bin Cheng  
>
> PR tree-optimization/82604
> * tree-loop-distribution.c (enum partition_kind): New enum item
> PKIND_PARTIAL_MEMSET.
> (partition_builtin_p): Support above new enum item.
> (generate_code_for_partition): Ditto.
> (compute_access_range): Differentiate cases that equality can be
> proven at all loops, the innermost loops or no loops.
> (classify_builtin_st, classify_builtin_ldst): Adjust call to above
> function.  Set PKIND_PARTIAL_MEMSET for partition appropriately.
> (finalize_partitions, distribute_loop): Don't fuse partition of
> PKIND_PARTIAL_MEMSET kind when distributing 3-level loop nest.
> (prepare_perfect_loop_nest): Distribute 3-level loop nest only if
> parloop is enabled.

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

[Boris Kolpackov]

Ximin Luo  writes:

> Boris Kolpackov:
>
> > This does feel like we are trying to fix the issue in the wrong place.
> > Also, won't such broken packages normally store all options (including
> > -I) rather than just CFLAGS? And if the answer is no, then perhaps you
> > could put -ffile-prefix-map into CPPFLAGS instead of CFLAGS? Kind of
> > even feels right seeing that it affects the preprocessor.
> > 
> 
> The broad issue affects -fdebug-prefix-map as well, not just __FILE__.

-ffile-prefix-map is the "common" option that (currently)
takes care of both debug and macro remapping (and should we
add any new -f*-prefix-map, those as well).


> Such packages are not "broken"; GCC itself stores command-line
> arguments in DW_AT_producer and as mentioned there was a bug to
> special-case filtering -fdebug-prefix-map out of that.
> 
> Now we'll have to add exceptions for -ffile-prefix-map and all
> the other flags you added, and everything else that might be
> added in future.

-ffile-prefix-map and -fmacro-prefix-map are already excluded.
And there is a note at the appropriate place in source code to
exclude any new -f*-prefix-map should they be added.

You also haven't answered my question about -I: don't the
projects that embed CFLAGS also embed CPPFLAGS (and thus
-I's with absolute/varying paths)? And if the answer is
no, then can't you use the same approach to make
-ffile-prefix-map a non-issue?

Boris

[AARCH64]Bug in fix for branch offsets over 1 MiB?

[Sameera Deshpande]

Hi!

I am seeing multiple assembler errors with error message "Error:
conditional branch out of range" for customer code.

The root cause of the bug is that conditional branches are generated
whose branch target ends up being too far away to be encoded in the
instruction.  It appears that there was an attempt to fix this issue
in the below change:

commit 050af05b9761f1979f11c151519e7244d5becd7c
Author: thopre01 
Date:   Thu Aug 27 10:08:54 2015 +

2015-08-27  Ramana Radhakrishnan
<[ramana.radhakrish...@arm.com|mailto:ramana.radhakrish...@arm.com]>
Andre Vieira
<[andre.simoesdiasvie...@arm.com|mailto:andre.simoesdiasvie...@arm.com]>

gcc/
* config/aarch64/[aarch64.md|http://aarch64.md/] (*condjump):
Handle functions > 1 MiB.
(*cb1): Likewise.
(*tb1): Likewise.
(*cb1): Likewise.
* config/aarch64/[iterators.md|http://iterators.md/] (inv_cb):
New code attribute.
(inv_tb): Likewise.
* config/aarch64/aarch64.c (aarch64_gen_far_branch): New.
* config/aarch64/aarch64-protos.h (aarch64_gen_far_branch): New.

gcc/testsuite/
* gcc.target/aarch64/long_branch_1.c: New test.

However, as per GCC Internal documentation, only special attribute
"length" should use PC and match_dup while defining an attribute. I
verified by looking at code in final pass, and realised that
get_attribute_length does not map directly to the functions generated
from the definition of attribute length in RTL patterns, but computes
the lengths in shorten_branches and uses insn_current_length as
intermediate function.

The far_branch attribute defined similar to attribute length expects
same values to be returned by (minus (match_dup 2) (pc)) which is
incorrect.

I am looking at TARGET_MACHINE_DEPENDENT_REORG macro instead like few
other architectures, to emit far branches.

Is that approach acceptable?

PS: I am waiting for customer's approval for attaching the test case.

-- 
- Thanks and regards,
  Sameera D.

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

[Richard Biener]

On January 20, 2018 4:34:20 AM GMT+01:00, Bill Schmidt 
 wrote:
>Forgot to mention, these have also been tested successfully as
>backports in
>gcc-7-branch.  Okay to fix there as well?

OK. 

Richard. 

>Thanks,
>Bill
>
>> On Jan 19, 2018, at 9:31 PM, Bill Schmidt
> wrote:
>> 
>> Hi,
>> 
>> Here's the same patch with corrected test cases.  This has now passed
>> bootstrap and testing on powerpc64-linux-gnu and
>powerpc64le-linux-gnu
>> with no regressions.  Is this okay for trunk?
>> 
>> Hopefully tomorrow early I will have a separate patch also changing
>> "setcr eq" to "setcr 2" to accommodate the AIX assembler.
>> 
>> Thanks,
>> Bill
>> 
>> 
>> [gcc]
>> 
>> 2018-01-19  Bill Schmidt  
>>  David Edelsohn 
>> 
>>  PR target/83946
>>  * config/rs6000/rs6000.md (*sibcall_nonlocal_sysv): Change
>>  assembly output from . to $.
>>  (*sibcall_value_nonlocal_sysv): Likewise.
>>  (indirect_jump_nospec): Likewise.
>>  (*tablejump_internal1_nospec): Likewise.
>> 
>> [gcc/testsuite]
>> 
>> 2018-01-19  Bill Schmidt  
>>  David Edelsohn 
>> 
>>  PR target/83946
>>  * gcc.target/powerpc/safe-indirect-jump-2.c: Change expected
>>  assembly output from . to $.
>>  * gcc.target/powerpc/safe-indirect-jump-3.c: Likewise.
>>  * gcc.target/powerpc/safe-indirect-jump-8.c: Likewise.
>> 
>> 
>> Index: gcc/config/rs6000/rs6000.md
>> ===
>> --- gcc/config/rs6000/rs6000.md  (revision 256894)
>> +++ gcc/config/rs6000/rs6000.md  (working copy)
>> @@ -10987,7 +10987,7 @@
>>  return \"b%T0\";
>>   else
>>  /* Can use CR0 since it is volatile across sibcalls.  */
>> -return \"crset eq\;beq%T0-\;b .\";
>> +return \"crset eq\;beq%T0-\;b $\";
>> }
>>   else if (DEFAULT_ABI == ABI_V4 && flag_pic)
>> {
>> @@ -11044,7 +11044,7 @@
>>  return \"b%T1\";
>>   else
>>  /* Can use CR0 since it is volatile across sibcalls.  */
>> -return \"crset eq\;beq%T1-\;b .\";
>> +return \"crset eq\;beq%T1-\;b $\";
>> }
>>   else if (DEFAULT_ABI == ABI_V4 && flag_pic)
>> {
>> @@ -12566,7 +12566,7 @@
>>   [(set (pc) (match_operand:P 0 "register_operand" "c,*l"))
>>(clobber (match_operand:CC 1 "cc_reg_operand" "=y,y"))]
>>   "!rs6000_speculate_indirect_jumps"
>> -  "crset %E1\;beq%T0- %1\;b ."
>> +  "crset %E1\;beq%T0- %1\;b $"
>>   [(set_attr "type" "jmpreg")
>>(set_attr "length" "12")])
>> 
>> @@ -12672,7 +12672,7 @@
>>(use (label_ref (match_operand 1)))
>>(clobber (match_operand:CC 2 "cc_reg_operand" "=y,y"))]
>>   "!rs6000_speculate_indirect_jumps"
>> -  "crset %E2\;beq%T0- %2\;b ."
>> +  "crset %E2\;beq%T0- %2\;b $"
>>   [(set_attr "type" "jmpreg")
>>(set_attr "length" "12")])
>> 
>> Index: gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-2.c
>> ===
>> --- gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-2.c  (revision
>256894)
>> +++ gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-2.c  (working
>copy)
>> @@ -30,4 +30,4 @@ int foo (int x)
>> 
>> /* { dg-final { scan-assembler "crset 30" } } */
>> /* { dg-final { scan-assembler "beqctr- 7" } } */
>> -/* { dg-final { scan-assembler "b ." } } */
>> +/* { dg-final { scan-assembler {b \$} } } */
>> Index: gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-3.c
>> ===
>> --- gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-3.c  (revision
>256894)
>> +++ gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-3.c  (working
>copy)
>> @@ -49,4 +49,4 @@ int foo (int x)
>> 
>> /* { dg-final { scan-assembler "crset 30" } } */
>> /* { dg-final { scan-assembler "beqctr- 7" } } */
>> -/* { dg-final { scan-assembler "b ." } } */
>> +/* { dg-final { scan-assembler {b \$} } } */
>> Index: gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-8.c
>> ===
>> --- gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-8.c  (revision
>256894)
>> +++ gcc/testsuite/gcc.target/powerpc/safe-indirect-jump-8.c  (working
>copy)
>> @@ -12,4 +12,4 @@ int bar ()
>> 
>> /* { dg-final { scan-assembler "crset eq" } } */
>> /* { dg-final { scan-assembler "beqctr-" } } */
>> -/* { dg-final { scan-assembler "b ." } } */
>> +/* { dg-final { scan-assembler {b \$} } } */
>> 

Re: [PATCH v3, rs6000] Use $ instead of . for PC, use "crset 2" instead of "crset eq"

[Jakub Jelinek]

On Sat, Jan 20, 2018 at 07:14:56AM -0600, Bill Schmidt wrote:
> On Jan 20, 2018, at 7:12 AM, Segher Boessenkool  
> wrote:
> > 
> > Hi Bill,
> > 
> > On Fri, Jan 19, 2018 at 10:48:18PM -0600, Bill Schmidt wrote:
> >> Here's another version of this patch incorporating the late-breaking news
> >> that the AIX assembler doesn't comprehend the "eq" symbol.  Same as 
> >> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01787.html but adding the
> >> change to use "crset 2" instead.
> >> 
> >> This one is still regstrapping on BE/LE, trunk/7.  If these all complete
> >> successfully, is this okay for trunk and backport?
> > 
> > This looks fine.  Okay for trunk if it also works on AIX.  For 7 you
> > need RM approval (no objections from me).
> 
> Thanks, would appreciate David testing on AIX as I have never managed
> to get that working in the past.  Adding RMs to CC for 7 approval.

Ok for 7.3.

Jakub

Re: [PATCH v3, rs6000] Use $ instead of . for PC, use "crset 2" instead of "crset eq"

[Bill Schmidt]

On Jan 20, 2018, at 7:12 AM, Segher Boessenkool  
wrote:
> 
> Hi Bill,
> 
> On Fri, Jan 19, 2018 at 10:48:18PM -0600, Bill Schmidt wrote:
>> Here's another version of this patch incorporating the late-breaking news
>> that the AIX assembler doesn't comprehend the "eq" symbol.  Same as 
>> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01787.html but adding the
>> change to use "crset 2" instead.
>> 
>> This one is still regstrapping on BE/LE, trunk/7.  If these all complete
>> successfully, is this okay for trunk and backport?
> 
> This looks fine.  Okay for trunk if it also works on AIX.  For 7 you
> need RM approval (no objections from me).

Thanks, would appreciate David testing on AIX as I have never managed
to get that working in the past.  Adding RMs to CC for 7 approval.

Thanks,
Bill
> 
> Thanks!
> 
> 
> Segher
> 
> 
>> 2018-01-19  Bill Schmidt  
>>  David Edelsohn 
>> 
>>  PR target/83946
>>  * config/rs6000/rs6000.md (*call_indirect_nonlocal_sysv):
>>  Change "crset eq" to "crset 2".
>>  (*call_value_indirect_nonlocal_sysv): Likewise.
>>  (*call_indirect_aix_nospec): Likewise.
>>  (*call_value_indirect_aix_nospec): Likewise.
>>  (*call_indirect_elfv2_nospec): Likewise.
>>  (*call_value_indirect_elfv2_nospec): Likewise.
>>  (*sibcall_nonlocal_sysv): Change "crset eq" to "crset 2";
>>  change assembly output from . to $.
>>  (*sibcall_value_nonlocal_sysv): Likewise.
>>  (indirect_jump_nospec): Change assembly output from . to $.
>>  (*tablejump_internal1_nospec): Likewise.
>> 
>> [gcc/testsuite]
>> 
>> 2018-01-19  Bill Schmidt  
>>  David Edelsohn 
>> 
>>  PR target/83946
>>  * gcc.target/powerpc/safe-indirect-jump-1.c: Change expected
>>  assembly output from "crset eq" to "crset 2".
>>  * gcc.target/powerpc/safe-indirect-jump-2.c: Change expected
>>  assembly output from . to $.
>>  * gcc.target/powerpc/safe-indirect-jump-3.c: Likewise.
>>  * gcc.target/powerpc/safe-indirect-jump-1.c: Change expected
>>  assembly output from "crset eq" to "crset 2".
>>  * gcc.target/powerpc/safe-indirect-jump-8.c: Change expected
>>  assembly output from "crset eq" to "crset 2", and from . to $.
> 

Re: [PATCH v3, rs6000] Use $ instead of . for PC, use "crset 2" instead of "crset eq"

[Segher Boessenkool]

Hi Bill,

On Fri, Jan 19, 2018 at 10:48:18PM -0600, Bill Schmidt wrote:
> Here's another version of this patch incorporating the late-breaking news
> that the AIX assembler doesn't comprehend the "eq" symbol.  Same as 
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01787.html but adding the
> change to use "crset 2" instead.
> 
> This one is still regstrapping on BE/LE, trunk/7.  If these all complete
> successfully, is this okay for trunk and backport?

This looks fine.  Okay for trunk if it also works on AIX.  For 7 you
need RM approval (no objections from me).

Thanks!


Segher


> 2018-01-19  Bill Schmidt  
>   David Edelsohn 
> 
>   PR target/83946
>   * config/rs6000/rs6000.md (*call_indirect_nonlocal_sysv):
>   Change "crset eq" to "crset 2".
>   (*call_value_indirect_nonlocal_sysv): Likewise.
>   (*call_indirect_aix_nospec): Likewise.
>   (*call_value_indirect_aix_nospec): Likewise.
>   (*call_indirect_elfv2_nospec): Likewise.
>   (*call_value_indirect_elfv2_nospec): Likewise.
>   (*sibcall_nonlocal_sysv): Change "crset eq" to "crset 2";
>   change assembly output from . to $.
>   (*sibcall_value_nonlocal_sysv): Likewise.
>   (indirect_jump_nospec): Change assembly output from . to $.
>   (*tablejump_internal1_nospec): Likewise.
> 
> [gcc/testsuite]
> 
> 2018-01-19  Bill Schmidt  
>   David Edelsohn 
> 
>   PR target/83946
>   * gcc.target/powerpc/safe-indirect-jump-1.c: Change expected
>   assembly output from "crset eq" to "crset 2".
>   * gcc.target/powerpc/safe-indirect-jump-2.c: Change expected
>   assembly output from . to $.
>   * gcc.target/powerpc/safe-indirect-jump-3.c: Likewise.
>   * gcc.target/powerpc/safe-indirect-jump-1.c: Change expected
>   assembly output from "crset eq" to "crset 2".
>   * gcc.target/powerpc/safe-indirect-jump-8.c: Change expected
>   assembly output from "crset eq" to "crset 2", and from . to $.

Re: [PATCH v3, rs6000] Use $ instead of . for PC, use "crset 2" instead of "crset eq"

[Bill Schmidt]

On Jan 19, 2018, at 10:48 PM, Bill Schmidt  wrote:
> 
> Hi,
> 
> Here's another version of this patch incorporating the late-breaking news
> that the AIX assembler doesn't comprehend the "eq" symbol.  Same as 
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01787.html but adding the
> change to use "crset 2" instead.
> 
> This one is still regstrapping on BE/LE, trunk/7.  If these all complete
> successfully, is this okay for trunk and backport?

All testing has passed successfully.

Bill
> 
> Thanks,
> Bill
> 
> 
> [gcc]
> 
> 2018-01-19  Bill Schmidt  
>   David Edelsohn 
> 
>   PR target/83946
>   * config/rs6000/rs6000.md (*call_indirect_nonlocal_sysv):
>   Change "crset eq" to "crset 2".
>   (*call_value_indirect_nonlocal_sysv): Likewise.
>   (*call_indirect_aix_nospec): Likewise.
>   (*call_value_indirect_aix_nospec): Likewise.
>   (*call_indirect_elfv2_nospec): Likewise.
>   (*call_value_indirect_elfv2_nospec): Likewise.
>   (*sibcall_nonlocal_sysv): Change "crset eq" to "crset 2";
>   change assembly output from . to $.
>   (*sibcall_value_nonlocal_sysv): Likewise.
>   (indirect_jump_nospec): Change assembly output from . to $.
>   (*tablejump_internal1_nospec): Likewise.
> 
> [gcc/testsuite]
> 
> 2018-01-19  Bill Schmidt  
>   David Edelsohn 
> 
>   PR target/83946
>   * gcc.target/powerpc/safe-indirect-jump-1.c: Change expected
>   assembly output from "crset eq" to "crset 2".
>   * gcc.target/powerpc/safe-indirect-jump-2.c: Change expected
>   assembly output from . to $.
>   * gcc.target/powerpc/safe-indirect-jump-3.c: Likewise.
>   * gcc.target/powerpc/safe-indirect-jump-1.c: Change expected
>   assembly output from "crset eq" to "crset 2".
>   * gcc.target/powerpc/safe-indirect-jump-8.c: Change expected
>   assembly output from "crset eq" to "crset 2", and from . to $.
> 
> 
> Index: gcc/config/rs6000/rs6000.md
> ===
> --- gcc/config/rs6000/rs6000.md   (revision 256894)
> +++ gcc/config/rs6000/rs6000.md   (working copy)
> @@ -10457,7 +10457,7 @@
>   || which_alternative == 1 || which_alternative == 3)
> return "b%T0l";
>   else
> -return "crset eq\;beq%T0l-";
> +return "crset 2\;beq%T0l-";
> }
>   [(set_attr "type" "jmpreg,jmpreg,jmpreg,jmpreg")
>(set (attr "length")
> @@ -10570,7 +10570,7 @@
>   || which_alternative == 1 || which_alternative == 3)
> return "b%T1l";
>   else
> -return "crset eq\;beq%T1l-";
> +return "crset 2\;beq%T1l-";
> }
>   [(set_attr "type" "jmpreg,jmpreg,jmpreg,jmpreg")
>(set (attr "length")
> @@ -10731,7 +10731,7 @@
>(set (reg:P TOC_REGNUM) (unspec:P [(match_operand:P 3 "const_int_operand" 
> "n,n")] UNSPEC_TOCSLOT))
>(clobber (reg:P LR_REGNO))]
>   "DEFAULT_ABI == ABI_AIX && !rs6000_speculate_indirect_jumps"
> -  "crset eq\; 2,%2\;beq%T0l-\; 2,%3(1)"
> +  "crset 2\; 2,%2\;beq%T0l-\; 2,%3(1)"
>   [(set_attr "type" "jmpreg")
>(set_attr "length" "16")])
> 
> @@ -10755,7 +10755,7 @@
>(set (reg:P TOC_REGNUM) (unspec:P [(match_operand:P 4 "const_int_operand" 
> "n,n")] UNSPEC_TOCSLOT))
>(clobber (reg:P LR_REGNO))]
>   "DEFAULT_ABI == ABI_AIX && !rs6000_speculate_indirect_jumps"
> -  "crset eq\; 2,%3\;beq%T1l-\; 2,%4(1)"
> +  "crset 2\; 2,%3\;beq%T1l-\; 2,%4(1)"
>   [(set_attr "type" "jmpreg")
>(set_attr "length" "16")])
> 
> @@ -10780,7 +10780,7 @@
>(set (reg:P TOC_REGNUM) (unspec:P [(match_operand:P 2 "const_int_operand" 
> "n,n")] UNSPEC_TOCSLOT))
>(clobber (reg:P LR_REGNO))]
>   "DEFAULT_ABI == ABI_ELFv2 && !rs6000_speculate_indirect_jumps"
> -  "crset eq\;beq%T0l-\; 2,%2(1)"
> +  "crset 2\;beq%T0l-\; 2,%2(1)"
>   [(set_attr "type" "jmpreg")
>(set_attr "length" "12")])
> 
> @@ -10803,7 +10803,7 @@
>(set (reg:P TOC_REGNUM) (unspec:P [(match_operand:P 3 "const_int_operand" 
> "n,n")] UNSPEC_TOCSLOT))
>(clobber (reg:P LR_REGNO))]
>   "DEFAULT_ABI == ABI_ELFv2 && !rs6000_speculate_indirect_jumps"
> -  "crset eq\;beq%T1l-\; 2,%3(1)"
> +  "crset 2\;beq%T1l-\; 2,%3(1)"
>   [(set_attr "type" "jmpreg")
>(set_attr "length" "12")])
> 
> @@ -10987,7 +10987,7 @@
>   return \"b%T0\";
>   else
>   /* Can use CR0 since it is volatile across sibcalls.  */
> - return \"crset eq\;beq%T0-\;b .\";
> + return \"crset 2\;beq%T0-\;b $\";
> }
>   else if (DEFAULT_ABI == ABI_V4 && flag_pic)
> {
> @@ -11044,7 +11044,7 @@
>   return \"b%T1\";
>   else
>   /* Can use CR0 since it is volatile across sibcalls.  */
> - return \"crset eq\;beq%T1-\;b .\";
> + return \"crset 2\;beq%T1-\;b $\";
> }
>   else if (DEFAULT_ABI == ABI_V4 && flag_pic)
> {
> @@ -12566,7 +12566,7 @@
>   [(set (pc) (match_operand:P 0 "register_operand" "c,*l"))
>(clobber 

Re: Compilation warning in simple-object-xcoff.c

[Eli Zaretskii]

> Date: Thu, 18 Jan 2018 05:25:20 +0200
> From: Eli Zaretskii 
> CC: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org,   
> gdb-patc...@sourceware.org
> 
> > From: DJ Delorie 
> > Cc: sch...@linux-m68k.org, gcc-patches@gcc.gnu.org, 
> > gdb-patc...@sourceware.org
> > Date: Wed, 17 Jan 2018 15:47:49 -0500
> > 
> > Eli Zaretskii  writes:
> > 
> > > DJ, would the following semi-kludgey workaround be acceptable?
> > 
> > It would be no worse than what we have now, if the only purpose is to
> > avoid a warning.
> > 
> > Ideally, we would check to see if we're discarding non-zero values from
> > that offset, and not call the callback with known bogus data.  I suppose
> > the usefulness of that depends on how often you'll encounter 4Gb+ xcoff64
> > files on mingw32 ?
> 
> The answer to that question is "never", AFAIU.

So can the patch I proposed be applied, please?

TIA

Re: Fix vect_def_type handling in x86 scatter support (PR 83940)

[Richard Biener]

On January 20, 2018 11:35:12 AM GMT+01:00, Richard Sandiford 
 wrote:
>As Jakub says in the PR, the problem here was that the x86/built-in
>version of the scatter support was using a bogus scatter_src_dt
>when calling vect_get_vec_def_for_stmt_copy (and had since it
>was added).  The patch uses the vect_def_type from the original
>call to vect_is_simple_use instead.
>
>However, Jakub also pointed out that other parts of the load and store
>code passed the vector operand rather than the scalar operand to
>vect_is_simple_use.  That probably works most of the time since
>a constant scalar operand should give a constant vector operand,
>and likewise for external and internal definitions.  But it
>definitely seems more robust to pass the scalar operand.
>
>The patch avoids the issue for gather and scatter offsets by
>using the cached gs_info.offset_dt.  This is safe because gathers
>and scatters are never grouped, so there's only one statement operand
>to consider.  The patch also caches the vect_def_type for mask
>operands,
>which is safe because grouped masked operations share the same mask.
>
>That just leaves the store rhs.  We still need to recalculate the
>vect_def_type there since different store values in the group can
>have different definition types.  But since we still have access
>to the original scalar operand, it seems better to use that instead.
>
>Tested on aarch64-linux-gnu, x86_64-linux-gnu and
>powerpc64le-linux-gnu.
>OK to install?

OK. 

Thanks, 
Richard. 

>Richard
>
>
>2018-01-20  Richard Sandiford  
>
>gcc/
>   PR tree-optimization/83940
>   * tree-vect-stmts.c (vect_truncate_gather_scatter_offset): Set
>   offset_dt to vect_constant_def rather than vect_unknown_def_type.
>   (vect_check_load_store_mask): Add a mask_dt_out parameter and
>   use it to pass back the definition type.
>   (vect_check_store_rhs): Likewise rhs_dt_out.
>   (vect_build_gather_load_calls): Add a mask_dt argument and use
>   it instead of a call to vect_is_simple_use.
>   (vectorizable_store): Update calls to vect_check_load_store_mask
>   and vect_check_store_rhs.  Use the dt returned by the latter instead
>   of scatter_src_dt.  Use the cached mask_dt and gs_info.offset_dt
>   instead of calls to vect_is_simple_use.  Pass the scalar rather
>   than the vector operand to vect_is_simple_use when handling
>   second and subsequent copies of an rhs value.
>   (vectorizable_load): Update calls to vect_check_load_store_mask
>   and vect_build_gather_load_calls.  Use the cached mask_dt and
>   gs_info.offset_dt instead of calls to vect_is_simple_use.
>
>gcc/testsuite/
>   PR tree-optimization/83940
>   * gcc.dg/torture/pr83940.c: New test.
>
>Index: gcc/tree-vect-stmts.c
>===
>--- gcc/tree-vect-stmts.c  2018-01-16 15:13:19.658832080 +
>+++ gcc/tree-vect-stmts.c  2018-01-20 10:31:16.692599735 +
>@@ -1932,7 +1932,7 @@ vect_truncate_gather_scatter_offset (gim
>but we don't need to store that here.  */
>   gs_info->base = NULL_TREE;
>   gs_info->offset = fold_convert (offset_type, step);
>-  gs_info->offset_dt = vect_unknown_def_type;
>+  gs_info->offset_dt = vect_constant_def;
>   gs_info->offset_vectype = NULL_TREE;
>   gs_info->scale = scale;
>   gs_info->memory_type = memory_type;
>@@ -2374,11 +2374,14 @@ get_load_store_type (gimple *stmt, tree
> }
> 
> /* Return true if boolean argument MASK is suitable for vectorizing
>-   conditional load or store STMT.  When returning true, store the
>-   type of the vectorized mask in *MASK_VECTYPE_OUT.  */
>+   conditional load or store STMT.  When returning true, store the
>type
>+   of the definition in *MASK_DT_OUT and the type of the vectorized
>mask
>+   in *MASK_VECTYPE_OUT.  */
> 
> static bool
>-vect_check_load_store_mask (gimple *stmt, tree mask, tree
>*mask_vectype_out)
>+vect_check_load_store_mask (gimple *stmt, tree mask,
>+  vect_def_type *mask_dt_out,
>+  tree *mask_vectype_out)
> {
>   if (!VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (mask)))
> {
>@@ -2398,9 +2401,9 @@ vect_check_load_store_mask (gimple *stmt
> 
>   stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
>   gimple *def_stmt;
>-  enum vect_def_type dt;
>+  enum vect_def_type mask_dt;
>   tree mask_vectype;
>-  if (!vect_is_simple_use (mask, stmt_info->vinfo, _stmt, ,
>+  if (!vect_is_simple_use (mask, stmt_info->vinfo, _stmt,
>_dt,
>  _vectype))
> {
>   if (dump_enabled_p ())
>@@ -2437,18 +2440,19 @@ vect_check_load_store_mask (gimple *stmt
>   return false;
> }
> 
>+  *mask_dt_out = mask_dt;
>   *mask_vectype_out = mask_vectype;
>   return true;
> }
> 
> /* Return true if stored value RHS is suitable for vectorizing store
>statement STMT.  When returning true, store 

Re: [PATCH v3] Ability to remap file names in __FILE__, etc (PR other/70268)

[Ximin Luo]

Boris Kolpackov:
> Ximin Luo  writes:
> 
>> Higher-level build scripts sometimes like to save CFLAGS etc into the build 
>> output, making the overall build output unreproducible even if GCC is 
>> playing 
>> nicely. Rather than add logic to strip -f{file,debug,macro,...}-prefix-map, 
>> into all possible higher-level programs that might want to save CFLAGS, it is
>> simpler if GCC could read it from a user-specified environment variable.
> 
> This does feel like we are trying to fix the issue in the wrong place.
> Also, won't such broken packages normally store all options (including
> -I) rather than just CFLAGS? And if the answer is no, then perhaps you
> could put -ffile-prefix-map into CPPFLAGS instead of CFLAGS? Kind of
> even feels right seeing that it affects the preprocessor.
> 

The broad issue affects -fdebug-prefix-map as well, not just __FILE__.

Such packages are not "broken"; GCC itself stores command-line arguments in 
DW_AT_producer and as mentioned there was a bug to special-case filtering 
-fdebug-prefix-map out of that.

Now we'll have to add exceptions for -ffile-prefix-map and all the other flags 
you added, and everything else that might be added in future.

The same goes for all possible buildsystems / Makefile / etc that are affected 
by the issue.

Therefore, I concluded that the best and most appropriate solution was to fix 
it at the source. That is, allow it to be read from an environment variable, to 
"cancel out" the information that is already read from the filesystem - rather 
than forcing this build-specific non-deterministic information to be added to 
the command-line.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Re: [PATCH] Fix various x86 avx512{bitalg,vpopcntdq,vbmi2} issues (PR target/83488)

[Kirill Yukhin]

Hello Julia,
On 12 Jan 08:55, Koval, Julia wrote:
> Changelog
> 
> gcc/
>   * config/i386/avx512bitalgintrin.h (_mm512_bitshuffle_epi64_mask,
>   _mm512_mask_bitshuffle_epi64_mask, _mm256_bitshuffle_epi64_mask,
>   _mm256_mask_bitshuffle_epi64_mask, _mm_bitshuffle_epi64_mask,
>   _mm_mask_bitshuffle_epi64_mask): Fix type.
>   * config/i386/i386-builtin-types.def (UHI_FTYPE_V2DI_V2DI_UHI,
>   USI_FTYPE_V4DI_V4DI_USI): Remove.
>   * config/i386/i386-builtin.def (__builtin_ia32_vpshufbitqmb512_mask,
>   __builtin_ia32_vpshufbitqmb256_mask,
>   __builtin_ia32_vpshufbitqmb128_mask): Fix types.
>   * config/i386/i386.c (ix86_expand_args_builtin): Remove old types.
>   * config/i386/sse.md (VI48_AVX512VLBW): Change types.
> 
> gcc/testsuite/
>   * gcc.target/i386/avx512bitalg-vpshufbitqmb-1.c: Add -mavx512f 
> -mavx512bw.
>   * gcc.target/i386/avx512bitalgvl-vpshufbitqmb-1.c: Add -mavx512bw.
>   * gcc.target/i386/i386.exp: Fix types.

 (define_mode_iterator VI48_AVX512VLBW
-  [(V8DI "TARGET_AVX512BW") (V4DI  "TARGET_AVX512VL")
-   (V2DI  "TARGET_AVX512VL")])
+  [(V64QI "TARGET_AVX512BW") (V32QI  "TARGET_AVX512VL")
+   (V16QI  "TARGET_AVX512VL")])
I'd call this iterator VI1_AVX512VLBW.

--
Thanks, K

Fix vect_def_type handling in x86 scatter support (PR 83940)

[Richard Sandiford]

As Jakub says in the PR, the problem here was that the x86/built-in
version of the scatter support was using a bogus scatter_src_dt
when calling vect_get_vec_def_for_stmt_copy (and had since it
was added).  The patch uses the vect_def_type from the original
call to vect_is_simple_use instead.

However, Jakub also pointed out that other parts of the load and store
code passed the vector operand rather than the scalar operand to
vect_is_simple_use.  That probably works most of the time since
a constant scalar operand should give a constant vector operand,
and likewise for external and internal definitions.  But it
definitely seems more robust to pass the scalar operand.

The patch avoids the issue for gather and scatter offsets by
using the cached gs_info.offset_dt.  This is safe because gathers
and scatters are never grouped, so there's only one statement operand
to consider.  The patch also caches the vect_def_type for mask operands,
which is safe because grouped masked operations share the same mask.

That just leaves the store rhs.  We still need to recalculate the
vect_def_type there since different store values in the group can
have different definition types.  But since we still have access
to the original scalar operand, it seems better to use that instead.

Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
OK to install?

Richard


2018-01-20  Richard Sandiford  

gcc/
PR tree-optimization/83940
* tree-vect-stmts.c (vect_truncate_gather_scatter_offset): Set
offset_dt to vect_constant_def rather than vect_unknown_def_type.
(vect_check_load_store_mask): Add a mask_dt_out parameter and
use it to pass back the definition type.
(vect_check_store_rhs): Likewise rhs_dt_out.
(vect_build_gather_load_calls): Add a mask_dt argument and use
it instead of a call to vect_is_simple_use.
(vectorizable_store): Update calls to vect_check_load_store_mask
and vect_check_store_rhs.  Use the dt returned by the latter instead
of scatter_src_dt.  Use the cached mask_dt and gs_info.offset_dt
instead of calls to vect_is_simple_use.  Pass the scalar rather
than the vector operand to vect_is_simple_use when handling
second and subsequent copies of an rhs value.
(vectorizable_load): Update calls to vect_check_load_store_mask
and vect_build_gather_load_calls.  Use the cached mask_dt and
gs_info.offset_dt instead of calls to vect_is_simple_use.

gcc/testsuite/
PR tree-optimization/83940
* gcc.dg/torture/pr83940.c: New test.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   2018-01-16 15:13:19.658832080 +
+++ gcc/tree-vect-stmts.c   2018-01-20 10:31:16.692599735 +
@@ -1932,7 +1932,7 @@ vect_truncate_gather_scatter_offset (gim
 but we don't need to store that here.  */
   gs_info->base = NULL_TREE;
   gs_info->offset = fold_convert (offset_type, step);
-  gs_info->offset_dt = vect_unknown_def_type;
+  gs_info->offset_dt = vect_constant_def;
   gs_info->offset_vectype = NULL_TREE;
   gs_info->scale = scale;
   gs_info->memory_type = memory_type;
@@ -2374,11 +2374,14 @@ get_load_store_type (gimple *stmt, tree
 }
 
 /* Return true if boolean argument MASK is suitable for vectorizing
-   conditional load or store STMT.  When returning true, store the
-   type of the vectorized mask in *MASK_VECTYPE_OUT.  */
+   conditional load or store STMT.  When returning true, store the type
+   of the definition in *MASK_DT_OUT and the type of the vectorized mask
+   in *MASK_VECTYPE_OUT.  */
 
 static bool
-vect_check_load_store_mask (gimple *stmt, tree mask, tree *mask_vectype_out)
+vect_check_load_store_mask (gimple *stmt, tree mask,
+   vect_def_type *mask_dt_out,
+   tree *mask_vectype_out)
 {
   if (!VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (mask)))
 {
@@ -2398,9 +2401,9 @@ vect_check_load_store_mask (gimple *stmt
 
   stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
   gimple *def_stmt;
-  enum vect_def_type dt;
+  enum vect_def_type mask_dt;
   tree mask_vectype;
-  if (!vect_is_simple_use (mask, stmt_info->vinfo, _stmt, ,
+  if (!vect_is_simple_use (mask, stmt_info->vinfo, _stmt, _dt,
   _vectype))
 {
   if (dump_enabled_p ())
@@ -2437,18 +2440,19 @@ vect_check_load_store_mask (gimple *stmt
   return false;
 }
 
+  *mask_dt_out = mask_dt;
   *mask_vectype_out = mask_vectype;
   return true;
 }
 
 /* Return true if stored value RHS is suitable for vectorizing store
statement STMT.  When returning true, store the type of the
-   vectorized store value in *RHS_VECTYPE_OUT and the type of the
-   store in *VLS_TYPE_OUT.  */
+   definition in *RHS_DT_OUT, the type of the vectorized store value in
+   *RHS_VECTYPE_OUT and the 

New Spanish PO file for 'gcc' (version 7.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-7.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.

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

[Mike Stump]

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

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

smime.p7s
Description: S/MIME cryptographic signature

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

[Mike Stump]

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

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

smime.p7s
Description: S/MIME cryptographic signature