[Bug libitm/63907] libitm/config/posix/rwlock.cc doesn't compile

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Andrew Pinski  ---
How does this work for everyone else?  Can you attach the preprocessed source?

[Bug middle-end/77981] gcc 7 miscompiles kernel

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Bug in the kernel, see dup bug 77964.

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

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||jirislaby at gmail dot com

--- Comment #12 from Andrew Pinski  ---
*** Bug 77981 has been marked as a duplicate of this bug. ***

[Bug middle-end/77981] New: gcc 7 miscompiles kernel

[jirislaby at gmail dot com]

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

Bug ID: 77981
   Summary: gcc 7 miscompiles kernel
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jirislaby at gmail dot com
  Target Milestone: ---

I am using
gcc-7 (SUSE Linux) 7.0.0 20161007 (experimental)
from martin liska's
https://build.opensuse.org/project/show/home:marxin:syzkaller

And the kernel does not boot. It is looping and page faulting inside 
get_builtin_firmware:
{
#ifdef CONFIG_FW_LOADER
struct builtin_fw *b_fw;

for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
if (!strcmp(name, b_fw->name)) {
cd->size = b_fw->size;
cd->data = b_fw->data;
return true;
}
}
#endif
return false;
}

But
$ nm vmlinux-4.8.1-* |grep __.*_builtin_fw
81ac2158 R __end_builtin_fw
81ac2158 R __start_builtin_fw


And sure, the test b_fw != __end_builtin_fw seems to be removed from the code:
81049d20 :
81049d20:   e8 fb bb 68 00  callq  816d5920
<__fentry__>
81049d25:   41 54   push   %r12
81049d27:   49 89 fcmov%rdi,%r12
81049d2a:   55  push   %rbp
81049d2b:   48 89 f5mov%rsi,%rbp
81049d2e:   53  push   %rbx
81049d2f:   48 c7 c3 58 21 ac 81mov$0x81ac2158,%rbx
81049d36:   eb 04   jmp81049d3c

81049d38:   48 83 c3 18 add$0x18,%rbx
81049d3c:   48 8b 33mov(%rbx),%rsi
81049d3f:   48 89 efmov%rbp,%rdi
81049d42:   e8 d9 3d 36 00  callq  813adb20

81049d47:   85 c0   test   %eax,%eax
81049d49:   75 ed   jne81049d38

81049d4b:   48 8b 43 10 mov0x10(%rbx),%rax
81049d4f:   49 89 44 24 08  mov%rax,0x8(%r12)
81049d54:   48 8b 43 08 mov0x8(%rbx),%rax
81049d58:   5b  pop%rbx
81049d59:   5d  pop%rbp
81049d5a:   49 89 04 24 mov%rax,(%r12)
81049d5e:   b8 01 00 00 00  mov$0x1,%eax
81049d63:   41 5c   pop%r12
81049d65:   c3  retq   
81049d66:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
81049d6d:   00 00 00 



gcc-6 produces this:
81ac2230 R __end_builtin_fw
81ac2230 R __start_builtin_fw

and (chopped)

81049e39:   48 c7 c3 30 22 ac 81mov$0x81ac2230,%rbx
81049e40:   48 81 fb 30 22 ac 81cmp$0x81ac2230,%rbx
81049e47:   74 3f   je 81049e88


The 'if' ^

81049e49:   48 89 f5mov%rsi,%rbp
81049e4c:   49 89 fcmov%rdi,%r12
81049e4f:   eb 0d   jmp81049e5e

81049e51:   48 83 c3 18 add$0x18,%rbx
81049e55:   48 81 fb 30 22 ac 81cmp$0x81ac2230,%rbx
81049e5c:   74 2a   je 81049e88

81049e5e:   48 8b 33mov(%rbx),%rsi
81049e61:   48 89 efmov%rbp,%rdi
81049e64:   e8 f7 1e 36 00  callq  813abd60

81049e69:   85 c0   test   %eax,%eax
81049e6b:   75 e4   jne81049e51

[Bug tree-optimization/77980] New: Regression in GCC-7.0.0's optimizer.

[ishiura-compiler at ml dot kwansei.ac.jp]

/7.0.0/lto-wrapper
target: x86_64-pc-linux-gnu
configure woth: ../gcc/configure --prefix=/home/kota/opt/gcc
--program-suffix=-7.0 --disable-multilib --enable-languages=c
thred model: posix
gcc version 7.0.0 20161013 (experimental) (GCC)


using built-in specs.
clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/6.0.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0
Candidate multilib: .;@m64
Selected multilib: .;@m64

 */

Re: [patch, fortran] PR77972 ICE on broken character continuation with -Wall etc.

[Steve Kargl]

On Thu, Oct 13, 2016 at 07:04:04PM -0700, Jerry DeLisle wrote:
> This patch is straight forward. We were sending bogus locus info to the 
> diagnostics machinery and catch an assert in error,c.
> 
> The patch avoids doing this.
> 
> Regression tested on x86-64-linux.
> 
> OK for trunk?
> 

Yes, but see below.

