[Bug fortran/77900] Compile time errors/warning for IO statements appear wrong

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77900

--- Comment #1 from Jerry DeLisle  ---
This goes way back to at least 4.0 so maybe we chose to do this?

[Bug fortran/77900] New: Compile time errors/warning for IO statements appear wrong

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77900

Bug ID: 77900
   Summary: Compile time errors/warning for IO statements appear
wrong
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org
  Target Milestone: ---

While looking at something else I stumbled on this with iomesg_1.f90.

$ gfc -std=gnu iomsg_1.f90 
iomsg_1.f90:25:121:

 sg=ch) ! { dg-warning "STATUS specifier in CLOSE statement.*has invalid value"
}
   
1
Warning: STATUS specifier in CLOSE statement at (1) has invalid value ‘no_idea’

I think the above should be a compile error no matter what.

The line in questions is:

  close(23,status="no_idea", err=500, iomsg=ch) ! { dg-warning "STATUS
specifier in CLOSE statement.*has invalid value" }

It gives the expected error when changed to:

  close(23,status="no_idea") ! { dg-warning "STATUS specifier in CLOSE
statement.*has invalid value" }

Compile time errors vs warning should have nothing to do with the absence or
presence of err= or iomsg=

The wrong logic is in fortran/io.c. Probably other statements involved here.

[Bug c++/77896] Object vtable lookups are not hoisted out of loops

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896

--- Comment #3 from Andrew Pinski  ---
Basically what I am trying to say is there is a lot of analysis needed to
determine if the lifetime of object does not end during a call to a virtual
function.

> Altering the test case to trigger speculative devirtualization as follows:

This is a dup of another bug which says once it has been speculative to a
specific function which does not change the lifetime of the object, we can
split the loop.  That is a dup of bug 67886 really.

[Bug c++/77896] Object vtable lookups are not hoisted out of loops

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896

--- Comment #2 from Andrew Pinski  ---
(In reply to Ryan Johnson from comment #1)
> Given that an object's vtable is fixed over its lifetime,

Yes but functions including virtual functions can deconstruct the object and
then call inplacement new on the same object and change what the type is for
that object.  So saying the object's vtable is fixed is correct but the
lifetime of the object is not fixed.

[Bug c++/77896] Object vtable lookups are not hoisted out of loops

[scovich at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896

--- Comment #1 from Ryan Johnson  ---
It appears that multiple calls to different virtual functions of the same
object are not optimized, either (each performs the same load-load-jump
operation).

[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||lkrupp at gcc dot gnu.org

--- Comment #6 from Dominique d'Humieres  ---
> AFAICT this PR has been fixed between revisions r240781 and r240870.

Likely by r240850.

[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892

--- Comment #5 from Dominique d'Humieres  ---
AFAICT this PR has been fixed between revisions r240781 and r240870.

[Bug fortran/64947] ICE in gimplify_expr, at gimplify.c:8425 with arrays of type(C_PTR)

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64947

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Dominique d'Humieres  ---
Duplicate of pr50892.

*** This bug has been marked as a duplicate of bug 50892 ***

[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||bugs at stellardeath dot org

--- Comment #4 from Dominique d'Humieres  ---
*** Bug 64947 has been marked as a duplicate of this bug. ***

[Bug c++/77887] -Wimplicit-fallthrough fails to trigger in an unused function template specialisation

[marc.mutz at kdab dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77887

--- Comment #2 from Marc Mutz  ---
Created attachment 39772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39772=edit
Expanded version of test-case for 77886, adding an unused inline non-template
overload of the function template

Findings:

  l.30 \ l.29   template specialisation  overload
  inline - doesn"t warn  - doesn't warn
  non-inline + warns + warns

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899

--- Comment #3 from Martin Sebor  ---
The offset is this in plus_stmt_object_size() in tree-object-size.c:

 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x70da41f8 precision
64 min  max >
static visited
def_stmt _1 = (sizetype) i_3(D);
version 1
ptr-info 0x70ec8f20>

I can work around it there by checking the type of i_3(D) (which is signed
char) and using its range to bound _1.  I wonder if this same workaround could
be put in get_range_info until POINTER_PLUS_EXPR is changed to take a signed
offset as you suggest.

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[marc.mutz at kdab dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886

--- Comment #10 from Marc Mutz  ---
I can confirm patch fixes my Qt build, ie. not just bug.cpp.

Thanks!

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899

--- Comment #2 from Andrew Pinski  ---
So to fix this in reality is to change how POINTER_PLUS_EXPR takes an unsigned
integer to be a signed integer.  But this will take many extra issues and need
to be done though out the compiler.

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899

--- Comment #1 from Andrew Pinski  ---
This is the complex part because size_type is unsigned so the range converting
from signed [-127, 128] to unsigned is ~[128, 18446744073709551487]

[Bug tree-optimization/77899] New: incorrect VR_RANGE for a signed char function argument

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899

Bug ID: 77899
   Summary: incorrect VR_RANGE for a signed char function argument
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similar to bug 77898 but with different and more wide-ranging symptoms (it
persists past even the last invocation of the VRP pass), in the following
program the range of the variable i is bounded by its type to [-128, 127]. 
Thus the result of the (p += i) expression is guaranteed to be in the range [d
+ 2, d + 257] and the if expression always false.  However, GCC represents the
range of the signed char offset by the VR_ANTI_RANGE ~[128,
18446744073709551487] and fails to optimize the if statement away.

This is another case that popped up during the testing of my patch for bug
77608 where it affects the result of __builtin_object_size.

$ cat x.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -O2 -S
-Wall -Wextra -Wpedantic -fdump-tree-vrp=/dev/stdout x.c
void f (signed char i)
{
  char d [260];

  const char *p = [130];

  p += i;

  if (p < d + 2 || d + 257 < p)
__builtin_abort ();
}

;; Function f (f, funcdef_no=0, decl_uid=1791, cgraph_uid=0, symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4 5
;; 2 succs { 4 3 }
;; 3 succs { 4 5 }
;; 4 succs { }
;; 5 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

p_7 -> { p_3 }
Incremental SSA update started at block: 2
Number of blocks in CFG: 6
Number of blocks to update: 2 ( 33%)



Value ranges after VRP:

_1: ~[128, 18446744073709551487]
i_2(D): VARYING
p_3: VARYING
p_7: VARYING


f (signed char i)
{
  const char * p;
  char d[260];
  sizetype _1;

  :
  _1 = (sizetype) i_2(D);
  p_3 = [130] + _1;
  if ([(void *) + 2B] > p_3)
goto ;
  else
goto ;

  :
  if ([(void *) + 257B] < p_3)
goto ;
  else
goto ;

  :
  __builtin_abort ();

  :
  d ={v} {CLOBBER};
  return;

}



;; Function f (f, funcdef_no=0, decl_uid=1791, cgraph_uid=0, symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4
;; 2 succs { 3 4 }
;; 3 succs { }
;; 4 succs { 1 }

Value ranges after VRP:

_1: ~[128, 18446744073709551487]
i_2(D): VARYING
p_3: VARYING
_7: [0, +INF]
_8: [0, +INF]
_9: [0, +INF]


f (signed char i)
{
  const char * p;
  char d[260];
  sizetype _1;
  _Bool _7;
  _Bool _8;
  _Bool _9;

  :
  _1 = (sizetype) i_2(D);
  p_3 = [130] + _1;
  _7 = [(void *) + 257B] < p_3;
  _8 = [(void *) + 2B] > p_3;
  _9 = _8 | _7;
  if (_9 != 0)
goto ;
  else
goto ;

  :
  __builtin_abort ();

  :
  d ={v} {CLOBBER};
  return;

}

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-10-07
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #9 from Jakub Jelinek  ---
Created attachment 39771
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39771=edit
gcc7-pr77886.patch

Untested fix.

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[marc.mutz at kdab dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886

--- Comment #8 from Marc Mutz  ---
#c3 is also in a template, indeed.

[Bug c++/77886] -Wimplicit-fallthrough: breaks duff's device (in function templates)

[marc.mutz at kdab dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886

--- Comment #7 from Marc Mutz  ---
Version:

  $ g++ -v
  Using built-in specs.
  COLLECT_GCC=g++
 
COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
  Target: x86_64-pc-linux-gnu
  Configured with: ../gcc/configure --prefix=/d/gcc/trunk
--enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++
  Thread model: posix
  gcc version 7.0.0 20161005 (experimental) (GCC) 

Specifically:

  $ git log -10 --online
  c7b01e7 PR sanitizer/77823  * c-ubsan.c (ubsan_instrument_shift):
Return NULL_TREE if type0 is not integral.
  d20 Fix pr69941.c test failure for avr
  ea55eab 2016-10-05  Jerry DeLisle  
  9ce1157 PR bootstrap/77819 - undefined reference to
gnu_libc_printf_pointer_format with uClibc
  5c176eb * c-common.c (c_common_reswords): Update comment for C++11.
  4ef2832 [fold-const] Fix native_encode_real for HFmode constants
  59deb1a 70564 fix newly-added tests for not_fn
  c375ef0 libcpp/ChangeLog:
  77a1a89 Move all existing strchr and strrchr folding from builtins.c to
gimple-fold.c.
  ad69f5a PR 70101 fix allocator-extended ctors for std::priority_queue

[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device

[marc.mutz at kdab dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886

--- Comment #6 from Marc Mutz  ---
Created attachment 39770
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39770=edit
Test case

Result:

  $ g++ -Wextra -std=c++1z -O2 bug.cpp
  bug.cpp: In function ‘void qt_memfill(T*, T, int) [with T = int]’:
  bug.cpp:10:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 0: do { *dest++ = value;
  ^
  bug.cpp:12:7: note: here
 case 7:  *dest++ = value;
 ^~~~
  bug.cpp:12:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 7:  *dest++ = value;
  ^
  bug.cpp:14:7: note: here
 case 6:  *dest++ = value;
 ^~~~
  bug.cpp:14:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 6:  *dest++ = value;
  ^
  bug.cpp:16:7: note: here
 case 5:  *dest++ = value;
 ^~~~
  bug.cpp:16:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 5:  *dest++ = value;
  ^
  bug.cpp:18:7: note: here
 case 4:  *dest++ = value;
 ^~~~
  bug.cpp:18:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 4:  *dest++ = value;
  ^
  bug.cpp:20:7: note: here
 case 3:  *dest++ = value;
 ^~~~
  bug.cpp:20:20: warning: this statement may fall through
[-Wimplicit-fallthrough]
 case 3:  *dest++ = value;
  ^
  bug.cpp:22:7: note: here
 case 2:  *dest++ = value;
 ^~~~

iow: only the attribute helps.

[Bug c/77886] -Wimplicit-fallthrough: breaks duff's device

[marc.mutz at kdab dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77886

--- Comment #5 from Marc Mutz  ---
It's in a function template, in case that helps. I'll try to trim it down now.

Re: [PATCH 1/5] [AARCH64]: Move #undef into .def files.

[Andrew Pinski]

On Wed, Nov 18, 2015 at 4:29 AM, Marcus Shawcroft
 wrote:
> On 17 November 2015 at 22:10, Andrew Pinski  wrote:
>>
>> This moves the #undef from the header files to the .def files like was done
>> for builtins.def (https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00662.html).
>>
>> OK?   Bootstrapped and tested on aarch64-linux-gnu with no regressions.
>>
>> Thanks,
>> Andrew Pinski
>>
>> * config/aarch64/aarch64-arches.def (AARCH64_ARCH): #undef at the end.
>> * config/aarch64/aarch64-cores.def (AARCH64_CORE): Likewise.
>> * config/aarch64/aarch64-fusion-pairs.def (AARCH64_FUSION_PAIR): Likewise.
>> * config/aarch64/aarch64-tuning-flags.def (AARCH64_EXTRA_TUNING_OPTION): 
>> Likewise.
>> * config/aarch64/aarch64-opts.h (AARCH64_CORE): Don't #undef here.
>> (AARCH64_ARCH): Likewise.
>> * config/aarch64/aarch64-protos.h (AARCH64_FUSION_PAIR): Likewise.
>> (AARCH64_EXTRA_TUNING_OPTION): Likewise.
>> * config/aarch64/aarch64.c (AARCH64_FUION_PAIR): Likewise.
>> (AARCH64_EXTRA_TUNING_OPTION): Likewise.
>> (AARCH64_ARCH): Likewise.
>> (AARCH64_CORE): Likewise.
>> (AARCH64_OPT_EXTENSION): Likewise.
>> * config/aarch64/aarch64.h (AARCH64_CORE): Likewise.
>> * config/aarch64/driver-aarch64.c (AARCH64_OPT_EXTENSION): Likewise.
>> (AARCH64_CORE): Likewise.
>> (AARCH64_ARCH): Likewise.
>> * common/config/aarch64/aarch64-common.c: Likewise.
>
> OK Thanks /Marcus


This is what I applied finally after a new bootstrap/test.

By the way there was even a typo in the code originally for
AARCH64_FUSION_PAIR; there was an undef for AARCH64_FUION_PAIR in
config/aarch64/aarch64.c.  So this patch alone fixes that issue.

Thanks,
Andrew Pinski

2016-10-07  Andrew Pinski  

* config/aarch64/aarch64-arches.def (AARCH64_ARCH): #undef at the end.
* config/aarch64/aarch64-cores.def (AARCH64_CORE): Likewise.
* config/aarch64/aarch64-fusion-pairs.def
(AARCH64_FUSION_PAIR): Likewise.
* config/aarch64/aarch64-option-extensions.def
(AARCH64_OPT_EXTENSION): Likewise.
* config/aarch64/aarch64-tuning-flags.def
(AARCH64_EXTRA_TUNING_OPTION): Likewise.
* config/aarch64/aarch64-opts.h (AARCH64_CORE): Don't #undef here.
(AARCH64_ARCH): Likewise.
* common/config/aarch64/aarch64-common.c
(AARCH64_OPT_EXTENSION): Likewise.
(AARCH64_CORE): Likewise.
(AARCH64_ARCH): Likewise.
* config/aarch64/aarch64-protos.h (AARCH64_FUSION_PAIR): Likewise.
(AARCH64_EXTRA_TUNING_OPTION): Likewise.
* config/aarch64/aarch64.c (AARCH64_FUION_PAIR): Likewise.
(AARCH64_EXTRA_TUNING_OPTION): Likewise.
(AARCH64_ARCH): Likewise.
(AARCH64_CORE): Likewise.
* config/aarch64/aarch64.h (AARCH64_CORE): Likewise.
* config/aarch64/driver-aarch64.c (AARCH64_OPT_EXTENSION): Likewise.
(AARCH64_CORE): Likewise.
(AARCH64_ARCH): Likewise.
Index: common/config/aarch64/aarch64-common.c
===
--- common/config/aarch64/aarch64-common.c  (revision 240845)
+++ common/config/aarch64/aarch64-common.c  (working copy)
@@ -123,7 +123,6 @@ static const struct aarch64_option_exten
 #define AARCH64_OPT_EXTENSION(NAME, FLAG_CANONICAL, FLAGS_ON, FLAGS_OFF, Z) \
   {NAME, FLAG_CANONICAL, FLAGS_ON, FLAGS_OFF},
 #include "config/aarch64/aarch64-option-extensions.def"
-#undef AARCH64_OPT_EXTENSION
   {NULL, 0, 0, 0}
 };
 
@@ -148,7 +147,6 @@ static const struct processor_name_to_ar
 #define AARCH64_CORE(NAME, X, IDENT, ARCH_IDENT, FLAGS, COSTS, IMP, PART) \
   {NAME, AARCH64_ARCH_##ARCH_IDENT, FLAGS},
 #include "config/aarch64/aarch64-cores.def"
-#undef AARCH64_CORE
   {"generic", AARCH64_ARCH_8A, AARCH64_FL_FOR_ARCH8},
   {"", aarch64_no_arch, 0}
 };
@@ -159,7 +157,6 @@ static const struct arch_to_arch_name al
 #define AARCH64_ARCH(NAME, CORE, ARCH_IDENT, ARCH, FLAGS) \
   {AARCH64_ARCH_##ARCH_IDENT, NAME, FLAGS},
 #include "config/aarch64/aarch64-arches.def"
-#undef AARCH64_ARCH
   {aarch64_no_arch, "", 0}
 };
 
Index: config/aarch64/aarch64-arches.def
===
--- config/aarch64/aarch64-arches.def   (revision 240845)
+++ config/aarch64/aarch64-arches.def   (working copy)
@@ -34,3 +34,4 @@ AARCH64_ARCH("armv8-a", generic,
 AARCH64_ARCH("armv8.1-a", generic,  8_1A,  8,  
AARCH64_FL_FOR_ARCH8_1)
 AARCH64_ARCH("armv8.2-a", generic,  8_2A,  8,  
AARCH64_FL_FOR_ARCH8_2)
 
+#undef AARCH64_ARCH
Index: config/aarch64/aarch64-cores.def
===
--- config/aarch64/aarch64-cores.def(revision 240846)
+++ config/aarch64/aarch64-cores.def(working copy)
@@ -70,3 +70,5 @@ AARCH64_CORE("cortex-a57.cortex-a53",  c
 AARCH64_CORE("cortex-a72.cortex-a53",  cortexa72cortexa53, cortexa53, 8A,  
AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa72, "0x41", "0xd08.0xd03")
 

Re: Repository for the conversion machinery

[Joseph Myers]

On Fri, 7 Oct 2016, Frank Ch. Eigler wrote:

> joseph wrote:
> 
> > Thanks, here are further authors map additions for new committers.
> > [...]
> > avieira = Andre Vieira 
> > [...]
> 
> FWIW, I thought at one point the consensus was that the mailmap would
> expand only to $use...@gcc.gnu.org rather than $userid@$organization,
> esp. considering the case where there is no single $organization that
> accurately covers the whole contribution timespan of the given $userid.

I don't think there was any such consensus (older ids weren't from 
gcc.gnu.org anyway so @gcc.gnu.org would be nonsense for that part of the 
history).

My view is: contributors are free to specify what name and email address 
they want used, but if they want something other than a single name and 
email address for the whole commit history with a given username, it's the 
contributor's responsibility to come up with lists of commits that use 
each mapping rather than a hypothetical recipe based on examining 
ChangeLogs.


[reposurgeon aside from observations with other conversions where 
different author maps were needed for different revisions: the revision 
range for commits from the gcc2 repository works in the GCC case because 
that revision range came from CVS and so there are no tags with valid 
commit authors in that range.  But if you have a repository with different 
ranges of commits having different author maps *and* those ranges contain 
SVN tags, simply specifying a range .. doesn't 
work as expected, since ranges are interpreted in reposurgeon's ordering 
of events, not SVN's ordering, and the tag events are out of sequence with 
the commit events.]

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Frank Ch. Eigler]

joseph wrote:

> Thanks, here are further authors map additions for new committers.
> [...]
> avieira = Andre Vieira 
> [...]

FWIW, I thought at one point the consensus was that the mailmap would
expand only to $use...@gcc.gnu.org rather than $userid@$organization,
esp. considering the case where there is no single $organization that
accurately covers the whole contribution timespan of the given $userid.

- FChE

[PATCH/AARCH64] Handle ILP32 multi-arch

[Andrew Pinski]

Hi,
  This patch adds ilp32 multi-arch support.  This is needed to support
multi-arch on Debian like systems.

OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
Also tested with ilp32 with a newly built toolchain that supports
ILP32 with Ubuntu 1604 base.

Thanks,
Andrew

ChangeLog:
* config/aarch64/t-aarch64-linux (MULTILIB_OSDIRNAMES): Handle
multi-arch for ilp32.
Index: gcc/config/aarch64/t-aarch64-linux
===
--- gcc/config/aarch64/t-aarch64-linux  (revision 240867)
+++ gcc/config/aarch64/t-aarch64-linux  (working copy)
@@ -25,4 +25,4 @@ AARCH_BE = $(if $(findstring TARGET_BIG_
 MULTILIB_OSDIRNAMES = mabi.lp64=../lib64$(call 
if_multiarch,:aarch64$(AARCH_BE)-linux-gnu)
 MULTIARCH_DIRNAME = $(call if_multiarch,aarch64$(AARCH_BE)-linux-gnu)
 
-MULTILIB_OSDIRNAMES += mabi.ilp32=../libilp32
+MULTILIB_OSDIRNAMES += mabi.ilp32=../libilp32$(call 
if_multiarch,:aarch64$(AARCH_BE)_ilp32-linux-gnu)

Re: Repository for the conversion machinery

[Joseph Myers]

On Fri, 7 Oct 2016, Jason Merrill wrote:

> But if you want to do it with reposurgeon, I won't complain.  I've
> pushed my WIP to https://github.com/jicama/gcc-reposurgeon

Thanks, here are further authors map additions for new committers.

avieira = Andre Vieira 
foreese = Fritz Reese 
jemarch = Jose E. Marchesi 
jyong = Jonathan Yong <10wa...@gmail.com>
ksejdak = Jakub Sejdak 
saaadhu = Senthil Kumar Selvaraj 
seurer = Bill Seurer 
tnfchris = Tamar Christina 

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Repository for the conversion machinery

[Joseph Myers]

On Fri, 7 Oct 2016, Jason Merrill wrote:

> no additional commits, and keeps other branches that were deleted in
> SVN, though I was able to work around this with a postprocessing
> script.

I suppose there's the question of what we want cases where branches might 
have been deleted to look like, both for past history and for future 
development.  Branch deletion in git is not directly equivalent to branch 
deletion in SVN because of the potential for leaving objects unreachable.  
So either you rename the branches (e.g. into dead/) or you keep tags 
pointing to their tips so the history stays reachable.

-- 
Joseph S. Myers
jos...@codesourcery.com

[Bug tree-optimization/77898] New: VR_RANGE with inverted bounds after evrp and before vrp1

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77898

Bug ID: 77898
   Summary: VR_RANGE with inverted bounds after evrp and before
vrp1
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following problem was uncovered during the testing of a patch for bug 77608
and briefly discussed in the thread Re: VR_RANGE with inverted bounds at
https://gcc.gnu.org/ml/gcc/2016-10/msg00054.html.

Given the code below, a call to the get_range_info() function made in
plus_stmt_object_size() in tree-object-size.c yields the VR_RANGE [2147483648,
-2147483649] for the offset i in the (p += i) expression even though the
correct range is [0, 1].

void f (int i)
{
  const char *p = "ab";

  if (i < 0 || 1 < i)
i = 0;

  p += i;

  unsigned long n = __builtin_object_size (p, 2);

  if (n < 2 || 3 < n)
__builtin_abort ();
}


The .evrp dump for the function shows what looks like an incorrect anti-range. 
The .vrp1 dump, however, shows the correct range.

Value ranges after Early VRP:

i.0_1: [0, +INF]
_2: ~[2147483648, 18446744071562067967]
_3: [0, +INF]
i_4: VARYING
i_6(D): VARYING
p_8: VARYING
n_10: VARYING


f (int i)
{
  int i_6(D) = i;
  long unsigned int n;
  const char * p;
  unsigned int i.0_1;
  sizetype _2;
  long unsigned int _3;

  :
  # RANGE [0, 4294967295]
  i.0_1 = (unsigned int) i_6(D);
  if (i.0_1 > 1)
goto ;
  else
goto ;

  :

  :
  # i_4 = PHI 
  # RANGE ~[2147483648, 18446744071562067967]
  _2 = (sizetype) i_4;
  # PT = 
  p_8 = "ab" + _2;
  ...

Re: error printing in reversed order ?

[nicolas bouillot]

oops this works better:
alias reversed_make='make 2>&1 >/dev/null | tac | egrep --color
"\b(error|cpp|hpp)\b|$"'

On Fri, Oct 7, 2016 at 4:39 PM, nicolas bouillot
 wrote:
> Thank you Joe and Dave.
>
> I tried -fmax-errors but my test error (c++ iterator type) is itself
> very long and still requires scrolling. In this case I had success
> with tac. It just need to get some color back after filtering, which
> is resulting for me in this following alias:
> alias reversed_make='make 2>&1 >/dev/null | tac | egrep --color
> "\b(error|cpp|hpp)\b|$ "'
>
> Nicolas
>
> On Fri, Oct 7, 2016 at 3:23 PM, David Malcolm  wrote:
>> On Fri, 2016-10-07 at 15:08 -0400, nicolas bouillot wrote:
>>> Hi,
>>>
>>> Was wondering this could be a feature request ? Basically, this could
>>> be a GCC option to print compilation errors in a reversed order, i.e.
>>> the first being printed last. This is because when compiling from the
>>> terminal, it would avoid mouse scrolling all day in order to get the
>>> first error.
>>>
>>> I'll be happy to write a feature request somewhere if this deserves
>>> it, but I do not know where and if this can be considered as a
>>> feature
>>> request.
>>
>> There's an option
>>   -fmax-errors=
>> which can be set to limit the number of errors emitted.
>>
>> It defaults to off.  The clang equivalent, -ferror-limit=, defaults to
>> 20.
>>
>> Maybe we should change -fmax-errors= to default to on, maybe 20?  This
>> ought to solve the "scrolling all day" problem you describe.
>>
>> Also, our error message is "computerese":
>>
>>   compilation terminated due to -fmax-errors=2.
>>
>> clang's is better:
>>
>>   fatal error: too many errors emitted, stopping now [-ferror-limit=]
>>
>> but we could improve ours by showing the number after the option), and
>> say how to disable the limiter:
>>
>>   fatal error: too many errors emitted, stopping now [-fmax-errors=2]
>>
>> note: use -fmax-errors=0 to print all errors
>>
>> or somesuch.
>>
>> Thoughts?
>>
>> Dave

Re: error printing in reversed order ?

[nicolas bouillot]

Thank you Joe and Dave.

I tried -fmax-errors but my test error (c++ iterator type) is itself
very long and still requires scrolling. In this case I had success
with tac. It just need to get some color back after filtering, which
is resulting for me in this following alias:
alias reversed_make='make 2>&1 >/dev/null | tac | egrep --color
"\b(error|cpp|hpp)\b|$ "'

Nicolas

On Fri, Oct 7, 2016 at 3:23 PM, David Malcolm  wrote:
> On Fri, 2016-10-07 at 15:08 -0400, nicolas bouillot wrote:
>> Hi,
>>
>> Was wondering this could be a feature request ? Basically, this could
>> be a GCC option to print compilation errors in a reversed order, i.e.
>> the first being printed last. This is because when compiling from the
>> terminal, it would avoid mouse scrolling all day in order to get the
>> first error.
>>
>> I'll be happy to write a feature request somewhere if this deserves
>> it, but I do not know where and if this can be considered as a
>> feature
>> request.
>
> There's an option
>   -fmax-errors=
> which can be set to limit the number of errors emitted.
>
> It defaults to off.  The clang equivalent, -ferror-limit=, defaults to
> 20.
>
> Maybe we should change -fmax-errors= to default to on, maybe 20?  This
> ought to solve the "scrolling all day" problem you describe.
>
> Also, our error message is "computerese":
>
>   compilation terminated due to -fmax-errors=2.
>
> clang's is better:
>
>   fatal error: too many errors emitted, stopping now [-ferror-limit=]
>
> but we could improve ours by showing the number after the option), and
> say how to disable the limiter:
>
>   fatal error: too many errors emitted, stopping now [-fmax-errors=2]
>
> note: use -fmax-errors=0 to print all errors
>
> or somesuch.
>
> Thoughts?
>
> Dave

[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers

[marc.mutz at kdab dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66343

--- Comment #14 from Marc Mutz  ---
More examples (incl. ones with .Lubsan_type3) available on request.

Re: [PATCH][AArch64] Add spellchecking hints for -march,-mcpu,-mtune and their attributes

[Andrew Pinski]

On Fri, Oct 7, 2016 at 7:52 AM, Kyrill Tkachov
 wrote:
> Hi all,
>
> This patch uses the spellcheck API from David and Jakub [1] to implement
> hints for the
> march, mcpu and mtune options to suggest appropriate architectures and CPU
> names
> for users.  It also adds such hints for the equivalent arch, cpu, tune
> attributes.
> Architecture extensions like 'crc', 'crypto' are not handled in this patch
> as they
> can be combined and modified with '+no' so it would be quite tricky. But if
> a user
> misspells those we just give a proper "unknown modifier" error. The hints
> appear
> only when the actual CPU or architecture name is misspelled.
>
> Bootstrapped and tested on aarch64-none-linux-gnu.
>
> Ok for trunk?


I like this idea.  Though I need to check how it will interact with my
patch set which I am doing right now to support some more of Cavium's
SOCs.

Thanks,
Andrew Pinski

>
> Thanks,
> Kyrill
>
> [1] https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00339.html
>
> 2016-10-07  Kyrylo Tkachov  
>
> * config/aarch64/aarch64.c (aarch64_print_hint_for_core_or_arch):
> New function.
> (aarch64_print_hint_for_core): Likewise.
> (aarch64_print_hint_for_arch): Likewise.
> (aarch64_validate_march): Use it.  Fix indentation in type signature.
> (aarch64_validate_mcpu): Use aarch64_print_hint_for_core_or_arch.
> (aarch64_validate_mtune): Likewise.
> (aarch64_handle_attr_arch): Likewise.
> (aarch64_handle_attr_cpu): Likewise.
> (aarch64_handle_attr_tune): Likewise.
>
> 2016-10-07  Kyrylo Tkachov  
>
> * gcc.target/aarch64/spellcheck_1.c: New test.
> * gcc.target/aarch64/spellcheck_2.c: Likewise.
> * gcc.target/aarch64/spellcheck_3.c: Likewise.
> * gcc.target/aarch64/spellcheck_4.c: Likewise.
> * gcc.target/aarch64/spellcheck_5.c: Likewise.
> * gcc.target/aarch64/spellcheck_6.c: Likewise.

[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers

[marc.mutz at kdab dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66343

Marc Mutz  changed:

   What|Removed |Added

 CC||marc.mutz at kdab dot com

--- Comment #13 from Marc Mutz  ---
Created attachment 39769
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39769=edit
Preprocessed source for a TU that fails

Command line for a TU that fails:

  g++ -c -include .pch/Qt5Core -pipe -g -O3 -std=c++1z \
-I/usr/include/glib-2.0 \
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include \
-pthread \
-fvisibility=hidden \
-fvisibility-inlines-hidden \
-fsanitize=address \
-fsanitize=undefined \
-fno-omit-frame-pointer \
-Wall \
-W \
-Wvla \
-Wdate-time \
-Wshift-overflow=2 \
-Wduplicated-cond \
-Werror \
-Wno-error=cpp \
-Wno-error=deprecated-declarations \
-Wno-error=strict-overflow \
-D_REENTRANT \
-fPIC \
-DQT_NO_USING_NAMESPACE \
-DQT_NO_FOREACH \
-DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" \
-DQT_USE_ICU \
-DQT_HAVE_POLL \
-DQT_HAVE_PPOLL \
-DQT_BUILD_CORE_LIB \
-DQT_BUILDING_QT \
-DQT_NO_CAST_TO_ASCII \
-DQT_ASCII_CAST_WARNINGS \
-DQT_MOC_COMPAT \
-DQT_USE_QSTRINGBUILDER \
-DQT_DEPRECATED_WARNINGS \
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 \
-D_LARGEFILE64_SOURCE \
-D_LARGEFILE_SOURCE \
-DQT_NO_DEBUG \
-I/home/marc/Qt/qt5/qtbase/src/corelib \
-I. \
-Iglobal \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/harfbuzz/src \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md5 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md4 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/sha3 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/forkfd \
-I../../include \
-I../../include/QtCore \
-I../../include/QtCore/5.8.0 \
-I../../include/QtCore/5.8.0/QtCore \
-I.moc \
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ \
-o .obj/qlibraryinfo.o \
/home/marc/Qt/qt5/qtbase/src/corelib/global/qlibraryinfo.cpp

Fails with:
  {standard input}: Assembler messages:
  {standard input}:22992: Error: symbol `.Lubsan_type1' is already defined

[Bug sanitizer/66343] "Error: .Lubsan_type3 already defined" with UBSan and precompiled headers

[marc.mutz at kdab dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66343

--- Comment #12 from Marc Mutz  ---
Created attachment 39768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39768=edit
Preprocessed source for PCH

Command line for PCH file:

  g++ -pipe -g -O3 -std=c++1z \
-I/usr/include/glib-2.0 \
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include \
-pthread \
-fvisibility=hidden \
-fvisibility-inlines-hidden \
-fsanitize=address \
-fsanitize=undefined \
-fno-omit-frame-pointer \
-Wall \
-W \
-Wvla \
-Wdate-time \
-Wshift-overflow=2 \
-Wduplicated-cond \
-Werror \
-Wno-error=cpp \
-Wno-error=deprecated-declarations \
-Wno-error=strict-overflow \
-D_REENTRANT \
-fPIC \
-DQT_NO_USING_NAMESPACE \
-DQT_NO_FOREACH \
-DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" \
-DQT_USE_ICU \
-DQT_HAVE_POLL \
-DQT_HAVE_PPOLL \
-DQT_BUILD_CORE_LIB \
-DQT_BUILDING_QT \
-DQT_NO_CAST_TO_ASCII \
-DQT_ASCII_CAST_WARNINGS \
-DQT_MOC_COMPAT \
-DQT_USE_QSTRINGBUILDER \
-DQT_DEPRECATED_WARNINGS \
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 \
-D_LARGEFILE64_SOURCE \
-D_LARGEFILE_SOURCE \
-DQT_NO_DEBUG \
-I/home/marc/Qt/qt5/qtbase/src/corelib \
-I. \
-Iglobal \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/harfbuzz/src \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md5 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/md4 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/sha3 \
-I/home/marc/Qt/qt5/qtbase/src/3rdparty/forkfd \
-I../../include \
-I../../include/QtCore \
-I../../include/QtCore/5.8.0 \
-I../../include/QtCore/5.8.0/QtCore \
-I.moc \
-I/home/marc/Qt/qt5/qtbase/mkspecs/linux-g++ \
-x c++-header \
-c /home/marc/Qt/qt5/qtbase/src/corelib/global/qt_pch.h \
-o .pch/Qt5Core.gch/c++

  g++ -v
   Using built-in specs.
   COLLECT_GCC=g++
  
COLLECT_LTO_WRAPPER=/d/gcc/trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
   Target: x86_64-pc-linux-gnu
   Configured with: ../gcc/configure --prefix=/d/gcc/trunk
--enable-checking=release --enable-languges=c,c++,fortran,lto,objc,obj-c++
   Thread model: posix
   gcc version 7.0.0 20161005 (experimental) (GCC) 

  git log -10 --oneline
   c7b01e7 PR sanitizer/77823  * c-ubsan.c
(ubsan_instrument_shift): Return NULL_TREE if type0 is not integral.
   d20 Fix pr69941.c test failure for avr
   ea55eab 2016-10-05  Jerry DeLisle  
   9ce1157 PR bootstrap/77819 - undefined reference to
gnu_libc_printf_pointer_format with uClibc
   5c176eb * c-common.c (c_common_reswords): Update comment for C++11.
   4ef2832 [fold-const] Fix native_encode_real for HFmode constants
   59deb1a 70564 fix newly-added tests for not_fn
   c375ef0 libcpp/ChangeLog:
   77a1a89 Move all existing strchr and strrchr folding from builtins.c to
gimple-fold.c.
   ad69f5a PR 70101 fix allocator-extended ctors for std::priority_queue

Re: Patch, Split powerpc -mfloat128 into 2 parts

[Michael Meissner]

On Thu, Oct 06, 2016 at 05:19:39PM -0500, Segher Boessenkool wrote:
> On Wed, Oct 05, 2016 at 06:18:50PM -0400, Michael Meissner wrote:
> > I have removed the #define of __float128, and instead created a keyword that
> > points to the _Float128 type.  I added a little commentary on the use of
> > __ieee128 (which is needed to create the type when we aren't using 
> > __float128).
> > 
> > I did a bootstrap and test on a little endian power8 system with no
> > regressions.  Can I install the patch on the trunk?
> 
> Not easy to read this patch :-)
> 
> It looks good; it is fine for trunk if Joseph thinks it is good, too.
> One nit...
> 
> > --- gcc/testsuite/gcc.target/powerpc/float128-type-1.c  
> > (.../svn+ssh://meiss...@gcc.gnu.org/svn/gcc/trunk/gcc/testsuite/gcc.target/powerpc)
> >  (revision 0)
> > +++ gcc/testsuite/gcc.target/powerpc/float128-type-1.c  
> > (.../gcc/testsuite/gcc.target/powerpc)  (revision 240807)
> > @@ -0,0 +1,24 @@
> > +/* { dg-do compile { target { powerpc64*-*-linux* && lp64 } } } */
> > +/* { dg-require-effective-target powerpc_vsx_ok } */
> > +/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
> > "-mcpu=power8" } } */
> > +/* { dg-options "-mcpu=power8 -O2" } */
> > +
> > +/* -mfloat128-type is enabled by default on VSX Linux 64-bit systems.  */
> 
> "Check that" etc.?  Also for the next testcase.  It is really helpful
> five or ten years later if a testcase bluntly says what it is testing
> for so you don't have to reverse engineer that :-)

I added more to the comments to saw what these files were checking, and
committed them:

Index: gcc/testsuite/gcc.target/powerpc/float128-type-1.c
===
--- gcc/testsuite/gcc.target/powerpc/float128-type-1.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/float128-type-1.c  (revision 0)
@@ -0,0 +1,28 @@
+/* { dg-do compile { target { powerpc64*-*-linux* && lp64 } } } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
+/* { dg-options "-mcpu=power8 -O2" } */
+
+/* This test tests whether -mfloat128-type (which enables the underlying IEEE
+   128-bit floating point) is enabled by default on VSX Linux 64-bit systems,
+   even if the keywords __float128 and _Float128 (-mfloat128) are not enabled
+   via the -mfloat128 switch.  Test that power8 generates a call to the
+   __addkf3 emulation function.  */
+
+typedef double  __attribute__((__mode__(__KF__))) f128_t;
+typedef _Complex double __attribute__((__mode__(__KC__))) f128c_t;
+
+f128_t
+add_scalar (f128_t a, f128_t b)
+{
+  return a+b;
+}
+
+
+f128c_t
+add_complex (f128c_t a, f128c_t b)
+{
+  return a+b;
+}
+
+/* { dg-final { scan-assembler "bl __addkf3" } } */
Index: gcc/testsuite/gcc.target/powerpc/float128-type-2.c
===
--- gcc/testsuite/gcc.target/powerpc/float128-type-2.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/float128-type-2.c  (revision 0)
@@ -0,0 +1,31 @@
+/* { dg-do compile { target { powerpc64-*-linux* && lp64 } } } */
+/* { dg-require-effective-target powerpc_p9vector_ok } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power9" } } */
+/* { dg-options "-mcpu=power9 -O2" } */
+
+/* This test tests whether -mfloat128-type (which enables the underlying IEEE
+   128-bit floating point) is enabled by default on VSX Linux 64-bit systems,
+   even if the keywords __float128 and _Float128 (-mfloat128) are not enabled
+   via the -mfloat128 switch.  Test that power9 generates the xsaddqp
+   instruction.  */
+
+/* The effective target powerpc_float128_hw_ok is not used, as that will pass
+   -mfloat128.  */
+
+typedef double  __attribute__((__mode__(__KF__))) f128_t;
+typedef _Complex double __attribute__((__mode__(__KC__))) f128c_t;
+
+f128_t
+add_scalar (f128_t a, f128_t b)
+{
+  return a+b;
+}
+
+
+f128c_t
+add_complex (f128c_t a, f128c_t b)
+{
+  return a+b;
+}
+
+/* { dg-final { scan-assembler "xsaddqp" } } */

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

[Bug c++/66443] [DR 1611] Virtual inheritance vs. non-default constructors

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66443

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Nathan Sidwell  ---
Fixed in r240874.

Re: Repository for the conversion machinery

[Eric S. Raymond]

Jason Merrill :
> > I've used both git-svn (sometimes with git filter-branch) and reposurgeon
> > for repository conversions.  My experience is that if there's anything at
> > all complicated or messy about the history, using git-svn for the
> > conversion is not a good idea, so I don't think that's an attractive
> > option at all.
> 
> But we're already using git-svn, and it's fine.

My hair stands on end when I hear anyone say that.  git-svn is tolerable,
if a bit flaky, for live gatewaying. It is *dangerous* for whole-history
conversions.  I wrote a public-service announcement about this a while back.

Don’t do svn-to-git repository conversions with git-svn!
  http://esr.ibiblio.org/?p=6778

It should be more widely known that git-svn is bad in this mode; it's
not because on small, linear or near-linear repos without operator
errors or CVS-conversion scar tissues it happens to work reasonably
well. GCC is not in this category.

> Specifically, reposurgeon doesn't like subdirectory branches much more
> than git-svn does, though I was able to work around that with
> branchify (and some fixes in reposurgeon).  It discards branches with
> no additional commits, and keeps other branches that were deleted in
> SVN, though I was able to work around this with a postprocessing
> script.
> 
> Most significantly, it fails to handle some commits (I noticed r137307
> and r131989), leading to incorrect file content at the top of the
> affected branches.  This is the issue that I didn't hear back from
> Eric about, which led me to consider other approaches.  Fortunately it
> marked them (as well as many others) with emptycommit tags for review.
> 
> But if you want to do it with reposurgeon, I won't complain.  I've
> pushed my WIP to https://github.com/jicama/gcc-reposurgeon

This is my fault. I think you hit that bug right around one of the times I
was being most distracted by NTPsec, and I somehow formed the mistaken
impression you had gotten past it.

I'll get back on this.  I still have your bug report in my back mail; the
first thing I need to do is fix that.  Can't promise immediate action, I'm
preparing for the 1.0 release of NTPsec (spent the last week mostly
clearing our issue list) but now that I know this is unfinished I won't
drop it until it is.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

[Bug c++/64433] Segmentation fault while compiling

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64433

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Fri Oct  7 20:01:17 2016
New Revision: 240874

URL: https://gcc.gnu.org/viewcvs?rev=240874=gcc=rev
Log:
cp/
PR c++/64433
DR1658, DR1611
* init.c (emit_mem_initializers): Don't construct vbases of
abstract classes.
(push_base_cleanups): Don't push vbase cleanups for abstract class
when in C++14 mode.
* method.c (synthethesized_method_walk): Don't walk vbases of
abstract classes when in C++14 mode.

testsuite/
PR c++/66443
* g++.dg/cpp0x/pr66443-cxx11.C: New.
* g++.dg/cpp0x/pr66443-cxx11-2.C: New.
* g++.dg/cpp1y/pr66443-cxx14.C: New
* g++.dg/cpp1y/pr66443-cxx14-2.C: New.
* g++.dg/cpp1y/pr66443-cxx14-3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr66443-cxx11-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr66443-cxx11.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14-2.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14-3.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/66443] [DR 1611] Virtual inheritance vs. non-default constructors

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66443

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Fri Oct  7 20:01:17 2016
New Revision: 240874

URL: https://gcc.gnu.org/viewcvs?rev=240874=gcc=rev
Log:
cp/
PR c++/64433
DR1658, DR1611
* init.c (emit_mem_initializers): Don't construct vbases of
abstract classes.
(push_base_cleanups): Don't push vbase cleanups for abstract class
when in C++14 mode.
* method.c (synthethesized_method_walk): Don't walk vbases of
abstract classes when in C++14 mode.

testsuite/
PR c++/66443
* g++.dg/cpp0x/pr66443-cxx11.C: New.
* g++.dg/cpp0x/pr66443-cxx11-2.C: New.
* g++.dg/cpp1y/pr66443-cxx14.C: New
* g++.dg/cpp1y/pr66443-cxx14-2.C: New.
* g++.dg/cpp1y/pr66443-cxx14-3.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr66443-cxx11-2.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr66443-cxx11.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14-2.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14-3.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr66443-cxx14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog

Re: [PATCH, libgfortran] PR 67585 Handle EINTR

[Mike Stump]

On Oct 7, 2016, at 9:42 AM, Jack Howarth  wrote:
> 
> So using EINTR properly can be really tricky.

I'd not phrase it that way.  I'd phrase it as deferral can be tricky and 
choosing what action to do in a signal handler can be tricky.

I don't mention deferral nor signal semantics, as these are significantly more 
challenging.  Merely looping on EINTR I think is a no-brainer.

[Bug fortran/77406] ICE in generic_correspondence, at fortran/interface.c:1123

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77406

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.3

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on 6 and 7. Closing.

Re: [PATCH, libgfortran] PR 67585 Handle EINTR

[Mike Stump]

On Oct 7, 2016, at 7:50 AM, Fritz Reese  wrote:
> what if a user wants/expects a system call to be interrupted?

Then it is interrupted.

> With the patch we would always restart the system call even if

No, this is a misunderstanding on your part.  The signal is delivered and 
delivered first then the system call is restarted.

> the user was expecting it would be interrupted. For small calls like lseek 
> this may
> not be a big deal but if read on a pipe/socket/terminal is restarted
> after being interrupted (e.g. with CTRL-C) we may loop forever

No, that isn't possible.

> even if the user program was written to expect and handle EINTR after the read
> call, e.g. to terminate nicely with "non async-safe" calls like printf
> that couldn't be done in the handler.
> 
> This is discussed as "use case 2" in the PEP you referenced. Python
> handles this case by explicitly calling user defined signal handlers
> directly after EINTR and checking the return value from the handler,
> only trying again if the handler reports success. Not so simple I
> think with libgfortran.

Yes, it is.  signals are delivered first.  First in python, and first in C, 
there is a reason for that.

Re: [PATCH] Untested #pragma acc declare fix

[Nathan Sidwell]

On 10/07/16 08:21, Jakub Jelinek wrote:

Hi!

During review of Martin's -fsanitize-use-after-scope patch, I've noticed
what I believe is a bug in #pragma acc declare support.

In particular, the oacc_declare_returns has been added next to the CLOBBER
additions, but the clobbers are guarded with many conditions, e.g. aren't
emitted with -fstack-reuse=none and many other conditions.

I believe the additions to that data structure aren't guarded by these
conditions, it is just for VAR_DECLs that aren't is_global_var and have
current_function_decl context.

I haven't tested this patch (can bootstrap/regtest it), but don't have time
to try to write a testcase for all the cases where the conditions matter.


thanks, your logic seems sound.  I'll see what we can do about a test case.

nathan

[Bug fortran/38592] eliminate some string comparisons

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38592

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #6 from kargl at gcc dot gnu.org ---
Sometime between 4.8.4 and 4.9.4, the _gfortran_compare_string
has been replaced by a memcmp().

% gfc48 -O3 -fdump-tree-optimized -S -fdump-tree-original a.f90
% grep compare a.s
call_gfortran_compare_string
% gfc49 -O3 -fdump-tree-optimized -S -fdump-tree-original a.f90
% grep compare a.s


With gcc7, the -fdump-tree-original gives

  __builtin_memmove ((void *) , (void *) &"yes"[1]{lb: 1 sz: 1}, 3);
  {
struct __st_parameter_dt dt_parm.0;

dt_parm.0.common.filename = &"a.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 4;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (_parm.0);
{
  logical(kind=4) D.3408;

  D.3408 = __builtin_memcmp ((void *) &"yes"[1]{lb: 1 sz: 1},
 (void *) , 3) == 0;
  _gfortran_transfer_logical_write (_parm.0, , 4);
}
_gfortran_st_write_done (_parm.0);

and -fdump-tree-optimized shows

  :
  MEM[(c_char * {ref-all})] = "yes";
  dt_parm.0.common.filename = &"a.f90"[1]{lb: 1 sz: 1};
  dt_parm.0.common.line = 4;
  dt_parm.0.common.flags = 128;
  dt_parm.0.common.unit = 6;
  _gfortran_st_write (_parm.0);
  _1 = __builtin_memcmp_eq (&"yes"[1]{lb: 1 sz: 1}, , 3);
  _2 = _1 == 0;
  D.3408 = _2;
  _gfortran_transfer_logical_write (_parm.0, , 4);
  D.3408 ={v} {CLOBBER};
  _gfortran_st_write_done (_parm.0);
  dt_parm.0 ={v} {CLOBBER};
  a ={v} {CLOBBER};
  return;

I personally think this is non-issue now and the bug can be
closed.

Re: [C++ PATCH] Implement LWG2296 helper intrinsic

[Jason Merrill]

OK.

On Fri, Oct 7, 2016 at 3:23 PM, Jakub Jelinek  wrote:
> Hi!
>
> The following patch adds __builtin_addressof with the semantics it has in
> clang, i.e. it is a constexpr & operator alternative that never uses the
> overloaded & operator.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2016-10-07  Jakub Jelinek  
>
> Implement LWG2296 helper intrinsic
> c-family/
> * c-common.h (enum rid): Add RID_ADDRESSOF.
> * c-common.c (c_common_reswords): Add __builtin_addressof.
> cp/
> * parser.c (cp_parser_postfix_expression): Handle RID_ADDRESSOF.
> * cp-objcp-common.c (cp_common_init_ts): Handle ADDRESSOF_EXPR.
> * constexpr.c (potential_constant_expression_1): Likewise.
> * error.c (dump_expr): Likewise.
> * typeck.c (cp_build_addressof): New function.
> * cp-tree.h (cp_build_addressof): Declare.
> * cxx-pretty-print.h (pp_cxx_addressof_expression): Declare.
> * cp-tree.def (ADDRESSOF_EXPR): New tree code.
> * cxx-pretty-print.c (cxx_pretty_printer::primary_expression): Handle
> ADDRESSOF_EXPR.  Add __builtin_addressof and
> __has_unique_object_representations into syntax in function comment.
> (pp_cxx_addressof_expression): New function.
> * pt.c (tsubst_copy_and_build): Handle ADDRESSOF_EXPR.
> testsuite/
> * g++.dg/cpp0x/addressof1.C: New test.
> * g++.dg/cpp0x/addressof2.C: New test.
>
> --- gcc/c-family/c-common.h.jj  2016-10-06 23:16:43.347087129 +0200
> +++ gcc/c-family/c-common.h 2016-10-07 09:24:56.377835519 +0200
> @@ -146,6 +146,7 @@ enum rid
>RID_CONSTCAST, RID_DYNCAST, RID_REINTCAST, RID_STATCAST,
>
>/* C++ extensions */
> +  RID_ADDRESSOF,
>RID_BASES,   RID_DIRECT_BASES,
>RID_HAS_NOTHROW_ASSIGN,  RID_HAS_NOTHROW_CONSTRUCTOR,
>RID_HAS_NOTHROW_COPY,RID_HAS_TRIVIAL_ASSIGN,
> --- gcc/c-family/c-common.c.jj  2016-10-06 23:16:43.351087082 +0200
> +++ gcc/c-family/c-common.c 2016-10-07 09:24:56.380835482 +0200
> @@ -463,6 +463,7 @@ const struct c_common_resword c_common_r
>{ "__attribute__",   RID_ATTRIBUTE,  0 },
>{ "__auto_type", RID_AUTO_TYPE,  D_CONLY },
>{ "__bases",  RID_BASES, D_CXXONLY },
> +  { "__builtin_addressof", RID_ADDRESSOF, D_CXXONLY },
>{ "__builtin_call_with_static_chain",
>  RID_BUILTIN_CALL_WITH_STATIC_CHAIN, D_CONLY },
>{ "__builtin_choose_expr", RID_CHOOSE_EXPR, D_CONLY },
> --- gcc/cp/parser.c.jj  2016-10-06 23:16:43.362086951 +0200
> +++ gcc/cp/parser.c 2016-10-07 09:55:18.386923503 +0200
> @@ -6602,6 +6602,7 @@ cp_parser_postfix_expression (cp_parser
> break;
>}
>
> +case RID_ADDRESSOF:
>  case RID_BUILTIN_SHUFFLE:
>{
> vec *vec;
> @@ -6618,19 +6619,29 @@ cp_parser_postfix_expression (cp_parser
> FOR_EACH_VEC_ELT (*vec, i, p)
>   mark_exp_read (p);
>
> -   if (vec->length () == 2)
> - return build_x_vec_perm_expr (loc, (*vec)[0], NULL_TREE, (*vec)[1],
> -tf_warning_or_error);
> -   else if (vec->length () == 3)
> - return build_x_vec_perm_expr (loc, (*vec)[0], (*vec)[1], (*vec)[2],
> -tf_warning_or_error);
> -   else
> -   {
> - error_at (loc, "wrong number of arguments to "
> - "%<__builtin_shuffle%>");
> - return error_mark_node;
> -   }
> -   break;
> +   switch (keyword)
> + {
> + case RID_ADDRESSOF:
> +   if (vec->length () == 1)
> + return cp_build_addressof (loc, (*vec)[0], tf_warning_or_error);
> +   error_at (loc, "wrong number of arguments to "
> +  "%<__builtin_addressof%>");
> +   return error_mark_node;
> +
> + case RID_BUILTIN_SHUFFLE:
> +   if (vec->length () == 2)
> + return build_x_vec_perm_expr (loc, (*vec)[0], NULL_TREE,
> +   (*vec)[1], tf_warning_or_error);
> +   else if (vec->length () == 3)
> + return build_x_vec_perm_expr (loc, (*vec)[0], (*vec)[1],
> +   (*vec)[2], tf_warning_or_error);
> +   error_at (loc, "wrong number of arguments to "
> +  "%<__builtin_shuffle%>");
> +   return error_mark_node;
> +
> + default:
> +   gcc_unreachable ();
> + }
>}
>
>  default:
> --- gcc/cp/cp-objcp-common.c.jj 2016-10-06 17:46:29.0 +0200
> +++ gcc/cp/cp-objcp-common.c2016-10-07 09:55:18.391923440 +0200
> @@ -315,6 +315,7 @@ cp_common_init_ts (void)
>MARK_TS_TYPED (STMT_EXPR);
>MARK_TS_TYPED (OFFSET_REF);
>MARK_TS_TYPED (OFFSETOF_EXPR);
> +  MARK_TS_TYPED (ADDRESSOF_EXPR);
>MARK_TS_TYPED (PTRMEM_CST);
>MARK_TS_TYPED (EMPTY_CLASS_EXPR);
>

Re: VR_RANGE with inverted bounds

[Richard Biener]

On October 7, 2016 8:03:34 PM GMT+02:00, Martin Sebor  wrote:
>On 10/07/2016 11:15 AM, Richard Biener wrote:
>> On October 7, 2016 6:49:39 PM GMT+02:00, Martin Sebor
> wrote:
>>> While processing the (p += i) expression below to validate the
>bounds
>>> of the pointer in I call get_range_info for i (in
>tree-object-size.c).
>>> The function returns the following VR_RANGE: [2147483648,
>-2147483649]
>>> rather than the expected [0, 1].  Is such a range to be expected or
>>> is it a bug?
>>
>> This range is not valid (unless unsigned and you show it as signed).
>
>Thanks.  I believe it's signed but even if it was unsigned it wouldn't
>be correct (correspond to the actual range of [0, 1]).
>
>I don't have a test case that makes this manifest with an unpatched
>compiler.  There aren't too many places that call get_range_info
>and the range only appears to be wrong between the second and third
>runs of the object-size pass.  After the third run the range is
>correct.  (I can see this with the -Wformat-length warning when
>I pass the variable to sprintf and trigger a warning.)
>
>Unless you have a suggestion for how I might be able to reproduce
>it I'll go ahead and open a bug and include a minimum patch to show
>the problem.

Look at -fdump-tree-all-alias dumps, they show the present ranges.  See where 
they get introduced.

Richard.

>Martin

Re: Repository for the conversion machinery

[Jason Merrill]

On Thu, Oct 6, 2016 at 4:31 PM, Joseph Myers  wrote:
> On Thu, 6 Oct 2016, Jason Merrill wrote:
>
>> After I ran into a couple of reposurgeon bugs and didn't hear back
>> from you, I started investigating rewriting the existing git svn
>> mirror with git filter-branch instead.  That seems an attractive
>> option, but not long afterward I needed to shift focus to front end
>
> I've used both git-svn (sometimes with git filter-branch) and reposurgeon
> for repository conversions.  My experience is that if there's anything at
> all complicated or messy about the history, using git-svn for the
> conversion is not a good idea, so I don't think that's an attractive
> option at all.

But we're already using git-svn, and it's fine.  Introducing another
tool just adds opportunities to be affected by new and different bugs.

Specifically, reposurgeon doesn't like subdirectory branches much more
than git-svn does, though I was able to work around that with
branchify (and some fixes in reposurgeon).  It discards branches with
no additional commits, and keeps other branches that were deleted in
SVN, though I was able to work around this with a postprocessing
script.

Most significantly, it fails to handle some commits (I noticed r137307
and r131989), leading to incorrect file content at the top of the
affected branches.  This is the issue that I didn't hear back from
Eric about, which led me to consider other approaches.  Fortunately it
marked them (as well as many others) with emptycommit tags for review.

But if you want to do it with reposurgeon, I won't complain.  I've
pushed my WIP to https://github.com/jicama/gcc-reposurgeon

Jason

[Bug c/38295] Support pointer difference as constant in static initializer

[fw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295

Florian Weimer  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 CC||fw at gcc dot gnu.org
 Resolution|WONTFIX |---

--- Comment #10 from Florian Weimer  ---
This is already implemented for differences between C && label addresses.  I
think there is no compelling reason why this would not work for the addresses
of static functions, too.

Re: [PATCH, libgfortran] PR 67585 Handle EINTR

[Mike Stump]

On Oct 7, 2016, at 5:59 AM, Janne Blomqvist  wrote:
> 
> So I suppose in theory you could have a situation where something
> continuously fires signals at the process, and the result is some kind
> of race between the process restarting the syscall which then never
> manages to complete before being interrupted again. But I think this
> goes into the "Doctor, this hurts! Then don't do that" territory.

No, this is in the territory of seriously broken software that I don't think 
has ever existed.

[C++ PATCH] Implement LWG2296 helper intrinsic

[Jakub Jelinek]

Hi!

The following patch adds __builtin_addressof with the semantics it has in
clang, i.e. it is a constexpr & operator alternative that never uses the
overloaded & operator.

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

2016-10-07  Jakub Jelinek  

Implement LWG2296 helper intrinsic
c-family/
* c-common.h (enum rid): Add RID_ADDRESSOF.
* c-common.c (c_common_reswords): Add __builtin_addressof.
cp/
* parser.c (cp_parser_postfix_expression): Handle RID_ADDRESSOF.
* cp-objcp-common.c (cp_common_init_ts): Handle ADDRESSOF_EXPR.
* constexpr.c (potential_constant_expression_1): Likewise.
* error.c (dump_expr): Likewise.
* typeck.c (cp_build_addressof): New function.
* cp-tree.h (cp_build_addressof): Declare.
* cxx-pretty-print.h (pp_cxx_addressof_expression): Declare.
* cp-tree.def (ADDRESSOF_EXPR): New tree code.
* cxx-pretty-print.c (cxx_pretty_printer::primary_expression): Handle
ADDRESSOF_EXPR.  Add __builtin_addressof and
__has_unique_object_representations into syntax in function comment.
(pp_cxx_addressof_expression): New function.
* pt.c (tsubst_copy_and_build): Handle ADDRESSOF_EXPR.
testsuite/
* g++.dg/cpp0x/addressof1.C: New test.
* g++.dg/cpp0x/addressof2.C: New test.

--- gcc/c-family/c-common.h.jj  2016-10-06 23:16:43.347087129 +0200
+++ gcc/c-family/c-common.h 2016-10-07 09:24:56.377835519 +0200
@@ -146,6 +146,7 @@ enum rid
   RID_CONSTCAST, RID_DYNCAST, RID_REINTCAST, RID_STATCAST,
 
   /* C++ extensions */
+  RID_ADDRESSOF,
   RID_BASES,   RID_DIRECT_BASES,
   RID_HAS_NOTHROW_ASSIGN,  RID_HAS_NOTHROW_CONSTRUCTOR,
   RID_HAS_NOTHROW_COPY,RID_HAS_TRIVIAL_ASSIGN,
--- gcc/c-family/c-common.c.jj  2016-10-06 23:16:43.351087082 +0200
+++ gcc/c-family/c-common.c 2016-10-07 09:24:56.380835482 +0200
@@ -463,6 +463,7 @@ const struct c_common_resword c_common_r
   { "__attribute__",   RID_ATTRIBUTE,  0 },
   { "__auto_type", RID_AUTO_TYPE,  D_CONLY },
   { "__bases",  RID_BASES, D_CXXONLY },
+  { "__builtin_addressof", RID_ADDRESSOF, D_CXXONLY },
   { "__builtin_call_with_static_chain",
 RID_BUILTIN_CALL_WITH_STATIC_CHAIN, D_CONLY },
   { "__builtin_choose_expr", RID_CHOOSE_EXPR, D_CONLY },
--- gcc/cp/parser.c.jj  2016-10-06 23:16:43.362086951 +0200
+++ gcc/cp/parser.c 2016-10-07 09:55:18.386923503 +0200
@@ -6602,6 +6602,7 @@ cp_parser_postfix_expression (cp_parser
break;
   }
 
+case RID_ADDRESSOF:
 case RID_BUILTIN_SHUFFLE:
   {
vec *vec;
@@ -6618,19 +6619,29 @@ cp_parser_postfix_expression (cp_parser
FOR_EACH_VEC_ELT (*vec, i, p)
  mark_exp_read (p);
 
-   if (vec->length () == 2)
- return build_x_vec_perm_expr (loc, (*vec)[0], NULL_TREE, (*vec)[1],
-tf_warning_or_error);
-   else if (vec->length () == 3)
- return build_x_vec_perm_expr (loc, (*vec)[0], (*vec)[1], (*vec)[2],
-tf_warning_or_error);
-   else
-   {
- error_at (loc, "wrong number of arguments to "
- "%<__builtin_shuffle%>");
- return error_mark_node;
-   }
-   break;
+   switch (keyword)
+ {
+ case RID_ADDRESSOF:
+   if (vec->length () == 1)
+ return cp_build_addressof (loc, (*vec)[0], tf_warning_or_error);
+   error_at (loc, "wrong number of arguments to "
+  "%<__builtin_addressof%>");
+   return error_mark_node;
+
+ case RID_BUILTIN_SHUFFLE:
+   if (vec->length () == 2)
+ return build_x_vec_perm_expr (loc, (*vec)[0], NULL_TREE,
+   (*vec)[1], tf_warning_or_error);
+   else if (vec->length () == 3)
+ return build_x_vec_perm_expr (loc, (*vec)[0], (*vec)[1],
+   (*vec)[2], tf_warning_or_error);
+   error_at (loc, "wrong number of arguments to "
+  "%<__builtin_shuffle%>");
+   return error_mark_node;
+
+ default:
+   gcc_unreachable ();
+ }
   }
 
 default:
--- gcc/cp/cp-objcp-common.c.jj 2016-10-06 17:46:29.0 +0200
+++ gcc/cp/cp-objcp-common.c2016-10-07 09:55:18.391923440 +0200
@@ -315,6 +315,7 @@ cp_common_init_ts (void)
   MARK_TS_TYPED (STMT_EXPR);
   MARK_TS_TYPED (OFFSET_REF);
   MARK_TS_TYPED (OFFSETOF_EXPR);
+  MARK_TS_TYPED (ADDRESSOF_EXPR);
   MARK_TS_TYPED (PTRMEM_CST);
   MARK_TS_TYPED (EMPTY_CLASS_EXPR);
   MARK_TS_TYPED (VEC_INIT_EXPR);
--- gcc/cp/constexpr.c.jj   2016-10-06 17:46:29.0 +0200
+++ gcc/cp/constexpr.c  2016-10-07 09:55:18.395923390 +0200
@@ -5025,6 +5025,11 @@ potential_constant_expression_1 (tree t,
 return (RECUR (from, TREE_CODE (t) != VIEW_CONVERT_EXPR));
  

Re: error printing in reversed order ?

[David Malcolm]

On Fri, 2016-10-07 at 15:08 -0400, nicolas bouillot wrote:
> Hi,
> 
> Was wondering this could be a feature request ? Basically, this could
> be a GCC option to print compilation errors in a reversed order, i.e.
> the first being printed last. This is because when compiling from the
> terminal, it would avoid mouse scrolling all day in order to get the
> first error.
> 
> I'll be happy to write a feature request somewhere if this deserves
> it, but I do not know where and if this can be considered as a
> feature
> request.

There's an option
  -fmax-errors=
which can be set to limit the number of errors emitted.

It defaults to off.  The clang equivalent, -ferror-limit=, defaults to
20.

Maybe we should change -fmax-errors= to default to on, maybe 20?  This
ought to solve the "scrolling all day" problem you describe.

Also, our error message is "computerese":

  compilation terminated due to -fmax-errors=2.

clang's is better:

  fatal error: too many errors emitted, stopping now [-ferror-limit=]

but we could improve ours by showing the number after the option), and
say how to disable the limiter:

  fatal error: too many errors emitted, stopping now [-fmax-errors=2]
 
note: use -fmax-errors=0 to print all errors

or somesuch.

Thoughts?

Dave

[Bug fortran/77897] Compile error with KNL & -O3 for GTC code

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897

--- Comment #1 from Bill Long  ---
Compiling these files appears to have a problem when the target is set to Intel
KNL.  The compiler appears to be generating incorrect register and instruction
names, leading to assembler messages.  See with gfortran 6.2.

Compiles OK with any of these changes:

1) Change target to Sandybridge
2) Remove the -O3 option
3) Use a different vendor compiler (Cray)

Re: [PATCH, libgfortran] PR 67585 Handle EINTR

[Mike Stump]

On Oct 7, 2016, at 5:41 AM, FX  wrote:
> 
>> Many POSIX systems have the bad habit of not restarting interrupted
>> syscalls. On these systems it's up to the user to check for an error
>> with errno == EINTR and restart manually. This patch does this for
>> libgfortran, so that GFortran users don't have to do it.
> 
> I have not much experience with EINTR, but is it garanteed that those EINTR 
> loops will never cycle forever?

They will not.  You get at most 1 for 1 signal, sometimes less.  If you have a 
finite number of signals, you will have a finite number of loops.

RE: error printing in reversed order ?

[Joe Buck]

You can already do this today.  Run the output of the compiler through 'tac'.  
No need for a new feature.  

https://linux.die.net/man/1/tac

-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of nicolas 
bouillot
Sent: Friday, October 07, 2016 12:09 PM
To: gcc@gcc.gnu.org
Subject: error printing in reversed order ?

Hi,

Was wondering this could be a feature request ? Basically, this could be a GCC 
option to print compilation errors in a reversed order, i.e.
the first being printed last. This is because when compiling from the terminal, 
it would avoid mouse scrolling all day in order to get the first error.

I'll be happy to write a feature request somewhere if this deserves it, but I 
do not know where and if this can be considered as a feature request.

Nicolas

[Bug fortran/77897] New: Compile error with KNL & -O3 for GTC code

[longb at cray dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897

Bug ID: 77897
   Summary: Compile error with KNL & -O3 for GTC code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: longb at cray dot com
  Target Milestone: ---

Created attachment 39767
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39767=edit
Source files module.F90 and pushe.f90 (in bug.tar)

As a basic sanity check:

> ftn -c module.F90
> ftn -c pushe.f90 
> module swap PrgEnv-cray PrgEnv-gnu
> ftn -c module.F90
> ftn -c pushe.f90 
> ftn -c -O3 module.F90
> ftn -c -O3 pushe.f90 
> 
> module list
Currently Loaded Modulefiles:
...
 12) gcc/6.2.0
 13) craype-network-aries
 14) craype-sandybridge


Now checking KNL target:

> module swap craype-sandybridge craype-mic-knl
> ftn -c -O3 module.F90
> ftn -c -O3 pushe.f90 
/tmp/cc4TRnzd.s: Assembler messages:
/tmp/cc4TRnzd.s:61: Error: bad register name `%xmm24'
/tmp/cc4TRnzd.s:63: Error: bad register name `%xmm24'
/tmp/cc4TRnzd.s:65: Error: bad register name `%xmm16'
...
[many more lines of messages]

error printing in reversed order ?

[nicolas bouillot]

Hi,

Was wondering this could be a feature request ? Basically, this could
be a GCC option to print compilation errors in a reversed order, i.e.
the first being printed last. This is because when compiling from the
terminal, it would avoid mouse scrolling all day in order to get the
first error.

I'll be happy to write a feature request somewhere if this deserves
it, but I do not know where and if this can be considered as a feature
request.

Nicolas

[Bug fortran/77406] ICE in generic_correspondence, at fortran/interface.c:1123

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77406

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct  7 18:57:45 2016
New Revision: 240871

URL: https://gcc.gnu.org/viewcvs?rev=240871=gcc=rev
Log:
2016-10-07  Steven G. Kargl  

PR fortran/77406
* interface.c (gfc_compare_interfaces): Fix detection of ambiguous
interface involving alternate return.
(check_interface1): Improve error message and loci.

2016-10-07  Steven G. Kargl  

PR fortran/77406
* gfortran.dg/pr77406.f90: New test.
* gfortran.dg/assumed_type_3.f90: Update error messages.
* gfortran.dg/defined_operators_1.f90: Ditto.
* gfortran.dg/generic_26.f90: Ditto.
* gfortran.dg/generic_7.f90: Ditto.
* gfortran.dg/gomp/udr5.f90: Ditto.
* gfortran.dg/gomp/udr7.f90: Ditto.
* gfortran.dg/interface_1.f90: Ditto.
* gfortran.dg/interface_37.f90: Ditto.
* gfortran.dg/interface_5.f90: Ditto.
* gfortran.dg/interface_6.f90: Ditto.
* gfortran.dg/interface_7.f90
* gfortran.dg/no_arg_check_3.f90
* gfortran.dg/operator_5.f90
* gfortran.dg/proc_ptr_comp_20.f90: Ditto.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr77406.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/interface.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/assumed_type_3.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/defined_operators_1.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/generic_26.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/generic_7.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/udr5.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/gomp/udr7.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_1.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_37.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_5.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_6.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_7.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/no_arg_check_3.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/operator_5.f90
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_20.f90

Re: [patch,wwwdocs] Add v7 AVR release notes.

[Denis Chertykov]

2016-10-07 17:06 GMT+03:00 Georg-Johann Lay :
> Mentioning some AVR target specific improvements.
>
> Ok?
>

Ok.

[PATCH] go-lang.c: remove a redundant cast

[David Malcolm]

Amongst many other changes, r146451 added this cast:

 -#define GET_MODE_CLASS(MODE)  mode_class[MODE]
 +#define GET_MODE_CLASS(MODE)  ((enum mode_class) mode_class[MODE])

making a cast in go-lang.c redundant; remove it.

Successfully bootstrapped on x86_64-pc-linux-gnu.

OK for trunk?

gcc/go/ChangeLog:
* go-lang.c (go_langhook_type_for_mode): Remove redundant cast
from result of GET_MODE_CLASS.  Minor formatting fixes.
---
 gcc/go/go-lang.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/go/go-lang.c b/gcc/go/go-lang.c
index 88667e0..acf1fb7 100644
--- a/gcc/go/go-lang.c
+++ b/gcc/go/go-lang.c
@@ -370,10 +370,9 @@ go_langhook_type_for_mode (machine_mode mode, int 
unsignedp)
   return NULL_TREE;
 }
 
-  // FIXME: This static_cast should be in machmode.h.
-  enum mode_class mc = static_cast(GET_MODE_CLASS(mode));
+  enum mode_class mc = GET_MODE_CLASS (mode);
   if (mc == MODE_INT)
-return go_langhook_type_for_size(GET_MODE_BITSIZE(mode), unsignedp);
+return go_langhook_type_for_size (GET_MODE_BITSIZE (mode), unsignedp);
   else if (mc == MODE_FLOAT)
 {
   switch (GET_MODE_BITSIZE (mode))
-- 
1.8.5.3

[Bug c++/77896] New: Object vtable lookups are not hoisted out of loops

[scovich at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77896

Bug ID: 77896
   Summary: Object vtable lookups are not hoisted out of loops
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: scovich at gmail dot com
  Target Milestone: ---

C++ virtual function calls normally require two memory loads followed by an
indirect jump: one load fetches the vtable from the object, another to fetch
the function address from the vtable, and the indirect call to invoke the
function. 

Given that an object's vtable is fixed over its lifetime, and the contents of a
given vtable are compile-time constant, I would expect the vtable lookups to be
hoisted out of loops when appropriate. For example:

 foo.cpp ===
struct Foo { virtual void frob(int i)=0; };
void frobN(Foo* f, int n) {
   for (int i=0; i < n; i++)
  f->frob(i);
}


Compiles at -O2 to substantially the same x86 assembly code for gcc-4.9,
gcc-5.2 and gcc-6.2:

_Z5frobNP3Fooi:
testl   %esi, %esi
jle .L10
pushq   %r12
movl%esi, %r12d
pushq   %rbp
movq%rdi, %rbp
pushq   %rbx
xorl%ebx, %ebx
.L5:
movq0(%rbp), %rax
movl%ebx, %esi
addl$1, %ebx
movq%rbp, %rdi
call*(%rax)
cmpl%ebx, %r12d
jne .L5
popq%rbx
popq%rbp
popq%r12
.L10:
rep ret

I would have expected to see something more like this (obtained using the bound
member function extension):

_Z5frobNP3Fooi:
.LFB12:
pushq   %r13
pushq   %r12
pushq   %rbp
pushq   %rbx
subq$8, %rsp
movq(%rdi), %rax
testl   %esi, %esi
movq(%rax), %r13
jle .L1
movq%rdi, %r12
movl%esi, %ebp
xorl%ebx, %ebx
.L5:
movl%ebx, %esi
addl$1, %ebx
movq%r12, %rdi
call*%r13
cmpl%ebx, %ebp
jne .L5
.L1:
addq$8, %rsp
popq%rbx
popq%rbp
popq%r12
popq%r13
ret

Altering the test case to trigger speculative devirtualization as follows:

 bug2.cpp ===
#include 
struct Foo { virtual void frob(int i)=0; };
void frobN(Foo* f, int n)
{
   for (int i=0; i < n; i++)
  f->frob(i);
}
struct Bar : Foo { 
   void frob(int i) { printf("Bar:%d\n", i); }
};
int main()
{
   Bar b;
   frobN(, 10);
}
=

Shows that even the speculative devirtualization is stuck inside the loop body:

_Z5frobNP3Fooi:
testl   %esi, %esi
jle .L13
pushq   %r12
movl%esi, %r12d
pushq   %rbp
movq%rdi, %rbp
pushq   %rbx
xorl%ebx, %ebx
jmp .L8
.L16:
xorl%eax, %eax
movl$.LC0, %edi
addl$1, %ebx
callprintf
cmpl%ebx, %r12d
je  .L15
.L8:
movq0(%rbp), %rax
movl%ebx, %esi
movq(%rax), %rax
cmpq$_ZN3Bar4frobEi, %rax
je  .L16
addl$1, %ebx
movq%rbp, %rdi
call*%rax
cmpl%ebx, %r12d
jne .L8
.L15:
popq%rbx
popq%rbp
popq%r12
.L13:
rep ret

If the vtable lookup could be hoisted, the speculative de-virt could become
very powerful by replicating the loop, something like this:

_Z5frobNP3Fooi:
testl   %esi, %esi
jle .L10
pushq   %r12
movl%esi, %r12d
pushq   %rbp
movq%rdi, %rbp
pushq   %rbx
xorl%ebx, %ebx
movq0(%rbp), %rax
pushq   %r12
movq(%rax), %r13
cmpq$_ZN3Bar4frobEi, %r13
je  .L16
.L5:
movl%ebx, %esi
addl$1, %ebx
movq%rbp, %rdi
call*%r13
cmpl%ebx, %r12d
jne .L5
jmp .L10
.L16:
xorl%eax, %eax
movl$.LC0, %edi
movl%ebx, %esi
addl$1, %ebx
callprintf
cmpl%ebx, %r12d
jne .L16
popq%r13
.L10:
popq%rbx
popq%rbp
popq%r12
rep ret

[Bug fortran/77406] ICE in generic_correspondence, at fortran/interface.c:1123

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77406

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Oct  7 18:18:03 2016
New Revision: 240870

URL: https://gcc.gnu.org/viewcvs?rev=240870=gcc=rev
Log:
2016-10-07  Steven G. Kargl  

PR fortran/77406
* interface.c (gfc_compare_interfaces): Fix detection of ambiguous
interface involving alternate return.
(check_interface1): Improve error message and loci.

2016-10-07  Steven G. Kargl  

PR fortran/77406
* gfortran.dg/pr77406.f90: New test.
* gfortran.dg/assumed_type_3.f90: Update error messages.
* gfortran.dg/defined_operators_1.f90: Ditto.
* gfortran.dg/generic_26.f90: Ditto.
* gfortran.dg/generic_7.f90: Ditto.
* gfortran.dg/gomp/udr5.f90: Ditto.
* gfortran.dg/gomp/udr7.f90: Ditto.
* gfortran.dg/interface_1.f90: Ditto.
* gfortran.dg/interface_37.f90: Ditto.
* gfortran.dg/interface_5.f90: Ditto.
* gfortran.dg/interface_6.f90: Ditto.
* gfortran.dg/interface_7.f90
* gfortran.dg/no_arg_check_3.f90
* gfortran.dg/operator_5.f90
* gfortran.dg/proc_ptr_comp_20.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77406.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/assumed_type_3.f90
trunk/gcc/testsuite/gfortran.dg/defined_operators_1.f90
trunk/gcc/testsuite/gfortran.dg/generic_26.f90
trunk/gcc/testsuite/gfortran.dg/generic_7.f90
trunk/gcc/testsuite/gfortran.dg/gomp/udr5.f90
trunk/gcc/testsuite/gfortran.dg/gomp/udr7.f90
trunk/gcc/testsuite/gfortran.dg/interface_1.f90
trunk/gcc/testsuite/gfortran.dg/interface_37.f90
trunk/gcc/testsuite/gfortran.dg/interface_5.f90
trunk/gcc/testsuite/gfortran.dg/interface_6.f90
trunk/gcc/testsuite/gfortran.dg/interface_7.f90
trunk/gcc/testsuite/gfortran.dg/no_arg_check_3.f90
trunk/gcc/testsuite/gfortran.dg/operator_5.f90
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_20.f90

Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)

[David Malcolm]

On Fri, 2016-10-07 at 15:58 +0200, Bernd Schmidt wrote:
> On 10/07/2016 03:26 PM, David Malcolm wrote:
> > 
> > We could simply print the INSN_UID for CODE_LABELs; something like
> > this
> > (see the "(code_label 16" below):
> 
> I think that should work.

OK: we'll keep the INSN_UID for CODE_LABELs when suppressing it for
others.

Should we drop the "[1 uses]" in the code_label? i.e. should it look
like this:

(code_label 16 [1 uses])

or this:

(code_label 16)

> > You appear to have trimmed the idea of enclosing the insns with
> > (basic-block) directives without commenting on it.  Did you like
> > this
> > idea?
> 
> Sorry - I appear to have completely missed it.
> 
> > It would make the above look like:
> > 
> >   (basic-block 2
> > ;; insns snipped
> > (jump_insn (set (pc)
> > (if_then_else (ge (reg:CCGC 17 flags)
> > (const_int 0 [0]))
> > (label_ref 16)
> > (pc))) "test.c":3
> >-> 16)
> >   ) ;; basic-block 2
> >   (basic-block 4
> > (note [bb 4] NOTE_INSN_BASIC_BLOCK)
> > ;; insns snipped
> > (jump_insn (set (pc) (label_ref 20)) "test.c":4
> >  -> 20)
> >   ) ;; basic-block 4
> >   (barrier)
> >   (basic-block 5
> > (code_label 16 [1 uses])
> > (note [bb 5] NOTE_INSN_BASIC_BLOCK)
> > ;; etc
> >   ) ;; basic-block 5
> > 
> > Note how the above format expresses clearly that:
> > * the (barrier) is part of the insn chain, but not in a basic
> > block, and
> > * some insns can happen in a basic block
> 
> That looks really nice IMO. Except maybe drop the "-> 16" bit for the
> jump_insn (that's the JUMP_LABEL, isn't it?)

It is the JUMP_LABEL.  This can be an INSN_UID, but it can also be
"return" or "simple_return"; presumably we do want to print JUMP_LABEL
somehow, though maybe it's always possible to reconstruct it:

  (jump_insn (simple_return) "test.c":15
   -> simple_return)

> > Taking this idea further: if we have (basic-block) directives
> > integrated into the insn-chain like this, we could express the CFG
> > by
> > adding (edge) directives. Here's a suggestion for doing it with
> > (edge-from) and (edge-to) directives, expressing the predecessor
> > and
> > successor edges in the CFG, along with :
> 
> That also looks reasonable. Probably a small but maybe not a huge 
> improvement over the other syntax. Having both from and to edges
> seems 
> redundant but might help readability. The reader should check 
> consistency in that case.

Would you prefer if it just showed out-edges?  If so, should the
directive be just "(edge" rather than "(edge-to"?

Did you like the stringified flags? e.g.

(edge-to 4 (flags "FALLTHRU"))

presumably with | separators within the string e.g.:

(edge-to 4 (flags "ABNORMAL | EH"))

> > Should we spell "0" and "1" as "entry" and "exit" when
> > parsing/dumping
> > basic block indices? e.g.:
> > 
> >   (basic-block 2
> > (edge-from entry)
> 
> If that can be done it would be an improvement.

Yes, it ought to be simple to do.

> > > I think maybe you want a separate compact form of insns and notes
> > > (cinsn/cnote maybe), with a flag selecting which gets written out
> > > in
> > > the
> > > dumper. The reader could then read them in like any other rtx
> > > code,
> > > and
> > > there'd be a postprocessing stage to reconstruct the insn chain.
> > 
> > By this separate compact form, do you mean the form we've been
> > discussing above, with no INSN_UID/PREV/NEXT, etc?  Or something
> > else?
> 
> Yes, the form we're discussing, except instead of (insn ...) you'd
> have 
> (cinsn ...), which I assume would make it easier for the reader and
> less 
> ambiguous overall.

By "reader" do you mean humans or computers? (or both?)

> > As for "cinsn", "cnote", how about just "insn" and "note", and
> > having
> > the compactness be expressed at the top of the dump e.g. implicitly
> > by
> > the presence of a "(function" directive.  Could even have a format
> > version specifier in the function directive, to give us some future
> > -proofing e.g.
> >   (function (format 20161007)
> > or somesuch.
> 
> Having it implicit should also be ok - I have no strong preference 
> really. I'm not sure we want versionin

[PATCH] Improve implementation-defined docs for libstdc++

[Jonathan Wakely]

We're required to document anything the standard says is
implementation-defined. This adds a few missing things to the C++98
and C++11 docs, and adds the new stuff for C++17.

I'll regenerate the HTML soon, as I'll be making some more doc changes
next week.

* doc/xml/manual/status_cxx1998.xml: Improve documentation of
implementation-defined properties.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise.

Committed to trunk. I'll backport the relevant parts to the branches
too.

commit f31956238e6e47f44a333e48fc903c6b6b6f8835
Author: Jonathan Wakely 
Date:   Fri Oct 7 16:17:28 2016 +0100

Improve implementation-defined docs for libstdc++

* doc/xml/manual/status_cxx1998.xml: Improve documentation of
implementation-defined properties.
* doc/xml/manual/status_cxx2011.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
index 1679ee0..6afb016 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
@@ -1087,19 +1087,14 @@ particular release.
   [18.6.1]/8 (exception),
   [18.6.2.1]/5 (bad_exception):  The 
what()
   member function of class std::exception, and these other
-  classes publicly derived from it, simply returns the name of the
-  class.  But they are the mangled names; you will 
need to call
-  c++filt and pass the names as command-line parameters to
-  demangle them, or call a
-  runtime demangler function.
-  (The classes in stdexcept have constructors which
-  require an argument to use later for what() calls, so the
-  problem of what()'s value does not arise in most
-  user-defined exceptions.)
+  classes publicly derived from it, returns the name of the
+  class, e.g. "std::bad_alloc".

[18.5.1]/7 The return value of
-  std::type_info::name() is the mangled type name (see the
-  previous entry for more).
+  std::type_info::name() is the mangled type name.
+  You will need to call c++filt and pass the names as
+  command-line parameters to demangle them, or call a
+  runtime demangler function.

[20.1.5]/5 "Implementors are 
encouraged to
   supply libraries that can accept allocators that encapsulate more
@@ -1114,6 +1109,7 @@ particular release.

[21.1.3.1]/3,4,
   [21.1.3.2]/2,
+  [21.3]/6 basic_string::iterator, 
basic_string::const_iterator,
   [23.*]'s foo::iterator,
   [27.*]'s foo::*_type,
   others...
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
index e1b372d..83a266f 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
@@ -2572,9 +2572,41 @@ particular release.

 

+  17.6.5.12 [res.on.exception.handling]
+  There are no implementation-defined exception classes, only standard
+  exception classes (or classes derived from them) will be thrown.
+   
+
+   
+  17.6.5.14 [value.error.codes]
+  The error_category for errors originating outside
+  the OS, and the possible error code values for each error category,
+  should be documented here.
+   
+
+   
+  18.6.2.2 [new.badlength]
+  what() returns
+  "std::bad_array_new_length".
+   
+
+   
+  20.6.9.1 [allocator.member]/5
+  Over-aligned types are not supported by
+  std::allocator.
+   
+
+   
   20.7.2.2.1 [util.smartptr.shared.const]
-  Only bad_alloc (or types derived from it) will
-  be thrown.
+  When a shared_ptr constructor fails
+  bad_alloc (or types derived from it) will
+  be thrown, or when an allocator is passed to the constructor then any
+  exceptions thrown by the allocator.
+   
+
+   
+  20.7.2.0 [util.smartptr.weakptr]
+  what() returns "bad_weak_ptr".

 

@@ -2584,6 +2616,18 @@ particular release.

 

+  20.11.7.1 [time.clock.system]/3, /4
+  Time point values are truncated to time_t values.
+  There is no loss of precision for conversions in the other direction.
+   
+
+   
+  20.15.7 [meta.trans]/2
+  aligned_storage does not support extended
+  alignment.
+   
+
+   
   21.2.3.2 [char.traits.specializations.char16_t],
   21.2.3.3 [char.traits.specializations.char32_t]
   The types u16streampos and
@@ -2593,6 +2637,11 @@ particular release.

 

+  22.3.1 [locale]
+  There is one global locale for the whole program, not per-thread.
+   
+
+   
   22.4.5.1.2 [locale.time.get.virtuals],
   22.4.5.3.2 [locale.time.put.virtuals]
   Additional supported formats should be documented here.
@@ -2604,6 +2653,13 @@ particular release.

 

+  23.3.2.1 [array.overview]
+  arrayT, 

Re: VR_RANGE with inverted bounds

[Martin Sebor]

On 10/07/2016 11:15 AM, Richard Biener wrote:

On October 7, 2016 6:49:39 PM GMT+02:00, Martin Sebor  wrote:

While processing the (p += i) expression below to validate the bounds
of the pointer in I call get_range_info for i (in tree-object-size.c).
The function returns the following VR_RANGE: [2147483648, -2147483649]
rather than the expected [0, 1].  Is such a range to be expected or
is it a bug?


This range is not valid (unless unsigned and you show it as signed).


Thanks.  I believe it's signed but even if it was unsigned it wouldn't
be correct (correspond to the actual range of [0, 1]).

I don't have a test case that makes this manifest with an unpatched
compiler.  There aren't too many places that call get_range_info
and the range only appears to be wrong between the second and third
runs of the object-size pass.  After the third run the range is
correct.  (I can see this with the -Wformat-length warning when
I pass the variable to sprintf and trigger a warning.)

Unless you have a suggestion for how I might be able to reproduce
it I'll go ahead and open a bug and include a minimum patch to show
the problem.

Martin

[PATCH] Implement std::has_unique_object_representations

[Jonathan Wakely]

Another new C++17 feature, using Jakub's new builtin.

* doc/xml/manual/status_cxx2017.xml: Update status.
* include/std/type_traits (has_unique_object_representations): Define.
* testsuite/20_util/has_unique_object_representations/value.cc: New.
* testsuite/20_util/has_unique_object_representations/requirements/
explicit_instantiation.cc: New.
* testsuite/20_util/has_unique_object_representations/requirements/
typedefs.cc: New.

Tested x86_64-linux, committed to trunk.


commit 79664ebd750fbe597021ce039ac86f503d477e76
Author: Jonathan Wakely 
Date:   Fri Oct 7 12:59:16 2016 +0100

Implement std::has_unique_object_representations

* doc/xml/manual/status_cxx2017.xml: Update status.
* include/std/type_traits (has_unique_object_representations): Define.
* testsuite/20_util/has_unique_object_representations/value.cc: New.
* testsuite/20_util/has_unique_object_representations/requirements/
explicit_instantiation.cc: New.
* testsuite/20_util/has_unique_object_representations/requirements/
typedefs.cc: New.

diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml 
b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
index 9f47b349..f1d709e 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx2017.xml
@@ -441,14 +441,13 @@ Feature-testing recommendations for C++.
 
 
 
-  
has_unique_object_representations 
   
http://www.w3.org/1999/xlink; 
xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0258r2.html;>
P0258R2

   
-   No 
+   7 
__cpp_lib_has_unique_object_representations >= 201606 

 
 
diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index cd0ba99..d402b5b 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -3040,6 +3040,16 @@ template 
   constexpr bool is_base_of_v = is_base_of<_Base, _Derived>::value;
 template 
   constexpr bool is_convertible_v = is_convertible<_From, _To>::value;
+
+# define __cpp_lib_has_unique_object_representations 201606
+  /// has_unique_object_representations
+  template
+struct has_unique_object_representations
+: bool_constant<__has_unique_object_representations(
+  remove_cv_t>
+  )>
+{ };
+
 #endif // C++17
 
 _GLIBCXX_END_NAMESPACE_VERSION
diff --git 
a/libstdc++-v3/testsuite/20_util/has_unique_object_representations/requirements/explicit_instantiation.cc
 
b/libstdc++-v3/testsuite/20_util/has_unique_object_representations/requirements/explicit_instantiation.cc
new file mode 100644
index 000..29be714
--- /dev/null
+++ 
b/libstdc++-v3/testsuite/20_util/has_unique_object_representations/requirements/explicit_instantiation.cc
@@ -0,0 +1,29 @@
+// { dg-options "-std=gnu++1z" }
+// { dg-do compile { target c++1z } }
+
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// NB: This file is for testing type_traits with NO OTHER INCLUDES.
+
+#include 
+
+namespace std
+{
+  typedef short test_type;
+  template struct has_unique_object_representations;
+}
diff --git 
a/libstdc++-v3/testsuite/20_util/has_unique_object_representations/requirements/typedefs.cc
 
b/libstdc++-v3/testsuite/20_util/has_unique_object_representations/requirements/typedefs.cc
new file mode 100644
index 000..e24a972
--- /dev/null
+++ 
b/libstdc++-v3/testsuite/20_util/has_unique_object_representations/requirements/typedefs.cc
@@ -0,0 +1,32 @@
+// { dg-options "-std=gnu++1z" }
+// { dg-do compile { target c++1z } }
+
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public 

Re: [C++/66443] deleted ctor and vbase construction

[Jason Merrill]

OK.

On Fri, Oct 7, 2016 at 6:31 AM, Nathan Sidwell  wrote:
> On 10/05/16 19:49, Jason Merrill wrote:
>
>> But DR 1658 says that B::B is *not* deleted (because A is not a
>> potentially constructed subobject).  Implementing that might be
>> simpler than trying to have a deleted complete and non-deleted base
>> constructor variant.
>
>
> Always better to read the actual DR rather than infer it from the bug
> report. Here's an updated patch, which also addresses DR1611 (the dtor
> case).
>
> emit_mem_initializers and push_base_cleanups only operate on vbases when
> !ABSTRACT_CLASS_TYPE_P (we'll have already checked that's valid or not, so
> we don't care about what version of C++ this is).
>
> synthesized_method_walk only scans vbases (for cdtors) when
> !BSTRACT_CLASS_TYPE_P or < c++14.  This is the validity check.
>
> much simples. ok?
>
> nathan
>

Re: [PATCH][simplify-rtx] Zero-initialise local array in simplify_immed_subreg

[Andrew Pinski]

On Fri, Oct 7, 2016 at 10:55 AM, Andrew Pinski  wrote:
> On Fri, Oct 7, 2016 at 7:08 AM, Kyrill Tkachov
>  wrote:
>> Hi all,
>>
>> I've encountered another wrong-code bug with the store merging pass. This
>> time it's in RTL.
>> The test gcc.target/aarch64/aapcs64/test_27.c on aarch64 merges a few __fp16
>> values at GIMPLE level but
>> during RTL dse1 one of the constants generated gets wrongly misinterpreted
>> from HImode to HFmode
>> by simplify_immed_subreg. The HFmode value it ends up producing is
>> completely bogus.
>>
>> By stepping through the code with GDB the problem is in the hunk touched by
>> this patch when it
>> fills in an array of longs with the value bytes before passing it down to
>> real_from_target.
>> It fills in the array by orring in each byte.
>>
>> However, the array it declared to use for this doesn not get properly
>> zero-initialised for modes
>> less that 32 bits wide (HFmode in this case). The fix in this patch is to
>> just use an array initialiser
>> to zero it out. This makes the failure go away.
>>
>> Bootstrapped and tested on aarch64, x86_64.
>>
>> Ok for trunk?
>
> Even though this has been approved I think it is best to do write this
> code as this:
> long tmp[MAX_BITSIZE_MODE_ANY_MODE / 32];
>  /* real_from_target wants its input in words affected by
> FLOAT_WORDS_BIG_ENDIAN.  However, we ignore this,
> and use WORDS_BIG_ENDIAN instead; see the documentation
> of SUBREG in rtl.texi.  */
> memset (tmp, 0, sizeof(tmp));


Also the / 32 should be changed to / (sizeof(long) * BITS_PER_CHAR)
but that was there before hand.

THanks,
Andrew

>
> Thanks,
> Andrew Pinski
>
>
>> Thanks,
>> Kyrill
>>
>> 2016-10-06  Kyrylo Tkachov  
>>
>> * simplify-rtx.c (simplify_immed_subreg): Zero-initialize tmp array
>> before merging in bytes to pass down to real_from_target.

Re: VR_RANGE with inverted bounds

[Richard Biener]

On October 7, 2016 6:49:39 PM GMT+02:00, Martin Sebor  wrote:
>While processing the (p += i) expression below to validate the bounds
>of the pointer in I call get_range_info for i (in tree-object-size.c).
>The function returns the following VR_RANGE: [2147483648, -2147483649]
>rather than the expected [0, 1].  Is such a range to be expected or
>is it a bug?

This range is not valid (unless unsigned and you show it as signed).

>In general, what assumptions can I safely make about the bounds for
>VR_RANGE and VR_ANTI_RANGE?  For example, besides being inverted like
>in this example, can the bounds also ever be the same?  I don't think
>I have seen them be the same but I think I have seen a case where the
>variable's effective range was [X, X] (i.e., it was equal to
>a constant) and get_range_info returned VR_VARYING.  Should that also
>be expected?

Tree-vrp. Has various assertions in its lattice update function which should 
hold for all ranges.

Richard.

>Thanks
>Martin
>
>   void g (char *p, int i)
>   {
> if (i < 0 || 1 < i)
>   i = 0;
>
> p += i;
> ...
>   }

[Bug c++/77700] suspicios code in cp/parser.c

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77700

Bernd Edlinger  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Bernd Edlinger  ---
fixed on trunk.

[Bug c++/77700] suspicios code in cp/parser.c

[edlinger at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77700

--- Comment #1 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Oct  7 17:10:38 2016
New Revision: 240867

URL: https://gcc.gnu.org/viewcvs?rev=240867=gcc=rev
Log:
2016-10-07  Bernd Edlinger  

PR c++/77700
* c-common.c (c_common_truthvalue_conversion): Warn also for
suspicious enum values in boolean context.

cp:
2016-10-07  Bernd Edlinger  

PR c++/77700
* parser.c (cp_parser_base_specifier): Fix a warning.

testsuite:
2016-10-07  Bernd Edlinger  

PR c++/77700
* c-c++-common/Wint-in-bool-context.c: Update test.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wint-in-bool-context.c

Re: [PATCH] Extend -Wint-in-bool-context to suspicious enum values (PR 77700)

[Jason Merrill]

OK.

On Fri, Oct 7, 2016 at 11:18 AM, Bernd Edlinger
 wrote:
> Hi!
>
> This extends -Wint-in-bool-context to uses of enum values in boolean
> context, and fixes one place where accidentally an enum value was
> passed to a bool parameter.
>
> I excluded enum values 0 and 1 because that is used in
> gimple-ssa-strength-reduction.c, where we have enums
> which are passed in bool function arguments:
>
> enum stride_status
> {
>UNKNOWN_STRIDE = 0,
>KNOWN_STRIDE = 1
> };
>
> enum phi_adjust_status
> {
>NOT_PHI_ADJUST = 0,
>PHI_ADJUST = 1
> };
>
> enum count_phis_status
> {
>DONT_COUNT_PHIS = 0,
>COUNT_PHIS = 1
> };
>
> I would'nt use an enum in that way, but I think it is
> at least not completely wrong to do it like that...
>
>
> Unfortunately C is less strict with enum values, and from
> and enum we only see an integer value without an enum type
> in C.
>
> Therefore this warning does not work in C, only in C++.
> Also integer constants do not have a source location, so
> the displayed location is usually a bit vague.
> But I think it is still better than no warning at all.
>
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
>
>
> Thanks
> Bernd.

VR_RANGE with inverted bounds

[Martin Sebor]

While processing the (p += i) expression below to validate the bounds
of the pointer in I call get_range_info for i (in tree-object-size.c).
The function returns the following VR_RANGE: [2147483648, -2147483649]
rather than the expected [0, 1].  Is such a range to be expected or
is it a bug?

In general, what assumptions can I safely make about the bounds for
VR_RANGE and VR_ANTI_RANGE?  For example, besides being inverted like
in this example, can the bounds also ever be the same?  I don't think
I have seen them be the same but I think I have seen a case where the
variable's effective range was [X, X] (i.e., it was equal to
a constant) and get_range_info returned VR_VARYING.  Should that also
be expected?

Thanks
Martin

  void g (char *p, int i)
  {
if (i < 0 || 1 < i)
  i = 0;

p += i;
...
  }

Re: [PATCH, libgfortran] PR 67585 Handle EINTR

[Jack Howarth]

On Fri, Oct 7, 2016 at 12:09 PM, Janne Blomqvist
 wrote:
> On Fri, Oct 7, 2016 at 5:50 PM, Fritz Reese  wrote:
>> On Fri, Oct 7, 2016 at 8:59 AM, Janne Blomqvist
>>  wrote:
>>> On Fri, Oct 7, 2016 at 2:41 PM, FX  wrote:
> Many POSIX systems have the bad habit of not restarting interrupted
> syscalls. On these systems it's up to the user to check for an error
> with errno == EINTR and restart manually. This patch does this for
> libgfortran, so that GFortran users don't have to do it.

 I have not much experience with EINTR, but is it garanteed that those 
 EINTR loops will never cycle forever?
>>>
>>> Hmm, no I don't think so, but I don't think it'll be a problem. So on
>>> systems where syscalls are not restarted automatically, EINTR happens
>>> when the process receives a signal while blocked in a system call [1].
>>> So I suppose in theory you could have a situation where something
>>> continuously fires signals at the process, and the result is some kind
>>> of race between the process restarting the syscall which then never
>>> manages to complete before being interrupted again. But I think this
>>> goes into the "Doctor, this hurts! Then don't do that" territory.
>>>
>>> There's some more info in https://www.python.org/dev/peps/pep-0475/
>>> (Python nowadays does the same as this patch).
>>
>>
>> Just one concern (slightly different from the race you described) -
>> what if a user wants/expects a system call to be interrupted? With the
>> patch we would always restart the system call even if the user was
>> expecting it would be interrupted. For small calls like lseek this may
>> not be a big deal but if read on a pipe/socket/terminal is restarted
>> after being interrupted (e.g. with CTRL-C) we may loop forever even if
>> the user program was written to expect and handle EINTR after the read
>> call, e.g. to terminate nicely with "non async-safe" calls like printf
>> that couldn't be done in the handler.
>
> Concievable yes, but IMHO unlikely. And since many systems
> automatically restart syscalls, a program like the above perhaps isn't
> that robust to begin with?
>
>> This is discussed as "use case 2" in the PEP you referenced. Python
>> handles this case by explicitly calling user defined signal handlers
>> directly after EINTR and checking the return value from the handler,
>> only trying again if the handler reports success. Not so simple I
>> think with libgfortran.
>
> With GFortran, a problem is that due to the buffering, handling of
> record markers etc. there is no 1:1 mapping between Fortran READ/WRITE
> statements and read(2)/write(2) syscalls. So even if we let EINTR
> propagate all the way back up to the Fortran caller (as happens now,
> except for write()), it actually has no way of knowing what should be
> restarted.
>

One issue that might need to be considered is whether the libgfortran
routines would ever be indirectly called from code that is using
fork()/exec(). We ran into a nasty regression in GNU Make 4.0/4.1
which was tickled when NLS support was enabled which indirectly pulled
in the CoreFoundation framework and its threading support via
libiconv. Upstream fixed this with...

http://savannah.gnu.org/bugs/index.php?46261#comment12

http://git.savannah.gnu.org/cgit/make.git/commit/?id=85c788572d054bc2c41b84007875edbd37ad3ed5

in make 4.2. So using EINTR properly can be really tricky.

>
>
> --
> Janne Blomqvist

[PATCH] RTL frontend (rtl1), on top of dump reader (v4)

[David Malcolm]

On Thu, 2016-10-06 at 17:23 +0200, Bernd Schmidt wrote:
> Let me just make a first pass over this for minor/obvious issues.
>
> > +we have little control of the input to that specific pass.  We
>
> "control over" maybe?

Fixed.

> > +The testsuite is below @file{gcc/testsuite/rtl.dg}.
>
> Not sure this needs to be in the manual (I have similar doubts about
> the
> entire motivation section, but I guess we can keep it).

This is within the "internals" part of the manual; presumably the
audience for that manual is gcc developers.

> Also, "below"?

Changed to "within".

> > +/* rtl-error.c - Replacement for errors.c for use by RTL frontend
> > +   Copyright (C) 2016 Free Software Foundation, Inc.
>
> Why have this and not use the normal machinery?

(see https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00489.html for
discussion of that).

> > +
> > +static bool
> > +rtl_langhook_handle_option (
> > +size_t scode,
> > +const char *arg,
> > +int value ATTRIBUTE_UNUSED,
> > +int kind ATTRIBUTE_UNUSED,
> > +location_t loc ATTRIBUTE_UNUSED,
> > +const struct cl_option_handlers *handlers ATTRIBUTE_UNUSED)
>
> Please line up the arguments, including the first, with the open
> paren.

Fixed.

> For hooks I think we're converging towards just not naming unused
> args.

I removed the names (and ATTRIBUTE_UNUSED).

> > +
> > +  /*  If -fsingle-pass=PASS_NAME was provided, locate and run
> > PASS_NAME
> > +  on cfun, as created above.  */
>
> Comment text indented too much.

Fixed.

> > +/* Implementation of LANG_HOOKS_TYPE_FOR_MODE, taken from Go
> > frontend.  */
> > +
> > +static tree
> > +rtl_langhook_type_for_mode (machine_mode mode, int unsignedp)
> > +{
> > +  tree type;
> > +  /* Go has no vector types.  Build them here.  FIXME: It does not
> > + make sense for the middle-end to ask the frontend for a type
> > + which the frontend does not support.  However, at least for
> > now
> > + it is required.  See PR 46805.  */
>
> Hmm, not sure it makes much sense to have comments referencing Go.

Heh.  Can you spot which frontend I used as a model? :)

> > +  if (VECTOR_MODE_P (mode))
> > +{
> > +  tree inner;
> > +
> > +  inner = rtl_langhook_type_for_mode (GET_MODE_INNER (mode),
> > unsignedp);
> > +  if (inner != NULL_TREE)
> > +   return build_vector_type_for_mode (inner, mode);
> > +  return NULL_TREE;
> > +}
> > +
> > +  // FIXME: This static_cast should be in machmode.h.
> > +  enum mode_class mc = static_cast > mode_class>(GET_MODE_CLASS(mode));
> > +  if (mc == MODE_INT)
> > +return rtl_langhook_type_for_size(GET_MODE_BITSIZE(mode),
> > unsignedp);
>
> Also not really following our coding standards. Presumably this is
> all
> copied?

Yes, from Go.  I've fixed things up in the next version of the patch,
and I'll work on a patch for Go to fix them up there.

> > +#include 
>
> The include list probably wants checking whether everything is really
> necessary; this one stood out as a bit odd (several files).

This was for the:

  /* The default precision for floating point numbers.  This is used
 for floating point constants with abstract type.  This may
 eventually be controllable by a command line option.  */
  mpfr_set_default_prec (256);

call in rtl_langhook_init, again copied from Go.  I can drop it.

I went through the list of includes; doing so revealed that this code
within rtl_langhook_parse_file:

  in_rtl_frontend_p = true;

  initialize_rtl ();
  init_emit ();
  init_varasm_status ();

was redundant (we were also doing it in read_rtl_function_body; this
code has gone through a *lot* of refactoring).

So I've trimmed things quite a bit in rtl-frontend.c.

When trimming the headers, I was able to eliminate rtl.h from the deps,
so I was able to remove:

 /* Front ends normally should never have to include RTL headers.
This is enforced in system.h by poisoning various header double-include
protection defines.
However, for obvious reasons, the RTL frontend needs RTL headers.
Override this protection for this special case.  */
 #undef IN_GCC_FRONTEND

> > +
> > +#ifndef GCC_RUN_ONE_RTL_PASS_H
> > +#define GCC_RUN_ONE_RTL_PASS_H
> > +
> > +extern void run_one_rtl_pass_by_name (const char *pass_name);
> > +
> > +#endif /* GCC_RUN_ONE_RTL_PASS_H */
>
> Do we really need an entire header file for a single declaration?

The problem I kept running into was that system.h has this:

/* Front ends should never have to include middle-end headers.  Enforce
   this by poisoning the header double-include protection defines.  */

run_one_rtl_pass_by_name gets used by both the RTL frontend in this
patch, and by cc1 in the followup __RTL patch (from c-parser.c), so
whatever header it's in, it needs to be one that can be included by
these frontend files with no rtl.h poisoning.  This seems like a
special-case, so it seemed to make sense to give it its own header.
Is there a better place for it?  Maybe pass_manager.h?

Updated patch 

Re: [PATCH, libgfortran] PR 67585 Handle EINTR

[Janne Blomqvist]

On Fri, Oct 7, 2016 at 5:50 PM, Fritz Reese  wrote:
> On Fri, Oct 7, 2016 at 8:59 AM, Janne Blomqvist
>  wrote:
>> On Fri, Oct 7, 2016 at 2:41 PM, FX  wrote:
 Many POSIX systems have the bad habit of not restarting interrupted
 syscalls. On these systems it's up to the user to check for an error
 with errno == EINTR and restart manually. This patch does this for
 libgfortran, so that GFortran users don't have to do it.
>>>
>>> I have not much experience with EINTR, but is it garanteed that those EINTR 
>>> loops will never cycle forever?
>>
>> Hmm, no I don't think so, but I don't think it'll be a problem. So on
>> systems where syscalls are not restarted automatically, EINTR happens
>> when the process receives a signal while blocked in a system call [1].
>> So I suppose in theory you could have a situation where something
>> continuously fires signals at the process, and the result is some kind
>> of race between the process restarting the syscall which then never
>> manages to complete before being interrupted again. But I think this
>> goes into the "Doctor, this hurts! Then don't do that" territory.
>>
>> There's some more info in https://www.python.org/dev/peps/pep-0475/
>> (Python nowadays does the same as this patch).
>
>
> Just one concern (slightly different from the race you described) -
> what if a user wants/expects a system call to be interrupted? With the
> patch we would always restart the system call even if the user was
> expecting it would be interrupted. For small calls like lseek this may
> not be a big deal but if read on a pipe/socket/terminal is restarted
> after being interrupted (e.g. with CTRL-C) we may loop forever even if
> the user program was written to expect and handle EINTR after the read
> call, e.g. to terminate nicely with "non async-safe" calls like printf
> that couldn't be done in the handler.

Concievable yes, but IMHO unlikely. And since many systems
automatically restart syscalls, a program like the above perhaps isn't
that robust to begin with?

> This is discussed as "use case 2" in the PEP you referenced. Python
> handles this case by explicitly calling user defined signal handlers
> directly after EINTR and checking the return value from the handler,
> only trying again if the handler reports success. Not so simple I
> think with libgfortran.

With GFortran, a problem is that due to the buffering, handling of
record markers etc. there is no 1:1 mapping between Fortran READ/WRITE
statements and read(2)/write(2) syscalls. So even if we let EINTR
propagate all the way back up to the Fortran caller (as happens now,
except for write()), it actually has no way of knowing what should be
restarted.



-- 
Janne Blomqvist

[Bug middle-end/77889] missing optimization on strlen(p + offset) with a bounded offset

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77889

--- Comment #3 from Martin Sebor  ---
(In reply to Richard Biener from comment #2)
> So you are complaining that VRP doesn't compute a range for n?  Because I
> can't see the tree-ssa-strlen pass computing ranges.
> 
> Confirmed for VRP.  It seems to ignore most builtins completely.

I wasn't suggesting the problem is in VRP but rather in tree-ssa-strlen.  My
patch for bug 77608 makes it work by having the plus_stmt_object_size function
call get_range_info to obtain the range for the offset so it seems that the
same approach should work for strlen.

(Please note this isn't meant to be a complaint. I'm pointing out an
opportunity for improvement.)

RE: [PATCH, PR77558] Remove RECORD_TYPE special-casing in std_canonical_va_list_type

[Tamar Christina]

Ping?

Would be great to get this in, it's currently showing up as a major issue on 
our nightlies.

Cheers,
Tamar

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Tom de Vries
> Sent: 25 September 2016 10:08
> To: GCC Patches
> Subject: [PATCH, PR77558] Remove RECORD_TYPE special-casing in
> std_canonical_va_list_type
> 
> Hi,
> 
> this patch fixes PR77558, an ice-on-invalid-code 6/7 regression.
> 
> The fix for PR71602 introduced the invalid-code test-case
> c-c++-common/va-arg-va-list-type.c:
> ...
> __builtin_va_list *pap;
> 
> void
> fn1 (void)
> {
>__builtin_va_arg (pap, double); /* { dg-error "first argument to 'va_arg' 
> not
> of type 'va_list'" } */ } ...
> 
> The test-case passes for x86_64, but fails for aarch64 and ICEs for arm.
> 
> The ICE happens because the patch for PR71602 is incomplete. The patch
> tries to be more strict about returning a canonical va_list only for actual
> va_lists, but doesn't implement this for structure va_list types, such as we
> have for arm, aarch64 and alpha.
> 
> This patch adds the missing part, and fixes the ICE.
> 
> OK for trunk, 6-branch?
> 
> Thanks,
> - Tom

[PATCH] Add "__RTL" to cc1 (v2)

[David Malcolm]

On Wed, 2016-10-05 at 16:09 +, Joseph Myers wrote:
> On Wed, 5 Oct 2016, David Malcolm wrote:
> 
> > @@ -1752,6 +1759,35 @@ c_parser_declaration_or_fndef (c_parser
> > *parser, bool fndef_ok,
> >c_parser_skip_to_end_of_block_or_statement (parser);
> >return;
> >  }
> > +
> > +  if (c_parser_next_token_is (parser, CPP_KEYWORD))
> > +{
> > +  c_token *kw_token = c_parser_peek_token (parser);
> > +  if (kw_token->keyword == RID_RTL)
> 
> if (c_parser_next_token_is_keyword (parser, RID_RTL))
> 
> You're missing an update to the comment above this function to show
> what
> the new syntax is.

Thanks.  Here's an updated version of the patch which fixes that,
along with some other fixes:
* Use c_parser_next_token_is_keyword.
* Removed a stray "FIXME".
* Removed some debug code.
* Add more comments
* Fixed a typo in the ChangeLog ("__RID" -> "__RTL")

Blurb from original version:

This patch implements Richi's idea of having a custom __RTL marker
in C function definitions, to indicate that the body of the function
is to be parsed as RTL, rather than C:

int __RTL test_fn_1 (int i)
{
 (function "times_two"
   (insn-chain
 (note 1 0 4 (nil) NOTE_INSN_DELETED)
 ;; etc
   ) ;; insn-chain
   (crtl
 (return_rtx
   (reg/i:SI 0 ax)
 ) ;; return_rtx
   ) ;; crtl
  ) ;; function
}

This allows for decls and types to be declared in C, and to use
the function decl from the C frontend.

I added support for running a single pass by giving __RTL an optional
parameter (the name of the pass).  For example:

int __RTL ("rtl-dfinit") test_fn_2 (int i)
{
 (function "times_two"
   (insn-chain
 (note 1 0 4 (nil) NOTE_INSN_DELETED)
 ;; etc
   ) ;; insn-chain
   (crtl
 (return_rtx
   (reg/i:SI 0 ax)
 ) ;; return_rtx
   ) ;; crtl
  ) ;; function
}

The top-level "function" directive is rather redundant; perhaps it should
be omitted?  This would give e.g.:

int __RTL ("rtl-dfinit") test_fn_3 (int i)
{
   (insn-chain
 (note 1 0 4 (nil) NOTE_INSN_DELETED)
 ;; etc
   ) ;; insn-chain
   (crtl
 (return_rtx
   (reg/i:SI 0 ax)
 ) ;; return_rtx
   ) ;; crtl
}

(Though maybe we want to keep it as a place to hold top-level metadata)

gcc/c-family/ChangeLog:
* c-common.c (c_common_reswords): Add "__RTL".
* c-common.h (enum rid): Add RID_RTL.

gcc/c/ChangeLog:
* c-parser.c: Include "read-rtl-function.h" and
"run-one-rtl-pass.h".
(c_parser_declaration_or_fndef): In the "GNU extensions" part of
the leading comment, add an alternate production for
"function-definition", along with new "rtl-body-specifier" and
"rtl-body-pass-specifier" productions.  Handle "__RTL" by calling
c_parser_parse_rtl_body.  Convert a timevar_push/pop pair
to an auto_timevar, to cope with early exit.
(c_parser_parse_rtl_body): New function.

gcc/ChangeLog:
* read-md.c (base_rtx_reader::read_char): Support filtering
the input to a subset of line numbers.
(base_rtx_reader::base_rtx_reader): Initialize fields
m_first_line and m_last_line.
(base_rtx_reader::read_file_fragment): New method.
* read-md.h (base_rtx_reader::read_file_fragment): New decl.
(base_rtx_reader::m_first_line): New field.
(base_rtx_reader::m_last_line): New field.
* read-rtl-function.c (function_reader::create_function): Only create
cfun if it doesn't already exist.
(read_rtl_function_body_from_file_range): New function.
* read-rtl-function.h (read_rtl_function_body_from_file_range):
New decl.

gcc/testsuite/ChangeLog:
* rtl.dg/rtl.exp: Add .c files below rtl.dg to "tests".
* rtl.dg/x86_64/different-structs.c: New file.
* rtl.dg/x86_64/test-return-const.c.after-expand.c: New file.
* rtl.dg/x86_64/test-return-const.c.before-fwprop.c: New file.
* rtl.dg/x86_64/test-rtl.c: New file.
* rtl.dg/x86_64/times-two.c.after-expand.c: New file.
* rtl.dg/x86_64/times-two.c.before-df.c: New file.
---
 gcc/c-family/c-common.c|   1 +
 gcc/c-family/c-common.h|   3 +
 gcc/c/c-parser.c   | 113 -
 gcc/read-md.c  |  34 ++-
 gcc/read-md.h  |   7 ++
 gcc/read-rtl-function.c|  78 ++
 gcc/read-rtl-function.h|   3 +
 gcc/testsuite/rtl.dg/rtl.exp   |   4 +-
 gcc/testsuite/rtl.dg/x86_64/different-structs.c| 101 ++
 .../x86_64/test-return-const.c.after-expand.c  |  23 +
 .../x86_64/test-return-const.c.before-fwprop.c |  27 +
 gcc/testsuite/rtl.dg/x86_64/test-rtl.c |  95 +
 .../rtl.dg/x86_64/times-two.c.after-expand.c   |  40 
 

[PATCH] Extend -Wint-in-bool-context to suspicious enum values (PR 77700)

[Bernd Edlinger]

Hi!

This extends -Wint-in-bool-context to uses of enum values in boolean
context, and fixes one place where accidentally an enum value was
passed to a bool parameter.

I excluded enum values 0 and 1 because that is used in
gimple-ssa-strength-reduction.c, where we have enums
which are passed in bool function arguments:

enum stride_status
{
   UNKNOWN_STRIDE = 0,
   KNOWN_STRIDE = 1
};

enum phi_adjust_status
{
   NOT_PHI_ADJUST = 0,
   PHI_ADJUST = 1
};

enum count_phis_status
{
   DONT_COUNT_PHIS = 0,
   COUNT_PHIS = 1
};

I would'nt use an enum in that way, but I think it is
at least not completely wrong to do it like that...


Unfortunately C is less strict with enum values, and from
and enum we only see an integer value without an enum type
in C.

Therefore this warning does not work in C, only in C++.
Also integer constants do not have a source location, so
the displayed location is usually a bit vague.
But I think it is still better than no warning at all.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
c-family:
2016-10-07  Bernd Edlinger  

	PR c++/77700
	* c-common.c (c_common_truthvalue_conversion): Warn also for
	suspicious enum values in boolean context.

cp:
2016-10-07  Bernd Edlinger  

	PR c++/77700
	* parser.c (cp_parser_base_specifier): Fix a warning.


testsuite:
2016-10-07  Bernd Edlinger  

	PR c++/77700
	* c-c++-common/Wint-in-bool-context.c: Update test.

Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c	(revision 240838)
+++ gcc/c-family/c-common.c	(working copy)
@@ -4588,6 +4588,11 @@ c_common_truthvalue_conversion (location_t locatio
   return expr;
 
 case INTEGER_CST:
+  if (TREE_CODE (TREE_TYPE (expr)) == ENUMERAL_TYPE
+	  && !integer_zerop (expr)
+	  && !integer_onep (expr))
+	warning_at (location, OPT_Wint_in_bool_context,
+		"enum constant in boolean context");
   return integer_zerop (expr) ? truthvalue_false_node
   : truthvalue_true_node;
 
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c	(revision 240838)
+++ gcc/cp/parser.c	(working copy)
@@ -23334,7 +23334,7 @@ cp_parser_base_specifier (cp_parser* parser)
   cp_parser_nested_name_specifier_opt (parser,
    /*typename_keyword_p=*/true,
    /*check_dependency_p=*/true,
-   typename_type,
+   /*type_p=*/true,
    /*is_declaration=*/true);
   /* If the base class is given by a qualified name, assume that names
  we see are type names or templates, as appropriate.  */
Index: gcc/testsuite/c-c++-common/Wint-in-bool-context.c
===
--- gcc/testsuite/c-c++-common/Wint-in-bool-context.c	(revision 240838)
+++ gcc/testsuite/c-c++-common/Wint-in-bool-context.c	(working copy)
@@ -2,6 +2,8 @@
 /* { dg-options "-Wint-in-bool-context" } */
 /* { dg-do compile } */
 
+enum truth { yes, no, maybe };
+
 int foo (int a, int b)
 {
   if (a > 0 && a <= (b == 1) ? 1 : 2) /* { dg-warning "boolean context" } */
@@ -27,5 +29,11 @@ int foo (int a, int b)
 
   for (a = 0; 1 << a; a++); /* { dg-warning "boolean context" } */
 
+  if (yes || no || maybe) /* { dg-warning "boolean context" "" { target c++ } } */
+return 8;
+
+  if (yes || no) /* { dg-bogus "boolean context" } */
+return 9;
+
   return 0;
 }

[PATCH] Fix computation of register limit for -fsched-pressure

[Pat Haugen]

The patch here, https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01872.html, 
attempted to scale down the register limit used by -fsched-pressure for the 
case where the block in question executes as frequently as the entry block to 
just the call_clobbered (i.e. call_used) regs. But the code is actually scaling 
toward call_saved registers. The following patch corrects that by computing 
call_saved regs per class and subtracting out some scaled portion of that.

Bootstrap/regtest on powerpc64le with no new failures. Ok for trunk?

-Pat


2016-10-07  Pat Haugen  

* haifa-sched.c call_used_regs_num: Rename to...
call_saved_regs_num: ...this.
(sched_pressure_start_bb): Scale call_saved regs not call_used.
(alloc_global_sched_pressure_data): Compute call_saved regs.


Index: gcc/haifa-sched.c
===
--- gcc/haifa-sched.c	(revision 240812)
+++ gcc/haifa-sched.c	(working copy)
@@ -932,9 +932,9 @@ static bitmap region_ref_regs;
 /* Effective number of available registers of a given class (see comment
in sched_pressure_start_bb).  */
 static int sched_class_regs_num[N_REG_CLASSES];
-/* Number of call_used_regs.  This is a helper for calculating of
+/* Number of call_saved_regs.  This is a helper for calculating of
sched_class_regs_num.  */
-static int call_used_regs_num[N_REG_CLASSES];
+static int call_saved_regs_num[N_REG_CLASSES];
 
 /* Initiate register pressure relative info for scheduling the current
region.  Currently it is only clearing register mentioned in the
@@ -3900,13 +3900,13 @@ sched_pressure_start_bb (basic_block bb)
  * If the basic block executes as often as the prologue/epilogue,
  then spill in the block is as costly as in the prologue, so the effective
  number of available registers is
- (ira_class_hard_regs_num[cl] - call_used_regs_num[cl]).
+ (ira_class_hard_regs_num[cl] - call_saved_regs_num[cl]).
  Note that all-else-equal, we prefer to spill in the prologue, since that
  allows "extra" registers for other basic blocks of the function.
  * If the basic block is on the cold path of the function and executes
  rarely, then we should always prefer to spill in the block, rather than
  in the prologue/epilogue.  The effective number of available register is
- (ira_class_hard_regs_num[cl] - call_used_regs_num[cl]).  */
+ (ira_class_hard_regs_num[cl] - call_saved_regs_num[cl]).  */
   {
 int i;
 int entry_freq = ENTRY_BLOCK_PTR_FOR_FN (cfun)->frequency;
@@ -3925,7 +3925,7 @@ sched_pressure_start_bb (basic_block bb)
 	enum reg_class cl = ira_pressure_classes[i];
 	sched_class_regs_num[cl] = ira_class_hard_regs_num[cl];
 	sched_class_regs_num[cl]
-	  -= (call_used_regs_num[cl] * entry_freq) / bb_freq;
+	  -= (call_saved_regs_num[cl] * entry_freq) / bb_freq;
   }
   }
 
@@ -7237,17 +7237,17 @@ alloc_global_sched_pressure_data (void)
 	  region_ref_regs = BITMAP_ALLOC (NULL);
 	}
 
-  /* Calculate number of CALL_USED_REGS in register classes that
+  /* Calculate number of CALL_SAVED_REGS in register classes that
 	 we calculate register pressure for.  */
   for (int c = 0; c < ira_pressure_classes_num; ++c)
 	{
 	  enum reg_class cl = ira_pressure_classes[c];
 
-	  call_used_regs_num[cl] = 0;
+	  call_saved_regs_num[cl] = 0;
 
 	  for (int i = 0; i < ira_class_hard_regs_num[cl]; ++i)
-	if (call_used_regs[ira_class_hard_regs[cl][i]])
-	  ++call_used_regs_num[cl];
+	if (!call_used_regs[ira_class_hard_regs[cl][i]])
+	  ++call_saved_regs_num[cl];
 	}
 }
 }

Re: [ARM] PR 67591 ARM v8 Thumb IT blocks are deprecated

[Kyrill Tkachov]

Hi Christophe,

On 07/09/16 21:05, Christophe Lyon wrote:

Hi,

The attached patch is a first part to solve PR 67591: it removes
several occurrences of "IT blocks containing 32-bit Thumb
instructions are deprecated in ARMv8" messages in the
gcc/g++/libstdc++/fortran testsuites.

It does not remove them all yet. This patch only modifies the
*cmp_and, *cmp_ior, *ior_scc_scc, *ior_scc_scc_cmp,
*and_scc_scc and *and_scc_scc_cmp patterns.
Additional work is required in sub_shiftsi etc, at least.
I've started looking at these, but I decided I could already
post this self-contained patch to check if this implementation
is OK.

Regarding *cmp_and and *cmp_ior patterns, the addition of the
enabled_for_depr_it attribute is aggressive in the sense that it keeps
only the alternatives with 'l' and 'Py' constraints, while in some
cases the constraints could be relaxed. Indeed, these 2 patterns can
swap their input comparisons, meaning that any of them can be emitted
in the IT-block, and is thus subject to the ARMv8 deprecation.
The generated code is possibly suboptimal in the cases where the
operands are not swapped, since 'r' could be used.

Cross-tested on arm-none-linux-gnueabihf with -mthumb/-march=armv8-a
and --with-cpu=cortex-a57 --with-mode=thumb, showing only improvements:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc-test-patches/239850-depr-it-4/report-build-info.html

Bootstrapped OK on armv8l HW.

Is this OK?

Thanks,

Christophe


 (define_insn_and_split "*ior_scc_scc"
-  [(set (match_operand:SI 0 "s_register_operand" "=Ts")
+  [(set (match_operand:SI 0 "s_register_operand" "=Ts,Ts")
(ior:SI (match_operator:SI 3 "arm_comparison_operator"
-[(match_operand:SI 1 "s_register_operand" "r")
- (match_operand:SI 2 "arm_add_operand" "rIL")])
+[(match_operand:SI 1 "s_register_operand" "r,l")
+ (match_operand:SI 2 "arm_add_operand" "rIL,lPy")])
(match_operator:SI 6 "arm_comparison_operator"
-[(match_operand:SI 4 "s_register_operand" "r")
- (match_operand:SI 5 "arm_add_operand" "rIL")])))
+[(match_operand:SI 4 "s_register_operand" "r,l")
+ (match_operand:SI 5 "arm_add_operand" "rIL,lPy")])))

Can you please put the more restrictive alternatives (lPy) first?
Same with the other patterns your patch touches.
Ok with that change if a rebased testing run is ok.
Sorry for the delay in reviewing.

Thanks for improving this area!
Kyrill

[PATCH][AArch64] Add spellchecking hints for -march,-mcpu,-mtune and their attributes

[Kyrill Tkachov]

Hi all,

This patch uses the spellcheck API from David and Jakub [1] to implement hints 
for the
march, mcpu and mtune options to suggest appropriate architectures and CPU names
for users.  It also adds such hints for the equivalent arch, cpu, tune 
attributes.
Architecture extensions like 'crc', 'crypto' are not handled in this patch as 
they
can be combined and modified with '+no' so it would be quite tricky. But if a 
user
misspells those we just give a proper "unknown modifier" error. The hints appear
only when the actual CPU or architecture name is misspelled.

Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk?

Thanks,
Kyrill

[1] https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00339.html

2016-10-07  Kyrylo Tkachov  

* config/aarch64/aarch64.c (aarch64_print_hint_for_core_or_arch):
New function.
(aarch64_print_hint_for_core): Likewise.
(aarch64_print_hint_for_arch): Likewise.
(aarch64_validate_march): Use it.  Fix indentation in type signature.
(aarch64_validate_mcpu): Use aarch64_print_hint_for_core_or_arch.
(aarch64_validate_mtune): Likewise.
(aarch64_handle_attr_arch): Likewise.
(aarch64_handle_attr_cpu): Likewise.
(aarch64_handle_attr_tune): Likewise.

2016-10-07  Kyrylo Tkachov  

* gcc.target/aarch64/spellcheck_1.c: New test.
* gcc.target/aarch64/spellcheck_2.c: Likewise.
* gcc.target/aarch64/spellcheck_3.c: Likewise.
* gcc.target/aarch64/spellcheck_4.c: Likewise.
* gcc.target/aarch64/spellcheck_5.c: Likewise.
* gcc.target/aarch64/spellcheck_6.c: Likewise.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index eeaaa724edb1c70c6aaec32c51316336ef6ef01a..2bb7b8f021f1b67b005bec619f38ecc71ed9cd07 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -8276,6 +8276,44 @@ aarch64_override_options_internal (struct gcc_options *opts)
   aarch64_override_options_after_change_1 (opts);
 }
 
+/* Print a hint with a suggestion for a core or architecture name that
+   most closely resembles what the user passed in STR.  ARCH is true if
+   the user is asking for an architecture name.  ARCH is false if the user
+   is asking for a core name.  */
+
+static void
+aarch64_print_hint_for_core_or_arch (const char *str, bool arch)
+{
+  auto_vec candidates;
+  const struct processor *entry = arch ? all_architectures : all_cores;
+  for (; entry->name != NULL; entry++)
+candidates.safe_push (entry->name);
+  char *s;
+  const char *hint = candidates_list_and_hint (str, s, candidates);
+  if (hint)
+inform (input_location, "valid arguments are: %s;"
+			 " did you mean %qs?", s, hint);
+  XDELETEVEC (s);
+}
+
+/* Print a hint with a suggestion for a core name that most closely resembles
+   what the user passed in STR.  */
+
+inline static void
+aarch64_print_hint_for_core (const char *str)
+{
+  aarch64_print_hint_for_core_or_arch (str, false);
+}
+
+/* Print a hint with a suggestion for an architecture name that most closely
+   resembles what the user passed in STR.  */
+
+inline static void
+aarch64_print_hint_for_arch (const char *str)
+{
+  aarch64_print_hint_for_core_or_arch (str, true);
+}
+
 /* Validate a command-line -mcpu option.  Parse the cpu and extensions (if any)
specified in STR and throw errors if appropriate.  Put the results if
they are valid in RES and ISA_FLAGS.  Return whether the option is
@@ -8298,6 +8336,7 @@ aarch64_validate_mcpu (const char *str, const struct processor **res,
 	break;
   case AARCH64_PARSE_INVALID_ARG:
 	error ("unknown value %qs for -mcpu", str);
+	aarch64_print_hint_for_core (str);
 	break;
   case AARCH64_PARSE_INVALID_FEATURE:
 	error ("invalid feature modifier in -mcpu=%qs", str);
@@ -8316,7 +8355,7 @@ aarch64_validate_mcpu (const char *str, const struct processor **res,
 
 static bool
 aarch64_validate_march (const char *str, const struct processor **res,
-		   unsigned long *isa_flags)
+			 unsigned long *isa_flags)
 {
   enum aarch64_parse_opt_result parse_res
 = aarch64_parse_arch (str, res, isa_flags);
@@ -8331,6 +8370,7 @@ aarch64_validate_march (const char *str, const struct processor **res,
 	break;
   case AARCH64_PARSE_INVALID_ARG:
 	error ("unknown value %qs for -march", str);
+	aarch64_print_hint_for_arch (str);
 	break;
   case AARCH64_PARSE_INVALID_FEATURE:
 	error ("invalid feature modifier in -march=%qs", str);
@@ -8363,6 +8403,7 @@ aarch64_validate_mtune (const char *str, const struct processor **res)
 	break;
   case AARCH64_PARSE_INVALID_ARG:
 	error ("unknown value %qs for -mtune", str);
+	aarch64_print_hint_for_core (str);
 	break;
   default:
 	gcc_unreachable ();
@@ -8736,6 +8777,7 @@ aarch64_handle_attr_arch (const char *str, const char *pragma_or_attr)
 	break;
   case AARCH64_PARSE_INVALID_ARG:
 	error ("unknown value %qs for 'arch' target %s", str, pragma_or_attr);
+	aarch64_print_hint_for_arch (str);
 	break;
  

Re: [PATCH, libgfortran] PR 67585 Handle EINTR

[Fritz Reese]

On Fri, Oct 7, 2016 at 8:59 AM, Janne Blomqvist
 wrote:
> On Fri, Oct 7, 2016 at 2:41 PM, FX  wrote:
>>> Many POSIX systems have the bad habit of not restarting interrupted
>>> syscalls. On these systems it's up to the user to check for an error
>>> with errno == EINTR and restart manually. This patch does this for
>>> libgfortran, so that GFortran users don't have to do it.
>>
>> I have not much experience with EINTR, but is it garanteed that those EINTR 
>> loops will never cycle forever?
>
> Hmm, no I don't think so, but I don't think it'll be a problem. So on
> systems where syscalls are not restarted automatically, EINTR happens
> when the process receives a signal while blocked in a system call [1].
> So I suppose in theory you could have a situation where something
> continuously fires signals at the process, and the result is some kind
> of race between the process restarting the syscall which then never
> manages to complete before being interrupted again. But I think this
> goes into the "Doctor, this hurts! Then don't do that" territory.
>
> There's some more info in https://www.python.org/dev/peps/pep-0475/
> (Python nowadays does the same as this patch).


Just one concern (slightly different from the race you described) -
what if a user wants/expects a system call to be interrupted? With the
patch we would always restart the system call even if the user was
expecting it would be interrupted. For small calls like lseek this may
not be a big deal but if read on a pipe/socket/terminal is restarted
after being interrupted (e.g. with CTRL-C) we may loop forever even if
the user program was written to expect and handle EINTR after the read
call, e.g. to terminate nicely with "non async-safe" calls like printf
that couldn't be done in the handler.

This is discussed as "use case 2" in the PEP you referenced. Python
handles this case by explicitly calling user defined signal handlers
directly after EINTR and checking the return value from the handler,
only trying again if the handler reports success. Not so simple I
think with libgfortran.

---
Fritz Reese

Re: [PATCH][simplify-rtx] Zero-initialise local array in simplify_immed_subreg

[Bernd Schmidt]

On 10/07/2016 04:08 PM, Kyrill Tkachov wrote:


* simplify-rtx.c (simplify_immed_subreg): Zero-initialize tmp array
before merging in bytes to pass down to real_from_target.


Ok.


Bernd

[PATCH][simplify-rtx] Zero-initialise local array in simplify_immed_subreg

[Kyrill Tkachov]

Hi all,

I've encountered another wrong-code bug with the store merging pass. This time 
it's in RTL.
The test gcc.target/aarch64/aapcs64/test_27.c on aarch64 merges a few __fp16 
values at GIMPLE level but
during RTL dse1 one of the constants generated gets wrongly misinterpreted from 
HImode to HFmode
by simplify_immed_subreg. The HFmode value it ends up producing is completely 
bogus.

By stepping through the code with GDB the problem is in the hunk touched by 
this patch when it
fills in an array of longs with the value bytes before passing it down to 
real_from_target.
It fills in the array by orring in each byte.

However, the array it declared to use for this doesn not get properly 
zero-initialised for modes
less that 32 bits wide (HFmode in this case). The fix in this patch is to just 
use an array initialiser
to zero it out. This makes the failure go away.

Bootstrapped and tested on aarch64, x86_64.

Ok for trunk?
Thanks,
Kyrill

2016-10-06  Kyrylo Tkachov  

* simplify-rtx.c (simplify_immed_subreg): Zero-initialize tmp array
before merging in bytes to pass down to real_from_target.
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index 4bb16f896f89b06612e923a0b8db8e074b8a734c..9e7376c9f2b967d96b3195a6d9de57a543644d10 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -5906,14 +5906,12 @@ simplify_immed_subreg (machine_mode outermode, rtx op,
 	case MODE_DECIMAL_FLOAT:
 	  {
 	REAL_VALUE_TYPE r;
-	long tmp[MAX_BITSIZE_MODE_ANY_MODE / 32];
+	long tmp[MAX_BITSIZE_MODE_ANY_MODE / 32] = { 0 };
 
 	/* real_from_target wants its input in words affected by
 	   FLOAT_WORDS_BIG_ENDIAN.  However, we ignore this,
 	   and use WORDS_BIG_ENDIAN instead; see the documentation
 	   of SUBREG in rtl.texi.  */
-	for (i = 0; i < max_bitsize / 32; i++)
-	  tmp[i] = 0;
 	for (i = 0; i < elem_bitsize; i += value_bit)
 	  {
 		int ibase;

[patch,wwwdocs] Add v7 AVR release notes.

[Georg-Johann Lay]

Mentioning some AVR target specific improvements.

Ok?

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.15
diff -r1.15 changes.html
261c261,299
< 
---
> AVR
> 
>   On the reduced Tiny cores, the progmem
> https://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html;>variable
>   attribute
> is now properly supported.  Respective read-only variables are located
> in flash memory in section .progmem.data.  No special
> code is needed to access such variables; the compiler automatically
> adds an offset of 0x4000 to all addresses which is needed
> to access variables in flash memory.  As opposed to ordinary cores
> where it is sufficient to specify the progmem attribute
> with definitions, on the reduced Tiny cores the attribute has also to
> be specified with (external) declarations:
> 
> extern const int array[] __attribute__((__progmem__));
> 
> int get_value2 (void)
> {
>   /* Access via addresses array + 0x4004 and array + 0x4005. */
>   return array[2];
> }
> 
> const int* get_address (unsigned idx)
> {
>   /* Returns array + 0x4000 + 2 * idx. */
>   return array[idx];
> }
>   A new command line option -Wmisspelled-isr has been added.
> It can be used to turn off  or turn into errors 
> warnings that are reported for interrupt service routines (ISRs)
> which don't follow AVR-LibC's naming convention of prefixing
> ISR names with __vector.
>   __builtin_avr_nops(n_nops) is a new
> https://gcc.gnu.org/onlinedocs/gcc/AVR-Built-in-Functions.html;>built-in
>   function
> that inserts n_nops NOP instructions into
> the instruction stream. n_nops must be a value known at
> compile time.
> 

Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)

[Bernd Schmidt]

On 10/07/2016 03:26 PM, David Malcolm wrote:


We could simply print the INSN_UID for CODE_LABELs; something like this
(see the "(code_label 16" below):


I think that should work.


You appear to have trimmed the idea of enclosing the insns with
(basic-block) directives without commenting on it.  Did you like this
idea?


Sorry - I appear to have completely missed it.


It would make the above look like:

  (basic-block 2
;; insns snipped
(jump_insn (set (pc)
(if_then_else (ge (reg:CCGC 17 flags)
(const_int 0 [0]))
(label_ref 16)
(pc))) "test.c":3
   -> 16)
  ) ;; basic-block 2
  (basic-block 4
(note [bb 4] NOTE_INSN_BASIC_BLOCK)
;; insns snipped
(jump_insn (set (pc) (label_ref 20)) "test.c":4
 -> 20)
  ) ;; basic-block 4
  (barrier)
  (basic-block 5
(code_label 16 [1 uses])
(note [bb 5] NOTE_INSN_BASIC_BLOCK)
;; etc
  ) ;; basic-block 5

Note how the above format expresses clearly that:
* the (barrier) is part of the insn chain, but not in a basic block, and
* some insns can happen in a basic block


That looks really nice IMO. Except maybe drop the "-> 16" bit for the 
jump_insn (that's the JUMP_LABEL, isn't it?)



Taking this idea further: if we have (basic-block) directives
integrated into the insn-chain like this, we could express the CFG by
adding (edge) directives. Here's a suggestion for doing it with
(edge-from) and (edge-to) directives, expressing the predecessor and
successor edges in the CFG, along with :


That also looks reasonable. Probably a small but maybe not a huge 
improvement over the other syntax. Having both from and to edges seems 
redundant but might help readability. The reader should check 
consistency in that case.



Should we spell "0" and "1" as "entry" and "exit" when parsing/dumping
basic block indices? e.g.:

  (basic-block 2
(edge-from entry)


If that can be done it would be an improvement.


I think maybe you want a separate compact form of insns and notes
(cinsn/cnote maybe), with a flag selecting which gets written out in
the
dumper. The reader could then read them in like any other rtx code,
and
there'd be a postprocessing stage to reconstruct the insn chain.


By this separate compact form, do you mean the form we've been
discussing above, with no INSN_UID/PREV/NEXT, etc?  Or something else?


Yes, the form we're discussing, except instead of (insn ...) you'd have 
(cinsn ...), which I assume would make it easier for the reader and less 
ambiguous overall.



As for "cinsn", "cnote", how about just "insn" and "note", and having
the compactness be expressed at the top of the dump e.g. implicitly by
the presence of a "(function" directive.  Could even have a format
version specifier in the function directive, to give us some future
-proofing e.g.
  (function (format 20161007)
or somesuch.


Having it implicit should also be ok - I have no strong preference 
really. I'm not sure we want versioning - better to have an automatic 
conversion if we ever feel we need to change the format.



Do you want to want to try hand-edited a test case, using some of the
format ideas we've been discussing?  That might suggest further
improvements to the format.


We'll definitely want to have a look at one or two. Also, we ought to 
try to set up situations we haven't discussed: ADDR_VECs (in light of 
the basic block dumping) and ASMs maybe. I'm probably forgetting some.


One other thing in terms of format is the printout of CONST_INT - I 
think it should suffice to have either decimal, or hex, but not really 
both. The reader should maybe accept either.


I think all hosts have 64-bit HWI these days, so CONST_INT ought to 
always stay valid through a roundtrip.


I may have missed it, but is there any kind of provision yet for 
providing an "after" dump for what is expected after a pass is run? 
Might be worth thinking about whether the reader could have a mode where 
it matches internal RTL against an input.



OK.  If so, do we need to print the regno for hard registers?  Or
should we just print the name for those, for consistency with virtual
regs?  (i.e. have it be controlled by the same flag?)


Just the name should work, leaving only pseudos with numbers - that 
ought to be reasonable. In the reader, when encountering a reg with a 
number, just add FIRST_PSEUDO_REGISTER, and you should end up with 
something that's consistent. Or maybe even dump the expected 
FIRST_PSEUDO_REGISTER, and adjust for it in case the one we have at 
run-time differs.



Does the C one have an advantage in terms of meaningful decls in
MEM_ATTRs/SYMBOL_REFs?


Probably.


I think that might be the more promising path then.


Bernd

Re: [PATCH 10/16] Introduce class function_reader (v3)

[David Malcolm]

On Wed, 2016-10-05 at 18:00 +0200, Bernd Schmidt wrote:
> On 10/05/2016 06:15 PM, David Malcolm wrote:
> > * errors.c: Use consistent pattern for bconfig.h vs config.h
> > includes.
> > (progname): Wrap with #ifdef GENERATOR_FILE.
> > (error): Likewise.  Add "error: " to message.
> > (fatal): Likewise.
> > (internal_error): Likewise.
> > (trim_filename): Likewise.
> > (fancy_abort): Likewise.
> > * errors.h (struct file_location): Move here from read-md.h.
> > (file_location::file_location): Likewise.
> > (error_at): New decl.
> 
> Can you split these out into a separate patch as well? I'll require
> more 
> explanation for them and they seem largely independent.

[CCing Richard Sandiford]

The gen* tools have their own diagnostics system, in errors.c:

/* warning, error, and fatal.  These definitions are suitable for use
   in the generator programs; the compiler has a more elaborate suite
   of diagnostic printers, found in diagnostic.c.  */

with file locations tracked using read-md.h's struct file_location,
rather than location_t (aka libcpp's source_location).

Implementing an RTL frontend by using the RTL reader from read-rtl.c
means that we now need a diagnostics subsystem on the *host* for
handling errors in RTL files, rather than just on the build machine.

There seem to be two ways to do this:

  (A) build the "light" diagnostics system (errors.c) for the host as
well as build machine, and link it with the RTL reader there, so there
are two parallel diagnostics subsystems.

  (B) build the "real" diagnostics system (diagnostics*) for the
*build* machine as well as the host, and use it from the gen* tools,
eliminating the "light" system, and porting the gen* tools to use
libcpp for location tracking.

Approach (A) seems to be simpler, which is what this part of the patch
does.

I've experimented with approach (B).  I think it's doable, but it's
much more invasive (perhaps needing a libdiagnostics.a and a
build/libdiagnostics.a in gcc/Makefile.in), so I hope this can be
followup work.

I can split the relevant parts out into a separate patch, but I was
wondering if either of you had a strong opinion on (A) vs (B) before I
do so?

Dave

Re: RTL frontend input format again (was Re: [PATCH 15/16] RTL frontend (rtl1), on top of dump reader)

[David Malcolm]

like this idea?
It would make the above look like:

  (basic-block 2
;; insns snipped
(jump_insn (set (pc)
(if_then_else (ge (reg:CCGC 17 flags)
(const_int 0 [0]))
(label_ref 16)
(pc))) "test.c":3
   -> 16)
  ) ;; basic-block 2
  (basic-block 4
(note [bb 4] NOTE_INSN_BASIC_BLOCK)
;; insns snipped
(jump_insn (set (pc) (label_ref 20)) "test.c":4   
 -> 20)
  ) ;; basic-block 4
  (barrier)
  (basic-block 5
(code_label 16 [1 uses])
(note [bb 5] NOTE_INSN_BASIC_BLOCK)
;; etc
  ) ;; basic-block 5

Note how the above format expresses clearly that:
* the (barrier) is part of the insn chain, but not in a basic block, and
* some insns can happen in a basic block

Taking this idea further: if we have (basic-block) directives integrated into 
the insn-chain like this, we could express the CFG by adding (edge) directives. 
 Here's a suggestion for doing it with (edge-from) and (edge-to) directives, 
expressing the predecessor and successor edges in the CFG, along with :

  (basic-block 2
(edge-from 0)
;; insns snipped
(jump_insn (set (pc)
(if_then_else (ge (reg:CCGC 17 flags)
(const_int 0 [0]))
(label_ref 16)
(pc))) "test.c":3
   -> 16)
(edge-to 4 (flags "FALLTHRU"))
(edge-to 5 (flags ""))
  ) ;; basic-block 2
  (basic-block 4
(edge-from 2 (flags "FALLTHRU"))
(note [bb 4] NOTE_INSN_BASIC_BLOCK)
;; some insns snipped
(jump_insn (set (pc) (label_ref 20)) "test.c":4   
 -> 20)
(edge-to 6 (flags ""))
  ) ;; basic-block 4
  (barrier)
  (basic-block 5
(edge-from 2 (flags ""))
(code_label 16 [1 uses])
(note [bb 5] NOTE_INSN_BASIC_BLOCK)
;; some insns snipped
(edge-to 6 (flags ""))
  ) ;; basic-block 5


Do you like this approach?   It could also support insns that are on
edges (though I don't know if that's something we need to support in
dumps).

Should we spell "0" and "1" as "entry" and "exit" when parsing/dumping
basic block indices? e.g.:

  (basic-block 2
(edge-from entry)

> What about file names/line numbers? We'll probably want some tests
> for 
> these, but for most others they will be irrelevant.

Yeah.  We cover this below.

> I think maybe you want a separate compact form of insns and notes 
> (cinsn/cnote maybe), with a flag selecting which gets written out in
> the 
> dumper. The reader could then read them in like any other rtx code,
> and 
> there'd be a postprocessing stage to reconstruct the insn chain.

By this separate compact form, do you mean the form we've been
discussing above, with no INSN_UID/PREV/NEXT, etc?  Or something else?

As for "cinsn", "cnote", how about just "insn" and "note", and having
the compactness be expressed at the top of the dump e.g. implicitly by
the presence of a "(function" directive.  Could even have a format
version specifier in the function directive, to give us some future
-proofing e.g.
  (function (format 20161007)
or somesuch.

> > My hope here is to that the input format is something that existing
> > gcc
> > developers will be comfortable reading, which is why I opted for
> > parsing the existing output - and I'm nervous about moving away too
> > much from the existing format.
> 
> Hey, I'm as existing a gcc developer as they come, and I don't much
> like 
> staring at unpruned rtl dumps. They've gotten worse over the years
> too.

Fair enough :)

Do you want to want to try hand-edited a test case, using some of the
format ideas we've been discussing?  That might suggest further
improvements to the format.

> > Some other possible changes: locations could do with a wrapper,
> > and/or
> > to quote the filename, since otherwise we can't cope with spaces in
> > filenames).  So instead of:
> > 
> > (insn 2 (set (reg:DI 481)
> >  (subreg:DI (reg/f:SI 479)
> > 0)) y.c:12702)
> > 
> > we could have:
> > 
> > (insn 2 (set (reg:DI 481)
> >  (subreg:DI (reg/f:SI 479) 0)) "y.c":12702)
> > 
> > or:
> > 
> > (insn 2 (set (reg:DI 481)
> >  (subreg:DI (reg/f:SI 479)
> > 0)) (srcloc "y.c" 12702))
> > 
> > Any preferences on these?
> 
> I suspect just putting it in quotes is good enough. Might be worth
> doing 
> that in general.

Good.  Let's quote the filenames.

> > > There was also a testcase where virtual regs still occurred with
> > > register number, I think it would be best to disallow this and
> > > add
> > > the
> >

Re: [Patch 3/11] Implement TARGET_C_EXCESS_PRECISION for s390

[Joseph Myers]

On Fri, 7 Oct 2016, Andreas Krebbel wrote:

> wrt (c): float_t appears to be more widely used than I expected. But the 
> only hits which might indicate potential ABI problems where in clucene 
> and libassa. (I've scanned the header files of about 25k Ubuntu source 
> packages).

If it's two out of 25000 source packages whose ABIs might be affected, I 
think that shows it's much safer as a change in glibc than moving to 
_FILE_OFFSET_BITS=64 as a default (which I expect will happen when someone 
puts the work in).  And probably safer than many past changes done through 
symbol versioning.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Verify package integrity of downloaded prerequisites (partially fixes 61439)

[Moritz Klammler]

I would like to bump my patch that makes the
`contrib/download_prerequisites` script verify the checksums of
the downloaded packages and augments it with a few additional options.
All feedback I have received has been incorporated.  Is it okay like
this?

Below is again the latest iteration of the patch.


Index: contrib/download_prerequisites
===
--- contrib/download_prerequisites	(revision 240137)
+++ contrib/download_prerequisites	(working copy)
@@ -1,60 +1,215 @@
-#! /bin/sh
+#! /bin/sh -eu
+#! -*- coding:utf-8; mode:shell-script; -*-
 
-# Download some prerequisites needed by gcc.
-# Run this from the top level of the gcc source tree and the gcc
-# build will do the right thing.
+# Download some prerequisites needed by GCC.
+# Run this from the top level of the GCC source tree and the GCC build will do
+# the right thing.  Run it with the `--help` option for more information.
 #
-# (C) 2010-2016 Free Software Foundation
+# (C) 2016 Free Software Foundation
 #
-# This program is free software: you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation, either version 3 of the License, or
-# (at your option) any later version.
-# 
-# This program is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-# General Public License for more details.
-# 
-# You should have received a copy of the GNU General Public License
-# along with this program. If not, see http://www.gnu.org/licenses/.
+# This program is free software: you can redistribute it and/or modify it under
+# the terms of the GNU General Public License as published by the Free Software
+# Foundation, either version 3 of the License, or (at your option) any later
+# version.
+#
+# This program is distributed in the hope that it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+# FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more
+# details.
+#
+# You should have received a copy of the GNU General Public License along with
+# this program.  If not, see http://www.gnu.org/licenses/.
 
-# If you want to disable Graphite loop optimizations while building GCC,
-# DO NOT set GRAPHITE_LOOP_OPT as yes so that the isl package will not
-# be downloaded.
-GRAPHITE_LOOP_OPT=yes
 
-if [ ! -e gcc/BASE-VER ] ; then
-	echo "You must run this script in the top level GCC source directory."
-	exit 1
-fi
+program='download_prerequisites'
+version='(unversioned)'
 
-# Necessary to build GCC.
-MPFR=mpfr-3.1.4
-GMP=gmp-6.1.0
-MPC=mpc-1.0.3
+# MAINTAINERS: If you update the package versions below, please
+# remember to also update the files `contrib/prerequisites.sha512` and
+# `contrib/prerequisites.md5` with the new checksums.
 
-wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$MPFR.tar.bz2 || exit 1
-tar xjf $MPFR.tar.bz2 || exit 1
-if test -L mpfr; then rm -f mpfr; fi
-ln -sf $MPFR mpfr || exit 1
+gmp='gmp-6.1.0.tar.bz2'
+mpfr='mpfr-3.1.4.tar.bz2'
+mpc='mpc-1.0.3.tar.gz'
+isl='isl-0.16.1.tar.bz2'
 
-wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$GMP.tar.bz2 || exit 1
-tar xjf $GMP.tar.bz2  || exit 1
-if test -L gmp; then rm -f gmp; fi
-ln -sf $GMP gmp || exit 1
+base_url='ftp://gcc.gnu.org/pub/gcc/infrastructure/'
 
-wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$MPC.tar.gz || exit 1
-tar xzf $MPC.tar.gz || exit 1
-if test -L mpc; then rm -f mpc; fi
-ln -sf $MPC mpc || exit 1
+echo_archives() {
+echo "${gmp}"
+echo "${mpfr}"
+echo "${mpc}"
+if [ ${graphite} -gt 0 ]; then echo "${isl}"; fi
+}
 
-# Necessary to build GCC with the Graphite loop optimizations.
-if [ "$GRAPHITE_LOOP_OPT" = "yes" ] ; then
-  ISL=isl-0.16.1
+graphite=1
+verify=1
+force=0
+chksum='sha512'
+directory='.'
 
-  wget ftp://gcc.gnu.org/pub/gcc/infrastructure/$ISL.tar.bz2 || exit 1
-  tar xjf $ISL.tar.bz2  || exit 1
-  if test -L isl; then rm -f isl; fi
-  ln -sf $ISL isl || exit 1
+helptext="usage: ${program} [OPTION...]
+
+Downloads some prerequisites needed by GCC.  Run this from the top level of the
+GCC source tree and the GCC build will do the right thing.
+
+The following options are available:
+
+ --directory=DIR  download and unpack packages into DIR instead of '.'
+ --force  download again overwriting existing packages
+ --no-force   do not download existing packages again (default)
+ --isldownload ISL, needed for Graphite loop optimizations (default)
+ --graphite   same as --isl
+ --no-isl don't download ISL
+ --no-graphitesame as --no-isl
+ --verify verify package integrity after download (default)
+ --no-verify  don't verify package integrity
+ --sha512 use SHA512 checksum to verify package integrity (default)
+ --md5use MD5 checksum to verify 

Re: [PATCH, libgfortran] PR 67585 Handle EINTR

[Janne Blomqvist]

On Fri, Oct 7, 2016 at 2:41 PM, FX  wrote:
>> Many POSIX systems have the bad habit of not restarting interrupted
>> syscalls. On these systems it's up to the user to check for an error
>> with errno == EINTR and restart manually. This patch does this for
>> libgfortran, so that GFortran users don't have to do it.
>
> I have not much experience with EINTR, but is it garanteed that those EINTR 
> loops will never cycle forever?

Hmm, no I don't think so, but I don't think it'll be a problem. So on
systems where syscalls are not restarted automatically, EINTR happens
when the process receives a signal while blocked in a system call [1].
So I suppose in theory you could have a situation where something
continuously fires signals at the process, and the result is some kind
of race between the process restarting the syscall which then never
manages to complete before being interrupted again. But I think this
goes into the "Doctor, this hurts! Then don't do that" territory.

There's some more info in https://www.python.org/dev/peps/pep-0475/
(Python nowadays does the same as this patch).

>
> Apart from that, OK to commit.
>
> FX



-- 
Janne Blomqvist

Re: [PATCH, libgfortran] PR 67585 Handle EINTR

[FX]

> Many POSIX systems have the bad habit of not restarting interrupted
> syscalls. On these systems it's up to the user to check for an error
> with errno == EINTR and restart manually. This patch does this for
> libgfortran, so that GFortran users don't have to do it.

I have not much experience with EINTR, but is it garanteed that those EINTR 
loops will never cycle forever?

Apart from that, OK to commit.

FX

[PATCH][LTO] Properly stream the BLOCK tree

[Richard Biener]

This implements what was probably intended(?) -- streaming DECL_INITIAL
as a whole (full BLOCK tree plus associated BLOCK_VARs) in
output_function.  Currently we only stream the outermost BLOCK
(and its vars) and the rest lazily during statement streaming
when we somehow get a BLOCK reference or a VAR_DECL reference.

I'm not sure we're not missing unreferenced BLOCKs with still used
VAR_DECLs of them and thus will fail to annotate the VAR_DECL DIEs
with locations in late LTO debug.

LTO bootstrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2016-10-07  Richard Biener  

* lto-streamer-out.c (collect_block_tree_leafs): New helper.
(output_function): Properly stream the whole block tree.
* lto-streamer-in.c (input_function): Likewise.

Index: gcc/lto-streamer-out.c
===
--- gcc/lto-streamer-out.c  (revision 240855)
+++ gcc/lto-streamer-out.c  (working copy)
@@ -2016,6 +2016,18 @@ output_struct_function_base (struct outp
 }
 
 
+/* Collect all leaf BLOCKs beyond ROOT into LEAFS.  */
+
+static void
+collect_block_tree_leafs (tree root, vec )
+{
+  for (root = BLOCK_SUBBLOCKS (root); root; root = BLOCK_CHAIN (root))
+if (! BLOCK_SUBBLOCKS (root))
+  leafs.safe_push (root);
+else
+  collect_block_tree_leafs (BLOCK_SUBBLOCKS (root), leafs);
+}
+
 /* Output the body of function NODE->DECL.  */
 
 static void
@@ -2048,10 +2060,15 @@ output_function (struct cgraph_node *nod
   streamer_write_chain (ob, DECL_ARGUMENTS (function), true);
 
   /* Output DECL_INITIAL for the function, which contains the tree of
- lexical scopes.
- ???  This only streams the outermost block because we do not
- recurse into BLOCK_SUBBLOCKS but re-build those on stream-in.  */
+ lexical scopes.  */
   stream_write_tree (ob, DECL_INITIAL (function), true);
+  /* As we do not recurse into BLOCK_SUBBLOCKS but only BLOCK_SUPERCONTEXT
+ collect block tree leafs and stream those.  */
+  auto_vec block_tree_leafs;
+  collect_block_tree_leafs (DECL_INITIAL (function), block_tree_leafs);
+  streamer_write_uhwi (ob, block_tree_leafs.length ());
+  for (unsigned i = 0; i < block_tree_leafs.length (); ++i)
+stream_write_tree (ob, block_tree_leafs[i], true);
 
   /* We also stream abstract functions where we stream only stuff needed for
  debug info.  */
Index: gcc/lto-streamer-in.c
===
--- gcc/lto-streamer-in.c   (revision 240855)
+++ gcc/lto-streamer-in.c   (working copy)
@@ -1036,6 +1036,9 @@ input_function (tree fn_decl, struct dat
 
   /* Read the tree of lexical scopes for the function.  */
   DECL_INITIAL (fn_decl) = stream_read_tree (ib, data_in);
+  unsigned block_leaf_count = streamer_read_uhwi (ib);
+  while (block_leaf_count--)
+stream_read_tree (ib, data_in);
 
   if (!streamer_read_uhwi (ib))
 return;

Re: Fix missing -Wimplicit-fallthrough warning

[Jakub Jelinek]

On Wed, Oct 05, 2016 at 06:52:55PM +0200, Marek Polacek wrote:
> Ping.
> 
> On Thu, Sep 29, 2016 at 06:10:27PM +0200, Marek Polacek wrote:
> > Here, a missing -Wimplicit-fallthrough warning was caused by a misplaced
> > FALLTHROUGH_LABEL_P check.  As it is now, for FALLTHROUGH_LABEL_P we'd
> > never gotten around to
> >  1933 /* So that next warn_implicit_fallthrough_r will start 
> > looking for
> >  1934a new sequence starting with this label.  */
> >  1935 gsi_prev (gsi_p);
> > 
> > The fix is to move the check to should_warn_for_implicit_fallthrough.
> > 
> > Bootstrapped/regtested on x86_64-linux and ppc64-linux, ok for trunk?
> > 
> > 2016-09-29  Marek Polacek  
> > 
> > * gimplify.c (should_warn_for_implicit_fallthrough): Check for
> > FALLTHROUGH_LABEL_P here...
> > (warn_implicit_fallthrough_r): ...not here.
> > 
> > * c-c++-common/Wimplicit-fallthrough-22.c: New test.

Ok, thanks.

Jakub

[PATCH, libgfortran] PR 67585 Handle EINTR

[Janne Blomqvist]

Many POSIX systems have the bad habit of not restarting interrupted
syscalls. On these systems it's up to the user to check for an error
with errno == EINTR and restart manually. This patch does this for
libgfortran, so that GFortran users don't have to do it.

2016-10-07  Janne Blomqvist  

PR libfortran/67585
* io/unix.c (raw_read): Handle EINTR.
(raw_write): Check for return value -1.
(raw_seek): Handle EINTR.
(raw_tell): Likewise.
(raw_size): Likewise.
(raw_truncate): Likewise.
(raw_close): Likewise.
(buf_flush): Call raw_seek instead of lseek.
(buf_read): Likewise.
(buf_write): Likewise.

Regtested on x86_64-pc-linux-gnu. Ok for trunk?
---
 libgfortran/io/unix.c | 64 ---
 1 file changed, 51 insertions(+), 13 deletions(-)

diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c
index 29818cd..43e33c8 100644
--- a/libgfortran/io/unix.c
+++ b/libgfortran/io/unix.c
@@ -298,8 +298,15 @@ static ssize_t
 raw_read (unix_stream * s, void * buf, ssize_t nbyte)
 {
   /* For read we can't do I/O in a loop like raw_write does, because
- that will break applications that wait for interactive I/O.  */
-  return read (s->fd, buf, nbyte);
+ that will break applications that wait for interactive I/O.  We
+ still can loop around EINTR, though.  */
+  while (true)
+{
+  ssize_t trans = read (s->fd, buf, nbyte);
+  if (trans == -1 && errno == EINTR)
+   continue;
+  return trans;
+}
 }
 
 static ssize_t
@@ -316,7 +323,7 @@ raw_write (unix_stream * s, const void * buf, ssize_t nbyte)
   while (bytes_left > 0)
 {
   trans = write (s->fd, buf_st, bytes_left);
-  if (trans < 0)
+  if (trans == -1)
{
  if (errno == EINTR)
continue;
@@ -333,22 +340,37 @@ raw_write (unix_stream * s, const void * buf, ssize_t 
nbyte)
 static gfc_offset
 raw_seek (unix_stream * s, gfc_offset offset, int whence)
 {
-  return lseek (s->fd, offset, whence);
+  while (true)
+{
+  gfc_offset off = lseek (s->fd, offset, whence);
+  if (off == (gfc_offset) -1 && errno == EINTR)
+   continue;
+  return off;
+}
 }
 
 static gfc_offset
 raw_tell (unix_stream * s)
 {
-  return lseek (s->fd, 0, SEEK_CUR);
+  while (true)
+{
+  gfc_offset off = lseek (s->fd, 0, SEEK_CUR);
+  if (off == (gfc_offset) -1 && errno == EINTR)
+   continue;
+  return off;
+}
 }
 
 static gfc_offset
 raw_size (unix_stream * s)
 {
   struct stat statbuf;
-  int ret = fstat (s->fd, );
-  if (ret == -1)
-return ret;
+  while (fstat (s->fd, ) == -1)
+{
+  if (errno == EINTR)
+   continue;
+  return -1;
+}
   if (S_ISREG (statbuf.st_mode))
 return statbuf.st_size;
   else
@@ -390,7 +412,13 @@ raw_truncate (unix_stream * s, gfc_offset length)
   lseek (s->fd, cur, SEEK_SET);
   return -1;
 #elif defined HAVE_FTRUNCATE
-  return ftruncate (s->fd, length);
+  while (ftruncate (s->fd, length) == -1)
+{
+  if (errno == EINTR)
+   continue;
+  return -1;
+}
+  return 0;
 #elif defined HAVE_CHSIZE
   return chsize (s->fd, length);
 #else
@@ -409,7 +437,17 @@ raw_close (unix_stream * s)
   else if (s->fd != STDOUT_FILENO
   && s->fd != STDERR_FILENO
   && s->fd != STDIN_FILENO)
-retval = close (s->fd);
+{
+  retval = close (s->fd);
+  /* close() and EINTR is special, as the file descriptor is
+deallocated before doing anything that might cause the
+operation to be interrupted. Thus if we get EINTR the best we
+can do is ignore it and continue (otherwise if we try again
+the file descriptor may have been allocated again to some
+other file).  */
+  if (retval == -1 && errno == EINTR)
+   retval = errno = 0;
+}
   else
 retval = 0;
   free (s);
@@ -463,7 +501,7 @@ buf_flush (unix_stream * s)
 return 0;
   
   if (s->physical_offset != s->buffer_offset
-  && lseek (s->fd, s->buffer_offset, SEEK_SET) < 0)
+  && raw_seek (s, s->buffer_offset, SEEK_SET) < 0)
 return -1;
 
   writelen = raw_write (s, s->buffer, s->ndirty);
@@ -518,7 +556,7 @@ buf_read (unix_stream * s, void * buf, ssize_t nbyte)
   to_read = nbyte - nread;
   new_logical = s->logical_offset + nread;
   if (s->physical_offset != new_logical
-  && lseek (s->fd, new_logical, SEEK_SET) < 0)
+  && raw_seek (s, new_logical, SEEK_SET) < 0)
 return -1;
   s->buffer_offset = s->physical_offset = new_logical;
   if (to_read <= BUFFER_SIZE/2)
@@ -587,7 +625,7 @@ buf_write (unix_stream * s, const void * buf, ssize_t nbyte)
{
  if (s->physical_offset != s->logical_offset)
{
- if (lseek (s->fd, s->logical_offset, SEEK_SET) < 0)
+ if (raw_seek (s, s->logical_offset, SEEK_SET) < 0)
return -1;
  

[Bug c++/69733] -Wignored-qualifiers points to wrong const

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69733

Bernd Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Bernd Schmidt  ---
Fixed.

[Bug tree-optimization/77880] [7 Regression] out of memory building recent LLVM on ppc64le with -O3

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77880

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Bernd Schmidt  ---
Fixed.

[Bug c++/69733] -Wignored-qualifiers points to wrong const

[bernds at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69733

--- Comment #2 from Bernd Schmidt  ---
Author: bernds
Date: Fri Oct  7 12:21:55 2016
New Revision: 240863

URL: https://gcc.gnu.org/viewcvs?rev=240863=gcc=rev
Log:
c/
PR c++/69733
* c-decl.c (smallest_type_quals_location): New static function.
(grokdeclarator): Try to find the correct location for an ignored
qualifier.
cp/
PR c++/69733
* decl.c (grokdeclarator): Try to find the correct location for an
ignored qualifier.
testsuite/
PR c++/69733
* c-c++-common/pr69733.c: New test.
* gcc.dg/pr69733.c: New test.
* gcc.target/i386/pr69733.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/pr69733.c
trunk/gcc/testsuite/gcc.dg/pr69733.c
trunk/gcc/testsuite/gcc.target/i386/pr69733.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/ChangeLog

Re: C, C++: Fix PR 69733 (bad location for ignored qualifiers warning)

[Bernd Schmidt]

On 07/21/2016 08:39 PM, Jeff Law wrote:

On 07/15/2016 07:04 AM, Bernd Schmidt wrote:

c/
PR c++/69733
* c-decl.c (smallest_type_quals_location): New static function.
(grokdeclarator): Try to find the correct location for an ignored
qualifier.
cp/
PR c++/69733
* decl.c (grokdeclarator): Try to find the correct location for an
ignored qualifier.
testsuite/
PR c++/69733
* c-c++-common/pr69733.c: New test.
* gcc.dg/pr69733.c: New test.
* gcc.target/i386/pr69733.c: New test.

Yes, this version is OK too.


It fell through the cracks for a while - now committed.


Bernd

[PATCH] Untested #pragma acc declare fix

[Jakub Jelinek]

Hi!

During review of Martin's -fsanitize-use-after-scope patch, I've noticed
what I believe is a bug in #pragma acc declare support.

In particular, the oacc_declare_returns has been added next to the CLOBBER
additions, but the clobbers are guarded with many conditions, e.g. aren't
emitted with -fstack-reuse=none and many other conditions.

I believe the additions to that data structure aren't guarded by these
conditions, it is just for VAR_DECLs that aren't is_global_var and have
current_function_decl context.

I haven't tested this patch (can bootstrap/regtest it), but don't have time
to try to write a testcase for all the cases where the conditions matter.

2016-10-07  Jakub Jelinek  

* gimplify.c (gimplify_bind_expr): Handle oacc_declare_returns
even for -fstack-reuse=none, or for volatile vars etc.

--- gcc/gimplify.c.jj   2016-09-26 12:06:46.0 +0200
+++ gcc/gimplify.c  2016-10-07 14:11:09.299624104 +0200
@@ -1192,21 +1192,24 @@ gimplify_bind_expr (tree *expr_p, gimple
 {
   if (TREE_CODE (t) == VAR_DECL
  && !is_global_var (t)
- && DECL_CONTEXT (t) == current_function_decl
- && !DECL_HARD_REGISTER (t)
- && !TREE_THIS_VOLATILE (t)
- && !DECL_HAS_VALUE_EXPR_P (t)
- /* Only care for variables that have to be in memory.  Others
-will be rewritten into SSA names, hence moved to the top-level.  */
- && !is_gimple_reg (t)
- && flag_stack_reuse != SR_NONE)
+ && DECL_CONTEXT (t) == current_function_decl)
{
- tree clobber = build_constructor (TREE_TYPE (t), NULL);
- gimple *clobber_stmt;
- TREE_THIS_VOLATILE (clobber) = 1;
- clobber_stmt = gimple_build_assign (t, clobber);
- gimple_set_location (clobber_stmt, end_locus);
- gimplify_seq_add_stmt (, clobber_stmt);
+ if (!DECL_HARD_REGISTER (t)
+ && !TREE_THIS_VOLATILE (t)
+ && !DECL_HAS_VALUE_EXPR_P (t)
+ /* Only care for variables that have to be in memory.  Others
+will be rewritten into SSA names, hence moved to the
+top-level.  */
+ && !is_gimple_reg (t)
+ && flag_stack_reuse != SR_NONE)
+   {
+ tree clobber = build_constructor (TREE_TYPE (t), NULL);
+ gimple *clobber_stmt;
+ TREE_THIS_VOLATILE (clobber) = 1;
+ clobber_stmt = gimple_build_assign (t, clobber);
+ gimple_set_location (clobber_stmt, end_locus);
+ gimplify_seq_add_stmt (, clobber_stmt);
+   }
 
  if (flag_openacc && oacc_declare_returns != NULL)
{

Jakub