> Regards,
> 
> Jerry
> 
> 2016-10-13  Jerry DeLisle  
> 
>   * scanner.c (gfc_next_char_literal): If nextc is null do not
>   decrement the pointer and call the diagnostics.
> 
> diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
> index be9c5091..5e355359 100644
> --- a/gcc/fortran/scanner.c
> +++ b/gcc/fortran/scanner.c
> @@ -1414,10 +1414,9 @@ restart:
> 
> if (c != '&')
>  {
> - if (in_string)
> + if (in_string && gfc_current_locus.nextc)
>  {
> - if (gfc_current_locus.nextc)
> -   gfc_current_locus.nextc--;
> + gfc_current_locus.nextc--;
>if (warn_ampersand && in_string == INSTRING_WARN)
>  gfc_warning (OPT_Wampersand,
>   "Missing %<&%> in continued character "

If this is a "missing '&' in a continued..." and the '&' is 
required by the standard, then why is this just a warning?

-- 
Steve

[Bug driver/36312] should refuse to overwrite input file with output file

[riccardo at cs dot wisc.edu]

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

Riccardo Mutschlechner  changed:

   What|Removed |Added

 CC||riccardo at cs dot wisc.edu

--- Comment #21 from Riccardo Mutschlechner  ---
Not sure if this is the best place to start, but here goes. I've noticed
another similar issue.

Let's say you've compiled a binary, `test`, from a source `test.c`. If you then
flip the arguments to gcc by mistake, `gcc -o test.c test` rather than `gcc -o
test test.c`, you will overwrite the source file by trying to compile the
binary, thus losing it permanently without some other backup.

Can I add some functionality that double checks against compiling *into* a
source file extension? 

Is this cruft, or something that would actually be used - and if so, what is a
good way to go about doing this? 

Would love to do it ASAP.

[Bug tree-optimization/77979] New: ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault

[su at cs dot ucdavis.edu]

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

Bug ID: 77979
   Summary: ICE on valid code at -Os and above on
x86_64-linux-gnu: Segmentation fault
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This is a regression from 6.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161013 (experimental) [trunk revision 241136] (GCC)
$
$ gcc-trunk -O1 -c small.c
$ gcc-6.2 -Os -c small.c
$
$ gcc-trunk -Os -c small.c
small.c: In function ‘fn1’:
small.c:3:6: internal compiler error: Segmentation fault
 void fn1 ()
  ^~~
0xbe954f crash_signal
../../gcc-source-trunk/gcc/toplev.c:338
0xe7b040 tree_check
../../gcc-source-trunk/gcc/tree.h:3286
0xe7b040 get_value_range
../../gcc-source-trunk/gcc/tree-vrp.c:650
0xe7f51c get_vr_for_comparison
../../gcc-source-trunk/gcc/tree-vrp.c:7134
0xe7f51c compare_names
../../gcc-source-trunk/gcc/tree-vrp.c:7299
0xe7f51c vrp_evaluate_conditional_warnv_with_ops
../../gcc-source-trunk/gcc/tree-vrp.c:7389
0xe7f93b vrp_evaluate_conditional
../../gcc-source-trunk/gcc/tree-vrp.c:7423
0xe90f36 simplify_stmt_for_jump_threading
../../gcc-source-trunk/gcc/tree-vrp.c:10349
0xdf169e simplify_control_stmt_condition
../../gcc-source-trunk/gcc/tree-ssa-threadedge.c:453
0xdf20e8 thread_through_normal_block
../../gcc-source-trunk/gcc/tree-ssa-threadedge.c:1088
0xdf3402 thread_across_edge(gcond*, edge_def*, bool, const_and_copies*,
avail_exprs_stack*, tree_node* (*)(gimple*, gimple*, avail_exprs_stack*))
../../gcc-source-trunk/gcc/tree-ssa-threadedge.c:1189
0xe88843 identify_jump_threads
../../gcc-source-trunk/gcc/tree-vrp.c:10536
0xe88843 vrp_finalize
../../gcc-source-trunk/gcc/tree-vrp.c:10624
0xe88843 execute_vrp
../../gcc-source-trunk/gcc/tree-vrp.c:11016
0xe88843 execute
../../gcc-source-trunk/gcc/tree-vrp.c:11102
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


---


int a, b, c, d, e, f;

void fn1 ()
{ 
  int g = b;
  a = -~(d || a) << 4 || e;
  b = c || g ^ a;
  if (f < g)
d = e;
}

[patch, fortran] PR77972 ICE on broken character continuation with -Wall etc.

[Jerry DeLisle]

This patch is straight forward. We were sending bogus locus info to the 
diagnostics machinery and catch an assert in error,c.


The patch avoids doing this.

Regression tested on x86-64-linux.

OK for trunk?

Regards,

Jerry

2016-10-13  Jerry DeLisle  

* scanner.c (gfc_next_char_literal): If nextc is null do not
decrement the pointer and call the diagnostics.

diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index be9c5091..5e355359 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -1414,10 +1414,9 @@ restart:

   if (c != '&')
{
- if (in_string)
+ if (in_string && gfc_current_locus.nextc)
{
- if (gfc_current_locus.nextc)
-   gfc_current_locus.nextc--;
+ gfc_current_locus.nextc--;
  if (warn_ampersand && in_string == INSTRING_WARN)
gfc_warning (OPT_Wampersand,
 "Missing %<&%> in continued character "

[Bug fortran/77978] New: stop codes misinterpreted in both f2003 and f2008

[john.harper at vuw dot ac.nz]

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

Bug ID: 77978
   Summary: stop codes misinterpreted in both f2003 and f2008
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

Stop codes changed from the f2003 standard to f2008. The first of these 2 
programs has a stop code valid in f2003 but not in f2008, the second has a stop
code valid in f2008 but not in f2003. But gfortran 6.1.1 happily compiles and
runs both programs with either -std=f2003 or -f2008.

Here are the program listings, gfortran -v result, and the results of compiling
with the -std options that should not have worked:

cayley[~/Jfh] % cat stopnumber.f90
! stop666 (no space before 666) is valid f95 or f2003 but bad f2008
  implicit none
  stop666
end program
cayley[~/Jfh] % cat stopnumber2.f90
! stop expression is valid f2008 but bad f2003
  implicit none 
  stop merge(667,668,.true.)
end program 
cayley[~/Jfh] % gfortran -v
Using built-in specs.   
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper  
Target: x86_64-pc-linux-gnu 
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release  
Thread model: posix 
gcc version 6.1.1 20160602 (GCC)
cayley[~/Jfh] % gfortran -std=f2008 stopnumber.f90
cayley[~/Jfh] % ./a.out 
STOP 666
cayley[~/Jfh] % gfortran -std=f2003 stopnumber2.f90 
cayley[~/Jfh] % ./a.out
STOP 667
cayley[~/Jfh] %

[Bug fortran/77972] ICE on broken character continuation with -Wall etc.

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #3 from Jerry DeLisle  ---
Testing fix now.

Re: [ipa-vrp] Use get/set_ptr_nonnull in ipa-vrp

[kugan]

Hi Honza,

On 12/10/16 22:16, Jan Hubicka wrote:

Hi,

This patch uses the get/set_ptr_nonnull so that ipa-vrp also
propagates nonnull ranges for pinter.

Bootstrapped and regression tested this with other patched without
any new regressions on x86_64-linux-gnu.

Is this OK for trunk?

Thanks,
Kugan




gcc/ChangeLog:

2016-10-12  Kugan Vivekanandarajah  

* ipa-prop.c (ipa_compute_jump_functions_for_edge): Set value range
  for pointer type too.
(ipcp_update_vr): set_ptr_nonnull for pointer.

gcc/testsuite/ChangeLog:

2016-10-12  Kugan Vivekanandarajah  

* gcc.dg/ipa/vrp4.c: New test.

OK, thank you!
We should be able to derive a lot of (useful) non-null information from the
fact that the pointers are dereferenced either prior the function call or in a
statement that postdominate the function entry.
I will try with spec2k/2006. Do you have any specific benchmark in mind 
that I can try first?


  I guess we could also give (semi)

useful -Wmissing-attribute=nonnull hints in that case.


I will send a follow up patch for this.

Thanks,
Kugan


Honza

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[glisse at gcc dot gnu.org]

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

--- Comment #11 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #5)
> Looks like a kernel issue. An asm ("", "+r"(x)); is needed in the source for
> __start_builtin_fw and __end_builtin_fw

Shouldn't we recommend "+g" instead of "+r"?

(In reply to Markus Trippelsdorf from comment #9)
> Is subtracting undefined, too?
> 
> -   for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
> +   for (b_fw = __start_builtin_fw;  __end_builtin_fw - b_fw; b_fw++) {

See bug 77813.

Re: Set nonnull attribute to ptr_info_def based on VRP

[kugan]

Hi Richard,

On 13/10/16 20:44, Richard Biener wrote:

On Thu, Oct 13, 2016 at 6:49 AM, kugan
 wrote:

Hi Richard,



what does this try to do?  Preserve info VRP computed across PTA?

I think we didn't yet sort out the nonlocal/escaped vs. null handling
properly
(or how PTA should handle get_ptr_nonnull).  The way you are using it
asks for pt.null to be orthogonal to nonlocal/escaped and thus having
nonlocal or escaped would also require setting ptr.null in PTA.  It then
would be also more canonical to set it for pt.anything as well.  Which
means conservatively handling it would be equivalent to flipping its
semantic and changing its name to pt.nonnull.

That said, you seem to be simply "reserving" the bit for VRP, keeping it
conservatively true when "not computed".  I guess I'm fine with this for
now
but it should be documented in the header file that way.



Thanks for the comments.

To summarize, currently I am not relying on PTA analysis at all. Just saving
null from VRP (or rather nonnull) and preserving it across PTA. Primary
intention is to pass it for PARM_DECL SSA names (from ipa-vrp).

In this case, using  pt.anything/nonlocal/escaped will only make the result
more pessimistic.

Ideally, we should improve pt.null within PTA but for now as you said, I
will document it.

When we start using pt.null from PTA analysis, we would also have to take
into account pt.anything/nonlocal/escaped.

Does that make sense?


Yes.



Here is the revised patch based on the review. I also had to adjust two 
testcases since we set pt.null conservatively and dumps that too.


Thanks,
Kugan

gcc/ChangeLog:

2016-10-14  Kugan Vivekanandarajah  

* tree-ssa-alias.h (pt_solution_singleton_or_null_p): Renamed from
pt_solution_singleton_p.
* tree-ssa-ccp.c (fold_builtin_alloca_with_align): Use renamed
pt_solution_singleton_or_null_p from pt_solution_singleton_p.
* tree-ssa-structalias.c (find_what_var_points_to): Conservatively set
pt.null to 1.
(find_what_p_points_to): Preserve pointer nonnull computed by VRP.
(pt_solution_singleton_or_null_p): Renamed from
pt_solution_singleton_p.
* tree-ssanames.h (set_ptr_nonnull): Declare.
(get_ptr_nonnull): Likewise.
* tree-ssanames.c (set_ptr_nonnull): New.
(get_ptr_nonnull): Likewise.
* tree-vrp.c (vrp_finalize): Set ptr that are nonnull.
(evrp_dom_walker::before_dom_children): Likewise.


gcc/testsuite/ChangeLog:

2016-10-14  Kugan Vivekanandarajah  

* gcc.dg/torture/pr39074-2.c: Adjust testcase.
* gcc.dg/torture/pr39074.c: Likewise.
>From 0bc1c2efb600854148889bfdd9d121a3edc2841b Mon Sep 17 00:00:00 2001
From: Kugan Vivekanandarajah 
Date: Wed, 12 Oct 2016 13:48:07 +1100
Subject: [PATCH 1/3] Add-nonnull-to-pointer-from-VRP

---
 gcc/testsuite/gcc.dg/torture/pr39074-2.c |  2 +-
 gcc/testsuite/gcc.dg/torture/pr39074.c   |  2 +-
 gcc/tree-ssa-alias.h |  2 +-
 gcc/tree-ssa-ccp.c   |  2 +-
 gcc/tree-ssa-structalias.c   | 11 ++--
 gcc/tree-ssanames.c  | 29 +
 gcc/tree-ssanames.h  |  2 ++
 gcc/tree-vrp.c   | 44 +---
 8 files changed, 73 insertions(+), 21 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/torture/pr39074-2.c b/gcc/testsuite/gcc.dg/torture/pr39074-2.c
index 740b463..0693f2d 100644
--- a/gcc/testsuite/gcc.dg/torture/pr39074-2.c
+++ b/gcc/testsuite/gcc.dg/torture/pr39074-2.c
@@ -31,4 +31,4 @@ int main()
 }
 
 /* { dg-final { scan-tree-dump "y.._. = { i }" "alias" } } */
-/* { dg-final { scan-tree-dump "y.._., points-to vars: { D. }" "alias" } } */
+/* { dg-final { scan-tree-dump "y.._., points-to NULL, points-to vars: { D. }" "alias" } } */
diff --git a/gcc/testsuite/gcc.dg/torture/pr39074.c b/gcc/testsuite/gcc.dg/torture/pr39074.c
index 31ed499..54c444e 100644
--- a/gcc/testsuite/gcc.dg/torture/pr39074.c
+++ b/gcc/testsuite/gcc.dg/torture/pr39074.c
@@ -30,4 +30,4 @@ int main()
 }
 
 /* { dg-final { scan-tree-dump "y.._. = { i }" "alias" } } */
-/* { dg-final { scan-tree-dump "y.._., points-to vars: { D. }" "alias" } } */
+/* { dg-final { scan-tree-dump "y.._., points-to NULL, points-to vars: { D. }" "alias" } } */
diff --git a/gcc/tree-ssa-alias.h b/gcc/tree-ssa-alias.h
index 6680cc0..27a06fc 100644
--- a/gcc/tree-ssa-alias.h
+++ b/gcc/tree-ssa-alias.h
@@ -146,7 +146,7 @@ extern void dump_alias_stats (FILE *);
 /* In tree-ssa-structalias.c  */
 extern unsigned int compute_may_aliases (void);
 extern bool pt_solution_empty_p (struct pt_solution *);
-extern bool pt_solution_singleton_p (struct pt_solution *, unsigned *);
+extern bool pt_solution_singleton_or_null_p (struct pt_solution *, unsigned *);
 extern bool pt_solution_includes_global (struct 

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
Created attachment 39807
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39807=edit
Pre-processed source for tools/qtextboundaryfinder.cpp

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[glaubitz at physik dot fu-berlin.de]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #12 from John Paul Adrian Glaubitz  ---
Hi!

We just recently started seeing this issue in Debian, however, only for the
powerpc-linux-gnuspe targets, i.e. e500v2 (Debian architecture: powerpcspe)
[1]:

g++ -c -g -O2 -fdebug-prefix-map=/<>/qt4-x11-4.8.7+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=gnu++98 -I/usr/include/freetype2 -pthread
-I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnuspe/glib-2.0/include -O2
-fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC
-DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU
-DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include
-I../../include/QtCore -I.rcc/release-shared -Iglobal -I../../tools/shared
-I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4
-I.moc/release-shared -o .obj/release-shared/qtextboundaryfinder.o
tools/qtextboundaryfinder.cpp
tools/qtextboundaryfinder.cpp: In member function 'bool
QTextBoundaryFinder::isAtBoundary() const':
tools/qtextboundaryfinder.cpp:444:1: internal compiler error: in
validate_condition_mode, at config/rs6000/rs6000.c:17958
 }
 ^
0x109c5aab validate_condition_mode(rtx_code, machine_mode)
../../src/gcc/config/rs6000/rs6000.c:17957
0x10b438df branch_comparison_operator(rtx_def*, machine_mode)
../../src/gcc/config/rs6000/predicates.md:1125
0x10b43b13 branch_positive_comparison_operator(rtx_def*, machine_mode)
../../src/gcc/config/rs6000/predicates.md:1204
0x10b5bad7 recog_72
../../src/gcc/config/rs6000/altivec.md:643
0x10bb7f3b recog_for_combine_1
../../src/gcc/combine.c:10945
0x10bbd4ff recog_for_combine
../../src/gcc/combine.c:11142
0x10bcb0c7 try_combine
../../src/gcc/combine.c:3503
0x10bcec7f combine_instructions
../../src/gcc/combine.c:1475
0x10bcec7f rest_of_handle_combine
../../src/gcc/combine.c:14356
0x10bcec7f execute
../../src/gcc/combine.c:14399
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
g++ -c -g -O2 -fdebug-prefix-map=/<>/qt4-x11-4.8.7+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=gnu++98 -I/usr/include/freetype2 -pthread
-I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnuspe/glib-2.0/include -O2
-fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC
-DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU
-DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include
-I../../include/QtCore -I.rcc/release-shared -Iglobal -I../../tools/shared
-I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4
-I.moc/release-shared -o .obj/release-shared/qtimeline.o tools/qtimeline.cpp
g++ -c -g -O2 -fdebug-prefix-map=/<>/qt4-x11-4.8.7+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -std=gnu++98 -I/usr/include/freetype2 -pthread
-I/usr/include/glib-2.0 -I/usr/lib/powerpc-linux-gnuspe/glib-2.0/include -O2
-fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -D_REENTRANT -fPIC
-DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII
-DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER
-DELF_INTERPRETER=\"/lib/ld.so.1\" -DQLIBRARYINFO_EPOCROOT -DQT_USE_ICU
-DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE
-D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. -I../../include
-I../../include/QtCore -I.rcc/release-shared -Iglobal -I../../tools/shared
-I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4
-I.moc/release-shared -o .obj/release-shared/qvector.o tools/qvector.cpp
Preprocessed source stored into /tmp/ccg5tpbm.out file, please attach this to
your bugreport.

I'm attaching the pre-processed source in case that might be useful. Odd that
despite this bug being so old, it just surfaced on Debian powerpcspe recently.

Thanks,
Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=qt4-x11=powerpcspe=4%3A4.8.7%2Bdfsg-9=1476330034

Re: PING [PATCH] accept flexible arrays in struct in unions (c++/71912 - [6/7 regression])

[Martin Sebor]

On 10/12/2016 07:43 AM, Jason Merrill wrote:

On Tue, Oct 11, 2016 at 9:45 PM, Martin Sebor  wrote:

Are there any other changes you want me to make to the patch?
I leave this weekend for the WG14 meeting and would like to
get this change finalized and hopefully committed before then.

  https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00410.html


OK, thanks.  Sorry I overlooked your earlier mail.


I forgot to also request approval to backport it to the 6 branch.
Are you fine with that as well?

Thanks
Martin

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Markus Trippelsdorf from comment #9)
> Is subtracting undefined, too?
Yes.  Comparing two unrelated arrays or subtracting them is undefined.

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from Markus Trippelsdorf  ---
Is subtracting undefined, too?

-   for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
+   for (b_fw = __start_builtin_fw;  __end_builtin_fw - b_fw; b_fw++) {

gcc-6-20161013 is now available

[gccadmin]

Snapshot gcc-6-20161013 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20161013/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch 
revision 241143

You'll find:

 gcc-6-20161013.tar.bz2   Complete GCC

  MD5=7a743b8da784e21a8ddec70b66f6705c
  SHA1=02de76f527e2a09222f901830ccabd414df95a8b

Diffs from 6-20161006 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug fortran/69566] Failure of SELECT TYPE with unlimited polymorphic function result

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
Beware of pr30617 in the test in comment 4! Otherwise the patch seems to work
as expected.

Thanks,

Dominique

> Le 13 oct. 2016 à 16:14, pault at gcc dot gnu.org  
> a écrit :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566
> 
> --- Comment #5 from Paul Thomas  ---
> Created attachment 39805
>  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39805=edit
> Fix for the PR
> 
> The attached fixes the testcase in the comment and more besides. I think that
> some of the fix is unnecessary. I will do final adjustments once I am back at
> base.
> 
> It bootstraps and regtests on FC23/x87_64
> 
> Paul
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/71912] [6 regression] flexible array in struct in union rejected

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|[6/7 regression] flexible   |[6 regression] flexible
   |array in struct in union|array in struct in union
   |rejected|rejected
  Known to fail|7.0 |

--- Comment #8 from Martin Sebor  ---
Fixed on trunk in r241143.

[Bug c++/71912] [6/7 regression] flexible array in struct in union rejected

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Thu Oct 13 22:26:36 2016
New Revision: 241143

URL: https://gcc.gnu.org/viewcvs?rev=241143=gcc=rev
Log:
PR c++/71912 - [6/7 regression] flexible array in struct in union rejected

gcc/cp/ChangeLog:

PR c++/71912
* class.c (struct flexmems_t):  Add members.
(find_flexarrays): Add arguments.  Correct handling of anonymous
structs.
(diagnose_flexarrays): Adjust to issue warnings in addition to errors.
(check_flexarrays): Add argument.
(diagnose_invalid_flexarray): New functions.

gcc/testsuite/ChangeLog:

PR c++/71912
* g++.dg/ext/flexary4.C: Adjust.
* g++.dg/ext/flexary5.C: Same.
* g++.dg/ext/flexary9.C: Same.
* g++.dg/ext/flexary19.C: New test.
* g++.dg/ext/flexary18.C: New test.
* g++.dg/torture/pr64312.C: Add a dg-error directive to an ill-formed
regression test.
* g++.dg/compat/struct-layout-1_generate.c (subfield): Add argument.
Avoid generating a flexible array member in an array.


Added:
trunk/gcc/testsuite/g++.dg/ext/flexary18.C
trunk/gcc/testsuite/g++.dg/ext/flexary19.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c
trunk/gcc/testsuite/g++.dg/ext/flexary4.C
trunk/gcc/testsuite/g++.dg/ext/flexary5.C
trunk/gcc/testsuite/g++.dg/ext/flexary9.C
trunk/gcc/testsuite/g++.dg/torture/pr64312.C

Re: Questionable code in gcov-io.c

[Andrew Pinski]

On Wed, Oct 12, 2016 at 11:24 AM, Nathan Sidwell  wrote:
> On 10/12/16 11:04, Andreas Schwab wrote:
>
>> Do we still need to call fstat?  I don't think it can ever fail here.
>
>
> Update removing the fstat.  Survived a profiled bootstrap, so I'll commit
> tomorrow, unless there are further comments.  Thanks for spotting this!


This breaks the build for aarch64-elf:

In file included from
/home/jenkins/workspace/BuildToolchainAARCH64_thunder_elf_upstream/toolchain/scripts/../src/libgcc/libgcov-driver.c:53:0:
/home/jenkins/workspace/BuildToolchainAARCH64_thunder_elf_upstream/toolchain/scripts/../src/libgcc/../gcc/gcov-io.c:
In function ‘__gcov_open’:
/home/jenkins/workspace/BuildToolchainAARCH64_thunder_elf_upstream/toolchain/scripts/../src/libgcc/../gcc/gcov-io.c:184:10:
error: assignment of read-only variable ‘mode’
 mode = 1;
  ^

Thanks,
Andrew


>
> nathan
>
>

[Bug fortran/68040] [5/6/7 Regression] Internal compiler error: Error reporting routines re-entered.

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
related to/duplicate of pr77972?

[Bug fortran/77972] ICE on broken character continuation with -Wall etc.

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
related to/duplicate of pr68040?

Re: [PATCH] Remove x86 pcommit instruction

[H.J. Lu]

On Thu, Oct 13, 2016 at 5:09 AM, Andrew Senkevich
 wrote:
> 2016-10-11 20:09 GMT+03:00 H.J. Lu :
>> On Tue, Oct 11, 2016 at 10:04 AM, Andrew Senkevich
>>  wrote:
>>> 2016-10-06 1:07 GMT+03:00 H.J. Lu :
 On Wed, Oct 5, 2016 at 1:42 PM, Andrew Senkevich
  wrote:
> 2016-10-05 18:06 GMT+03:00 Uros Bizjak :
>> On Wed, Oct 5, 2016 at 3:47 PM, Andrew Senkevich
>>  wrote:
 -mpcommit
 -Target Report Mask(ISA_PCOMMIT) Var(ix86_isa_flags) Save
 -Support PCOMMIT instruction.
 -

 You should not simply delete a option that was in the released
 compiler, but a warning should be emitted instead. Please see how
 msse5 is handled in i386.opt.
>>>
>>> Thank you, it is fixed in patch below. Ok for trunk?
>>
>> OK.
>>
>>> Is it subject for backport for 5.* and 6.* releases?
>>
>> Yes, but please wait a couple of days if any problem arises in trunk.
>>
>> (Please also provide an entry for Release Changes, since this is
>> user-facing change. Also for release branches.)
>
> Hi HJ,
>
> could you please commit this patch for trunk since I have no commit 
> rights.
> Attached in format for git am.
>
>

 Done.
>>>
>>> Thanks, HJ!
>>>
>>> Should I ask you or somebody else for backports for to 5.* and 6.* or
>>> may be I can somehow get commit after approval rights to don't disturb
>>> others with commits? I am preparing several patches.
>>>
>>
>> Please provide patches for GCC 5 and 6.
>
> Attached.

I checked them into GCC 5 and GCC 6 branches.

> Have you possibility to update according changes.html files?
>

Here is the patch for GCC 7.  I am not sure what to do with GCC
5 and 6.

-- 
H.J.
---
Index: gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.18
diff -u -p -r1.18 changes.html
--- gcc-7/changes.html 12 Oct 2016 11:08:25 - 1.18
+++ gcc-7/changes.html 13 Oct 2016 21:37:18 -
@@ -318,7 +318,14 @@ const int* get_address (unsigned idx)

 

-
+IA-32/x86-64
+   
+ 
+   Support for
+   https://software.intel.com/en-us/blogs/2016/09/12/deprecate-pcommit-instruction;>deprecated
+   pcommit instruction has been removed.
+ 
+   

 

[Bug sanitizer/59962] --with-build-config=bootstrap-asan doesn't work

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Does this work now?

[Bug debug/52472] ICE: in convert_debug_memory_address, at cfgexpand.c:2491

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #10 from Andrew Pinski  ---
Fixed over 2 years ago but forgot to close.

[Bug c++/77976] `auto x = type{…}` initialization syntax rejects `explicit` user-defined conversion

[tomaszkam at gmail dot com]

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

Tomasz Kamiński  changed:

   What|Removed |Added

 CC||tomaszkam at gmail dot com

--- Comment #1 from Tomasz Kamiński  ---
Duplicate of: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63999

[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails

[tulipawn at gmail dot com]

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

--- Comment #10 from PeteVine  ---
Yeah, I began suspecting as much yesterday so I left it running overnight on
ARM. It managed to get to stage comparison but failed due to many differences.

But not before I'd got impatient in the morning and did a start/stop switching
the linker back to gold, probably my fault :)

Re: [PATCH, libfortran] PR 48587 Newunit allocator

[Dominique d'Humières]

With the patch, the following code

integer :: i, j
i = -10
write(unit=i,fmt=*, iostat=j) 10
print *, j
end

fails at run time with

Assertion failed: (ind >= 0 && ind < newunit_size), function newunit_free, file 
../../../work/libgfortran/io/unit.c, line 966.

Without the patch the output is 5002.

TIA

Dominique

[Bug tree-optimization/64567] missed optimization: redundant test before clearing bit(s)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #3 from Andrew Pinski  ---
(In reply to Rasmus Villemoes from comment #2)
> (In reply to Andreas Schwab from comment #1)
> > This transformation is incorrect if the lvalue may be pointing to a
> > read-only object.
> 
> True. And one may also incur an extra cache penalty if the cache line
> containing foo was already held shared but not exclusive.

Or incorrect due to C11/C++11 memory model.  Anyways it is correct for scalar
auto variables and this should be transformed at the gimple level if not
already.

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #7)
> You don't need it for both.
>   struct builtin_fw *b_fw = __start_builtin_fw;
>   asm ("" : "+r" (b_fw));
>   for (; b_fw != __end_builtin_fw; b_fw++) {
> should be enough.  And indeed, without that it is undefined behavior.

You might want to do end only then instead of the start.  Because in theory GCC
could say it is always false as &__end_builtin_fw[-1] is undefined behavior too
so GCC say if the initial value was not __end_builtin_fw[0] go into an infinite
loop.

Re: [PATCH] Allow `make tags` to work from top-level directory

[Eric Gallager]

On 10/13/16, Jeff Law  wrote:
> On 10/06/2016 07:21 AM, Eric Gallager wrote:
>> The libdecnumber, libgcc, and libobjc subdirectories are missing TAGS
>> targets in their Makefiles. The attached patch causes them to be
>> skipped when running `make tags`.
>>
>> ChangeLog entry:
>>
>> 2016-10-06  Eric Gallager  
>>
>>  * Makefile.def: Mark libdecnumber, libgcc, and libobjc as missing
>>  TAGS target.
>>  * Makefile.in: Regenerate.
>>
> OK.  Please install.
>
> Thanks,
> Jeff
>


I'm still waiting to hear back from  about my request
for copyright assignment, which I'll need to get sorted out before I
can start committing stuff (like this patch).

Thanks,
Eric

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
You don't need it for both.
  struct builtin_fw *b_fw = __start_builtin_fw;
  asm ("" : "+r" (b_fw));
  for (; b_fw != __end_builtin_fw; b_fw++) {
should be enough.  And indeed, without that it is undefined behavior.

[Bug bootstrap/77962] [7 Regression] Bootstrap failure on x86_64-linux starting with r241063

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
*** Bug 77977 has been marked as a duplicate of this bug. ***

[Bug go/77977] stage3 bootstrap error in libgo on x86_64: cannot stat 'stubs.o'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Jakub Jelinek  ---
Yeah.

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

[Bug go/77977] stage3 bootstrap error in libgo on x86_64: cannot stat 'stubs.o'

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #1 from Ian Lance Taylor  ---
Jakub, did you figure anything out about this?

Re: [PATCH v4] PR48344: Fix unrecognizable insn error with -fstack-limit-register=r2

[Andreas Schwab]

I've committed this to fix the ICE.

Andreas.

* config/m68k/m68k.c (m68k_option_override): Check
opt_fstack_limit_symbol_arg and opt_fstack_limit_register_no
instead of stack_limit_rtx.

* gcc.target/m68k/stack-limit-1.c: Expect warning on line 0.

diff --git a/gcc/config/m68k/m68k.c b/gcc/config/m68k/m68k.c
index e6bcfa0caf..a883e42514 100644
--- a/gcc/config/m68k/m68k.c
+++ b/gcc/config/m68k/m68k.c
@@ -638,10 +638,12 @@ m68k_option_override (void)
 }
 #endif
 
-  if (stack_limit_rtx != NULL_RTX && !TARGET_68020)
+  if ((opt_fstack_limit_symbol_arg != NULL || opt_fstack_limit_register_no >= 
0)
+  && !TARGET_68020)
 {
   warning (0, "-fstack-limit- options are not supported on this cpu");
-  stack_limit_rtx = NULL_RTX;
+  opt_fstack_limit_symbol_arg = NULL;
+  opt_fstack_limit_register_no = -1;
 }
 
   SUBTARGET_OVERRIDE_OPTIONS;
diff --git a/gcc/testsuite/gcc.target/m68k/stack-limit-1.c 
b/gcc/testsuite/gcc.target/m68k/stack-limit-1.c
index b1e9b99b26..5086edd77f 100644
--- a/gcc/testsuite/gcc.target/m68k/stack-limit-1.c
+++ b/gcc/testsuite/gcc.target/m68k/stack-limit-1.c
@@ -1,6 +1,6 @@
 /* -fstack-limit- should be ignored without an ICE if not supported.  */
 /* { dg-do compile } */
 /* { dg-options "-fstack-limit-symbol=_stack_limit -m68000" } */
-/* { dg-warning "not supported" "" { target *-*-* } 1 } */
+/* { dg-warning "not supported" "" { target *-*-* } 0 } */
 
 void dummy (void) { }
-- 
2.10.1


-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: bootstrap possibly broken on trunk ?

[Martin Sebor]

On 10/13/2016 11:42 AM, Prathamesh Kulkarni wrote:

Hi,
I am getting the following error when bootstrapping trunk (tried with r241108)
on x86_64-unknown-linux-gnu during stage-1:

../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:12:
error: ISO C++ forbids declaration of \u2018_Bind_simple_helper\u2019
with no type [-fpermissive]
   template _Bind_simple_helper>::__type __bind_simple(void (thread::*&&)(),
reference_wrapper&&);
^~~
../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:12:
error: \u2018_Bind_simple_helper\u2019 is not a template function
../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:31:
error: expected \u2018;\u2019 before \u2018<\u2019 token
   template _Bind_simple_helper>::__type __bind_simple(void (thread::*&&)(),
reference_wrapper&&);

Could someone please confirm this for me ?


I don't see this at r241131 but I just raised bug 77977 for a stage3
bootstrap error in libgo on x86_64: cannot stat 'stubs.o'

Martin

Re: PR35503 - warn for restrict pointer

[Prathamesh Kulkarni]

On 7 October 2016 at 10:33, Prathamesh Kulkarni
 wrote:
> On 22 September 2016 at 23:15, Joseph Myers  wrote:
>> On Thu, 22 Sep 2016, Prathamesh Kulkarni wrote:
>>
>>> Would that be acceptable ? I am not sure how to make %Z check if the
>>> argument has type vec *
>>> since vec is not really a builtin C type.
>>> Could you suggest me a better solution so that the format checker will check
>>> if arg has type vec * instead of checking if it's just a pointer ?
>>> Also for testing, should I create a testcase in g++.dg since
>>> gcc.dg/format/ tests are C-only ?
>>
>> If it's C++-only then it would need to be in g++.dg.
>>
>> The way we handle GCC-specific types in checking these formats is that the
>> code using these formats has to define typedefs which the format-checking
>> code then looks up.  In most cases it can just look up names like
>> location_t or tree, but for HOST_WIDE_INT it looks up
>> __gcc_host_wide_int__ which the user must have defined as a typedef.
>> Probably that's the way to go in this case: the user must do "typedef
>> vec __gcc_vec_int__;" or similar, and the code looks up
>> __gcc_vec_int__.
> Thanks for the suggestions. To keep it simple, instead of vec,
> I made %Z take two args: int *v, unsigned len, and prints elements in
> v having length == len.
> Is that OK ?
>
> Bootstrapped+tested on x86_64-unknown-linux-gnu.
> As pointed out earlier in the thread, the patch can give false positives 
> because
> it only checks whether parameters are qualified with restrict, not how
> parameters
> are used inside the function. For instance it warned for example 10
> mentioned in n1570
> under section 6.7.3.1 - "Formal definition of restrict".
> Should we keep the warning in Wall or keep it in Wextra ?
> The attached patch enables it with Wall.
Ping for c, c-family changes:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00446.html

Thanks,
Prathamesh
>
> Thanks,
> Prathamesh
>>
>> --
>> Joseph S. Myers
>> jos...@codesourcery.com

Re: [PATCH, libfortran] PR 48587 Newunit allocator

[Jerry DeLisle]

On 10/13/2016 08:16 AM, Janne Blomqvist wrote:

Currently GFortran newer reuses unit numbers allocated with NEWUNIT=,
instead having a simple counter that is decremented each time such a
unit is opened.  For a long running program which repeatedly opens
files with NEWUNIT= and closes them, the counter can wrap around and
cause an abort.  This patch replaces the counter with an allocator
that keeps track of which units numbers are allocated, and can reuse
them once they have been deallocated.  Since operating systems tend to
limit the number of simultaneous open files for a process to a
relatively modest number, a relatively simple approach with a linear
scan through an array suffices.  Though as a small optimization there
is a low water indicator keeping track of the index for which all unit
numbers below are already allocated.  This linear scan also ensures
that we always allocate the smallest available unit number.

2016-10-13  Janne Blomqvist  

PR libfortran/48587
* io/io.h (get_unique_unit_number): Remove prototype.
(newunit_alloc): New prototype.
* io/open.c (st_open): Call newunit_alloc.
* io/unit.c (newunits,newunit_size,newunit_lwi): New static
variables.
(GFC_FIRST_NEWUNIT): Rename to NEWUNIT_START.
(next_available_newunit): Remove variable.
(get_unit): Call newunit_alloc.
(close_unit_1): Call newunit_free.
(close_units): Free newunits array.
(get_unique_number): Remove function.
(newunit_alloc): New function.
(newunit_free): New function.

Regtested on x86_64-pc-linux-gnu. Ok for trunk?



Yes, OK, clever! Thanks!

Jerry

[Bug go/77977] New: stage3 bootstrap error in libgo on x86_64: cannot stat 'stubs.o'

[msebor at gcc dot gnu.org]

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

Bug ID: 77977
   Summary: stage3 bootstrap error in libgo on x86_64: cannot stat
'stubs.o'
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: msebor at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

When configured with
--enable-languages=all,ada,c,c++,fortran,go,lto,objc,obj-c++ today's top of
trunk (at r241131) fails to bootstrap on x86_64-linux with the error below. 
There is no other error earlier that I can see (this was a serial build, i.e.,
with -j1).

make[8]: Entering directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/32/libgo'
/usr/bin/mkdir -p runtime/internal; files=`echo
/src/gcc/trunk/libgo/go/runtime/internal/atomic/gccgo.go
/src/gcc/trunk/libgo/go/runtime/internal/atomic/stubs.go | sed -e 's/[^
]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile
/home/msebor/build/gcc-trunk/./gcc/gccgo -B/home/msebor/build/gcc-trunk/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -minline-all-stringops
-fno-split-stack -O2 -g  -m32 -I . -c -fgo-pkgpath=`echo
runtime/internal/atomic.lo | sed -e 's/.lo$//' -e 's/-go$//'`
-fgo-compiling-runtime -o runtime/internal/atomic.lo $files
libtool: compile:  /home/msebor/build/gcc-trunk/./gcc/gccgo
-B/home/msebor/build/gcc-trunk/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -minline-all-stringops
-fno-split-stack -O2 -g -m32 -I . -c -fgo-pkgpath=runtime/internal/atomic
-fgo-compiling-runtime /src/gcc/trunk/libgo/go/runtime/internal/atomic/gccgo.go
/src/gcc/trunk/libgo/go/runtime/internal/atomic/stubs.go 
libtool: compile: mv -f "stubs.o" "runtime/internal/.libs/atomic.o"
mv: cannot stat 'stubs.o': No such file or directory
Makefile:4942: recipe for target 'runtime/internal/atomic.lo' failed
make[8]: *** [runtime/internal/atomic.lo] Error 1
make[8]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/32/libgo'
Makefile:3039: recipe for target 'all-recursive' failed
make[7]: *** [all-recursive] Error 1
make[7]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/32/libgo'
Makefile:1407: recipe for target 'all' failed
make[6]: *** [all] Error 2
make[6]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/32/libgo'
Makefile:5537: recipe for target 'multi-do' failed
make[5]: *** [multi-do] Error 1
make[5]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/libgo'
Makefile:2305: recipe for target 'all-multi' failed
make[4]: *** [all-multi] Error 2
make[4]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/libgo'
Makefile:3039: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/libgo'
Makefile:1407: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory
'/home/msebor/build/gcc-trunk/x86_64-pc-linux-gnu/libgo'
Makefile:25608: recipe for target 'all-target-libgo' failed
make[1]: *** [all-target-libgo] Error 2
make[1]: Leaving directory '/home/msebor/build/gcc-trunk'
Makefile:29771: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2
make: Leaving directory '/home/msebor/build/gcc-trunk'

Re: [PATCH] Test cases for PR77937

[Rainer Orth]

Hi Bill,

> Here are torture test cases for
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937.  Markus Trippelsdorf
> kindly provided the source for the tests and verified the correct
> dejagnu options on x86_64-pc-linux-gnu.  Committed.
>
> Thanks,
> Bill
>
>
> 2016-10-13  Bill Schmidt  
>
>   PR tree-optimization/77937
>   * gcc.dg/torture/pr77937-1.c: New.
>   * gcc.dg/torture/pr77937-2.c: New.
>
>
> Index: gcc/testsuite/gcc.dg/torture/pr77937-1.c
> ===
> --- gcc/testsuite/gcc.dg/torture/pr77937-1.c  (revision 0)
> +++ gcc/testsuite/gcc.dg/torture/pr77937-1.c  (working copy)
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-do options "-O3 -march=amdfam10" { target { x86_64-*-* } } } */

this can't be right: you always need target { i?86-*-* x86_64-*-* } and
if really need be restrict it to 64-bit only with lp64.  This makes sure
the test is run correctly for multilib x86 configurations
(e.g. i686-pc-linux-gnu with -m64).  Same in the other test.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-10-13
 Ever confirmed|0   |1

--- Comment #9 from Andrew Pinski  ---
.

[Bug bootstrap/77917] ARM/AARCH64 bootstrap-lto fails

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
(In reply to PeteVine from comment #7)
> BTW, I sincerely hope `--with-build-config=bootstrap-lto` is not derailed by
> the presence of `-flto` among environment C(XX)FLAGS, as otherwise it
> definitely makes sense for configure to always sanitize those flags.

With --with-build-config=bootstrap-lto you will not need -flto in C(XX)FLAGS. 
Really -flto in C(XX)FLAGS is the cause of the problem you are running into.

[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
That is change:
extern struct builtin_fw __start_builtin_fw[];
extern struct builtin_fw __end_builtin_fw[];

static bool fw_get_builtin_firmware(struct firmware *fw, const char *name,
void *buf, size_t size)
{
 struct builtin_fw *b_fw;

 for (b_fw = __start_builtin_fw; b_fw != __end_builtin_fw; b_fw++) {
--- CUT --

to (there might already be a macro in linux which does the asm like below
already):

extern struct builtin_fw __start_builtin_fw[];
extern struct builtin_fw __end_builtin_fw[];

static bool fw_get_builtin_firmware(struct firmware *fw, const char *name,
void *buf, size_t size)
{
 struct builtin_fw *b_fw;
 struct builtin_fw *b_fw_start = __start_builtin_fw, b_fw_end =
__end_builtin_fw;
 asm("":"+r"(b_fw_start));
 asm("":"+r"(b_fw_end));


 for (b_fw = b_fw_start; b_fw != b_fw_end; b_fw++) {

[PATCH] Test cases for PR77937

[Bill Schmidt]

Here are torture test cases for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77937.  Markus Trippelsdorf
kindly provided the source for the tests and verified the correct
dejagnu options on x86_64-pc-linux-gnu.  Committed.

Thanks,
Bill


2016-10-13  Bill Schmidt  

PR tree-optimization/77937
* gcc.dg/torture/pr77937-1.c: New.
* gcc.dg/torture/pr77937-2.c: New.


Index: gcc/testsuite/gcc.dg/torture/pr77937-1.c
===
--- gcc/testsuite/gcc.dg/torture/pr77937-1.c(revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr77937-1.c(working copy)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-do options "-O3 -march=amdfam10" { target { x86_64-*-* } } } */
+
+int *a;
+int b, c, d;
+void fn1(char *p1, int p2) {
+  int x;
+  while (1) {
+x = 0;
+for (; x < 8; x++)
+  p1[0] = -a[0] * d + p1[0] * c + 1 >> b >> 1;
+p1 += p2;
+  }
+}
Index: gcc/testsuite/gcc.dg/torture/pr77937-2.c
===
--- gcc/testsuite/gcc.dg/torture/pr77937-2.c(revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr77937-2.c(working copy)
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-do options "-O3 -march=amdfam10" { target { x86_64-*-* } } } */
+
+extern int fn2(int);
+extern int fn3(int);
+int a, b, c;
+void fn1(long p1) {
+  char *d;
+  for (;; d += p1) {
+d[0] = fn2(1 >> a);
+fn3(0);
+fn3(c >> a);
+d[1] = fn3(d[1] * b + c >> a);
+d[4] = fn3(d[4] * b + c >> a);
+d[5] = fn3(d[5] * b + c >> a);
+  }
+}

[Bug tree-optimization/77937] [7 Regression] ICE: in replace_one_candidate, at gimple-ssa-strength-reduction.c:3370

[wschmidt at gcc dot gnu.org]

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

--- Comment #13 from Bill Schmidt  ---
Author: wschmidt
Date: Thu Oct 13 19:50:41 2016
New Revision: 241139

URL: https://gcc.gnu.org/viewcvs?rev=241139=gcc=rev
Log:
2016-10-13  Bill Schmidt  

PR tree-optimization/77937
* gcc.dg/torture/pr77937-1.c: New.
* gcc.dg/torture/pr77937-2.c: New.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77937-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr77937-2.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/77975] [6/7 Regression] Missed optimization for some small constants

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c   |tree-optimization
   Target Milestone|--- |6.3
Summary|[6 / 7 Regression] Missed   |[6/7 Regression] Missed
   |optimization for some small |optimization for some small
   |constants   |constants

[Bug target/77974] m68k bootstrap failure due to -Werror=implicit-fallthrough

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Nice.  Will you commit the patch?  Thanks.

[Bug c/77975] New: [6 / 7 Regression] Missed optimization for some small constants

[quiath at go2 dot pl]

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

Bug ID: 77975
   Summary: [6 / 7 Regression] Missed optimization for some small
constants
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: quiath at go2 dot pl
  Target Milestone: ---

When compiling with GCC 6.1, 6.2 or 7.0 the code generated with -O1 -O2 and -O3
does not fold depending on some small constants e.g. 3 used in the body of the
function. GCC 5.4 was better.

Example code:

// missed optimization, compiled to a loop
unsigned int f3() {
  unsigned int a = 3;
  while (a) {
a >>= 1;
  }
  return a; 
}

// expected optimization, compiled to a single instruction
unsigned int f7() {
  unsigned int a = 7;
  while (a) {
a >>= 1;
  }
  return a; 
}

x86-64 assembly from gcc 7 (identical for 6) according to godbolt.org
Note that f7 is folded while f3 is not.

f3():
mov eax, 3
.L2:
shr eax
jne .L2
mov eax, 0
ret
f7():
mov eax, 0
ret

See also example here: https://godbolt.org/g/ircKQ0

[Bug target/77974] m68k bootstrap failure due to -Werror=implicit-fallthrough

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
I think this is intented:

diff --git a/gcc/config/m68k/m68k.c b/gcc/config/m68k/m68k.c
index a104193c23..0eb1528079 100644
--- a/gcc/config/m68k/m68k.c
+++ b/gcc/config/m68k/m68k.c
@@ -4546,6 +4546,7 @@ m68k_get_reloc_decoration (enum m68k_reloc reloc)
  return "";
}
}
+ return "";
}

 case RELOC_TLSGD:

Re: bootstrap possibly broken on trunk ?

[Christophe Lyon]

On 13 October 2016 at 20:30, Prathamesh Kulkarni
 wrote:
> On 13 October 2016 at 23:12, Prathamesh Kulkarni
>  wrote:
>> Hi,
>> I am getting the following error when bootstrapping trunk (tried with 
>> r241108)
>> on x86_64-unknown-linux-gnu during stage-1:
>>
>> ../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:12:
>> error: ISO C++ forbids declaration of \u2018_Bind_simple_helper\u2019
>> with no type [-fpermissive]
>>template _Bind_simple_helper> reference_wrapper>::__type __bind_simple(void (thread::*&&)(),
>> reference_wrapper&&);
>> ^~~
>> ../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:12:
>> error: \u2018_Bind_simple_helper\u2019 is not a template function
>> ../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:31:
>> error: expected \u2018;\u2019 before \u2018<\u2019 token
>>template _Bind_simple_helper> reference_wrapper>::__type __bind_simple(void (thread::*&&)(),
>> reference_wrapper&&);
>>
>> Could someone please confirm this for me ?
> Goes away after I updated trunk to r241132.
>

Indeed it was broken at r241093, and fixed at r24.

I'm not testing bootstrap, but cross-builds can catch already
catch most mistakes. Too bad I do not have more
bandwidth in our compute farm :-)

If you have subscribed to tcwg-validat...@linaro.org (Linaro internal only),
you should have received emails when builds failed.

Or you can have a look at:
http://people.linaro.org/~christophe.lyon/cross-validation/gcc-build/trunk/

these are the status of build-only jobs for a subset of our arm*/aarch64*
configurations.

Christophe


> Thanks,
> Prathamesh
>>
>> Thanks,
>> Prathamesh

[v3] Remove 'test' variables from a few more testsuite dirs

[Paolo Carlini]

Hi,

nothing especially interesting here... Tested x86_64-linux.

Thanks, Paolo.

//

2016-10-13  Paolo Carlini  

* testsuite/24_iterators/container_access.cc: Remove 'test' variables.
* testsuite/24_iterators/istream_iterator/2.cc: Likewise.
* testsuite/24_iterators/istreambuf_iterator/2.cc: Likewise.
* testsuite/24_iterators/istreambuf_iterator/2627.cc: Likewise.
* testsuite/24_iterators/operations/next.cc: Likewise.
* testsuite/24_iterators/operations/prev.cc: Likewise.
* testsuite/24_iterators/ostreambuf_iterator/2.cc: Likewise.
* testsuite/24_iterators/random_access_iterator/26020.cc: Likewise.
* testsuite/24_iterators/range_access_cpp14.cc: Likewise.
* testsuite/24_iterators/reverse_iterator/11729.cc: Likewise.
* testsuite/24_iterators/reverse_iterator/3.cc: Likewise.
* testsuite/25_algorithms/adjacent_find/vectorbool.cc: Likewise.
* testsuite/25_algorithms/all_of/1.cc: Likewise.
* testsuite/25_algorithms/any_of/1.cc: Likewise.
* testsuite/25_algorithms/binary_search/2.cc: Likewise.
* testsuite/25_algorithms/binary_search/partitioned.cc: Likewise.
* testsuite/25_algorithms/clamp/1.cc: Likewise.
* testsuite/25_algorithms/clamp/2.cc: Likewise.
* testsuite/25_algorithms/copy/1.cc: Likewise.
* testsuite/25_algorithms/copy/2.cc: Likewise.
* testsuite/25_algorithms/copy/3.cc: Likewise.
* testsuite/25_algorithms/copy/34595.cc: Likewise.
* testsuite/25_algorithms/copy/4.cc: Likewise.
* testsuite/25_algorithms/copy/deque_iterators/1.cc: Likewise.
* testsuite/25_algorithms/copy/move_iterators/1.cc: Likewise.
* testsuite/25_algorithms/copy/streambuf_iterators/char/1.cc: Likewise.
* testsuite/25_algorithms/copy/streambuf_iterators/char/2.cc: Likewise.
* testsuite/25_algorithms/copy/streambuf_iterators/char/3.cc: Likewise.
* testsuite/25_algorithms/copy/streambuf_iterators/char/4.cc: Likewise.
* testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/1.cc:
Likewise.
* testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/2.cc:
Likewise.
* testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/3.cc:
Likewise.
* testsuite/25_algorithms/copy/streambuf_iterators/wchar_t/4.cc:
Likewise.
* testsuite/25_algorithms/copy_backward/deque_iterators/1.cc: Likewise.
* testsuite/25_algorithms/copy_backward/move_iterators/1.cc: Likewise.
* testsuite/25_algorithms/copy_n/1.cc: Likewise.
* testsuite/25_algorithms/copy_n/2.cc: Likewise.
* testsuite/25_algorithms/copy_n/3.cc: Likewise.
* testsuite/25_algorithms/copy_n/4.cc: Likewise.
* testsuite/25_algorithms/copy_n/50119.cc: Likewise.
* testsuite/25_algorithms/copy_n/move_iterators/1.cc: Likewise.
* testsuite/25_algorithms/equal_range/2.cc: Likewise.
* testsuite/25_algorithms/equal_range/partitioned.cc: Likewise.
* testsuite/25_algorithms/fill/1.cc: Likewise.
* testsuite/25_algorithms/fill/2.cc: Likewise.
* testsuite/25_algorithms/fill/3.cc: Likewise.
* testsuite/25_algorithms/fill/4.cc: Likewise.
* testsuite/25_algorithms/fill_n/1.cc: Likewise.
* testsuite/25_algorithms/find/39546.cc: Likewise.
* testsuite/25_algorithms/find/istreambuf_iterators/char/1.cc: Likewise.
* testsuite/25_algorithms/find/istreambuf_iterators/char/2.cc: Likewise.
* testsuite/25_algorithms/find/istreambuf_iterators/wchar_t/1.cc:
Likewise.
* testsuite/25_algorithms/find/istreambuf_iterators/wchar_t/2.cc:
Likewise.
* testsuite/25_algorithms/find_if/1.cc: Likewise.
* testsuite/25_algorithms/find_if_not/1.cc: Likewise.
* testsuite/25_algorithms/for_each/1.cc: Likewise.
* testsuite/25_algorithms/heap/1.cc: Likewise.
* testsuite/25_algorithms/heap/moveable.cc: Likewise.
* testsuite/25_algorithms/heap/moveable2.cc: Likewise.
* testsuite/25_algorithms/heap/vectorbool.cc: Likewise.
* testsuite/25_algorithms/includes/1.cc: Likewise.
* testsuite/25_algorithms/inplace_merge/1.cc: Likewise.
* testsuite/25_algorithms/inplace_merge/49559.cc: Likewise.
* testsuite/25_algorithms/inplace_merge/moveable.cc: Likewise.
* testsuite/25_algorithms/inplace_merge/moveable2.cc: Likewise.
* testsuite/25_algorithms/is_heap/1.cc: Likewise.
* testsuite/25_algorithms/is_heap_until/1.cc: Likewise.
* testsuite/25_algorithms/is_partitioned/1.cc: Likewise.
* testsuite/25_algorithms/is_permutation/1.cc: Likewise.
* testsuite/25_algorithms/is_permutation/2.cc: Likewise.
* testsuite/25_algorithms/is_permutation/vectorbool.cc: Likewise.
* testsuite/25_algorithms/is_sorted/1.cc: 

Re: [C++ PATCH] RFC: implement P0386R2 - C++17 inline variables

[Jason Merrill]

On Tue, Oct 11, 2016 at 9:39 AM, Jakub Jelinek  wrote:
> Here is an attempt to implement C++17 inline variables.
> Bootstrapped/regtested on x86_64-linux and i686-linux.
>
> The main question is if the inline variables, which are vague linkage,
> should be !DECL_EXTERNAL or DECL_EXTERNAL DECL_NOT_REALLY_EXTERN while
> in the FE.  In the patch, they are !DECL_EXTERNAL, except for inline
> static data members in instantiated templates.  As the inline-var3.C
> testcase shows, even if they are !DECL_EXTERNAL (except for the instantiated
> static data members), even at -O0 we do not actually emit them unless
> odr-used, so to some extent I don't see the point in forcing them to
> be DECL_EXTERNAL DECL_NOT_REALLY_EXTERN.

Yeah, I ended up agreeing with you.  There's no need to work hard to
make them work with an obsolete system.  So I've checked in the patch
with a few minor tweaks, attached.

> Another thing is I've noticed (with Jonathan's help to look it up) that
> we aren't implementing DR1511, I'm willing to try to implement that, but
> as it will need to touch the same spots as the patch, I think it should be
> resolved incrementally.

Sounds good.

> Yet another thing are thread_local inline vars.  E.g. on:
> struct S { S (); ~S (); };
> struct T { ~T (); };
> int foo ();
> thread_local inline S s;
> inline thread_local T t;
> inline thread_local int u = foo ();
> it seems both clang++ (~2 months old) and g++ with the patch emits:
> 8 byte TLS _ZGV1{stu] variables
> 1 byte TLS __tls_guard variable
> and _ZTH1[stu] being aliases to __tls_init, which does essentially:
>   if (__tls_guard) return;
>   __tls_guard = 1;
>   if (*(char *)&_ZGV1s == 0) {
> *(char *)&_ZGV1s = 1;
> S::S ();
> __cxa_thread_atexit (S::~S, , &__dso_handle);
>   }
>   if (*(char *)&_ZGV1t == 0) {
> *(char *)&_ZGV1t = 1;
> __cxa_thread_atexit (T::~T, , &__dso_handle);
>   }
>   if (*(char *)&_ZGV1u == 0) {
> *(char *)&_ZGV1u = 1;
> u = foo ();
>   }
> Is that what we want to emit?  At first I doubted this could work properly,
> now thinking about it more, perhaps it can.

I think so; I don't see a reason for inline vars to work differently
from templates here.

> And, do we really want all the
> _ZGV* vars for the TLS inline vars (and other TLS comdats) to be 8 byte,
> even when we are using just a single byte?  Or is it too late to change (ABI
> break)?

Right, the ABI specifies that the guard variable is 8 bytes.  A
comment says, "The intent of specifying an 8-byte structure for the
guard variable, but only describing one byte of its contents, is to
allow flexibility in the implementation of the API above. On systems
with good small lock support, the second word might be used for a
mutex lock. On others, it might identify (as a pointer or index) a
more complex lock structure to use."  This seems unnecessary for
systems with byte atomic instructions, and we might be able to get
away with changing it without breaking any actual usage, but it would
indeed be an ABI change.

> And, as mentioned in the DWARF mailing list, I think we should emit
> DW_AT_inline on the inline vars (both explicit and implicit - static
> constexpr data members in C++17 mode).  I hope that can be done as a
> follow-up.

Makes sense.
diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
index 94af585..06b5aa3 100644
--- a/gcc/c-family/c-cppbuiltin.c
+++ b/gcc/c-family/c-cppbuiltin.c
@@ -935,6 +935,7 @@ c_cpp_builtins (cpp_reader *pfile)
  cpp_define (pfile, "__cpp_constexpr=201603");
  cpp_define (pfile, "__cpp_if_constexpr=201606");
  cpp_define (pfile, "__cpp_capture_star_this=201603");
+ cpp_define (pfile, "__cpp_inline_variables=201606");
}
   if (flag_concepts)
/* Use a value smaller than the 201507 specified in
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 7670162..f761d0d 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -2917,9 +2917,11 @@ redeclaration_error_message (tree newdecl, tree olddecl)
  && !DECL_INITIAL (newdecl))
{
  DECL_EXTERNAL (newdecl) = 1;
- if (warning_at (DECL_SOURCE_LOCATION (newdecl), OPT_Wdeprecated,
- "redundant redeclaration of % static "
- "data member %qD", newdecl))
+ /* For now, only warn with explicit -Wdeprecated.  */
+ if (global_options_set.x_warn_deprecated
+ && warning_at (DECL_SOURCE_LOCATION (newdecl), OPT_Wdeprecated,
+"redundant redeclaration of % static "
+"data member %qD", newdecl))
inform (DECL_SOURCE_LOCATION (olddecl),
"previous declaration of %qD", olddecl);
  return NULL;
@@ -5479,18 +5481,19 @@ maybe_commonize_var (tree decl)
 be merged.  */
  TREE_PUBLIC (decl) = 0;
  DECL_COMMON (decl) = 0;
+ const char *msg;
 

Re: RFC: Split into smaller pieces

[Jonathan Wakely]

On 13/10/16 19:19 +0100, Jonathan Wakely wrote:

On 13/10/16 18:34 +0100, Jonathan Wakely wrote:

Code which doesn't need the whole of  should include the
relevant  header instead.

This means that we don't need to pull the whole of  (and
 and ) into  just because shared_ptr
wants to use reference_wrapper in one place.  This reduces 
from 48kloc to 30kloc!


With a few additional changes to remove  from other
headers we can get:

old  |  new  | Header
--|---|---
47571 | 30449 | memory
49620 | 32498 | thread
49049 | 30861 | condition_variable
49459 | 31271 | shared_mutex
54215 | 37745 | future  75063 | 68509 | regex

Apart from , which is enormous even without , these
are pretty dramatic improvements.


And to show it's not just line-count that changes, here are the
-ftime-report numbers for including each header in an otherwise empty
file, compiled with -O0:

memory:
TOTAL  :   0.66  0.190.8656342 kB
TOTAL  :   0.41  0.090.4940487 kB

thread:
TOTAL  :   0.73  0.150.9063030 kB
TOTAL  :   0.59  0.110.7147508 kB

condition_variable:
TOTAL  :   0.77  0.150.9363641 kB
TOTAL  :   0.50  0.110.6147360 kB

shared_mutex:
TOTAL  :   0.79  0.140.9463985 kB
TOTAL  :   0.50  0.100.6147705 kB

future:
TOTAL  :   1.18  0.201.4092564 kB
TOTAL  :   0.90  0.171.0978584 kB

regex:
TOTAL  :   1.14  0.241.39100089 kB
TOTAL  :   1.04  0.241.3091322 kB

Re: RFC: Split into smaller pieces

[Jonathan Wakely]

Apparently this got spam-filtered and didn't make it to the lists...

On 13/10/16 18:34 +0100, Jonathan Wakely wrote:

This splits the large (2200 lines)  header into smaller
pieces, so there are separate headers for:

- std::less, std::equal_to etc. (already in their own header)
- std::__invoke (already in its own header)
- std::reference_wrapper (often used on its own, e.g. in )
- std::function (using in  and )

Everything else (std::mem_fn, std::bind, std::not_fn, searchers) stays
in , because we don't actually need them elsewhere in the
library.

Code which doesn't need the whole of  should include the
relevant  header instead.

This means that we don't need to pull the whole of  (and
 and ) into  just because shared_ptr
wants to use reference_wrapper in one place.  This reduces 
from 48kloc to 30kloc!

The patch is compressed because it's quite large, but it's mostly just
moving big blocks of code from  into new headers.

Any objections?

* include/Makefile.am: Add  and .
Order alphabetically.
* include/Makefile.in: Regenerate.
* include/bits/refwrap.h: New header.
(_Maybe_get_result_type,_Weak_result_type_impl, _Weak_result_type)
(_Reference_wrapper_base_impl, _Reference_wrapper_base)
(reference_wrapper, ref, cref): Move here from .
* include/bits/shared_ptr_base.h: Include  and
 instead of .
* include/bits/std_function.h: New header.
(_Maybe_unary_or_binary_function, bad_function_call)
(__is_location_invariant, _Nocopy_types, _Any_data)
(_Simple_type_wrapper, _Function_base, _Function_handler, function):
Move here from .
* include/bits/unique_ptr.h: Include .
* include/std/functional: Include new headers and move components to
them.
* include/std/future: Include .
* include/std/memory: Don't include .
* testsuite/20_util/default_delete/48631_neg.cc: Adjust dg-error line.
* testsuite/20_util/default_delete/void_neg.cc: Likewise.
* testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc:
Include .
* testsuite/20_util/shared_ptr/thread/mutex_weaktoshared.cc: Likewise.
* testsuite/20_util/specialized_algorithms/memory_management_tools/
1.cc: Include .
* testsuite/20_util/unique_ptr/assign/48635_neg.cc: Adjust dg-error
lines.
* testsuite/20_util/unique_ptr/assign/cv_qual.cc: Likewise.
* testsuite/20_util/unique_ptr/cons/cv_qual.cc: Likewise.
* testsuite/20_util/unique_ptr/modifiers/cv_qual.cc: Likewise.
* testsuite/30_threads/thread/native_handle/cancel.cc: Include
.

[Bug fortran/77973] [6/7 Regression] ICE in scan_omp_1_op, at omp-low.c:3841

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.4, 5.4.0
   Keywords||ice-on-valid-code, openmp
   Last reconfirmed||2016-10-13
 CC||marxin at gcc dot gnu.org,
   ||mjambor at suse dot cz
 Ever confirmed|0   |1
Summary|ICE in scan_omp_1_op, at|[6/7 Regression] ICE in
   |omp-low.c:3841  |scan_omp_1_op, at
   ||omp-low.c:3841
  Known to fail||6.2.0, 7.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r232549 (HSA branch merge).

[Bug fortran/77972] ICE on broken character continuation with -Wall etc.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-13
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
All compilers I have (4.5.0+) ICE.

[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Created attachment 39806
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39806=edit
Patch to remove special-case for reference_wrapper.

This patch makes it work as desired. We need to fix 3-4 test cases too which
explicitly check for the current behaviour (it's by design, matching
Boost.Function).

I submitted a defect report, with a proposed change to make the copy + move
constructors say "if f’s target is a callable
object passed viaspecialization of reference_wrapper
or a function pointer."

[Bug fortran/77971] ICE at -O0 in make_decl_rtl, at varasm.c:1310

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-10-13
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with GCC 4.6.0.

Re: [PATCH] Allow `make tags` to work from top-level directory

[Jeff Law]

On 10/06/2016 07:21 AM, Eric Gallager wrote:

The libdecnumber, libgcc, and libobjc subdirectories are missing TAGS
targets in their Makefiles. The attached patch causes them to be
skipped when running `make tags`.

ChangeLog entry:

2016-10-06  Eric Gallager  

* Makefile.def: Mark libdecnumber, libgcc, and libobjc as missing
TAGS target.
* Makefile.in: Regenerate.


OK.  Please install.

Thanks,
Jeff

[Bug bootstrap/77974] m68k bootstrap failure due to -Werror=implicit-fallthrough

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
This should fix it, but is the fallthru really intended?

--- a/gcc/config/m68k/m68k.c
+++ b/gcc/config/m68k/m68k.c
@@ -4548,6 +4548,7 @@ m68k_get_reloc_decoration (enum m68k_reloc reloc)
}
}
}
+  /* FALLTHRU */

 case RELOC_TLSGD:
   return "@TLSGD";

Re: [PATCH] Don't peel extra copy of loop in unroller for loops with exit at end

[Jeff Law]

On 09/22/2016 01:10 PM, Pat Haugen wrote:

I noticed the loop unroller peels an extra copy of the loop before it enters 
the switch block code to round the iteration count to a multiple of the unroll 
factor. This peeled copy is only needed for the case where the exit test is at 
the beginning of the loop since in that case it inserts the test for zero peel 
iterations before that peeled copy.

This patch bumps the iteration count by 1 for loops with the exit at the end so 
that it represents the number of times the loop body is executed, and therefore 
removes the need to always execute that first peeled copy. With this change, 
when the number of executions of the loop is an even multiple of the unroll 
factor then the code will jump to the unrolled loop immediately instead of 
executing all the switch code and peeled copies of the loop and then falling 
into the unrolled loop. This change also reduces code size by removing a peeled 
copy of the loop.

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



2016-09-22  Pat Haugen  

* loop-unroll.c (unroll_loop_runtime_iterations): Condition initial
loop peel to loops with exit test at the beginning.



OK.
jeff

[Bug bootstrap/77974] New: m68k bootstrap failure due to -Werror=implicit-fallthrough

[mikpelinux at gmail dot com]

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

Bug ID: 77974
   Summary: m68k bootstrap failure due to
-Werror=implicit-fallthrough
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikpelinux at gmail dot com
  Target Milestone: ---

Attempting to bootstrap gcc-7-20161009 on m68k-linux fails with:

/mnt/scratch/objdir7/./prev-gcc/xg++ -B/mnt/scratch/objdir7/./prev-gcc/
-B/mnt/scratch/install7/m68k-unknown-linux-gnu/bin/ -nostdinc++
-B/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/include/m68k-unknown-linux-gnu
 -I/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/include 
-I/mnt/scratch/gcc-7-20161009/libstdc++-v3/libsupc++
-L/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/mnt/scratch/objdir7/prev-m68k-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -I. -I. -I/mnt/scratch/gcc-7-20161009/gcc
-I/mnt/scratch/gcc-7-20161009/gcc/.
-I/mnt/scratch/gcc-7-20161009/gcc/../include
-I/mnt/scratch/gcc-7-20161009/gcc/../libcpp/include 
-I/mnt/scratch/gcc-7-20161009/gcc/../libdecnumber
-I/mnt/scratch/gcc-7-20161009/gcc/../libdecnumber/dpd -I../libdecnumber
-I/mnt/scratch/gcc-7-20161009/gcc/../libbacktrace   -o m68k.o -MT m68k.o -MMD
-MP -MF ./.deps/m68k.TPo /mnt/scratch/gcc-7-20161009/gcc/config/m68k/m68k.c
/mnt/scratch/gcc-7-20161009/gcc/config/m68k/m68k.c: In function 'const char*
m68k_get_reloc_decoration(m68k_reloc)':
/mnt/scratch/gcc-7-20161009/gcc/config/m68k/m68k.c:4537:4: error: this
statement may fall through [-Werror=implicit-fallthrough]
if (TARGET_68020)
^~
/mnt/scratch/gcc-7-20161009/gcc/config/m68k/m68k.c:4551:5: note: here
 case RELOC_TLSGD:
 ^~~~
cc1plus: all warnings being treated as errors
make[3]: *** [m68k.o] Error 1
make[3]: Leaving directory `/mnt/scratch/objdir7/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir7'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir7'
make: *** [bootstrap] Error 2

I believe gcc-7-20161002 had the same issue.  gcc-7-20160918 bootstrapped fine.

Configuration options:
/mnt/scratch/gcc-7-20161009/configure --prefix=/mnt/scratch/install7
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++
--disable-sjlj-exceptions --disable-libmudflap --disable-plugin --disable-lto
--disable-multilib --disable-libgomp

Re: bootstrap possibly broken on trunk ?

[Prathamesh Kulkarni]

On 13 October 2016 at 23:12, Prathamesh Kulkarni
 wrote:
> Hi,
> I am getting the following error when bootstrapping trunk (tried with r241108)
> on x86_64-unknown-linux-gnu during stage-1:
>
> ../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:12:
> error: ISO C++ forbids declaration of \u2018_Bind_simple_helper\u2019
> with no type [-fpermissive]
>template _Bind_simple_helper reference_wrapper>::__type __bind_simple(void (thread::*&&)(),
> reference_wrapper&&);
> ^~~
> ../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:12:
> error: \u2018_Bind_simple_helper\u2019 is not a template function
> ../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:31:
> error: expected \u2018;\u2019 before \u2018<\u2019 token
>template _Bind_simple_helper reference_wrapper>::__type __bind_simple(void (thread::*&&)(),
> reference_wrapper&&);
>
> Could someone please confirm this for me ?
Goes away after I updated trunk to r241132.

Thanks,
Prathamesh
>
> Thanks,
> Prathamesh

Re: [PATCH] PR68212, Correct frequencies/counts when unrolling

[Jeff Law]

On 09/20/2016 03:27 PM, Pat Haugen wrote:

The following patch corrects frequency/count values computed when generating 
the switch blocks/peeled loop copies before the loop. The two main problem 
areas were for the peeled copies duplicate_loop_to_header_edge was not using 
the preheader frequency as part of the scale factor when peeling a copy of the 
loop to the preheader edge, and the second was that the switch block generation 
was just totally lacking code to compute correct freq/count values. Verified by 
comparing freq/count values in the unroller dump before/after.

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

-Pat



2016-09-20  Pat Haugen  

PR rtl-optimization/68212
* cfgloopmanip.c (duplicate_loop_to_header_edge): Use preheader edge
frequency when computing scale factor for peeled copies.
* loop-unroll.c (unroll_loop_runtime_iterations): Fix freq/count
values for switch/peel blocks/edges.



OK.  Thanks for your patience.

Jeff

[Bug bootstrap/77962] [7 Regression] Bootstrap failure on x86_64-linux starting with r241063

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Thu Oct 13 18:25:15 2016
New Revision: 241135

URL: https://gcc.gnu.org/viewcvs?rev=241135=gcc=rev
Log:
Create the *logue in the same order as before (PR77962)

PR77962 shows Go failing on 32-bit x86.  This happens because the i386
port requires the split stack prologue to be created before the normal
prologue, and my previous patch changed it to be the other way around.

This patch changes it back.  Things will be exactly as before for targets
that do not do shrink-wrapping for separate components.  For targets
that *do* support it, all three prologue/epilogue creation functions
will now be called twice for functions that have anything wrapped
separately (instead of just the prologue created twice).


PR bootstrap/77962
* function.c (thread_prologue_and_epilogue_insns): Call all
make_*logue_seq in the same order as traditional.  Call them
all a second time if shrink_wrapped-separate.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c

Re: RFC: Split into smaller pieces

[Jonathan Wakely]

On 13/10/16 18:34 +0100, Jonathan Wakely wrote:

Code which doesn't need the whole of  should include the
relevant  header instead.

This means that we don't need to pull the whole of  (and
 and ) into  just because shared_ptr
wants to use reference_wrapper in one place.  This reduces 
from 48kloc to 30kloc!


With a few additional changes to remove  from other
headers we can get:

old  |  new  | Header
--|---|---
47571 | 30449 | memory
49620 | 32498 | thread
49049 | 30861 | condition_variable
49459 | 31271 | shared_mutex
54215 | 37745 | future  
75063 | 68509 | regex   


Apart from , which is enormous even without , these
are pretty dramatic improvements.

Re: [PATCH] Remove a few -Wno-error from Makefile.in

[Bernd Schmidt]

On 10/13/2016 08:09 PM, Marek Polacek wrote:

I thought I had already done this, but apparently not.  I added these because
of -Wimplicit-fallthrough, but they're no longer needed, so remove it to not
suppress any possible useful warnings.

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

2016-10-13  Marek Polacek  

* Makefile.in (insn-attrtab.o-warn, insn-dfatab.o-warn,
insn-latencytab.o-warn, insn-output.o-warn, insn-emit.o-warn): Don't
use -Wno-error.


Ok.


Bernd

Re: [PATCH] Remove a few -Wno-error from Makefile.in

[Jeff Law]

On 10/13/2016 12:09 PM, Marek Polacek wrote:

I thought I had already done this, but apparently not.  I added these because
of -Wimplicit-fallthrough, but they're no longer needed, so remove it to not
suppress any possible useful warnings.

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

2016-10-13  Marek Polacek  

* Makefile.in (insn-attrtab.o-warn, insn-dfatab.o-warn,
insn-latencytab.o-warn, insn-output.o-warn, insn-emit.o-warn): Don't
use -Wno-error.

OK.
jeff

Re: [PATCH] Create the *logue in the same order as before (PR77962)

[Jeff Law]

On 10/13/2016 09:15 AM, Segher Boessenkool wrote:

PR77962 shows Go failing on 32-bit x86.  This happens because the i386
port requires the split stack prologue to be created before the normal
prologue, and my previous patch changed it to be the other way around.

This patch changes it back.  Things will be exactly as before for targets
that do not do shrink-wrapping for separate components.  For targets
that *do* support it, all three prologue/epilogue creation functions
will now be called twice for functions that have anything wrapped
separately (instead of just the prologue created twice).

Bootstrapping+testing on powerpc64-linux {-m64,-m32}, all languages;
and on x86_64-linux all,go,obj-c++ (i.e. no ada).

Is this okay for trunk if testing succeeds?  And sorry for the breakage.


Segher


2016-10-13  Segher Boessenkool  

PR bootstrap/77962
* function.c (thread_prologue_and_epilogue_insns): Call all
make_*logue_seq in the same order as traditional.  Call them
all a second time if shrink_wrapped-separate.

OK.
jeff

[PATCH] Remove a few -Wno-error from Makefile.in

[Marek Polacek]

I thought I had already done this, but apparently not.  I added these because
of -Wimplicit-fallthrough, but they're no longer needed, so remove it to not
suppress any possible useful warnings.

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

2016-10-13  Marek Polacek  

* Makefile.in (insn-attrtab.o-warn, insn-dfatab.o-warn,
insn-latencytab.o-warn, insn-output.o-warn, insn-emit.o-warn): Don't
use -Wno-error.

diff --git gcc/Makefile.in gcc/Makefile.in
index 76b77ab..d6e44e4 100644
--- gcc/Makefile.in
+++ gcc/Makefile.in
@@ -218,11 +218,6 @@ libgcov-merge-tool.o-warn = -Wno-error
 gimple-match.o-warn = -Wno-unused
 generic-match.o-warn = -Wno-unused
 dfp.o-warn = -Wno-strict-aliasing
-insn-attrtab.o-warn = -Wno-error
-insn-dfatab.o-warn = -Wno-error
-insn-latencytab.o-warn = -Wno-error
-insn-output.o-warn = -Wno-error
-insn-emit.o-warn = -Wno-error
 
 # All warnings have to be shut off in stage1 if the compiler used then
 # isn't gcc; configure determines that.  WARN_CFLAGS will be either

Marek

[committed, arm, testsuite] fix dg-skip-if logic in Xscale-specific tests

[Sandra Loosemore]

I noticed that two Xscale-specific tests, gcc.target/arm/scd42-1.c and 
gcc.target/arm/scd42-2.c, were incorrectly being run in test 
configurations explicitly specifying some other incompatible -mcpu.  The 
similar test gcc.target/arm/scd42-3.c was correctly being skipped in 
that case, so I copied the logic from that file to correct the other two 
tests.  Because this was a straight cut-and-paste, I thought this 
qualified as an obvious fix, and have committed it.


-Sandra

2016-10-13  Sandra Loosemore 

	gcc/testsuite/
	* scd42-1.c: Skip if -mcpu incompatible with Xscale is specified,
	not just -march.
	* scd42-2.c: Fix existing logic to skip if -mcpu is incompatible
	with Xscale.
Index: gcc.target/arm/scd42-1.c
===
--- gcc.target/arm/scd42-1.c	(revision 470710)
+++ gcc.target/arm/scd42-1.c	(working copy)
@@ -1,6 +1,7 @@
 /* Verify that mov is preferred on XScale for loading a 1 byte constant. */
 /* { dg-do compile } */
-/* { dg-skip-if "incompatible options" { arm*-*-* } { "-march=*" } { "" } } */
+/* { dg-skip-if "Test is specific to Xscale" { arm*-*-* } { "-march=*" } { "-march=xscale" } } */
+/* { dg-skip-if "Test is specific to Xscale" { arm*-*-* } { "-mcpu=*" } { "-mcpu=xscale" } } */
 /* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } { "-mfloat-abi=softfp" } } */
 /* { dg-options "-mcpu=xscale -O -mfloat-abi=softfp" } */
 
Index: gcc.target/arm/scd42-2.c
===
--- gcc.target/arm/scd42-2.c	(revision 470710)
+++ gcc.target/arm/scd42-2.c	(working copy)
@@ -1,10 +1,10 @@
 /* Verify that mov is preferred on XScale for loading a 2 byte constant. */
 /* { dg-do compile } */
-/* { dg-options "-mcpu=xscale -O" } */
 /* { dg-skip-if "Test is specific to the Xscale" { arm*-*-* } { "-march=*" } { "-march=xscale" } } */
 /* { dg-skip-if "Test is specific to the Xscale" { arm*-*-* } { "-mcpu=*" } { "-mcpu=xscale" } } */
 /* { dg-skip-if "Test is specific to ARM mode" { arm*-*-* } { "-mthumb" } { "" } } */
 /* { dg-require-effective-target arm32 } */
+/* { dg-options "-mcpu=xscale -O" } */
 
 unsigned load2(void) __attribute__ ((naked));
 unsigned load2(void)

bootstrap possibly broken on trunk ?

[Prathamesh Kulkarni]

Hi,
I am getting the following error when bootstrapping trunk (tried with r241108)
on x86_64-unknown-linux-gnu during stage-1:

../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:12:
error: ISO C++ forbids declaration of \u2018_Bind_simple_helper\u2019
with no type [-fpermissive]
   template _Bind_simple_helper>::__type __bind_simple(void (thread::*&&)(),
reference_wrapper&&);
^~~
../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:12:
error: \u2018_Bind_simple_helper\u2019 is not a template function
../../../../gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:121:31:
error: expected \u2018;\u2019 before \u2018<\u2019 token
   template _Bind_simple_helper>::__type __bind_simple(void (thread::*&&)(),
reference_wrapper&&);

Could someone please confirm this for me ?

Thanks,
Prathamesh

[Bug fortran/77973] New: ICE in scan_omp_1_op, at omp-low.c:3841

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77973
   Summary: ICE in scan_omp_1_op, at omp-low.c:3841
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With version 7 and option -fopenmp :


$ cat z1.f90
subroutine s(x)
   integer :: x(:)
   integer :: i
!$omp parallel
!$omp target teams distribute
   do i = 1, 2
  x(i) = 1
   end do
!$omp end parallel
end


$ gfortran-7-20161009 -fopenmp -c z1.f90
z1.f90:5:0:

 !$omp target teams distribute

internal compiler error: in scan_omp_1_op, at omp-low.c:3841
0xafa012 scan_omp_1_op
../../gcc/omp-low.c:3841
0xee7462 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/tree.c:11684
0xb11b68 scan_omp_op
../../gcc/omp-low.c:394
0xb11b68 scan_sharing_clauses
../../gcc/omp-low.c:2054
0xb20d08 scan_omp_target
../../gcc/omp-low.c:3192
0xb20d08 scan_omp_1_stmt
../../gcc/omp-low.c:3983
0x9ad92a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:568
0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9ada02 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9ada02 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xaf5c99 scan_omp
../../gcc/omp-low.c:4026
0xb21038 scan_omp_parallel
../../gcc/omp-low.c:2694
0xb21038 scan_omp_1_stmt
../../gcc/omp-low.c:3950
0x9ad92a walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:568
0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x9ada02 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x9adb48 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xaf5c99 scan_omp
../../gcc/omp-low.c:4026

[Bug fortran/77972] New: ICE on broken character continuation with -Wall etc.

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77972
   Summary: ICE on broken character continuation with -Wall etc.
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

ICEs down to at least 4.8; gcc-7 in combination with option -Wall,
or one of -pedantic, -std=f95, -std=f2003, -std=f2008, ...
Follow-up of pr71686.


$ cat z1.f90
program p
   character(8) :: z
   z = 'abc&
!end


$ cat z2.f90
program p
   character(8) :: z = 'abc&
!end


$ gfortran-7-20161009 -Wall z1.f90
0x68903e gfc_format_decoder
../../gcc/fortran/error.c:935
0x13c9bff pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:660
0x13bd020 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:945
0x688d4f gfc_warning
../../gcc/fortran/error.c:792
0x6899e6 gfc_warning(int, char const*, ...)
../../gcc/fortran/error.c:823
0x6fecb8 gfc_next_char_literal(gfc_instring)
../../gcc/fortran/scanner.c:1424
0x6de738 next_string_char
../../gcc/fortran/primary.c:903
0x6e06a7 match_string_constant
../../gcc/fortran/primary.c:1102
0x6e06a7 gfc_match_literal_constant(gfc_expr**, int)
../../gcc/fortran/primary.c:1455
0x6bc01f match_primary
../../gcc/fortran/matchexp.c:149
0x6bc01f match_level_1
../../gcc/fortran/matchexp.c:211
0x6bc01f match_mult_operand
../../gcc/fortran/matchexp.c:267
0x6bc308 match_add_operand
../../gcc/fortran/matchexp.c:356
0x6bc59c match_level_2
../../gcc/fortran/matchexp.c:480
0x6bc6f2 match_level_3
../../gcc/fortran/matchexp.c:551
0x6bc804 match_level_4
../../gcc/fortran/matchexp.c:599
0x6bc804 match_and_operand
../../gcc/fortran/matchexp.c:693
0x6bc9c2 match_or_operand
../../gcc/fortran/matchexp.c:722
0x6bcab2 match_equiv_operand
../../gcc/fortran/matchexp.c:765
0x6bcba2 match_level_5
../../gcc/fortran/matchexp.c:811

[Bug fortran/77971] ICE at -O0 in make_decl_rtl, at varasm.c:1310

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---


For completeness, compiles without variable "g" :

$ cat z3.f90
module m
contains
   function f()
  f = 1
   entry g()
  g = 2
   end
end

$ gfortran-7-20161009 -O0 -c z3.f90



Problem detected with variable named "f" :

$ cat z4.f90
module m
   real f
contains
   function f()
  f = 1
   entry g()
  g = 2
   end
end

$ gfortran-7-20161009 -O0 -c z4.f90
z4.f90:4:13:

z4.f90:2:9:

real f
 2
z4.f90:4:13:

function f()
 1
Error: Procedure 'f' at (1) has an explicit interface and must not have
attributes declared at (2)

[Bug fortran/77971] New: ICE at -O0 in make_decl_rtl, at varasm.c:1310

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 77971
   Summary: ICE at -O0 in make_decl_rtl, at varasm.c:1310
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

ICE down to at least 4.8, at -O0 :


$ cat z1.f90
module m
   real g
contains
   function f()
  f = 1
   entry g()
  g = 2
   end
end


$ gfortran-7-20161009 -O0 -c z1.f90
z1.f90:7:0:

   g = 2

internal compiler error: in make_decl_rtl, at varasm.c:1310
0xf1e0be make_decl_rtl(tree_node*)
../../gcc/varasm.c:1306
0x90dd88 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:9755
0x91a8a6 expand_expr
../../gcc/expr.h:279
0x91a8a6 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5252
0x8083e6 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3649
0x8083e6 expand_gimple_stmt
../../gcc/cfgexpand.c:3745
0x80a80e expand_gimple_basic_block
../../gcc/cfgexpand.c:5752
0x810996 execute
../../gcc/cfgexpand.c:6363

Re: [ping * 2] remove optab functions for [us]divmod_optab in optabs.def

[Bernd Schmidt]

On 10/13/2016 07:18 PM, Prathamesh Kulkarni wrote:

On 13 October 2016 at 16:56, Bernd Schmidt  wrote:

On 10/06/2016 07:43 AM, Prathamesh Kulkarni wrote:


Pinging patch: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01038.html



If I understand correctly this is a latent issue where nonexistant libfunc
names are stored (but not currently used). If that's correct, then OK.

Hi Bernd,
AFAIU it's indeed a latent issue with optab_libfunc() returning
non-existent libfunc
names.


[...]


It seems probably this code-path never got triggered to generate call
to "__udivmoddi4" or "__divmoddi4"
and the issue remained latent.
Is the patch OK to commit ?


Yes, I think so. Thanks,


Bernd

Re: [ping * 2] remove optab functions for [us]divmod_optab in optabs.def

[Prathamesh Kulkarni]

On 13 October 2016 at 16:56, Bernd Schmidt  wrote:
> On 10/06/2016 07:43 AM, Prathamesh Kulkarni wrote:
>>
>> Pinging patch: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01038.html
>
>
> If I understand correctly this is a latent issue where nonexistant libfunc
> names are stored (but not currently used). If that's correct, then OK.
Hi Bernd,
AFAIU it's indeed a latent issue with optab_libfunc() returning
non-existent libfunc
names.

In expand_twoval_binop_libfunc() we have:
 mode = GET_MODE (op0);
  libfunc = optab_libfunc (binoptab, mode);
  if (!libfunc)
return false;

When binoptab is sdivmod_optab:
optab_libfunc () could return bogus libfunc like "__divmoddi4"
resulting in link-error. That's because optab_libfunc() calls gen_int_libfunc()
which lazily constructs libfunc for "__divmoddi4" and returns it.
This is the same issue I came across when implementing divmod transform.

When binoptab is udivmod_optab:
optab_libfunc() could return  "__udivmoddi4" which would result
in wrong code. That's because expand_twoval_binop_libfunc() expects
the libfunc to take two arguments and return result whose mode is
twice that of it's argument whereas __udivmoddi4() takes 3 arguments,
the 3rd argument being a pointer to store the remainder and return value
passed as quotient.

Currently the only way to generate call to divmod libfunc is via
expand_twoval_binop_libfunc()
which is called *only* from expand_divmod() if mod libfunc does not exist:

/* No remainder function.  Try a quotient-and-remainder
   function, keeping the remainder.  */
  if (!remainder)
{
  remainder = gen_reg_rtx (compute_mode);
  if (!expand_twoval_binop_libfunc
  (unsignedp ? udivmod_optab : sdivmod_optab,
   op0, op1,
   NULL_RTX, remainder,
   unsignedp ? UMOD : MOD))
remainder = NULL_RTX;
}

It seems probably this code-path never got triggered to generate call
to "__udivmoddi4" or "__divmoddi4"
and the issue remained latent.
Is the patch OK to commit ?

Thanks,
Prathamesh
>
>
> Bernd

Re: [PATCH, libfortran] PR 48587 Newunit allocator

[Jerry DeLisle]

On 10/13/2016 08:16 AM, Janne Blomqvist wrote:

Currently GFortran newer reuses unit numbers allocated with NEWUNIT=,
instead having a simple counter that is decremented each time such a
unit is opened.


I am going to have to study this a bit. After I added the newunit stack, the 
units are reused,  Need to see how this plays with internal units, and 
recursive, and dtio.


Jerry

[PATCH][AArch64] Use new target pass registration framework for FMA steering pass

[Kyrill Tkachov]

Hi all,

This patch moves the aarch64-specific FMA steering pass registration into the 
new framework
that Jakub introduced. With this patch the RTL dump for the steering pass is 
now numbered properly
so that it appears after the regrename pass, rather than getting a dump number 
that puts it after
all the other passes.

I've followed a similar approach to [1] and added an aarch64-passes.def file 
and updated
PASSES_EXTRA in t-aarch64. I deleted cortex-a57-fma-steering.h as I don't think 
it adds any value.
The prototype for the make_pass* function works just as well in 
aarch64-protos.h I think.

Bootstrapped and tested on aarch64-none-linux-gnu.
Manually checked that the pass still runs when tuning for Cortex-A57 and 
doesn't run otherwise.

Ok for trunk?

Thanks,
Kyrill

[1] https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00615.html

2016-10-13  Kyrylo Tkachov  

* config/aarch64/aarch64.c: Delete inclusion of
cortex-a57-fma-steering.h.
(aarch64_override_options): Delete call
to aarch64_register_fma_steering.
* config/aarch64/aarch64-protos.h (make_pass_fma_steering): Declare.
* config/aarch64/cortex-a57-fma-steering.h: Delete.
* config/aarch64/aarch64-passes.def: New file.
* config/aarch64/cortex-a57-fma-steering.c
(aarch64_register_fma_steering): Delete definition.
(make_pass_fma_steering): Remove static qualifier.
* config/aarch64/t-aarch64 (PASSES_EXTRA): New directive.
(cortex-a57-fma-steering.o): Remove dependency on
cortex-a57-fma-steering.h.
diff --git a/gcc/config/aarch64/aarch64-protos.h b/gcc/config/aarch64/aarch64-protos.h
index 4c551ef143d3b32e94bd58989c85ebd3352cdd9b..b6ca3dfacb0dc88e5d688905d9d013263d4e8d7f 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -464,4 +464,6 @@ enum aarch64_parse_opt_result aarch64_parse_extension (const char *,
 std::string aarch64_get_extension_string_for_isa_flags (unsigned long,
 			unsigned long);
 
+rtl_opt_pass *make_pass_fma_steering (gcc::context *ctxt);
+
 #endif /* GCC_AARCH64_PROTOS_H */
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index ef8b8a24388d2f8e21271e0285b8d9d48078e759..e7556632901177c04f9884be4f3ee40e5f677917 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -64,7 +64,6 @@
 #include "rtl-iter.h"
 #include "tm-constrs.h"
 #include "sched-int.h"
-#include "cortex-a57-fma-steering.h"
 #include "target-globals.h"
 #include "common/common-target.h"
 
@@ -8561,9 +8560,6 @@ aarch64_override_options (void)
  while processing functions with potential target attributes.  */
   target_option_default_node = target_option_current_node
   = build_target_option_node (_options);
-
-  aarch64_register_fma_steering ();
-
 }
 
 /* Implement targetm.override_options_after_change.  */
diff --git a/gcc/config/aarch64/cortex-a57-fma-steering.h b/gcc/config/aarch64/aarch64-passes.def
similarity index 78%
rename from gcc/config/aarch64/cortex-a57-fma-steering.h
rename to gcc/config/aarch64/aarch64-passes.def
index 65bf5acc132d2db645d1b00ef031dc33a195bb78..7fe80391a3fb0dc79715b9fb23fd4c08a9d26d74 100644
--- a/gcc/config/aarch64/cortex-a57-fma-steering.h
+++ b/gcc/config/aarch64/aarch64-passes.def
@@ -1,6 +1,5 @@
-/* This file contains declarations for the FMA steering optimization
-   pass for Cortex-A57.
-   Copyright (C) 2015-2016 Free Software Foundation, Inc.
+/* AArch64-specific passes declarations.
+   Copyright (C) 2016 Free Software Foundation, Inc.
Contributed by ARM Ltd.
 
This file is part of GCC.
@@ -19,4 +18,4 @@
along with GCC; see the file COPYING3.  If not see
.  */
 
-void aarch64_register_fma_steering (void);
+INSERT_PASS_AFTER (pass_regrename, 1, pass_fma_steering);
diff --git a/gcc/config/aarch64/cortex-a57-fma-steering.c b/gcc/config/aarch64/cortex-a57-fma-steering.c
index 1bf804b4873c6b32e0eb3d640a74c2e52843e796..b5f329f75a6ccfcdf5a1d1dda6758bdd87ba 100644
--- a/gcc/config/aarch64/cortex-a57-fma-steering.c
+++ b/gcc/config/aarch64/cortex-a57-fma-steering.c
@@ -35,7 +35,6 @@
 #include "context.h"
 #include "tree-pass.h"
 #include "regrename.h"
-#include "cortex-a57-fma-steering.h"
 #include "aarch64-protos.h"
 
 /* For better performance, the destination of FMADD/FMSUB instructions should
@@ -1068,21 +1067,8 @@ public:
 
 /* Create a new fma steering pass instance.  */
 
-static rtl_opt_pass *
+rtl_opt_pass *
 make_pass_fma_steering (gcc::context *ctxt)
 {
   return new pass_fma_steering (ctxt);
 }
-
-/* Register the FMA steering pass to the pass manager.  */
-
-void
-aarch64_register_fma_steering ()
-{
-  opt_pass *pass_fma_steering = make_pass_fma_steering (g);
-
-  struct register_pass_info fma_steering_info
-= { pass_fma_steering, "rnreg", 1, PASS_POS_INSERT_AFTER };
-
-  register_pass (_steering_info);
-}
diff --git a/gcc/config/aarch64/t-aarch64 b/gcc/config/aarch64/t-aarch64
index 

[PATCH] Avoid #include in other headers

[Jonathan Wakely]

The  header is pretty large, especially in C++17 mode
because the searchers include  and . This
tweaks other headers to avoid including it unnecessarily.

We could reduce things much further by splitting std::function and
std::reference_wrapper into their own headers, which I'm working on.
This kind of internal refactoring helps counteract the fact that the
library keep growing with each new standard revision so the headers
are larger and larger.

Any time we reduce interdepencies within the library headers we cause
compilation errors for some user code, but the fix is just to add the
missing headers. I'll mention this in the GCC 7 porting-to doc nearer
the release.

* include/bits/shared_ptr_base.h: Include .
[!__cpp_rtti]: Do not include .
* include/experimental/array: Do not include .
* include/experimental/memory: Include 
instead of .
* include/experimental/propagate_const: Include ,
, and  instead of .
* include/experimental/tuple: Do not include .
* include/std/future: Include .
* include/std/memory: Do not include .
* include/std/mutex: [_GLIBCXX_HAVE_TLS]: Likewise.
* testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc: Add
missing includes.
* testsuite/20_util/shared_ptr/thread/mutex_weaktoshared.cc: Likewise.
* testsuite/20_util/specialized_algorithms/memory_management_tools/
1.cc: Likewise.
* testsuite/30_threads/call_once/60497.cc: Likewise.
* testsuite/30_threads/lock/2.cc: Likewise.
* testsuite/30_threads/thread/native_handle/cancel.cc: Likewise.
* testsuite/experimental/algorithm/sample.cc: Likewise.
* testsuite/experimental/array/make_array.cc: Likewise.
* testsuite/experimental/array/neg.cc: Likewise. Adjust dg-error line.
* testsuite/experimental/propagate_const/assignment/move_neg.cc:
Adjust dg-error lines.
* testsuite/experimental/propagate_const/cons/move_neg.cc: Likewise.
* testsuite/experimental/propagate_const/requirements2.cc: Likewise.
* testsuite/experimental/propagate_const/requirements3.cc: Likewise.
* testsuite/experimental/propagate_const/requirements4.cc: Likewise.
* testsuite/experimental/propagate_const/requirements5.cc: Likewise.

Tested powerpc64le-linux (without PCH), committed to trunk.


commit b125f5397462eee46dec2693232afc677df4e421
Author: Jonathan Wakely 
Date:   Thu Oct 13 15:55:18 2016 +0100

Avoid #include  in other headers

* include/bits/shared_ptr_base.h: Include .
[!__cpp_rtti]: Do not include .
* include/experimental/array: Do not include .
* include/experimental/memory: Include 
instead of .
* include/experimental/propagate_const: Include ,
, and  instead of .
* include/experimental/tuple: Do not include .
* include/std/future: Include .
* include/std/memory: Do not include .
* include/std/mutex: [_GLIBCXX_HAVE_TLS]: Likewise.
* testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc: Add
missing includes.
* testsuite/20_util/shared_ptr/thread/mutex_weaktoshared.cc: Likewise.
* testsuite/20_util/specialized_algorithms/memory_management_tools/
1.cc: Likewise.
* testsuite/30_threads/call_once/60497.cc: Likewise.
* testsuite/30_threads/lock/2.cc: Likewise.
* testsuite/30_threads/thread/native_handle/cancel.cc: Likewise.
* testsuite/experimental/algorithm/sample.cc: Likewise.
* testsuite/experimental/array/make_array.cc: Likewise.
* testsuite/experimental/array/neg.cc: Likewise. Adjust dg-error line.
* testsuite/experimental/propagate_const/assignment/move_neg.cc:
Adjust dg-error lines.
* testsuite/experimental/propagate_const/cons/move_neg.cc: Likewise.
* testsuite/experimental/propagate_const/requirements2.cc: Likewise.
* testsuite/experimental/propagate_const/requirements3.cc: Likewise.
* testsuite/experimental/propagate_const/requirements4.cc: Likewise.
* testsuite/experimental/propagate_const/requirements5.cc: Likewise.

diff --git a/libstdc++-v3/include/bits/shared_ptr_base.h 
b/libstdc++-v3/include/bits/shared_ptr_base.h
index e8820a1..422e3b5 100644
--- a/libstdc++-v3/include/bits/shared_ptr_base.h
+++ b/libstdc++-v3/include/bits/shared_ptr_base.h
@@ -49,7 +49,10 @@
 #ifndef _SHARED_PTR_BASE_H
 #define _SHARED_PTR_BASE_H 1
 
-#include 
+#include 
+#if __cpp_rtti
+# include 
+#endif
 #include 
 #include 
 
diff --git a/libstdc++-v3/include/experimental/array 
b/libstdc++-v3/include/experimental/array
index 31a066b..34d75cc 100644
--- a/libstdc++-v3/include/experimental/array
+++ b/libstdc++-v3/include/experimental/array
@@ -36,7 +36,6 @@
 #else
 
 #include 
-#include 
 #include 
 
 namespace std _GLIBCXX_VISIBILITY(default)
diff --git 

[Bug c/77970] inconsistent and unhelpful -Wformat warning for %lc

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
I think the correct logic would be something like: if the argument is for 
a standard typedef, and the format doesn't correspond exactly to that 
typedef (or one differing only by sign, e.g. allow %ju for an intmax_t 
unless -Wformat-signedness), warn (with an option to disable it) even if 
they match (or match up to sign) on this particular system.  Likewise if 
the format is for a standard typedef but the argument isn't.  Hard to 
implement for various reasons (including  format macros - 
glibc's definitions of those for intmax_t match the underlying type rather 
than using "j", for example), and would have false positives in various 
cases, but more warnings rather than less seems right here and would make 
warnings more consistent between targets.

The option to disable warnings for mismatched typedefs could then have 
different stringencies for whether it disables even int/long mismatches, 
or only cases that already wouldn't warn but for the use of standard 
typedefs.

small testcase gcc6 + boost optional + Wmaybe-uninit

[Jason Mancini]

Web search shows that -Wmaybe-uninitialized is an imprecise check, and  that 
boost::optional is already a known sore spot, but I wanted to pass  along this 
small test case in case the warning's owner wanted to do  further improvements. 
 We solved our one grumpy instance with auto x =  make_optional(0, ...);.  
Something about the loop + conditional +  O1/O2/O3 optimization triggers the 
false positive.  Thanks!   -Jason

//==
// g++ -c sample.cc -O2 -Wall -Werror
// gcc 6.1/6.2 and boost 1.61/1.62
#include 
#include 
int main() {
  boost::optional value;
  for (int x(0); x < 3; ++x) {
    if (random() & 1)
  value = x;
  }
  if (value != boost::none) {
    int result = value.get();
    printf("%d\n", result); // error: '*((void*)& value +4)' may be used 
uninitialized
  }
}
//==

Re: [PATCH] Create the *logue in the same order as before (PR77962)

[Segher Boessenkool]

On Thu, Oct 13, 2016 at 03:15:37PM +, Segher Boessenkool wrote:
> Bootstrapping+testing on powerpc64-linux {-m64,-m32}, all languages;
> and on x86_64-linux all,go,obj-c++ (i.e. no ada).
> 
> Is this okay for trunk if testing succeeds?  And sorry for the breakage.

No new failures for either.


Segher

[PATCH] Add missing header in testcase

[Jonathan Wakely]

Another one that fails without PCH.

* testsuite/experimental/algorithm/sample.cc: Add missing header.

Tested x86_64-linux, committed to trunk.

commit b6ba4386fc81777bd4a06b2807b03b38f7f85d76
Author: Jonathan Wakely 
Date:   Thu Oct 13 17:42:03 2016 +0100

Add missing  header in testcase

* testsuite/experimental/algorithm/sample.cc: Add missing header.

diff --git a/libstdc++-v3/testsuite/experimental/algorithm/sample.cc 
b/libstdc++-v3/testsuite/experimental/algorithm/sample.cc
index 19681d7..0d84e9d 100644
--- a/libstdc++-v3/testsuite/experimental/algorithm/sample.cc
+++ b/libstdc++-v3/testsuite/experimental/algorithm/sample.cc
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 std::mt19937 rng;

[PATCH] Qualify use of std::declval to avoid ADL

[Jonathan Wakely]

* include/experimental/propagate_const (element_type): Qualify
declval.

Tested x86_64-linux, committted to trunk.

commit 1df5cda6740d67ac7074fbbf03178d25b45549bb
Author: Jonathan Wakely 
Date:   Thu Oct 13 17:39:18 2016 +0100

Qualify use of std::declval to avoid ADL

* include/experimental/propagate_const (element_type): Qualify
declval.

diff --git a/libstdc++-v3/include/experimental/propagate_const 
b/libstdc++-v3/include/experimental/propagate_const
index 15ffe4a..e1fb4e4 100644
--- a/libstdc++-v3/include/experimental/propagate_const
+++ b/libstdc++-v3/include/experimental/propagate_const
@@ -63,7 +63,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 class propagate_const
 {
 public:
-  typedef remove_reference_t())> element_type;
+  typedef remove_reference_t())> element_type;
 
 private:
   template 

[PATCH] Change test to use VERIFY not assert

[Jonathan Wakely]

This used to pass because  included , but
it doesn't now. The test wasn't failing because the stdc++.h PCH
included , but it fails without PCH.

* testsuite/26_numerics/random/default_random_engine.cc: Use VERIFY
instead of assert.

Tested x86_64-linux, committed to trunk.

commit 81c756a8a213ca217602aa1fa90d513989adb2e5
Author: Jonathan Wakely 
Date:   Thu Oct 13 17:30:43 2016 +0100

Change test to use VERIFY not assert

* testsuite/26_numerics/random/default_random_engine.cc: Use VERIFY
instead of assert.

diff --git a/libstdc++-v3/testsuite/26_numerics/random/default_random_engine.cc 
b/libstdc++-v3/testsuite/26_numerics/random/default_random_engine.cc
index 99d5e1f..e21c7ae 100644
--- a/libstdc++-v3/testsuite/26_numerics/random/default_random_engine.cc
+++ b/libstdc++-v3/testsuite/26_numerics/random/default_random_engine.cc
@@ -20,7 +20,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// 26.4.5 Engines and egine adaptors with predefined parameters [rand.predef]
+// 26.4.5 Engines and engine adaptors with predefined parameters [rand.predef]
 // 26.4.5 [10]
 
 #include 
@@ -38,7 +38,7 @@ test01()
   std::minstd_rand0 b;
   b.discard();
 
-  assert( a() == b() );
+  VERIFY( a() == b() );
 }
 
 int main()

[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type

[potswa at mac dot com]

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

--- Comment #3 from David Krauss  ---
… Woops, that f is the function parameter, not the target. So it's not a
conflicting requirement, but it could be a template for fixing the the copy
constructor constraint.

[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type

[potswa at mac dot com]

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

--- Comment #2 from David Krauss  ---
The converting constructor requirements also say more explicitly,

  shall not throw exceptions when f is a function pointer
  or a reference_wrapper for some T.

Probably the copy constructor should be worded similarly.

In any case, the exception guarantee isn't affected, as
sizeof(reference_wrapper) == sizeof(T*).

Go patch committed: don't get backend version of redefinition

[Ian Lance Taylor]

This patch to the Go frontend changes it to not try to get the backend
version of a redefinition.  A redefinition is an error anyhow, and
getting the backend version can cause the compiler to crash as it
walks over a list of statements for the second time.  No test case
added as I don't think it's worth adding a test case for a
crash-on-invalid.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 241124)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-681580a3afc687ba3ff9ef240c67e8630e4306e6
+e3913d96fb024b916c87a4dc01f413523467ead9
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/gogo.cc
===
--- gcc/go/gofrontend/gogo.cc   (revision 240942)
+++ gcc/go/gofrontend/gogo.cc   (working copy)
@@ -7214,6 +7214,14 @@ Named_object::get_backend(Gogo* gogo, st
   std::vector& type_decls,
   std::vector& func_decls)
 {
+  // If this is a definition, avoid trying to get the backend
+  // representation, as that can crash.
+  if (this->is_redefinition_)
+{
+  go_assert(saw_errors());
+  return;
+}
+
   switch (this->classification_)
 {
 case NAMED_OBJECT_CONST:

Re: [PATCH] - improve sprintf buffer overflow detection (middle-end/49905)

[Martin Sebor]

No worries: I've refreshed your patch on top of Thomas Preud'homme's for
PR testsuite/77710 and found that one more bit is needed to fix this
completely.  32-bit Solaris shows three more warnings:

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1355:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 6 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1356:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 6 has 
type 'int' [-Wformat=]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c:1357:3:
 warning: format '%lc' expects argument of type 'wint_t', but argument 6 has 
type 'int' [-Wformat=]


Rats!  I overlooked those in followup patch I committed to fix
the others.  I had tested the change with a 32-bit cross compiler
but I still see them in the 32-bit Solaris cross compiler, though
not in the i366 one.  I assumed the i386 compiler was a good enough
proxy but now that I've checked more carefully I see that it warns
for %lc with a wchar_t argument such as L'a' but not for int such
as 0, while the 32-bit Solaris compiler for %lc with an int argument
and not for wchar_t.

In the i386 compiler wchar_t is long and wint_t is unsigned int while
in the Solaris one both wchar_t and wint_t are long int.  Even though
these types and arguments are the same width (and on Solaris even the
same sign), -Wformat still warns.

I've fixed fix this in the test in r241123.  Since I didn't manage
to convince Joseph that the warning is unhelpful in our discussion
last week I wasn't going to pursue it but I've now changed my mind.
The warning is obviously detrimental to portability so I've raised
bug 77970 for it.

Thanks
Martin



Fixed as follows:




With this one and your refreshed patch, all failures are gone now for
i386-pc-solaris2.12, sparc-sun-solaris2.12, and x86_64-pc-linux-gnu.

Rainer

[Bug c/77970] New: inconsistent and unhelpful -Wformat warning for %lc

[msebor at gcc dot gnu.org]

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

Bug ID: 77970
   Summary: inconsistent and unhelpful -Wformat warning for %lc
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following snippet compiles with no warnings on popular 64-bit targets
including powerpc64-*-linux, sparc-sun-solaris2.10, and x86_64-*-linux. 
However, on a number of 32-bit targets the same code causes GCC to issue a
warning about one or the other call pedantically complaining about either the
literal zero not having the expected type of wint_t (e.g., where wint_t is an
alias for long) even though the two have the same size and sign, or about the
L'a' argument not having the wint_t type for the same reason (the type of L'a'
is wchar_t).  (This is analogous to warnings issued for %li with an int
argument, or for %i with a long argument, on ILP32.)

  printf ("%lc", 0);
  printf ("%lc", L'a');

Unlike the warnings for ordinary integer directives which is issued
consistently, issuing the warning for %lc inconsistently, based on the
underlying type of wchar_t and wint_t, and only on uncommon targets and not on
mainstream targets where most code is developed is unhelpful for portability
and only serves to cause code to fail to compile when ported (see for example
the thread around https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00993.html for
the effort it took to clean up these warnings in the builtin-sprintf*.c tests).

Issuing the warning when both the sign and the size of the argument are the
same as those expected is useless entirely since objects of the two types are
indistinguishable.  (The warning is not issued when the types only differ in
signedness such as int and unsigned int unless the -Wformat-signedness option
is explicitly specified.)

To be useful for portability, the warning should be issued consistently on all
targets, especially those where most development is done (LP64 targets such
powerpc64-*-linux and x86_64-*-linux.  The warning is also only useful if there
exists a target where wint_t and wchar_t (for the L'a' case) or int (for the
int argument case) are different sizes.  If there is no such target (I don't
know of one and a survey of GCC config files didn't reveal one either) the
warning isn't useful even if wint_t and wchar_t differ in sign because sign
mismatches are handled separately under the -Wformat-signedness option.

As a data point, Clang stopped issuing this warning in 2011 in response to the
following Clang bug:

  https://llvm.org/bugs/show_bug.cgi?id=7981

GCC should do the same and either suppress the warning altogether or issue it
only with -Wpedantic.

Test case:

$ (set -x && cd ~/tmp && cat a.c && for t in i386-rehat-linux
sparc-sun-solaris2.12 x86_64-unknown-solaris2.10 bfin-uclinux m68k-linux
hppa-unknown-linux-gnu; do /build/sysroot/$t/bin/$t-gcc -S -Wall -o/dev/null
a.c; done)
+ cd /home/msebor/tmp
+ cat a.c
typedef __WCHAR_TYPE__ wchar_t;

void f (void)
{
  __builtin_printf ("%lc", 0);
  __builtin_printf ("%lc", L'a');
}
+ for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10
bfin-uclinux m68k-linux hppa-unknown-linux-gnu
+ /build/sysroot/i386-rehat-linux/bin/i386-rehat-linux-gcc -S -Wall -o/dev/null
a.c
a.c: In function 'f':
a.c:6:24: warning: format '%lc' expects argument of type 'wint_t', but argument
2 has type 'long int' [-Wformat=]
   __builtin_printf ("%lc", L'a');
  ~~^
  %ld
+ for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10
bfin-uclinux m68k-linux hppa-unknown-linux-gnu
+ /build/sysroot/sparc-sun-solaris2.12/bin/sparc-sun-solaris2.12-gcc -S -Wall
-o/dev/null a.c
a.c: In function 'f':
a.c:5:24: warning: format '%lc' expects argument of type 'wint_t', but argument
2 has type 'int' [-Wformat=]
   __builtin_printf ("%lc", 0);
  ~~^
  %c
+ for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10
bfin-uclinux m68k-linux hppa-unknown-linux-gnu
+ /build/sysroot/x86_64-unknown-solaris2.10/bin/x86_64-unknown-solaris2.10-gcc
-S -Wall -o/dev/null a.c
+ for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10
bfin-uclinux m68k-linux hppa-unknown-linux-gnu
+ /build/sysroot/bfin-uclinux/bin/bfin-uclinux-gcc -S -Wall -o/dev/null a.c
+ for t in i386-rehat-linux sparc-sun-solaris2.12 x86_64-unknown-solaris2.10
bfin-uclinux m68k-linux hppa-unknown-linux-gnu
+ /build/sysroot/m68k-linux/bin/m68k-linux-gcc -S -Wall -o/dev/null a.c
a.c: In function 'f':
a.c:6:24: warning: format '%lc' expects argument of type 'wint_t', but argument
2 has type 'long int' [-Wformat=]
   __builtin_printf ("%lc", L'a');
  ~~^
  %ld
+ for t in i386-rehat-linux 

[PATCH] DWARF: make signedness explicit for enumerator const values

[Pierre-Marie de Rodat]

Hello,

Currently, the DWARF description does not specify the signedness of the
representation of enumeration types.  This is a problem in some
contexts where DWARF consumers need to determine if value X is greater
than value Y.

For instance in Ada:

type Enum_Type is ( A, B, C, D);
for Enum_Type use (-1, 0, 1, 2);

type Rec_Type (E : Enum_Type) is record
   when A .. B => null;
   when others => B : Booleann;
end record;

The above can be described in DWARF the following way:

DW_TAG_enumeration_type(Enum_Type)
| DW_AT_byte_size: 1
  DW_TAG_enumerator(A)
  | DW_AT_const_value: -1
  DW_TAG_enumerator(B)
  | DW_AT_const_value: 0
  DW_TAG_enumerator(C)
  | DW_AT_const_value: 1
  DW_TAG_enumerator(D)
  | DW_AT_const_value: 2

DW_TAG_structure_type(Rec_Type)
  DW_TAG_member(E)
  | DW_AT_type: 
  DW_TAG_variant_part
  | DW_AT_discr: 
DW_TAG_variant
| DW_AT_discr_list: DW_DSC_range 0x7f 0
DW_TAG_variant
| DW_TAG_member(b)

DWARF consumers need to know that enumerators (A, B, C and D) are signed
in order to determine the set of E values for which Rec_Type has a B
field.  In practice, they need to know how to interpret the 0x7f LEB128
number above (-1, not 127).

There seems to be only two alternatives to solve this issue: one is to
add a DW_AT_type attribute to DW_TAG_enumerator_type DIEs to make it
point to a base type that specifies the signedness.  The other is to
make sure the form of the DW_AT_const_value attribute carries the
signedness information.  This patch implements the latter.

Currently, most of these attributes are generated with DW_FORM_data*
forms (dw_val_class_unsigned_const).  This patch changes the enumerator
description generation to always use instead the DW_FORM_[us]data forms.
It does so adding a new dw_val_class ("explicit unsigned const"), using
it for unsigned enumerators and using "[signed] const" for the signed
ones.

Bootstrapped and regtested (GCC+GDB testsuites) sucessfully on
x86_64-linux.  I also checked that the new testcase fails with current
trunk.  Ok to commit?

Thank you in advance!

gcc/

* dwarf2out.h (enum dw_val_class): Add a
dw_val_class_explicit_unsigned_const class.
(struct dw_val_node): Add a val_explicit_unsigned variant.
* dwarf2out.c (dw_val_equal_p, print_dw_val, attr_checksum,
attr_checksum_ordered, same_dw_val_p, size_of_die, value_format,
output_die): Handle dw_val_class_explicit_unsigned_const.
(add_AT_explicit_unsigned, AT_explicit_unsigned): New functions.
(gen_enumeration_type_die): Use the explicit unsigned const form
for all unsigned enumerator values and use the explicit [signed]
const form for all signed ones.

gcc/testsuite/

* gnat.dg/debug10.adb: New testcase.
---
 gcc/dwarf2out.c   | 61 ++-
 gcc/dwarf2out.h   |  3 ++
 gcc/testsuite/gnat.dg/debug10.adb | 39 +
 3 files changed, 95 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gnat.dg/debug10.adb

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index b5787ef..7022e6c 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -1361,6 +1361,7 @@ dw_val_equal_p (dw_val_node *a, dw_val_node *b)
 
 case dw_val_class_offset:
 case dw_val_class_unsigned_const:
+case dw_val_class_explicit_unsigned_const:
 case dw_val_class_const:
 case dw_val_class_range_list:
 case dw_val_class_lineptr:
@@ -3947,6 +3948,29 @@ AT_unsigned (dw_attr_node *a)
   return a->dw_attr_val.v.val_unsigned;
 }
 
+/* Add an explicitely unsigned integer attribute value to a DIE.  */
+
+static inline void
+add_AT_explicit_unsigned (dw_die_ref die, enum dwarf_attribute attr_kind,
+ unsigned HOST_WIDE_INT unsigned_val)
+{
+  dw_attr_node attr;
+
+  attr.dw_attr = attr_kind;
+  attr.dw_attr_val.val_class = dw_val_class_explicit_unsigned_const;
+  attr.dw_attr_val.val_entry = NULL;
+  attr.dw_attr_val.v.val_explicit_unsigned = unsigned_val;
+  add_dwarf_attr (die, );
+}
+
+static inline unsigned HOST_WIDE_INT
+AT_explicit_unsigned (dw_attr_node *a)
+{
+  gcc_assert (a != NULL
+ && AT_class (a) == dw_val_class_explicit_unsigned_const);
+  return a->dw_attr_val.v.val_explicit_unsigned;
+}
+
 /* Add an unsigned wide integer attribute value to a DIE.  */
 
 static inline void
@@ -5600,6 +5624,7 @@ print_dw_val (dw_val_node *val, bool recurse, FILE 
*outfile)
   fprintf (outfile, HOST_WIDE_INT_PRINT_DEC, val->v.val_int);
   break;
 case dw_val_class_unsigned_const:
+case dw_val_class_explicit_unsigned_const:
   fprintf (outfile, HOST_WIDE_INT_PRINT_UNSIGNED, val->v.val_unsigned);
   break;
 case dw_val_class_const_double:
@@ -5998,6 +6023,7 @@ attr_checksum (dw_attr_node *at, struct md5_ctx *ctx, int 
*mark)
   CHECKSUM (at->dw_attr_val.v.val_int);
 

Re: [PATCH] Omit INSN_LOCATION from compact dumps

[Bernd Schmidt]

On 10/13/2016 05:52 PM, David Malcolm wrote:


Alternatively, it seems that we might want an additional flag for
this.


Probably - I imagine most testcases won't care (it's obviously easier to 
read without locations) but some will. The writing side is maybe less 
interesting than the reading side, making sure we parse either variant 
correctly.



If so, maybe it's time to introduce a "class rtx_writer" or
similar to hold the global state relating to dumping, and rewrite
the dumping in those terms?


Depends how invasive that's going to be. I have no clear picture of it.


Bernd

[PATCH] Use normal mode containers in searchers

[Jonathan Wakely]

We never want the searchers to use the debug mode or profile mode
containers.

* include/experiumental/functional (boyer_moore_searcher)
(__boyer_moore_map_base, __boyer_moore_array_base): Qualify containers
with _GLIBCXX_STD_C.
* include/std/functional: Likewise.

Tested powerpc64le-linux, committed to trunk.


commit 34bf8c32da5cc50b7ade97707f44e6b2cdcd86df
Author: Jonathan Wakely 
Date:   Thu Oct 13 16:24:14 2016 +0100

Use normal mode containers in searchers

* include/experiumental/functional (boyer_moore_searcher)
(__boyer_moore_map_base, __boyer_moore_array_base): Qualify containers
with _GLIBCXX_STD_C.
* include/std/functional: Likewise.

diff --git a/libstdc++-v3/include/experimental/functional 
b/libstdc++-v3/include/experimental/functional
index db45665..77e6e66 100644
--- a/libstdc++-v3/include/experimental/functional
+++ b/libstdc++-v3/include/experimental/functional
@@ -119,7 +119,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _Pred
   _M_pred() const { return _M_bad_char.key_eq(); }
 
-  std::unordered_map<_Key, _Tp, _Hash, _Pred> _M_bad_char;
+  _GLIBCXX_STD_C::unordered_map<_Key, _Tp, _Hash, _Pred> _M_bad_char;
 };
 
   template
@@ -128,7 +128,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
__boyer_moore_array_base(_RAIter __pat, size_t __patlen,
 _Unused&&, _Pred&& __pred)
-   : _M_bad_char{ std::array<_Tp, _Len>{}, std::move(__pred) }
+   : _M_bad_char{ _GLIBCXX_STD_C::array<_Tp, _Len>{}, std::move(__pred) }
{
  std::get<0>(_M_bad_char).fill(__patlen);
  if (__patlen > 0)
@@ -156,7 +156,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   const _Pred&
   _M_pred() const { return std::get<1>(_M_bad_char); }
 
-  std::tuple, _Pred> _M_bad_char;
+  std::tuple<_GLIBCXX_STD_C::array<_Tp, _Len>, _Pred> _M_bad_char;
 };
 
   template
@@ -229,7 +229,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   _RAIter _M_pat;
   _RAIter _M_pat_end;
-  std::vector<__diff_type> _M_good_suffix;
+  _GLIBCXX_STD_C::vector<__diff_type> _M_good_suffix;
 };
 
   template _M_bad_char;
+  _GLIBCXX_STD_C::unordered_map<_Key, _Tp, _Hash, _Pred> _M_bad_char;
 };
 
   template
@@ -2215,7 +2215,7 @@ _GLIBCXX_MEM_FN_TRAITS(&&, false_type, true_type)
   template
__boyer_moore_array_base(_RAIter __pat, size_t __patlen,
 _Unused&&, _Pred&& __pred)
-   : _M_bad_char{ std::array<_Tp, _Len>{}, std::move(__pred) }
+   : _M_bad_char{ _GLIBCXX_STD_C::array<_Tp, _Len>{}, std::move(__pred) }
{
  std::get<0>(_M_bad_char).fill(__patlen);
  if (__patlen > 0)
@@ -2243,7 +2243,7 @@ _GLIBCXX_MEM_FN_TRAITS(&&, false_type, true_type)
   const _Pred&
   _M_pred() const { return std::get<1>(_M_bad_char); }
 
-  std::tuple, _Pred> _M_bad_char;
+  std::tuple<_GLIBCXX_STD_C::array<_Tp, _Len>, _Pred> _M_bad_char;
 };
 
   template
@@ -2316,7 +2316,7 @@ _GLIBCXX_MEM_FN_TRAITS(&&, false_type, true_type)
 
   _RAIter _M_pat;
   _RAIter _M_pat_end;
-  std::vector<__diff_type> _M_good_suffix;
+  _GLIBCXX_STD_C::vector<__diff_type> _M_good_suffix;
 };
 
   template