[Bug c++/69901] Iniitializing non-const global array variable from runtime const global variable does not copy all values properly

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |DUPLICATE

--- Comment #5 from Andrew Pinski  ---
And yes it is a dup of bug 67550.

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

[Bug c++/67550] [5/6 regression] Initialization of local struct array with elements of global array yields zeros instead of initializer values

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||piotrwn1 at gmail dot com

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

[Bug c++/69901] Iniitializing non-const global array variable from runtime const global variable does not copy all values properly

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
r231777 aka PR67550 fixed that.

[Bug fortran/69930] fortran address sanitizer does not work with optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
That is intentional.  The address sanitization is performed quite late and is
testing violations after many optimizations have done its job.  In this case,
the cddce1 pass turned the endless loop into an empty endless loop, which is a
valid transformation in that case.
If you want to catch violations that are closer to what you have in the source
code, use -O0 instead with -fsanitize=address.

[Bug c++/69901] Iniitializing non-const global array variable from runtime const global variable does not copy all values properly

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Piotr Nycz from comment #2)
> How to get information in which version it is fixed?
> What we discover ourselves:
> 4.9.1 - work
> 4.9.2 - fail
> 4.9.4 - work
> 5.2 - fail
> 6.0 (experimental) - work
> 
> I need to know the newest stable version where it is fixed. How can I get
> this knowledge?

You can run an inverse "git bisect" on the source tree for example.

[Bug fortran/65996] [5/6 Regression] gfortran ICE with -dH

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #14 from Jerry DeLisle  ---
Fixed, Closing

[Bug fortran/65996] [5/6 Regression] gfortran ICE with -dH

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed Feb 24 06:45:41 2016
New Revision: 233653

URL: https://gcc.gnu.org/viewcvs?rev=233653=gcc=rev
Log:
2016-02-23  Jerry DeLisle  

Backported from mainline
PR fortran/65996
* error.c (gfc_error): Save the state of abort_on_error and set
it to false for buffered errors to allow normal processing.
Restore the state before leaving.

PR fortran/65996
* gfortran.dg/pr65996.f90: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr65996.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/error.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
(In reply to Jason Merrill from comment #7)
> But if I add loop inversion back into the C++ front end
> so that the .optimized output is indistinguishable, that resolves the
> difference without LTO

Actually, no, the loop inversion patch in comment 8 doesn't improve
performance; even though the .optimized dump is the same between C and C++, the
C++ build is still slower by roughly the same amount.  I guess the RTL
optimizers must be doing something different?  Mysterious.  Unassigning myself.

[Bug c++/69912] [6 regression] ICE in build_ctor_subob_ref initializing a flexible array member

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01614.html

[PATCH] 69912 - [6 regression] ICE in build_ctor_subob_ref initializing a flexible array member

[Martin Sebor]

The attached patch removes the assumption that the initializer for
a flexible array member is an array of the same cv-qualified type
as the array, avoiding the ICE.

Martin
PR c++/69912 - [6 regression] ICE in build_ctor_subob_ref initializing
	a flexible array member

gcc/testsuite/ChangeLog:
2016-02-23  Martin Sebor  

	PR c++/69912
	* g++.dg/ext/flexary15.C: New test.

gcc/cp/ChangeLog:
2016-02-23  Martin Sebor  

	PR c++/69912
	* tree.c (build_ctor_subob_ref): Compare types' main variants
instead of the types as they are.

Index: gcc/cp/tree.c
===
--- gcc/cp/tree.c	(revision 233652)
+++ gcc/cp/tree.c	(working copy)
@@ -2592,8 +2592,10 @@ build_ctor_subob_ref (tree index, tree t
 	{
 	  /* When the destination object refers to a flexible array member
 	 verify that it matches the type of the source object except
-	 for its domain.  */
-	  gcc_assert (comptypes (type, objtype, COMPARE_REDECLARATION));
+	 for its domain and qualifiers.  */
+	  gcc_assert (comptypes (TYPE_MAIN_VARIANT (type),
+	  			 TYPE_MAIN_VARIANT (objtype),
+	  			 COMPARE_REDECLARATION));
 	}
   else
 	gcc_assert (same_type_ignoring_top_level_qualifiers_p (type, objtype));
Index: gcc/testsuite/g++.dg/ext/flexary15.C
===
--- gcc/testsuite/g++.dg/ext/flexary15.C	(revision 0)
+++ gcc/testsuite/g++.dg/ext/flexary15.C	(working copy)
@@ -0,0 +1,14 @@
+// PR c++/69912 - [6 regression] ICE in build_ctor_subob_ref initializing
+//a flexible array member
+// { dg-do compile }
+// { dg-options "-Wno-pedantic -Wno-write-strings -fpermissive" }
+
+struct S {
+  int n; 
+  char *a[];
+};
+
+void foo (const char *a)
+{
+  const S s = { 1, { a, "b" } };   // { dg-warning "invalid conversion" }
+}

[Bug tree-optimization/69935] load not hoisted out of linked-list traversal loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|load not skinked out of |load not hoisted out of
   |linked-list traversal loop  |linked-list traversal loop

--- Comment #2 from Andrew Pinski  ---
Full testcase (not needing the link; just in case it goes down):

struct foo {
  struct foo *n;
  int a;
};
struct foo_head {
  struct foo*h;
};


int traverse(struct foo_head *ph)
{
  int a = -1;
  struct foo *p, *pprev;
  pprev = p = ph->h;
  while (p) {
pprev = p;
p = p->n;
  }
  if (pprev)
a = pprev->a;
  return a;
}

int traverse_loadloop(struct foo_head *ph)
{
  int a = -1;
  struct foo *p = ph->h;
  while (p) {
a = p->a;
p = p->n;
  }
  return a;
}

[Bug tree-optimization/69935] load not skinked out of linked-list traversal loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|load not hoisted out of |load not skinked out of
   |linked-list traversal loop  |linked-list traversal loop

--- Comment #1 from Andrew Pinski  ---
This is not about hoisting rather sinking.

[Bug tree-optimization/69935] New: load not hoisted out of linked-list traversal loop

[peter at cordes dot ca]

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

Bug ID: 69935
   Summary: load not hoisted out of linked-list traversal loop
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---

(please check the component.  I guessed tree-optimization since it's
cross-architecture.)

gcc doesn't hoist the p->a load out of the loop in this linked-list function

int traverse_loadloop(struct foo_head *ph)
{
  int a = -1;
  struct foo *p = ph->h;
  while (p) {
a = p->a;
p = p->n;
  }
  return a;
}

I checked on godbolt with gcc 4.8 on ARM/PPC/ARM64, and gcc 4.5.3 for AVR.
For x86, gcc 5.3.0 -O3 on godbolt (http://goo.gl/r8vb5L) does this:

movq(%rdi), %rdx
movl$-1, %eax
testq   %rdx, %rdx
je  .L10
.L11:
movl8(%rdx), %eax ; load p->a inside the loop, not hoisted
movq(%rdx), %rdx
testq   %rdx, %rdx
jne .L11
.L10:
rep ret

This is nice and compact, but less hyperthreading-friendly than it could be. 
(The mov reg,reg alternative doesn't even take an execution unit on recent
CPUs).

The load of p->a every time through the loop might also delay the p->n load by
a cycle on CPUs with only one load port, or when there's a cache-bank conflict.
 This might take the loop from one iteration per 4c to one per 5c (if L1
load-use latency is 4c).

Clang hoists the load out of the loop, producing identical asm output for this
function and one with the load hoisted in the C source.  (The godbolt link has
both versions.  Also see bug 69933 which I just reported, since gcc showed a
separate branch-layout issue for the source-level hoisting version.)

Re: better debug info for C++ cdtors, aliases, thunks and other trampolines

[Alexandre Oliva]

Hi, Richard,

Thanks for the feedback.  I'm afraid I can't quite figure out what
you're getting at.  Please see below.

On Feb 22, 2016, Richard Biener  wrote:

> I think this breaks early-debug assumptions in creating new decl DIEs
> rather than just annotating old ones.

Can you elaborate on it, or point at where these assumptions you allude
to are documented?  I'm afraid I can't even tell whether the problem you
allude to has to do with users of the debug hooks interface or the
dwarf2out implementation thereof.

Sure enough, we haven't created DIEs for user-introduced or C++ cdtor
aliases before, so there are no DIEs for us to annotate, and there are
no other uses of the debug hooks interface related with them, that could
possibly interfere with them.

Conversely, alias decls for which we *have* created DIEs are ones that
cgraph turned into aliases; we do NOT want to pretend they're the same
function, and ideally we'd emit separate debug information for them, but
we can't retroactively figure out blocks, line numbers, variable
locations and whatnot for the unrelated function that happened to
optimize to the same executable code.  The best we can do for such
aliases ATM is to leave them alone; that's unchanged.

> So assemble_aliases is the wrong spot to do this.

Here, you seem to be talking about *users* of the debug hooks interface.
But then, I'd argue that the fact that debug info for aliases in
dwarf2out is implemented as DIEs is an internal implementation detail,
so why should assumptions made by the user side of the interface matter?

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer

[Bug rtl-optimization/69933] New: non-ideal branch layout for an early-out return

[peter at cordes dot ca]

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

Bug ID: 69933
   Summary: non-ideal branch layout for an early-out return
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---

(just guessing about this being an RTL bug, please reassign if it's
target-specific or something else).

This simple linked-list traversal compiles to slightly bulkier code than it
needs to:

int traverse(struct foo_head *ph)
{
  int a = -1;
  struct foo *p, *pprev;
  pprev = p = ph->h;
  while (p != NULL) {
pprev = p;
p = p->n;
  }
  if (pprev)
a = pprev->a;
  return a;
}

 (gcc 5.3.0 -O3 on godbolt: http://goo.gl/r8vb5L)

movq(%rdi), %rdx
movl$-1, %eax   ; only needs to happen in the early-out case
testq   %rdx, %rdx
jne .L3 ; jne/ret or je / fall through would be better
jmp .L9
.L5:
movq%rax, %rdx
.L3:
movq(%rdx), %rax
testq   %rax, %rax
jne .L5
movl8(%rdx), %eax
ret
.L9:
   ; ARM / PPC gcc 4.8.2 put the a=-1 down here
ret ; this is a rep ret without -mtune=intel


Clang 3.7 chooses a better layout with a je .early_out instead the jne / jmp. 
It arranges the loop so it can enter at the top.  It actually look pretty
optimal:

movq(%rdi), %rcx
movl$-1, %eax
testq   %rcx, %rcx
je  .LBB0_3
.LBB0_1:# %.lr.ph
movq%rcx, %rax
movq(%rax), %rcx
testq   %rcx, %rcx
jne .LBB0_1
movl8(%rax), %eax
.LBB0_3:# %._crit_edge.thread
retq

Getting the mov $-1 out of the common case would require a separate mov/ret
block after the normal ret, so it's a code-size tradeoff which isn't worth it,
because a mov-immediate is dirt cheap.

Anyway, there are a couple different ways to lay out the branches and the mov
$-1, %eax, but gcc's choice is in no way optimal. :(

GNU MPFR 3.1.4 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 3.1.4 ("canard à l'orange", patch level 4)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.tar.xz
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.tar.bz2
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.tar.gz
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.zip

The SHA1 digests:
c4b149a6e077974b11203f08c64122e0025730ba  mpfr-3.1.4-rc1.tar.bz2
29d7dfaa2d31d38256f430d40a5514ba1953d2d6  mpfr-3.1.4-rc1.tar.gz
28116be85b2875a1c8ca6c12c84a2efd44db0322  mpfr-3.1.4-rc1.tar.xz
85fbadfb19be45f8f9745316a55f35ca9e9cfe59  mpfr-3.1.4-rc1.zip

The SHA256 digests:
f42d3b38237b62e9c8d15affd971c6833910538a716e6684f9e11f9860e65e76  
mpfr-3.1.4-rc1.tar.bz2
71813f92c0d73b4f8e551ea4d10c0ccb93c62d9b6d2667a76570300f812a018c  
mpfr-3.1.4-rc1.tar.gz
e9b216906625cacdcbe9d89e0895609f6d990020746b4f22917c40f4bdef7ea7  
mpfr-3.1.4-rc1.tar.xz
90b685dd5ed738b5aa2a11ec4dcfc2dfc136632d0bfcf2a14e4726642daa1a56  
mpfr-3.1.4-rc1.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified
using the DSA key ID 98C3739D; this key can be retrieved with:

  gpg --recv-keys 98C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 3.1.3 to version 3.1.4:
- Improved MPFR manual.
- Bug fixes (see  and ChangeLog file).

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 3.1.4 should be released
around 2016-03-02.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Not a regression, postponed to GCC 7, last patch is at
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01303.html .

[Bug plugins/69758] [6 Regression] Plugins can't include params.h (missing params.list)

[pageexec at gmail dot com]

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

PaX Team  changed:

   What|Removed |Added

 CC||pageexec at gmail dot com

--- Comment #4 from PaX Team  ---
just for the record, this was also reported at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176#c20

[Bug plugins/61176] plugin builds including gimple.h not building

[pageexec at gmail dot com]

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

--- Comment #21 from PaX Team  ---
(In reply to PaX Team from comment #20)
> update for gcc-6: /gcc/params.list is also needed now as it gets
> included by params.h.

PR69758 fixes it.

[Bug fortran/60126] Internal compiler error with code using pointer reshaping (gfortran 4.8.2)

[mfvalin at gmail dot com]

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

--- Comment #3 from Michel Valin  ---
for what it's worth, the bug is not present in 4.9.1 nor 5.3

Michel Valin
analyste de l'informatique

On 16-02-23 05:30 PM, anlauf at gmx dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60126
>
> Harald Anlauf  changed:
>
>What|Removed |Added
> 
>  CC||anlauf at gmx dot de
>
> --- Comment #2 from Harald Anlauf  ---
> (In reply to Dominique d'Humieres from comment #1)
>> Confirmed with 4.7 and 4.8. It seems fixed on trunk between r201266
>> (2013-07-26, ICE) and r201631 (2013-08-09, OK). There are several commits in
>> this range without obvious suspect.
> If it's fixed - I do not see an ICE with 4.9/5/6 trunk - this
> bug should be closed.  Maybe we should add the testcase from
> comment #0 to the testsuite.
>

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Richard Smith]

On Tue, Feb 23, 2016 at 8:28 AM, H.J. Lu  wrote:
> On Tue, Feb 23, 2016 at 8:15 AM, Michael Matz  wrote:
>> Hi,
>>
>> On Tue, 23 Feb 2016, H.J. Lu wrote:
>>
>>> I thought
>>>
>>> ---
>>> An empty type is a type where it and all of its subobjects (recursively)
>>> are of class, structure, union, or array type.
>>> ---
>>>
>>> excluded
>>>
>>> struct empty
>>> {
>>> empty () = default;
>>> };
>>
>>
>> Why would that be excluded?  There are no subobjects, hence all of them
>> are of class, structure, union or array type, hence this is an empty type.
>> (And that's good, it indeed looks quite empty to me).  Even if you would
>> add a non-trivial copy ctor, making this thing not trivially copyable
>> anymore, it would still be empty.  Hence, given your proposed language in
>> the psABI, without reference to any other ABI (in particular not to the
>> Itanium C++ ABI), you would then need to pass it without registers.  That
>> can't be done, and that's exactly why I find that wording incomplete.  It
>> needs implicit references to other languages ABIs to work.
>>
>
> It is clear to me now.  Let's go with
>
> ---
> An empty type is a type where it and all of its subobjects (recursively)
> are of class, structure, union, or array type.  No memory slot nor
> register should be used to pass or return an object of empty type that's
> trivially copyable.
> ---
>
> Any comments?

Yes. "trivially copyable" is the wrong restriction. See
http://mentorembedded.github.io/cxx-abi/abi.html#normal-call for the
actual Itanium C++ ABI rule.

It's also completely nonsensical to mention this as a special case in
relation to empty types. The special case applies to all function
parameters, irrespective of whether they're empty -- this rule applies
*long* before you consider whether the type is empty. For instance, in
the x86-64 psABI, this should go right at the start of section 2.2.3
("Parameter Passing and Returning Values"). But please don't add it
there -- it's completely redundant, as section 5.1 already says that
the Itanium C++ ABI is used, so it's not necessary to duplicate rules
from there.

[Bug tree-optimization/69932] New: gcc ICE at -O1 and above on valid code on x86_64-linux-gnu with “seg fault”

[helloqirun at gmail dot com]

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

Bug ID: 69932
   Summary: gcc ICE at -O1 and above on valid code on
x86_64-linux-gnu with “seg fault”
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following valid code causes an ICE when compiled with the current gcc trunk
at -O1 and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.


$ gcc-trunk  -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160223 (experimental) [trunk revision 233632] (GCC) 



$ gcc-trunk abc.c -c -O3
abc.c: In function ‘fn1’:
abc.c:8:1: internal compiler error: Segmentation fault
 }
 ^
0xb5ea1f crash_signal
../../gcc/gcc/toplev.c:335
0xbacab3 get_ref_base_and_extent(tree_node*, long*, long*, long*, bool*)
../../gcc/gcc/tree-dfa.c:392
0xc442da get_access_for_expr
../../gcc/gcc/tree-sra.c:2903
0xc4a97b sra_modify_assign
../../gcc/gcc/tree-sra.c:3314
0xc4a97b sra_modify_function_body
../../gcc/gcc/tree-sra.c:3621
0xc4a97b perform_intra_sra
../../gcc/gcc/tree-sra.c:3731
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.


$ cat abc.c
int a;
void fn1() {
  int b = 4;
  short c[4];
  c[b] = c[a];
  if (c[2]) {}

}

Re: Fix/work around PR57676, LRA terminates prematurely

[Vladimir Makarov]

On 02/23/2016 06:56 AM, Richard Biener wrote:

On Mon, Feb 22, 2016 at 4:34 PM, Jeff Law  wrote:

On 02/22/2016 07:34 AM, Richard Biener wrote:


Hum, but then you get to "inifinite" compiles again when LRA is buggy
or the user presents it with an impossible to handle asm.

Neither should be happening in practice, even an impossible asm should cause
LRA to halt in some way or another.

In practice looping has occurred due to bugs in machine descriptions are are
typically seen during development/porting.  Hence the desire to put it under
-fchecking for gcc-6 and possibly implement something smarter for gcc-7
(where we'd track more precisely whether or not we're making forward
progress).


I don't think that's a good idea - maybe bumping the limit is the way to
go instead?

No, because one just needs to build a longer chain of insns needing
reloading.


30 constraint passes sounds excessive and a sign of a bug to me anyway.

Not really.  If you look at the testcase and the chain of reloads, it's
legitimate.  Essentially each pass exposes a case where spill a register in
an insn that previously had a register allocated.

But requiring another full reload pass to handle such chains is pointing at
a wrong algorithm IMHO.  Isn't this also quadratic in the length of the chain?

This is a pathological case.  It is not quadratic although we have 
quadratic algorithms already in GCC.  IRA building conflict graphs (as 
the old global.c)  can be quadratic for some pathological cases.  
Actually reload + IRA can be slow as LRA for this case too if we takes 
into account that reload is asking IRA to reallocate a spilled pseudo 
each time.


But you are right for this case we can speed up LRA for such cases 
considering rebuilding live info only for places where there are 
changes.  Probably it will speed up most other cases too.

[Bug fortran/69930] fortran address sanitizer does not work with optimization

[dominiq at lps dot ens.fr]

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

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

[Bug fortran/69931] fortran address sanitizer does not work with optimization

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Dup.

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

[Bug c++/69901] Iniitializing non-const global array variable from runtime const global variable does not copy all values properly

[piotrwn1 at gmail dot com]

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

--- Comment #2 from Piotr Nycz  ---
How to get information in which version it is fixed?
What we discover ourselves:
4.9.1 - work
4.9.2 - fail
4.9.4 - work
5.2 - fail
6.0 (experimental) - work

I need to know the newest stable version where it is fixed. How can I get this
knowledge?

[Bug fortran/69931] New: fortran address sanitizer does not work with optimization

[physiker at toast2 dot net]

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

Bug ID: 69931
   Summary: fortran address sanitizer does not work with
optimization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---

When the code bnd11.f90, included in polyhedrons linux fortran testsuite, is
compiled without optimization the address sanitizer catches the error. With
optimization turned on, the address sanitizer does not spot the error. The
execution of the program is not stopped by the sanitizer.

bash-3.2$ gfortran-6 -v -W -Wall bnd11.f90 -fsanitize=address -o bnd11
Driving: gfortran-6 -v -W -Wall bnd11.f90 -fsanitize=address -o bnd11
-mmacosx-version-min=10.9.4 -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran-6
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc/configure --enable-languages=c,c++,fortran,lto
--with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw
--with-system-zlib --program-suffix=-6
Thread model: posix
gcc version 6.0.0 20160213 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-Wextra' '-Wall' '-fsanitize=address' '-o' 'bnd11'
'-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/f951 bnd11.f90 -fPIC
-quiet -dumpbase bnd11.f90 -mmacosx-version-min=10.9.4 -mtune=core2 -auxbase
bnd11 -Wextra -Wall -version -fsanitize=address -fintrinsic-modules-path
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccqDq0Sb.s
GNU Fortran (GCC) version 6.0.0 20160213 (experimental)
(x86_64-apple-darwin13.4.0)
compiled by GNU C version 6.0.0 20160213 (experimental), GMP version
6.1.0, MPFR version 3.1.3, MPC version 1.0.3, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 6.0.0 20160213 (experimental)
(x86_64-apple-darwin13.4.0)
compiled by GNU C version 6.0.0 20160213 (experimental), GMP version
6.1.0, MPFR version 3.1.3, MPC version 1.0.3, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
COLLECT_GCC_OPTIONS='-v' '-Wextra' '-Wall' '-fsanitize=address' '-o' 'bnd11'
'-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2'
 as -arch x86_64 -force_cpusubtype_ALL -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccSUHTPj.o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccqDq0Sb.s
Reading specs from
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/../../../libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-v' '-Wextra' '-Wall' '-fsanitize=address' '-o' 'bnd11'
'-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2'
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/:/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/:/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/:/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/:/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/../../../
COLLECT_GCC_OPTIONS='-v' '-Wextra' '-Wall' '-fsanitize=address' '-o' 'bnd11'
'-mmacosx-version-min=10.9.4' '-shared-libgcc' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/collect2 -dynamic -arch
x86_64 -macosx_version_min 10.9.4 -weak_reference_mismatches non-weak -o bnd11
-L/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0
-L/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/../../..
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccSUHTPj.o -lgfortran -lasan
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5
-lgcc -lSystem -v
collect2 version 6.0.0 20160213 (experimental)
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.9.4
-weak_reference_mismatches non-weak -o bnd11
-L/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0
-L/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/../../..
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccSUHTPj.o -lgfortran -lasan
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5
-lgcc -lSystem -v
@(#)PROGRAM:ld  PROJECT:ld64-241.9
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h
armv6m armv7m armv7em
Library search paths:
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0
/usr/local/lib
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
 /usr/bin/nm -n /var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccSUHTPj.o
bash-3.2$ ./bnd11
=
==643==ERROR: 

[Bug fortran/69930] New: fortran address sanitizer does not work with optimization

[physiker at toast2 dot net]

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

Bug ID: 69930
   Summary: fortran address sanitizer does not work with
optimization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---

Created attachment 37776
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37776=edit
Source code

When the code bnd11.f90, included in polyhedrons linux fortran testsuite, is
compiled without optimization the address sanitizer catches the error. With
optimization turned on, the address sanitizer does not spot the error. The
execution of the program is not stopped by the sanitizer.
bash-3.2$ gfortran -v -W -Wall bnd11.f90 -fsanitize=address -o bnd11
Driving: gfortran -mmacosx-version-min=10.9.4 -v -W -Wall bnd11.f90
-fsanitize=address -o bnd11 -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/5.3.0/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc-5.3.0/configure --prefix=/sw --prefix=/sw/lib/gcc5
--mandir=/sw/share/man --infodir=/sw/lib/gcc5/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
--program-suffix=-fsf-5
Thread model: posix
gcc version 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.4' '-v' '-Wextra' '-Wall'
'-fsanitize=address' '-o' 'bnd11' '-shared-libgcc' '-mtune=core2'
 /sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/5.3.0/f951 bnd11.f90 -fPIC
-quiet -dumpbase bnd11.f90 -mmacosx-version-min=10.9.4 -mtune=core2 -auxbase
bnd11 -Wextra -Wall -version -fsanitize=address -fintrinsic-modules-path
/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccqRKgpk.s
GNU Fortran (GCC) version 5.3.0 (x86_64-apple-darwin13.4.0)
compiled by GNU C version 5.3.0, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3
warning: GMP header version 6.0.0 differs from library version 6.1.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 5.3.0 (x86_64-apple-darwin13.4.0)
compiled by GNU C version 5.3.0, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3
warning: GMP header version 6.0.0 differs from library version 6.1.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.4' '-v' '-Wextra' '-Wall'
'-fsanitize=address' '-o' 'bnd11' '-shared-libgcc' '-mtune=core2'
 as -arch x86_64 -force_cpusubtype_ALL -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccmU9RIS.o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccqRKgpk.s
Reading specs from
/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/../../../libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.4' '-v' '-Wextra' '-Wall'
'-fsanitize=address' '-o' 'bnd11' '-shared-libgcc' '-mtune=core2'
COMPILER_PATH=/sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/5.3.0/:/sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/5.3.0/:/sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/:/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/:/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/
LIBRARY_PATH=/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/:/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.4' '-v' '-Wextra' '-Wall'
'-fsanitize=address' '-o' 'bnd11' '-shared-libgcc' '-mtune=core2'
 /sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/5.3.0/collect2 -dynamic
-arch x86_64 -macosx_version_min 10.9.4 -weak_reference_mismatches non-weak -o
bnd11 -L/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0
-L/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/../../..
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccmU9RIS.o -lgfortran -lasan
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5
-lgcc -lSystem -v
collect2 version 5.3.0
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.9.4
-weak_reference_mismatches non-weak -o bnd11
-L/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0
-L/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/../../..
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccmU9RIS.o -lgfortran -lasan
-no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lquadmath -lm -lgcc_ext.10.5
-lgcc -lSystem -v
@(#)PROGRAM:ld  PROJECT:ld64-241.9
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h
armv6m armv7m armv7em
Library search paths:
/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0
/sw/lib/gcc5/lib
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Fixed on trunk, back port in a few days.

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Feb 23 22:53:31 2016
New Revision: 233649

URL: https://gcc.gnu.org/viewcvs?rev=233649=gcc=rev
Log:
2016-02-23  Jerry DeLisle  

PR fortran/61156
* scanner.c (add_path_to_list): If include path is not a directory,
issue a fatal error.

PR fortran/61156
* gfortran.dg/include_6.f90: Update test.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/scanner.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/include_6.f90

[Bug fortran/69929] New: Internal compiler error GCC$ ATTRIBUTES STDCALL

[physiker at toast2 dot net]

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

Bug ID: 69929
   Summary: Internal compiler error GCC$ ATTRIBUTES STDCALL
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---

Created attachment 37775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37775=edit
Source code

Compiling the file win_gnu_dynlib.f90 causes an internal compiler error.The 
GCC$ ATTRIBUTES STDCALL lines (for windows) are causing the crash.

gfortran-6 -c -v win_gnu_dynlib.f90 
Using built-in specs.
COLLECT_GCC=gfortran-6
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc/configure --enable-languages=c,c++,fortran,lto
--with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw
--with-system-zlib --program-suffix=-6
Thread model: posix
gcc version 6.0.0 20160213 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-c' '-v' '-mmacosx-version-min=10.9.4' '-mtune=core2'
 /usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/6.0.0/f951 win_gnu_dynlib.f90
-fPIC -quiet -dumpbase win_gnu_dynlib.f90 -mmacosx-version-min=10.9.4
-mtune=core2 -auxbase win_gnu_dynlib -version -fintrinsic-modules-path
/usr/local/lib/gcc/x86_64-apple-darwin13.4.0/6.0.0/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//ccVTJ6eT.s
GNU Fortran (GCC) version 6.0.0 20160213 (experimental)
(x86_64-apple-darwin13.4.0)
compiled by GNU C version 6.0.0 20160213 (experimental), GMP version
6.1.0, MPFR version 3.1.3, MPC version 1.0.3, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran2008 (GCC) version 6.0.0 20160213 (experimental)
(x86_64-apple-darwin13.4.0)
compiled by GNU C version 6.0.0 20160213 (experimental), GMP version
6.1.0, MPFR version 3.1.3, MPC version 1.0.3, isl version 0.14 or 0.13
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
'
win_gnu_dynlib.f90:76:0:

 cproc = c_get_procedure( handle, cname )

in pp_format, at pretty-print.c:635

Internal compiler error: Error reporting routines re-entered.
gfortran-6: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Re: [patch, libstdc++] In debug mode, diagnose empty initializer_list in min/max/minmax

[Jonathan Wakely]

On 23/02/16 22:03 +0100, Eelis wrote:

The std::min, std::max, and std::minmax overloads that take a 
std::initializer_list all require that the list is not empty. The attached 
patch adds debug mode checks for this.


Nice, thanks for the patch.


Thanks,

Eelis



Index: libstdc++-v3/include/debug/formatter.h
===
--- libstdc++-v3/include/debug/formatter.h  (revision 233636)
+++ libstdc++-v3/include/debug/formatter.h  (working copy)
@@ -87,6 +87,8 @@
__msg_splice_bad,
__msg_splice_other,
__msg_splice_overlap,
+// std::initializer_list checks
+__msg_empty_init_list,
// iterator checks
__msg_init_singular,
__msg_init_copy_singular,
Index: libstdc++-v3/src/c++11/debug.cc
===
--- libstdc++-v3/src/c++11/debug.cc (revision 233636)
+++ libstdc++-v3/src/c++11/debug.cc (working copy)
@@ -139,6 +139,8 @@
"attempt to splice an iterator from a different container",
"splice destination %1.name;"
" occurs within source range [%2.name;, %3.name;)",
+// std::initializer_list checks
+"%1;(): empty initializer_list",
// iterator checks
"attempt to initialize an iterator that will immediately become singular",
"attempt to copy-construct an iterator from a singular iterator",


New entries should go at the end, so you don't alter the positions of
existing entries.



Index: libstdc++-v3/include/debug/macros.h
===
--- libstdc++-v3/include/debug/macros.h (revision 233636)
+++ libstdc++-v3/include/debug/macros.h (working copy)
@@ -69,6 +69,12 @@
  ._M_iterator(_First, #_First) \
  ._M_iterator(_Last, #_Last))

+// Verify that the initializer_list is non-empty.
+#define __glibcxx_check_non_empty_init_list(_List) \
+_GLIBCXX_DEBUG_VERIFY(_List.size() != 0,   \
+ _M_message(__gnu_debug::__msg_empty_init_list)\
+ ._M_string(__func__))
+
/** Verify that we can insert into *this with the iterator _Position.
 *  Insertion into a container at a specific position requires that
 *  the iterator be nonsingular, either dereferenceable or past-the-end,
Index: libstdc++-v3/include/debug/debug.h
===
--- libstdc++-v3/include/debug/debug.h  (revision 233636)
+++ libstdc++-v3/include/debug/debug.h  (working copy)
@@ -62,6 +62,7 @@

# define __glibcxx_requires_cond(_Cond,_Msg)
# define __glibcxx_requires_valid_range(_First,_Last)
+# define __glibcxx_requires_non_empty_init_list(_List)
# define __glibcxx_requires_sorted(_First,_Last)
# define __glibcxx_requires_sorted_pred(_First,_Last,_Pred)
# define __glibcxx_requires_sorted_set(_First1,_Last1,_First2)


This should be enabled for _GLIBCXX_ASSERTIONS not only
_GLIBCXX_DEBUG.

Otherwise this looks good, but will have to wait until after the GCC 6
release now. If I forget about it please send a ping email to remind
us once GCC 6 has been released, thanks.

gcc-5-20160223 is now available

[gccadmin]

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

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

You'll find:

 gcc-5-20160223.tar.bz2   Complete GCC

  MD5=ca142ce6e52c392a4b7cd388e08ca07e
  SHA1=13b7c4de9da654ef968e658c77e32b265aa4eb5b

Diffs from 5-20160216 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
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/60126] Internal compiler error with code using pointer reshaping (gfortran 4.8.2)

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed with 4.7 and 4.8. It seems fixed on trunk between r201266
> (2013-07-26, ICE) and r201631 (2013-08-09, OK). There are several commits in
> this range without obvious suspect.

If it's fixed - I do not see an ICE with 4.9/5/6 trunk - this
bug should be closed.  Maybe we should add the testcase from
comment #0 to the testsuite.

[Bug target/69810] PowerPC64: unrecognizable insn

[dje at gcc dot gnu.org]

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

--- Comment #8 from David Edelsohn  ---
Author: dje
Date: Tue Feb 23 22:28:23 2016
New Revision: 233648

URL: https://gcc.gnu.org/viewcvs?rev=233648=gcc=rev
Log:
PR target/69810
* config/rs6000/rs6000.md (zero_extendqi2_dot): Convert from
define_insn_and_split to define_insn.
(zero_extendqi2_dot2): Same.
(extendqi2_dot): Same.
(extendqi2_dot2): Same.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.md

[Bug libstdc++/69893] [6 Regression] Conflicting declarations in and

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed

[PATCH] Fix PR target/69810

[David Edelsohn]

Anton reported a latent bug in the rs6000 port discovered with csmith.
Splitters for extendqihi2 and zero_extendqihi2 can generate invalid
compare RTL.  PowerPC can load and store bytes or halfwords, but
computations operate on registers.  Currently the extend patterns
exist for HImode, although no instructions directly operate on
registers in that mode.

For GCC 7, I plan to disable the extendqihi2 and zero_extendqihi2
patterns, forcing GCC to use SUBREGs, but that is too dangerous for
Stage 4.

In the interim, this patch converts the splitters to normal combiner
patterns that directly emit the two instruction sequence when cr0 is
not available.  There is not a lot of scheduling opportunity after the
splitter, so not a huge degradation.  The temporary is allocated as
HImode, but always is a full register.  The compare is hard coded as
cmpw, but the condition bits will be the same for sign-extended or
zero-extended QImode whether the register is interpreted as word or
doubleword.

PR target/69810
* config/rs6000/rs6000.md (zero_extendqi2_dot): Convert from
define_insn_and_split to define_insn.
(zero_extendqi2_dot2): Same.
(extendqi2_dot): Same.
(extendqi2_dot2): Same.

Bootstrapped on powerpc-ibm-aix7.1.0.0 and powerpc64le-linux.

Thanks, David
Index: rs6000.md
===
--- rs6000.md   (revision 232439)
+++ rs6000.md   (working copy)
@@ -701,7 +701,7 @@
rlwinm %0,%1,0,0xff"
   [(set_attr "type" "load,shift")])
 
-(define_insn_and_split "*zero_extendqi2_dot"
+(define_insn "*zero_extendqi2_dot"
   [(set (match_operand:CC 2 "cc_reg_operand" "=x,?y")
(compare:CC (zero_extend:EXTQI (match_operand:QI 1 "gpc_reg_operand" 
"r,r"))
(const_int 0)))
@@ -709,19 +709,12 @@
   "rs6000_gen_cell_microcode"
   "@
andi. %0,%1,0xff
-   #"
-  "&& reload_completed && cc_reg_not_cr0_operand (operands[2], CCmode)"
-  [(set (match_dup 0)
-   (zero_extend:EXTQI (match_dup 1)))
-   (set (match_dup 2)
-   (compare:CC (match_dup 0)
-   (const_int 0)))]
-  ""
+   rlwinm %0,%1,0,0xff\;cmpwi %2,%0,0"
   [(set_attr "type" "logical")
(set_attr "dot" "yes")
(set_attr "length" "4,8")])
 
-(define_insn_and_split "*zero_extendqi2_dot2"
+(define_insn "*zero_extendqi2_dot2"
   [(set (match_operand:CC 2 "cc_reg_operand" "=x,?y")
(compare:CC (zero_extend:EXTQI (match_operand:QI 1 "gpc_reg_operand" 
"r,r"))
(const_int 0)))
@@ -730,14 +723,7 @@
   "rs6000_gen_cell_microcode"
   "@
andi. %0,%1,0xff
-   #"
-  "&& reload_completed && cc_reg_not_cr0_operand (operands[2], CCmode)"
-  [(set (match_dup 0)
-   (zero_extend:EXTQI (match_dup 1)))
-   (set (match_dup 2)
-   (compare:CC (match_dup 0)
-   (const_int 0)))]
-  ""
+   rlwinm %0,%1,0,0xff\;cmpwi %2,%0,0"
   [(set_attr "type" "logical")
(set_attr "dot" "yes")
(set_attr "length" "4,8")])
@@ -855,7 +841,7 @@
   "extsb %0,%1"
   [(set_attr "type" "exts")])
 
-(define_insn_and_split "*extendqi2_dot"
+(define_insn "*extendqi2_dot"
   [(set (match_operand:CC 2 "cc_reg_operand" "=x,?y")
(compare:CC (sign_extend:EXTQI (match_operand:QI 1 "gpc_reg_operand" 
"r,r"))
(const_int 0)))
@@ -863,19 +849,12 @@
   "rs6000_gen_cell_microcode"
   "@
extsb. %0,%1
-   #"
-  "&& reload_completed && cc_reg_not_cr0_operand (operands[2], CCmode)"
-  [(set (match_dup 0)
-   (sign_extend:EXTQI (match_dup 1)))
-   (set (match_dup 2)
-   (compare:CC (match_dup 0)
-   (const_int 0)))]
-  ""
+   extsb %0,%1\;cmpwi %2,%0,0"
   [(set_attr "type" "exts")
(set_attr "dot" "yes")
(set_attr "length" "4,8")])
 
-(define_insn_and_split "*extendqi2_dot2"
+(define_insn "*extendqi2_dot2"
   [(set (match_operand:CC 2 "cc_reg_operand" "=x,?y")
(compare:CC (sign_extend:EXTQI (match_operand:QI 1 "gpc_reg_operand" 
"r,r"))
(const_int 0)))
@@ -884,14 +863,7 @@
   "rs6000_gen_cell_microcode"
   "@
extsb. %0,%1
-   #"
-  "&& reload_completed && cc_reg_not_cr0_operand (operands[2], CCmode)"
-  [(set (match_dup 0)
-   (sign_extend:EXTQI (match_dup 1)))
-   (set (match_dup 2)
-   (compare:CC (match_dup 0)
-   (const_int 0)))]
-  ""
+   extsb %0,%1\;cmpwi %2,%0,0"
   [(set_attr "type" "exts")
(set_attr "dot" "yes")
(set_attr "length" "4,8")])

[Bug c++/69925] No warning for uninitialized char * passing to function as const char *

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #3 from Manuel López-Ibáñez  ---
Dup of PR10138, but probably need to fix PR33086 first.

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

[Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||developm...@faf-ltd.com

--- Comment #24 from Manuel López-Ibáñez  ---
*** Bug 69925 has been marked as a duplicate of this bug. ***

[Bug c++/69925] No warning for uninitialized char * passing to function as const char *

[developm...@faf-ltd.com]

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

--- Comment #2 from Peter VARGA  ---
I expected honestly this answer but then almost every compiler warning can be
"overruled" by a bad programmer.

By the way I found out this behavior because I used it in STL and there is
almost every parameter const when it makes sense.

[COMMITTED][AArch64] Tweak the pipeline model for Exynos M1

[Evandro Menezes]

Minor tweaks to the cost and scheduling models for Exynos M1.

Committed as r233646 and r233647.

--
Evandro Menezes

>From ab6127823e706361315f1c8b87fb4c32bc299b65 Mon Sep 17 00:00:00 2001
From: evandro 
Date: Tue, 23 Feb 2016 20:21:23 +
Subject: [PATCH 1/2] * gcc/config/aarch64/aarch64.c
 (exynosm1_tunings): Enable the Newton series for reciprocal square
 root in Exynos M1.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@233646 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog| 5 +
 gcc/config/aarch64/aarch64.c | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 3c629ef..22dd022 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2016-02-23  Evandro Menezes  
+
+* config/aarch64/aarch64.c (exynosm1_tunings): Enable the Newton
+series for reciprocal square root in Exynos M1.
+
 2016-02-23  Martin Sebor  
 
 	PR c/69759
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 923a4b3..dc3dfea 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -538,7 +538,7 @@ static const struct tune_params exynosm1_tunings =
   48,	/* max_case_values.  */
   64,	/* cache_line_size.  */
   tune_params::AUTOPREFETCHER_OFF, /* autoprefetcher_model.  */
-  (AARCH64_EXTRA_TUNE_NONE) /* tune_flags.  */
+  (AARCH64_EXTRA_TUNE_RECIP_SQRT) /* tune_flags.  */
 };
 
 static const struct tune_params thunderx_tunings =
-- 
1.9.1

>From 01cadc5b883a2613f847aa7a88b86aed454d9413 Mon Sep 17 00:00:00 2001
From: evandro 
Date: Tue, 23 Feb 2016 21:31:00 +
Subject: [PATCH 2/2] Tweak the pipeline model for Exynos M1

gcc/
	* config/aarch64/aarch64.c (exynosm1_tunings): Enable fusion of AES{D,E}
	and AESMC pairs.
	* config/arm/exynos-m1.md: Change cost of STP, fix bypass for stores
	and add bypass for AES{D,E} and AESMC pairs.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@233647 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog|  7 +++
 gcc/config/aarch64/aarch64.c |  2 +-
 gcc/config/arm/exynos-m1.md  | 26 +-
 3 files changed, 25 insertions(+), 10 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 22dd022..07b50b5 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,12 @@
 2016-02-23  Evandro Menezes  
 
+	* config/arm/exynos-m1.md: Change cost of STP, fix bypass for stores
+	and add bypass for AES{D,E} and AESMC pairs.
+	* config/aarch64/aarch64.c (exynosm1_tunings): Enable fusion of AES{D,E}
+	and AESMC pairs.
+
+2016-02-23  Evandro Menezes  
+
 * config/aarch64/aarch64.c (exynosm1_tunings): Enable the Newton
 series for reciprocal square root in Exynos M1.
 
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index dc3dfea..6dc8330 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -526,7 +526,7 @@ static const struct tune_params exynosm1_tunings =
   _branch_cost,
   4,	/* memmov_cost  */
   3,	/* issue_rate  */
-  (AARCH64_FUSE_NOTHING), /* fusible_ops  */
+  (AARCH64_FUSE_AES_AESMC), /* fusible_ops  */
   4,	/* function_align.  */
   4,	/* jump_align.  */
   4,	/* loop_align.  */
diff --git a/gcc/config/arm/exynos-m1.md b/gcc/config/arm/exynos-m1.md
index 2f52b22..318b151 100644
--- a/gcc/config/arm/exynos-m1.md
+++ b/gcc/config/arm/exynos-m1.md
@@ -248,10 +248,6 @@
 	  (eq_attr "type" "neon_load4_all_lanes, neon_load4_all_lanes_q")
 	(const_string "neon_load4_all")
 
-	  (eq_attr "type" "f_stores, f_stored,\
-			   neon_stp, neon_stp_q")
-	(const_string "neon_store")
-
 	  (eq_attr "type" "neon_store1_1reg, neon_store1_1reg_q")
 	(const_string "neon_store1_1")
 
@@ -730,8 +726,14 @@
 (define_insn_reservation
   "exynos_m1_neon_store" 1
   (and (eq_attr "tune" "exynosm1")
-   (eq_attr "exynos_m1_neon_type" "neon_store"))
-  "(em1_fst, em1_st)")
+   (eq_attr "type" "f_stores, f_stored, neon_stp"))
+  "em1_sfst")
+
+(define_insn_reservation
+  "exynos_m1_neon_store_q" 3
+  (and (eq_attr "tune" "exynosm1")
+   (eq_attr "type" "neon_stp_q"))
+  "(em1_sfst * 2)")
 
 (define_insn_reservation
   "exynos_m1_neon_store1_1" 1
@@ -761,7 +763,7 @@
   "exynos_m1_neon_store1_one" 7
   (and (eq_attr "tune" "exynosm1")
(eq_attr "exynos_m1_neon_type" "neon_store1_one"))
-  "(em1_fst, em1_st)")
+  "em1_sfst")
 
 (define_insn_reservation
   "exynos_m1_neon_store2" 7
@@ -892,7 +894,9 @@
 
 ;; Pre-decrement and post-increment addressing modes update the register quickly.
 ;; TODO: figure out how to tell the addressing mode register from the loaded one.
-(define_bypass 1 "exynos_m1_store*" "exynos_m1_store*")
+(define_bypass 1 "exynos_m1_store*, exynos_m1_neon_store*"
+		 "exynos_m1_store*, exynos_m1_neon_store*,
+		  exynos_m1_load*, 

[Bug web/69928] incorrect reference to gcc-plugin.h in plugin documentation

[petensotium at gmail dot com]

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

petensotium at gmail dot com changed:

   What|Removed |Added

   Severity|normal  |minor

[patch, libstdc++] In debug mode, diagnose empty initializer_list in min/max/minmax

[Eelis]

The std::min, std::max, and std::minmax overloads that take a 
std::initializer_list all require that the list is not empty. The attached 
patch adds debug mode checks for this.

Thanks,

Eelis
Index: libstdc++-v3/include/debug/formatter.h
===
--- libstdc++-v3/include/debug/formatter.h	(revision 233636)
+++ libstdc++-v3/include/debug/formatter.h	(working copy)
@@ -87,6 +87,8 @@
 __msg_splice_bad,
 __msg_splice_other,
 __msg_splice_overlap,
+// std::initializer_list checks
+__msg_empty_init_list,
 // iterator checks
 __msg_init_singular,
 __msg_init_copy_singular,
Index: libstdc++-v3/src/c++11/debug.cc
===
--- libstdc++-v3/src/c++11/debug.cc	(revision 233636)
+++ libstdc++-v3/src/c++11/debug.cc	(working copy)
@@ -139,6 +139,8 @@
 "attempt to splice an iterator from a different container",
 "splice destination %1.name;"
 " occurs within source range [%2.name;, %3.name;)",
+// std::initializer_list checks
+"%1;(): empty initializer_list",
 // iterator checks
 "attempt to initialize an iterator that will immediately become singular",
 "attempt to copy-construct an iterator from a singular iterator",
Index: libstdc++-v3/include/debug/macros.h
===
--- libstdc++-v3/include/debug/macros.h	(revision 233636)
+++ libstdc++-v3/include/debug/macros.h	(working copy)
@@ -69,6 +69,12 @@
 		  ._M_iterator(_First, #_First)			\
 		  ._M_iterator(_Last, #_Last))
 
+// Verify that the initializer_list is non-empty.
+#define __glibcxx_check_non_empty_init_list(_List)			\
+_GLIBCXX_DEBUG_VERIFY(_List.size() != 0,\
+		  _M_message(__gnu_debug::__msg_empty_init_list)	\
+		  ._M_string(__func__))
+
 /** Verify that we can insert into *this with the iterator _Position.
  *  Insertion into a container at a specific position requires that
  *  the iterator be nonsingular, either dereferenceable or past-the-end,
Index: libstdc++-v3/include/debug/debug.h
===
--- libstdc++-v3/include/debug/debug.h	(revision 233636)
+++ libstdc++-v3/include/debug/debug.h	(working copy)
@@ -62,6 +62,7 @@
 
 # define __glibcxx_requires_cond(_Cond,_Msg)
 # define __glibcxx_requires_valid_range(_First,_Last)
+# define __glibcxx_requires_non_empty_init_list(_List)
 # define __glibcxx_requires_sorted(_First,_Last)
 # define __glibcxx_requires_sorted_pred(_First,_Last,_Pred)
 # define __glibcxx_requires_sorted_set(_First1,_Last1,_First2)
@@ -99,6 +100,8 @@
 # define __glibcxx_requires_cond(_Cond,_Msg) _GLIBCXX_DEBUG_VERIFY(_Cond,_Msg)
 # define __glibcxx_requires_valid_range(_First,_Last)	\
   __glibcxx_check_valid_range(_First,_Last)
+# define __glibcxx_requires_non_empty_init_list(_List)	\
+  __glibcxx_check_non_empty_init_list(_List)
 # define __glibcxx_requires_non_empty_range(_First,_Last)	\
   __glibcxx_check_non_empty_range(_First,_Last)
 # define __glibcxx_requires_sorted(_First,_Last)	\
Index: libstdc++-v3/include/bits/stl_algo.h
===
--- libstdc++-v3/include/bits/stl_algo.h	(revision 233636)
+++ libstdc++-v3/include/bits/stl_algo.h	(working copy)
@@ -3452,25 +3452,37 @@
 _GLIBCXX14_CONSTEXPR
 inline _Tp
 min(initializer_list<_Tp> __l)
-{ return *std::min_element(__l.begin(), __l.end()); }
+{
+  __glibcxx_requires_non_empty_init_list(__l);
+  return *std::min_element(__l.begin(), __l.end());
+}
 
   template
 _GLIBCXX14_CONSTEXPR
 inline _Tp
 min(initializer_list<_Tp> __l, _Compare __comp)
-{ return *std::min_element(__l.begin(), __l.end(), __comp); }
+{
+  __glibcxx_requires_non_empty_init_list(__l);
+  return *std::min_element(__l.begin(), __l.end(), __comp);
+}
 
   template
 _GLIBCXX14_CONSTEXPR
 inline _Tp
 max(initializer_list<_Tp> __l)
-{ return *std::max_element(__l.begin(), __l.end()); }
+{
+  __glibcxx_requires_non_empty_init_list(__l);
+  return *std::max_element(__l.begin(), __l.end());
+}
 
   template
 _GLIBCXX14_CONSTEXPR
 inline _Tp
 max(initializer_list<_Tp> __l, _Compare __comp)
-{ return *std::max_element(__l.begin(), __l.end(), __comp); }
+{
+  __glibcxx_requires_non_empty_init_list(__l);
+  return *std::max_element(__l.begin(), __l.end(), __comp);
+}
 
   template
 _GLIBCXX14_CONSTEXPR
@@ -3477,6 +3489,7 @@
 inline pair<_Tp, _Tp>
 minmax(initializer_list<_Tp> __l)
 {
+  __glibcxx_requires_non_empty_init_list(__l);
   pair __p =
 	std::minmax_element(__l.begin(), __l.end());
   return std::make_pair(*__p.first, *__p.second);
@@ -3487,6 +3500,7 @@
 inline pair<_Tp, _Tp>
 minmax(initializer_list<_Tp> __l, _Compare __comp)
 {
+  

[Bug web/69928] New: incorrect reference to gcc-plugin.h in plugin documentation

[petensotium at gmail dot com]

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

Bug ID: 69928
   Summary: incorrect reference to gcc-plugin.h in plugin
documentation
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: petensotium at gmail dot com
  Target Milestone: ---

On the page "https://gcc.gnu.org/onlinedocs/gccint/Plugin-API.html#Plugin-API;,
the first sentence says "Plugins are activated by the compiler at specific
events as defined in gcc-plugin.h."  However, I was only able to find a list of
#includes in this file, with the even definitions being in "plugin.def".

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Created attachment 37774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37774=edit
loop inversion sketch

This patch does loop inversion sufficient for scimark.  It will break
constexpr, but might be useful for looking at the LTO issue.

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
(In reply to Richard Biener from comment #4)
> Yeah, didn't try to figure out whether the C vs. C++ thing is a 
> regression.  But I suspect the change to the C++ loop lowering.

Yes, the relatively small difference between C and C++ without LTO seems to be
due to the loop inversion that the C front end still does, and the C++ front
end doesn't.  But if I add loop inversion back into the C++ front end so that
the .optimized output is indistinguishable, that resolves the difference
without LTO, but LTO still makes the C++ output much slower.

[Bug c/69927] New: Internal compiler error (Segmentation fault) when compiling FFmpeg 3.0

[jb999 at gmx dot de]

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

Bug ID: 69927
   Summary: Internal compiler error (Segmentation fault) when
compiling FFmpeg 3.0
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb999 at gmx dot de
  Target Milestone: ---

Created attachment 37773
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37773=edit
preprocessed file

Compiling FFmpeg 3.0 being configured with ./configure --prefix=/usr
--pkgconfigdir=/var/state/pkgconfig --enable-gpl --enable-version3
--enable-shared --disable-static --disable-runtime-cpudetect --disable-ffserver
fails with

libavfilter/vf_dejudder.c: In function 'filter_frame':
libavfilter/vf_dejudder.c:158:1: internal compiler error: Segmentation fault
 }
 ^

System is Linux SMP i686 GNU/Linux (Linux From Scratch).

gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
Target: i686-pc-linux-gnu
Configured with: /tmp/gcc-4.9.3//configure --prefix=/usr --sysconfdir=/etc
--sharedstatedir=/var/state --localstatedir=/var/state --enable-shared
--disable-static --disable-nls --enable-languages=c,c++ --enable-__cxa_atexit
--with-arch=haswell --with-gxx-include-dir=/usr/include/c++ --with-system-zlib
--disable-multilib --disable-bootstrap --disable-plugin --disable-lto
Thread model: posix
gcc version 4.9.3 (GCC)

Command line (from FFmpeg Makefile):
gcc -I. -I./ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DZLIB_CONST -DHAVE_AV_CONFIG_H
-std=c99 -fomit-frame-pointer -pthread  -g -Wdeclaration-after-statement -Wall
-Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings
-Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast
-Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch
-Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros
-Werror=format-security -Werror=implicit-function-declaration
-Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat
-fdiagnostics-color=auto -Wno-maybe-uninitialized  -MMD -MF
libavfilter/vf_dejudder.d -MT libavfilter/vf_dejudder.o -c -save-temps -o
libavfilter/vf_dejudder.o libavfilter/vf_dejudder.c

The preprocessed file is attached.

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[PATCH] Bump max-ssa-name-query-depth default (PR c/69918)

[Jakub Jelinek]

Hi!

As mentioned in the PR, the builtin-integral-1.c testcase fails on
i?86 Solaris.  The problem is that on Solaris the dg-add-options c99_runtime 
adds -std=c99, which turns -fexcess-precision=standard, and that on some
arches changes
  _388 = (double) i1_63(D);
  _389 = (double) i2_335(D);
  _390 = _388 * _389;
  _391 = (long double) _390;
  _392 = __builtin_ceill (_391);
into
  _398 = (double) i1_63(D);
  _399 = (long double) _398;
  _400 = (double) i2_335(D);
  _401 = (long double) _400;
  _402 = _399 * _401;
  _403 = __builtin_ceill (_402);
But the default value of the max-ssa-name-query-depth param prevents in this
case from recognizing the argument to __builtin_ciell will always be
integral value.  We have the possibility to either tweak the testcase
(e.g. add -fexcess-precision=fast, or --param max-ssa-name-query-depth=3),
or change the IMHO way too low default.  As only the latter will help
for excess precision code in real-world even for simple addition of two
values, I think it is best to bump the default.  Perhaps even 5 wouldn't
hurt, but maybe we can increase it more for gcc 7.

Bootstrapped/regtested on x86_64-linux and i686-linux, tested on the
testcase using cross to i386-pc-solaris2.11.  Ok for trunk?

2016-02-23  Jakub Jelinek  

PR c/69918
* params.def (PARAM_MAX_SSA_NAME_QUERY_DEPTH): Bump default from
2 to 3.

--- gcc/params.def.jj   2016-02-01 23:34:34.0 +0100
+++ gcc/params.def  2016-02-23 18:43:04.359322654 +0100
@@ -1191,7 +1191,7 @@ DEFPARAM (PARAM_MAX_SSA_NAME_QUERY_DEPTH
  "max-ssa-name-query-depth",
  "Maximum recursion depth allowed when querying a property of an"
  " SSA name.",
- 2, 1, 0)
+ 3, 1, 0)
 
 DEFPARAM (PARAM_MAX_RTL_IF_CONVERSION_INSNS,
  "max-rtl-if-conversion-insns",

Jakub

[PATCH] Fix thinko in build_vector_from_ctor (PR middle-end/69915)

[Jakub Jelinek]

Hi!

This function has changed last year to support embedded VECTOR_CSTs in the
ctor elements.  Before that change, there was no pos var and idx used to
match exactly the indices in the new vector, but if there is any VECTOR_CST,
it will fill in more positions.
Unfortunately, the final loop which zeros in any positions not filled in yet
has not changed, which is wrong for the case when there were any
VECTOR_CSTs.  E.g. on the testcase, we have a V16HImode type ctor which
contains two V8HImode VECTOR_CSTs (full of zeros).  Each of them fills in
8 positions, so the final loop shouldn't add anything, but as idx at that
point is 2, it will add further 14 elements, resulting in alloca
buffer overflow.

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

2016-02-23  Jakub Jelinek  

PR middle-end/69915
* tree.c (build_vector_from_ctor): Fix handling of VECTOR_CST
elements.

* gcc.dg/pr69915.c: New test.

--- gcc/tree.c.jj   2016-02-08 18:39:17.0 +0100
+++ gcc/tree.c  2016-02-23 15:50:03.566700694 +0100
@@ -1749,7 +1749,7 @@ build_vector_from_ctor (tree type, vec

[patch] Document __STDCPP_WANT_MATH_SPEC_FUNCS__ macro

[Jonathan Wakely]

Committed to trunk.

commit 6da32ab58d56e2909ed39e5fc2170717ad26e895
Author: Jonathan Wakely 
Date:   Tue Feb 23 20:01:35 2016 +

Document __STDCPP_WANT_MATH_SPEC_FUNCS__ macro

	* doc/xml/manual/using.xml: Document __STDCPP_WANT_MATH_SPEC_FUNCS__.
	* doc/html/*: Regenerate.

diff --git a/libstdc++-v3/doc/html/manual/using_macros.html b/libstdc++-v3/doc/html/manual/using_macros.html
index 6b1fc1e..2ef05af 100644
--- a/libstdc++-v3/doc/html/manual/using_macros.html
+++ b/libstdc++-v3/doc/html/manual/using_macros.html
@@ -89,4 +89,6 @@
   _GLIBCXX_PROFILEUndefined by default. When defined, compiles user code
 	using the profile
 	mode.
+  __STDCPP_WANT_MATH_SPEC_FUNCS__Undefined by default. When defined to a non-zero integer constant,
+	enables support for ISO/IEC 29124 Special Math Functions.
   Prev??Up??NextHeaders??Home??Dual ABI
\ No newline at end of file
diff --git a/libstdc++-v3/doc/xml/manual/using.xml b/libstdc++-v3/doc/xml/manual/using.xml
index 96ae686..6e022d5 100644
--- a/libstdc++-v3/doc/xml/manual/using.xml
+++ b/libstdc++-v3/doc/xml/manual/using.xml
@@ -955,6 +955,13 @@ g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 hello.cc -o test.exe
 	mode.
   
 
+
+__STDCPP_WANT_MATH_SPEC_FUNCS__
+
+  Undefined by default. When defined to a non-zero integer constant,
+	enables support for ISO/IEC 29124 Special Math Functions.
+  
+
 
 
   

[Bug objc/69844] [6 Regression] Possibly bogus error: unknown type name in ObjC code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug libstdc++/69893] [6 Regression] Conflicting declarations in and

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue Feb 23 19:49:31 2016
New Revision: 233644

URL: https://gcc.gnu.org/viewcvs?rev=233644=gcc=rev
Log:
libstdc++/69893 make  work with C++11

PR libstdc++/69893
* include/tr1/cmath (acosh, asinh, atanh, cbrt, copysign, erf, erfc,
exp2, expm1, fdim, fma, fmax, fmin, hypot, ilogb, lgamma, llrint,
llround, log1p, log2, logb, lrint, lround, nan, nearbyint, nextafter,
nexttoward, remainder, remquo, rint, round, scalbln, scalbn, tgamma,
trunc) [__cplusplus >= 201103L]: Import from namespace std.
(fabs) [__cplusplus < 201103L]: Import from namespace std.
* include/tr1/complex (acosh, asinh, atanh) [__cplusplus >= 201103L]:
Likewise.
* testsuite/tr1/headers/c++200x/complex.cc: Add std::fabs to global
namespace before including TR1 headers.
* testsuite/tr1/headers/c++200x/math.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/tr1/headers/c++200x/math.cc
  - copied, changed from r233640,
trunk/libstdc++-v3/testsuite/tr1/headers/c++200x/complex.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/tr1/cmath
trunk/libstdc++-v3/include/tr1/complex
trunk/libstdc++-v3/testsuite/tr1/headers/c++200x/complex.cc

[patch] libstdc++/69893 make work with C++11

[Jonathan Wakely]

The  header was implicitly relying on the fact that the
additional overloads defined by C++11 were not added to the global
namespace, so that it could do "using ::acosh;" to get the C library's
acosh(double) declaration only, and not the C++11 overloads.

With the new  in GCC 6 that no longer works, because including
 before  means that "using ::acosh;" adds all the
C++11 overloads to namespace std::tr1, and then adding new overloads
with the same signatures is an error. (The same error can be triggered
in earlier versions of GCC with an explicit "using std::acosh;" at
global scope before including ).

The solution is to use the C++11 functions when possible, via "using
std::acosh;", and not add anything extra to namespace std::tr1. For
C++03 the additional overloads aren't in namespace std, so we continue
to define them explicitly in namespace std::tr1.

The new  also breaks the special handling for tr1::fabs,
because "using ::fabs;" might now bring in the unwanted std::fabs
overload for std::complex<>. The solution is similar to what is
already done for tr1::pow. I reworded the comment for tr1::pow,
because the problem being solved wasn't very clear to me at first
(even though I was already dealing with the same issue for fabs!)

Tested x86_64-linux, committed to trunk.

commit e8c6279426372f6b4469ee09e61d8c95422d3aa7
Author: Jonathan Wakely 
Date:   Mon Feb 22 23:52:26 2016 +

libstdc++/69893 make  work with C++11

	PR libstdc++/69893
	* include/tr1/cmath (acosh, asinh, atanh, cbrt, copysign, erf, erfc,
	exp2, expm1, fdim, fma, fmax, fmin, hypot, ilogb, lgamma, llrint,
	llround, log1p, log2, logb, lrint, lround, nan, nearbyint, nextafter,
	nexttoward, remainder, remquo, rint, round, scalbln, scalbn, tgamma,
	trunc) [__cplusplus >= 201103L]: Import from namespace std.
	(fabs) [__cplusplus < 201103L]: Import from namespace std.
	* include/tr1/complex (acosh, asinh, atanh) [__cplusplus >= 201103L]:
	Likewise.
	* testsuite/tr1/headers/c++200x/complex.cc: Add std::fabs to global
	namespace before including TR1 headers.
	* testsuite/tr1/headers/c++200x/math.cc: New test.

diff --git a/libstdc++-v3/include/tr1/cmath b/libstdc++-v3/include/tr1/cmath
index 14737e3..48466a0 100644
--- a/libstdc++-v3/include/tr1/cmath
+++ b/libstdc++-v3/include/tr1/cmath
@@ -151,6 +151,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #if _GLIBCXX_USE_C99_MATH_TR1
 
+  // Using declarations to bring names from libc's  into std::tr1.
+
   // types
   using ::double_t;
   using ::float_t;
@@ -416,8 +418,77 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 #if _GLIBCXX_USE_C99_MATH_TR1
 
-  /// Additional overloads [8.16.4].
+  /** Additional overloads [8.16.4].
+   *  @{
+   */
+
+  // For functions defined in C++03 the additional overloads are already
+  // declared in  so we can just re-declare them in std::tr1.
+
   using std::acos;
+  using std::asin;
+  using std::atan;
+  using std::atan2;
+  using std::ceil;
+  using std::cos;
+  using std::cosh;
+  using std::exp;
+  using std::floor;
+  using std::fmod;
+  using std::frexp;
+  using std::ldexp;
+  using std::log;
+  using std::log10;
+  using std::sin;
+  using std::sinh;
+  using std::sqrt;
+  using std::tan;
+  using std::tanh;
+
+#if __cplusplus >= 201103L
+
+  // Since C++11,  defines additional overloads for these functions
+  // in namespace std.
+
+  using std::acosh;
+  using std::asinh;
+  using std::atanh;
+  using std::cbrt;
+  using std::copysign;
+  using std::erf;
+  using std::erfc;
+  using std::exp2;
+  using std::expm1;
+  using std::fdim;
+  using std::fma;
+  using std::fmax;
+  using std::fmin;
+  using std::hypot;
+  using std::ilogb;
+  using std::lgamma;
+  using std::llrint;
+  using std::llround;
+  using std::log1p;
+  using std::log2;
+  using std::logb;
+  using std::lrint;
+  using std::lround;
+  using std::nan;
+  using std::nearbyint;
+  using std::nextafter;
+  using std::nexttoward;
+  using std::remainder;
+  using std::remquo;
+  using std::rint;
+  using std::round;
+  using std::scalbln;
+  using std::scalbn;
+  using std::tgamma;
+  using std::trunc;
+
+#else // __cplusplus < 201103L
+
+  // In C++03 we need to provide the additional overloads.
 
 #ifndef __CORRECT_ISO_CPP11_MATH_H_PROTO
   inline float
@@ -435,8 +506,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 acosh(_Tp __x)
 { return __builtin_acosh(__x); }
 
-  using std::asin;
-
 #ifndef __CORRECT_ISO_CPP11_MATH_H_PROTO
   inline float
   asinh(float __x)
@@ -453,9 +522,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 asinh(_Tp __x)
 { return __builtin_asinh(__x); }
 
-  using std::atan;
-  using std::atan2;
-
 #ifndef __CORRECT_ISO_CPP11_MATH_H_PROTO
   inline float
   atanh(float __x)
@@ -488,8 +554,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 cbrt(_Tp __x)
 { return __builtin_cbrt(__x); }
 
-  using std::ceil;
-
 #ifndef __CORRECT_ISO_CPP11_MATH_H_PROTO
   inline float
   copysign(float __x, float __y)
@@ -508,9 

Re: [PATCH] Fix c_parser_for_statement for ObjC (PR objc/69844)

[Jakub Jelinek]

On Tue, Feb 23, 2016 at 08:24:06PM +0100, Marek Polacek wrote:
> > --- gcc/c/c-parser.c.jj 2016-02-16 16:29:54.0 +0100
> > +++ gcc/c/c-parser.c2016-02-18 17:36:55.025067859 +0100
> > @@ -5887,12 +5887,27 @@ c_parser_for_statement (c_parser *parser
> >  {
> >c_token *token = c_parser_peek_token (parser);
> >tree decl = lookup_name (token->value);
> > -  if (decl == NULL_TREE || VAR_P (decl))
> > -   /* If DECL is null, we don't know what this token might be.  Treat
> > -  it as an ID for better diagnostics; we'll error later on.  */
> > -   token->id_kind = C_ID_ID;
> > -  else if (TREE_CODE (decl) == TYPE_DECL)
> > -   token->id_kind = C_ID_TYPENAME;
> > +  if (token->id_kind != C_ID_CLASSNAME)
> > +   {
> > + token->id_kind = C_ID_ID;
> 
> I think let's sink the lookup_name call here.  If id_kind is C_ID_CLASSNAME
> we're not looking at decl at all.

Done (and committed).  Thanks for review.

> > + if (decl)
> > +   {
> > + if (TREE_CODE (decl) == TYPE_DECL)
> > +   token->id_kind = C_ID_TYPENAME;
> > +   }
> > + else if (c_dialect_objc ())
> > +   {
> > + tree objc_interface_decl = objc_is_class_name (token->value);
> 
> This objc_is_class_name is a weird stub that always returns NULL_TREE but

It is a weird stub only in the cc1 binary, in cc1obj binary it comes from
objc/objc-act.c and does various ObjC magic.

Jakub

Re: [PATCH] New plugin events when evaluating constexpr expressions.

[Daniel Gutson]

On Tue, Nov 3, 2015 at 9:09 AM, Andres Tiraboschi
 wrote:
>  Hi
>  This patch adds two plugins events when evaluated call expression and
> an init or modify expression in constexpr.
>  The goal of this patch is to allow the plugins to analyze and or
> modify the evaluation of constant expressions.
>
>  This patch also adds an event that is called when the parsing of a
> file is finished.

ping

Any update on this?

Thanks!

   Daniel.

>
> Thanks,
> Andrés.



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson

[Bug objc/69844] [6 Regression] Possibly bogus error: unknown type name in ObjC code

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Feb 23 19:47:24 2016
New Revision: 233643

URL: https://gcc.gnu.org/viewcvs?rev=233643=gcc=rev
Log:
PR objc/69844
* c-parser.c (c_parser_for_statement): Properly handle ObjC classes
in id_kind reclassification.

* objc.dg/pr69844.m: New test.

Added:
trunk/gcc/testsuite/objc.dg/pr69844.m
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/testsuite/ChangeLog

Importance of transformations that turn data dependencies into control dependencies?

[Torvald Riegel]

I'd like to know, based on the GCC experience, how important we consider
optimizations that may turn data dependencies of pointers into control
dependencies.  I'm thinking about all optimizations or transformations
that guess that a pointer might have a specific value, and then create
(specialized) code that assumes this value that is only executed if the
pointer actually has this value.  For example:

int d[2] = {23, compute_something()};

int compute(int v) {
  if (likely(v == 23)) return 23;
  else ;
}

int bar() {
  int *p = ptr.load(memory_order_consume);
  size_t reveal_that_p_is_in_d = p - d[0];
  return compute(*p);
}

Could be transformed to (after inlining compute(), and specializing for
the likely path):

int bar() {
  int *p = ptr.load(memory_order_consume);
  if (p == d) return 23;
  else ;
}

Other potential examples that come to mind are de-virtualization, or
feedback-directed optimizations that has observed at runtime that a
certain pointer is likely to be always equal to some other pointer (eg.,
if p is almost always d[0], and specializing for that).

Also, it would be interesting to me to know how often we may turn data
dependencies into control dependencies in cases where this doesn't
affect performance significantly.


The background for this question is Paul McKenney's recently updated
proposal for a different memory_order_consume specification:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0190r0.pdf

In a nutshell, this requires a compiler to either prove that a pointer
value is not carrying a dependency (simplified, its value somehow
originates from a memory_order_consume load), or it has to
conservatively assume that it does; if it does, the compiler must not
turn data dependencies into control dependencies in generated code.
(The data dependencies, in contrast to control dependencies, enforce
memory ordering on archs such as Power and ARM; these orderings than
allow for not having to use an acquire HW barrier in the generated
code.)

Given that such a proof will likely be hard for a compiler (dependency
chains propagate through assignments to variables on the heap and stack,
chains are not marked in the code, and points-to analysis can be hard),
a compiler faces a trade-off between either:
(1) trying to support this memory_order_consume specification and likely
disallowing all transformations that change data dependencies into
control dependencies, or
(2) not support the proposal by simply emitting memory_order_acquire
code, but get no new constraints on transformations in return (ie, what
we do for memory_order_consume today).

A compiler could let users make this choice, but this will be hard for
users too, and the compiler would still have to pick a default.

Therefore, it would be good to know how important such transformations
or optimizations are in practice.  If they are, it either means somewhat
slower code everywhere (or at least having to change much in todays
compilers), or not supporting the new memory_order_consume (at least not
in the default setting of the compiler).

Thanks for any opinions.

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[rguenther at suse dot de]

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

--- Comment #81 from rguenther at suse dot de  ---
On February 23, 2016 4:20:48 PM GMT+01:00, "alalaw01 at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
>
>--- Comment #79 from alalaw01 at gcc dot gnu.org ---
>(In reply to rguent...@suse.de from comment #78)
>>
>> That would pessimize it too much IMHO.
>
>I'm not sure how to evaluate the pessimization, given it's thought to
>be a
>widespread pseudo-FORTRAN construct; so I probably have to defer to
>your
>judgement here. However...
>
>Given maxsize of an array as two elements, say, would the compiler not
>be
>entitled to optimize an index selection down to, say, computing only
>the LSBit
>of the actual index?  Whereas 'unknown' means, well, exactly what is
>the case.
>So I fear this is storing problems up for the future.

It doesn't do that.

>Is the concern that we can't hide this behind an option, as that would
>"drive
>people away from gfortran" ? If that's the case, can we hide it behind
>an
>option that defaults to pessimization (?? at least for fortran)??

I don't think it's necessary to hide it behind an option.

[Bug ada/69926] GNAT bug detected -- Storage_Error stack overflow or erroneous memory access

[keith at aquilonis dot net]

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

--- Comment #3 from Keith Godfrey  ---
Error seems to be caused by using an incorrect attribute (I used 'range when I
meant 'last). 

This is not a priority to fix. I only reported it because it induced an
internal error in the compiler

Re: [PATCH] Fix c_parser_for_statement for ObjC (PR objc/69844)

[Marek Polacek]

On Thu, Feb 18, 2016 at 10:39:02PM +0100, Jakub Jelinek wrote:
> Hi!
> 
> Here is an attempt to fix up the token reclassification after for statement,
> where we lexed the next token with the declaration from for in scope and
> need to undo that if it wasn't else.
> 
> If token->id_kind is C_ID_CLASSNAME (ObjC only), then token->value has
> changed already, but in that case I think it means we can just keep it as
> is, it can't be shadowed by the for init declaration (because it would be
> C_ID_ID or C_ID_TYPENAME? otherwise).
> Otherwise, this patch tries to model the handling closer to what
> c_lex_one_token does, i.e. set it to C_ID_ID, except when decl is non-NULL
> and TYPE_DECL, or for the ObjC case where for init declaration shadowed
> a class declaration.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2016-02-18  Jakub Jelinek  
> 
>   PR objc/69844
>   * c-parser.c (c_parser_for_statement): Properly handle ObjC classes
>   in id_kind reclassification.
> 
>   * objc.dg/pr69844.m: New test.
> 
> --- gcc/c/c-parser.c.jj   2016-02-16 16:29:54.0 +0100
> +++ gcc/c/c-parser.c  2016-02-18 17:36:55.025067859 +0100
> @@ -5887,12 +5887,27 @@ c_parser_for_statement (c_parser *parser
>  {
>c_token *token = c_parser_peek_token (parser);
>tree decl = lookup_name (token->value);
> -  if (decl == NULL_TREE || VAR_P (decl))
> - /* If DECL is null, we don't know what this token might be.  Treat
> -it as an ID for better diagnostics; we'll error later on.  */
> - token->id_kind = C_ID_ID;
> -  else if (TREE_CODE (decl) == TYPE_DECL)
> - token->id_kind = C_ID_TYPENAME;
> +  if (token->id_kind != C_ID_CLASSNAME)
> + {
> +   token->id_kind = C_ID_ID;

I think let's sink the lookup_name call here.  If id_kind is C_ID_CLASSNAME
we're not looking at decl at all.

> +   if (decl)
> + {
> +   if (TREE_CODE (decl) == TYPE_DECL)
> + token->id_kind = C_ID_TYPENAME;
> + }
> +   else if (c_dialect_objc ())
> + {
> +   tree objc_interface_decl = objc_is_class_name (token->value);

This objc_is_class_name is a weird stub that always returns NULL_TREE but
I know that the same code is in c_lex_one_token so let's keep it this way.

I've tried a bunch of invalid ObjC testcases and saw no ICEs and from the
C point of view this patch is safe.

Ok with that lookup_name change, thanks.

Marek

[Bug ada/69926] GNAT bug detected -- Storage_Error stack overflow or erroneous memory access

[keith at aquilonis dot net]

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

--- Comment #2 from Keith Godfrey  ---
Source code attached. Here is code as a comment:

 muscles.ads
package Muscles is
   type stretch is digits 5 range 0.0 .. 1.0;

   type spindle_t is
  record
 center: stretch := 0.0;
  end record;

   type spindle_array is array(1 .. 40) of spindle_t;

   procedure foo(spindles: in out spindle_array);
end Muscles;

 muscles.adb
package body Muscles is
   -- 
   procedure foo(spindles: in out spindle_array) is
  pos: stretch;
   begin
  for i in spindles'range loop
 pos := stretch(float(i - 1) / float(spindles'range - 1)):
 spindles(i).center := pos;
  end loop;
   end foo;
end Muscles;

[Bug ada/69926] New: GNAT bug detected -- Storage_Error stack overflow or erroneous memory access

[keith at aquilonis dot net]

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

Bug ID: 69926
   Summary: GNAT bug detected -- Storage_Error stack overflow or
erroneous memory access
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: keith at aquilonis dot net
  Target Milestone: ---

Created attachment 37771
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37771=edit
source file to reproduce error

Internal error detected in GNAT



$ gcc -v -save-temps -c muscles.adb
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.9/gnat1 -quiet -dumpbase muscles.adb -auxbase
muscles -mtune=generic -march=x86-64 muscles.adb -o muscles.s
+===GNAT BUG DETECTED==+
| 4.9.2 (x86_64-linux-gnu) Storage_Error stack overflow or erroneous memory
access|
| Error detected at muscles.adb:8:17   |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc-4.9 or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

muscles.adb
muscles.ads

:8:60: missing ")"
compilation abandoned

[Bug ada/69926] GNAT bug detected -- Storage_Error stack overflow or erroneous memory access

[keith at aquilonis dot net]

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

--- Comment #1 from Keith Godfrey  ---
Created attachment 37772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37772=edit
specification source file

[Bug c++/69924] gcc5.2 compile Error: std::basic_istream: no match for 'operator>>', while gcc 4.8 works

[derrick at ca dot ibm.com]

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

derrick at ca dot ibm.com changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #3 from derrick at ca dot ibm.com ---
"I assume you're compiling as C++11?"
- Oh, yes, with -std=c++11 flag:
  $g++ -std=c++11 ./_222d00_s.cpp -o test

"This is not valid C++11 code, there is no implicit conversion from streams to
void* or bool in C++11."

- But after I add static_cast, it still has the error. It looks like  
"loc" has some problem. If you think the code is invalid under C++11, could you
point out how I could modify the code to make it pass. Thanks.


#include 
#include 

inline int operator<<(void*,   const std::locale&) { return 1; }
inline int operator>>(void*,   const std::locale&) { return 1; }
inline int operator<<(bool,const std::locale&) { return 2; }
inline int operator>>(bool,const std::locale&) { return 2; }

int main(int argc, char *argv[])
{

  std::locale loc;
  if(static_cast(std::cin  >> loc)!=1)
 return 1;
  if(static_cast(std::cout << loc)!=1);
 return 1;

  return 0;
}

error: no match for 'operator>>' (operand types are 'std::istream {aka
std::basic_istream}' and 'std::locale')
if(static_cast(std::cin  >> loc)!=1)
 error: cannot bind 'std::istream {aka std::basic_istream}' lvalue to
'std::basic_istream&&'
if(static_cast(std::cin  >> loc)!=1)

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #7)
> With the patch in comment 6 the test gfortran.dg/include_6.f90 has to be
> updated to
> 
> --- ../_clean/gcc/testsuite/gfortran.dg/include_6.f90 2012-08-02
> 01:26:03.0 +0200
> +++ gcc/testsuite/gfortran.dg/include_6.f90   2016-02-23 16:32:18.0
> +0100
> @@ -1,5 +1,5 @@
>  ! { dg-do compile }
>  ! { dg-options "-I gfortran.log" }
> -! { dg-warning "is not a directory" "" { target *-*-* } 0 }
> +! { dg-error "is not a directory" "" { target *-*-* } 0 }
>  end 
> -
> +! { dg-prune-output "compilation terminated." }

I did not think about trying prune, I did try dg-excess_error. I will try your
idea first.

[Bug fortran/69456] Namelist value with trailing sign is ignored without error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Fixed on trunk. Will leave open for a bit to see if there is any fallout.

[Bug fortran/69910] ICE with NEWUNIT

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Patch tested.  It will be committed soon. Just need to go through the approval
process

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Jonathan Wakely]

On 19/02/16 13:17 -0700, Sandra Loosemore wrote:

On 02/19/2016 12:01 PM, Jason Merrill wrote:

On 02/19/2016 07:42 AM, Jonathan Wakely wrote:

In PR69864 Manu suggests improving the docs to explain that
-Wnarrowing sometimes produces errors not warnings.

I think the right way to do that is clarify how it interacts with
-std. Specifically that the effect of -Wnarrowing listed first in the
manual *only* applies to C++98 modes, For all later modes (not just
with -std=c++11 as it says now), narrowing conversions produce errors
or warnings by default.

OK for trunk?


OK, thanks.


I suppose the patch is OK as it stands, but I was going to suggest 
restructuring it so that it talks about the default behavior first and 
what it does with non-default -std= options after that, instead of 
vice-versa.  Unfortunately I am backlogged on other things right now 
and it might take me a day or two before I have time to come up with 
some alternate wording.  If we are in a rush, go ahead and commit the 
existing patch meanwhile, I guess.


Is this better?


diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 490df93..8d56efa 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2753,10 +2753,17 @@ During the link-time optimization warn about type mismatches in
 global declarations from different compilation units.
 Requires @option{-flto} to be enabled.  Enabled by default.
 
-@item -Wnarrowing @r{(C++ and Objective-C++ only)}
+@item -Wno-narrowing @r{(C++ and Objective-C++ only)}
 @opindex Wnarrowing
 @opindex Wno-narrowing
-With @option{-std=gnu++98} or @option{-std=c++98}, warn when a narrowing
+For C++11 and later standards, narrowing conversions are diagnosed by default,
+as required by the standard.  A narrowing conversion from a constant produces
+an error, and a narrowing conversion from a non-constant produces a warning,
+but @option{-Wno-narrowing} suppresses the diagnostic.
+Note that this does not affect the meaning of well-formed code;
+narrowing conversions are still considered ill-formed in SFINAE contexts.
+
+With @option{-Wnarrowing} in C++98, warn when a narrowing
 conversion prohibited by C++11 occurs within
 @samp{@{ @}}, e.g.
 
@@ -2766,14 +2773,6 @@ int i = @{ 2.2 @}; // error: narrowing from double to int
 
 This flag is included in @option{-Wall} and @option{-Wc++11-compat}.
 
-When a later standard is in effect, e.g. when using @option{-std=c++11},
-narrowing conversions are diagnosed by default, as required by the standard.
-A narrowing conversion from a constant produces an error,
-and a narrowing conversion from a non-constant produces a warning,
-but @option{-Wno-narrowing} suppresses the diagnostic.
-Note that this does not affect the meaning of well-formed code;
-narrowing conversions are still considered ill-formed in SFINAE contexts.
-
 @item -Wnoexcept @r{(C++ and Objective-C++ only)}
 @opindex Wnoexcept
 @opindex Wno-noexcept

[Bug fortran/69456] Namelist value with trailing sign is ignored without error

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Feb 23 18:38:31 2016
New Revision: 233641

URL: https://gcc.gnu.org/viewcvs?rev=233641=gcc=rev
Log:
2016-02-23  Jerry DeLisle  

PR libgfortran/69456
* io/list_read.c (read_real): If digit is missing from exponent issue
an error. (parse_real): Likewise and adjusted error message to clarify
it is part of a complex number.
(nml_read_obj): Bump item count and add comment that this is used to
identify which item in a namelist read has a problem.

PR libgfortran/69456
* gfortran.dg/namelist_89.f90: New test.
* gfortran.dg/pr59700.f90: Update test..

Added:
trunk/gcc/testsuite/gfortran.dg/namelist_89.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr59700.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c

[committed] Remove __seg_tls before first release

[Richard Henderson]

The addition of named address spaces to the i386 backend is new for gcc6.

I had invented __seg_tls while thinking about how it might be used within
glibc.  But during the last couple of weeks I've had occasion to attempt to use
the feature within the linux kernel.  There, things weren't quite so easy.

My conclusion is that __seg_tls is too specialized, and that what's really
needed is user-defined named address spaces, so that each project can define
its own mapping between segment base and the generic (flat) address space.

Therefore I have deleted __seg_tls before the first release, so that we don't
have to support this going forward.  The __seg_fs and __seg_gs namespaces are
still present in gcc6, and (with effort and casting) these can still be used to
produce memory references with segment overrides.


r~
* config/i386/i386-c.c (ix86_target_macros): Remove __SEG_TLS.
(ix86_register_pragmas): Remove __seg_tls.
* config/i386/i386-protos.h (ADDR_SPACE_SEG_TLS): Remove.
* config/i386/i386.c (ix86_print_operand_address_as): Don't handle it.
(ix86_addr_space_subset_p, TARGET_ADDR_SPACE_SUBSET_P): Remove.
(ix86_addr_space_convert, TARGET_ADDR_SPACE_CONVERT): Remove.
(ix86_addr_space_debug, TARGET_ADDR_SPACE_DEBUG): Remove.
* doc/extend.texi (__seg_tls): Remove item.
testsuite/
* gcc.target/i386/addr-space-3.c: Remove test.


diff --git a/gcc/config/i386/i386-c.c b/gcc/config/i386/i386-c.c
index ea0c5df..f93a09d 100644
--- a/gcc/config/i386/i386-c.c
+++ b/gcc/config/i386/i386-c.c
@@ -591,7 +591,6 @@ ix86_target_macros (void)
 
   cpp_define (parse_in, "__SEG_FS");
   cpp_define (parse_in, "__SEG_GS");
-  cpp_define (parse_in, "__SEG_TLS");
 }
 
 
@@ -608,7 +607,6 @@ ix86_register_pragmas (void)
 
   c_register_addr_space ("__seg_fs", ADDR_SPACE_SEG_FS);
   c_register_addr_space ("__seg_gs", ADDR_SPACE_SEG_GS);
-  c_register_addr_space ("__seg_tls", ADDR_SPACE_SEG_TLS);
 
 #ifdef REGISTER_SUBTARGET_PRAGMAS
   REGISTER_SUBTARGET_PRAGMAS ();
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index 252bb19..e4652f3 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -332,4 +332,3 @@ struct ix86_first_cycle_multipass_data_
 
 const addr_space_t ADDR_SPACE_SEG_FS = 1;
 const addr_space_t ADDR_SPACE_SEG_GS = 2;
-const addr_space_t ADDR_SPACE_SEG_TLS = 3;
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 29c73f6..d8a2909 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -17395,8 +17395,6 @@ ix86_print_operand_address_as (FILE *file, rtx addr,
 {
   const char *string;
 
-  if (as == ADDR_SPACE_SEG_TLS)
-   as = DEFAULT_TLS_SEG_REG;
   if (as == ADDR_SPACE_SEG_FS)
string = (ASSEMBLER_DIALECT == ASM_ATT ? "%fs:" : "fs:");
   else if (as == ADDR_SPACE_SEG_GS)
@@ -54256,54 +54254,8 @@ ix86_optab_supported_p (int op, machine_mode mode1, 
machine_mode,
 without resorting to a system call, we cannot convert a
 non-default address space to a default address space.
 Therefore we do not claim %fs or %gs are subsets of generic.
-(e) However, __seg_tls uses UNSPEC_TP as the base (which itself is
-   stored at __seg_tls:0) so we can map between tls and generic.  */
 
-static bool
-ix86_addr_space_subset_p (addr_space_t subset, addr_space_t superset)
-{
-return (subset == superset
-   || (superset == ADDR_SPACE_GENERIC
-   && subset == ADDR_SPACE_SEG_TLS));
-}
-#undef TARGET_ADDR_SPACE_SUBSET_P
-#define TARGET_ADDR_SPACE_SUBSET_P ix86_addr_space_subset_p
-
-static rtx
-ix86_addr_space_convert (rtx op, tree from_type, tree to_type)
-{
-  addr_space_t from_as = TYPE_ADDR_SPACE (TREE_TYPE (from_type));
-  addr_space_t to_as = TYPE_ADDR_SPACE (TREE_TYPE (to_type));
-
-  /* Conversion between SEG_TLS and GENERIC is handled by adding or
- subtracting the thread pointer.  */
-  if ((from_as == ADDR_SPACE_GENERIC && to_as == ADDR_SPACE_SEG_TLS)
-  || (from_as == ADDR_SPACE_SEG_TLS && to_as == ADDR_SPACE_GENERIC))
-{
-  machine_mode mode = GET_MODE (op);
-  if (mode == VOIDmode)
-   mode = ptr_mode;
-  rtx tp = get_thread_pointer (mode, optimize || mode != ptr_mode);
-  return expand_binop (mode, (to_as == ADDR_SPACE_GENERIC
- ? add_optab : sub_optab),
-  op, tp, NULL, 1, OPTAB_WIDEN);
-}
-
-  return op;
-}
-#undef TARGET_ADDR_SPACE_CONVERT
-#define TARGET_ADDR_SPACE_CONVERT ix86_addr_space_convert
-
-static int
-ix86_addr_space_debug (addr_space_t as)
-{
-  /* Fold __seg_tls to __seg_fs or __seg_gs for debugging.  */
-  if (as == ADDR_SPACE_SEG_TLS)
-as = DEFAULT_TLS_SEG_REG;
-  return as;
-}
-#undef TARGET_ADDR_SPACE_DEBUG
-#define TARGET_ADDR_SPACE_DEBUG ix86_addr_space_debug
+   Therefore we can (mostly) use the default hooks.  */
 
 /* All use of segmentation is assumed to make address 0 

[Bug c/69759] __builtin_alloca and __builtin_alloca_with_align undocumented

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Depends on|69780   |
 Resolution|--- |FIXED

--- Comment #7 from Martin Sebor  ---
Fixed by r233640.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69780
[Bug 69780] [4.9/5/6 Regression] ICE on  __builtin_alloca_with_align with small
alignment

[Bug c/69759] __builtin_alloca and __builtin_alloca_with_align undocumented

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69759
Bug 69759 depends on bug 69780, which changed state.

Bug 69780 Summary: [4.9/5/6 Regression] ICE on  __builtin_alloca_with_align 
with small alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69780

   What|Removed |Added

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

[Bug middle-end/69780] [4.9/5/6 Regression] ICE on __builtin_alloca_with_align with small alignment

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Blocks||69759
 Resolution|--- |FIXED

--- Comment #6 from Martin Sebor  ---
Fixed in r233640.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69759
[Bug 69759] __builtin_alloca and __builtin_alloca_with_align undocumented

[Bug middle-end/69780] [4.9/5/6 Regression] ICE on __builtin_alloca_with_align with small alignment

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Tue Feb 23 18:09:37 2016
New Revision: 233640

URL: https://gcc.gnu.org/viewcvs?rev=233640=gcc=rev
Log:
PR middle-end/69780 - [4.9/5/6 Regression] ICE on __builtin_alloca_with_align
with small alignment
PR c/69759 - __builtin_alloca and __builtin_alloca_with_align undocumented

gcc/c-family/ChangeLog:
* c-common.c (check_builtin_function_arguments): Validate and reject
invalid arguments to __builtin_alloca_with_align.

gcc/ChangeLog:
* doc/extend.texi (Other Builtins): Document __builtin_alloca and
__builtin_alloca_with_align.

gcc/testsuite/ChangeLog:
* g++.dg/ext/builtin_alloca.C: New test.
* gcc.dg/builtins-68.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/builtin_alloca.C
trunk/gcc/testsuite/gcc.dg/builtins-68.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug c/69759] __builtin_alloca and __builtin_alloca_with_align undocumented

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Tue Feb 23 18:09:37 2016
New Revision: 233640

URL: https://gcc.gnu.org/viewcvs?rev=233640=gcc=rev
Log:
PR middle-end/69780 - [4.9/5/6 Regression] ICE on __builtin_alloca_with_align
with small alignment
PR c/69759 - __builtin_alloca and __builtin_alloca_with_align undocumented

gcc/c-family/ChangeLog:
* c-common.c (check_builtin_function_arguments): Validate and reject
invalid arguments to __builtin_alloca_with_align.

gcc/ChangeLog:
* doc/extend.texi (Other Builtins): Document __builtin_alloca and
__builtin_alloca_with_align.

gcc/testsuite/ChangeLog:
* g++.dg/ext/builtin_alloca.C: New test.
* gcc.dg/builtins-68.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/builtin_alloca.C
trunk/gcc/testsuite/gcc.dg/builtins-68.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #30 from David Malcolm  ---
The issue reported in comment #18 should be fixed as of r233638; marking this
one as resolved again.

[Bug preprocessor/69543] [6/7 Regression] _Pragma does not apply within macro

[dmalcolm at gcc dot gnu.org]

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

--- Comment #6 from David Malcolm  ---
Author: dmalcolm
Date: Tue Feb 23 17:44:28 2016
New Revision: 233638

URL: https://gcc.gnu.org/viewcvs?rev=233638=gcc=rev
Log:
PR preprocessor/69126: avoid comparing ad-hoc and non-ad-hoc locations

gcc/testsuite/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
* c-c++-common/pr69126-2-long.c: New test.
* c-c++-common/pr69126-2-short.c: New test.
* c-c++-common/pr69543-1.c: Remove xfail.

libcpp/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
* line-map.c (linemap_compare_locations): At the function top,
replace inlined bodies of get_location_from_adhoc_loc with calls
to get_location_from_adhoc_loc.  Add a pair of calls to
get_location_from_adhoc_loc at the bottom of the function, to
avoid meaningless comparisons of ad-hoc and non-ad-hoc locations.


Added:
trunk/gcc/testsuite/c-c++-common/pr69126-2-long.c
trunk/gcc/testsuite/c-c++-common/pr69126-2-short.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr69543-1.c
trunk/libcpp/ChangeLog
trunk/libcpp/line-map.c

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

[dmalcolm at gcc dot gnu.org]

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

--- Comment #29 from David Malcolm  ---
Author: dmalcolm
Date: Tue Feb 23 17:44:28 2016
New Revision: 233638

URL: https://gcc.gnu.org/viewcvs?rev=233638=gcc=rev
Log:
PR preprocessor/69126: avoid comparing ad-hoc and non-ad-hoc locations

gcc/testsuite/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
* c-c++-common/pr69126-2-long.c: New test.
* c-c++-common/pr69126-2-short.c: New test.
* c-c++-common/pr69543-1.c: Remove xfail.

libcpp/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
* line-map.c (linemap_compare_locations): At the function top,
replace inlined bodies of get_location_from_adhoc_loc with calls
to get_location_from_adhoc_loc.  Add a pair of calls to
get_location_from_adhoc_loc at the bottom of the function, to
avoid meaningless comparisons of ad-hoc and non-ad-hoc locations.


Added:
trunk/gcc/testsuite/c-c++-common/pr69126-2-long.c
trunk/gcc/testsuite/c-c++-common/pr69126-2-short.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr69543-1.c
trunk/libcpp/ChangeLog
trunk/libcpp/line-map.c

[Bug c/69918] [6 regression] gcc.dg/torture/builtin-integral-1.c FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-23
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
So, what seems to be going on is that Solaris is the only target that adds
-std=c99 in add_options_for_c99_runtime, and -std=c99 (as opposed to
-std=gnu99) enables -fexcess-precision=standard, which on Solaris (but also on
i386-linux) 
means there is more code.
With -fexcess-precision=fast we e.g. get:
  _388 = (double) i1_63(D);
  _389 = (double) i2_335(D);
  _390 = _388 * _389;
  _391 = (long double) _390;
  _392 = __builtin_ceill (_391);
while with -fexcess-precision=standard we get corresponding:
  _398 = (double) i1_63(D);
  _399 = (long double) _398;
  _400 = (double) i2_335(D);
  _401 = (long double) _400;
  _402 = _399 * _401;
  _403 = __builtin_ceill (_402);
GCC is actually able to optimize even the latter, but only with --param
max-ssa-name-query-depth=3 or higher (default is 2).

Thus, for testsuite only fix for this PR, one possibility is add
-fexcess-precision=fast
to dg-options, another one is to add
-param max-ssa-name-query-depth=3
to dg-options.

Or, perhaps we could bump the max-ssa-name-query-depth default from 2 to 3. 
I'll bootstrap/regtest this last option on x86_64-linux and i686-linux, to see
if it doesn't break anything.

Richard, any preferences?

[Bug preprocessor/69543] [6/7 Regression] _Pragma does not apply within macro

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Tue Feb 23 17:39:16 2016
New Revision: 233637

URL: https://gcc.gnu.org/viewcvs?rev=233637=gcc=rev
Log:
Add test coverage for _Pragma (PR preprocessor 69126, 69543, 69558)

We had some regressions in the ability for _Pragma to disable a warning
(PR preprocessor/69126, PR preprocessor/69543, PR preprocessor/69558).

This patch attempts to add more test coverage for this, for the
various combinations of:
  - various warnings:
-Wunused-variable
-Wuninitialized
-Wdeprecated-declarations
  - various combinations of location of _Pragma relative to location of
the warning:
 - _Pragma is in a macro, warning isn't a macro
 - neither is in a macro
 - _Pragma isnt't in a macro, warning is in a macro
 - in different macros
 - both in the same macro
  - C vs C++ frontend.

It adds some XFAILs:
  - pr69543-1.c for C++ (fixed in the followup patch)
  - pr69543-3.c for both C and C++
  - pr69543-4.c for both C and C++
  - pr69558.c for C++ (moving it from gcc.dg to c-c++-common,
marking it as xfail for C++ for now)

gcc/testsuite/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
PR preprocessor/69558
* c-c++-common/pr69126.c (MACRO_1, test_1): New.
(f): Rename to...
(test_2): ...this, and add leading comment.
(MACRO_3, test_3): New.
(MACRO_4A, MACRO_4B, test_4): New.
(MACRO): Rename to...
(MACRO_5): ...this.
(g): Rename to...
(test_5): ...this, updating for renaming of MACRO, and
add leading comment.
* c-c++-common/pr69543-1.c: New.
* c-c++-common/pr69543-2.c: New.
* c-c++-common/pr69543-3.c: New.
* c-c++-common/pr69543-4.c: New.
* c-c++-common/pr69558-1.c: New.
* c-c++-common/pr69558-2.c: New.
* c-c++-common/pr69558-3.c: New.
* c-c++-common/pr69558-4.c: New.
* gcc.dg/pr69558.c: Move to...
* c-c++-common/pr69558.c: ...here.  Add dg-bogus directives, with
xfail for c++.


Added:
trunk/gcc/testsuite/c-c++-common/pr69543-1.c
trunk/gcc/testsuite/c-c++-common/pr69543-2.c
trunk/gcc/testsuite/c-c++-common/pr69543-3.c
trunk/gcc/testsuite/c-c++-common/pr69543-4.c
trunk/gcc/testsuite/c-c++-common/pr69558-1.c
trunk/gcc/testsuite/c-c++-common/pr69558-2.c
trunk/gcc/testsuite/c-c++-common/pr69558-3.c
trunk/gcc/testsuite/c-c++-common/pr69558-4.c
trunk/gcc/testsuite/c-c++-common/pr69558.c
  - copied, changed from r233636, trunk/gcc/testsuite/gcc.dg/pr69558.c
Removed:
trunk/gcc/testsuite/gcc.dg/pr69558.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr69126.c

[Bug c/69558] [6/7 Regression] glib2 warning pragmas stopped working

[dmalcolm at gcc dot gnu.org]

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

--- Comment #14 from David Malcolm  ---
Author: dmalcolm
Date: Tue Feb 23 17:39:16 2016
New Revision: 233637

URL: https://gcc.gnu.org/viewcvs?rev=233637=gcc=rev
Log:
Add test coverage for _Pragma (PR preprocessor 69126, 69543, 69558)

We had some regressions in the ability for _Pragma to disable a warning
(PR preprocessor/69126, PR preprocessor/69543, PR preprocessor/69558).

This patch attempts to add more test coverage for this, for the
various combinations of:
  - various warnings:
-Wunused-variable
-Wuninitialized
-Wdeprecated-declarations
  - various combinations of location of _Pragma relative to location of
the warning:
 - _Pragma is in a macro, warning isn't a macro
 - neither is in a macro
 - _Pragma isnt't in a macro, warning is in a macro
 - in different macros
 - both in the same macro
  - C vs C++ frontend.

It adds some XFAILs:
  - pr69543-1.c for C++ (fixed in the followup patch)
  - pr69543-3.c for both C and C++
  - pr69543-4.c for both C and C++
  - pr69558.c for C++ (moving it from gcc.dg to c-c++-common,
marking it as xfail for C++ for now)

gcc/testsuite/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
PR preprocessor/69558
* c-c++-common/pr69126.c (MACRO_1, test_1): New.
(f): Rename to...
(test_2): ...this, and add leading comment.
(MACRO_3, test_3): New.
(MACRO_4A, MACRO_4B, test_4): New.
(MACRO): Rename to...
(MACRO_5): ...this.
(g): Rename to...
(test_5): ...this, updating for renaming of MACRO, and
add leading comment.
* c-c++-common/pr69543-1.c: New.
* c-c++-common/pr69543-2.c: New.
* c-c++-common/pr69543-3.c: New.
* c-c++-common/pr69543-4.c: New.
* c-c++-common/pr69558-1.c: New.
* c-c++-common/pr69558-2.c: New.
* c-c++-common/pr69558-3.c: New.
* c-c++-common/pr69558-4.c: New.
* gcc.dg/pr69558.c: Move to...
* c-c++-common/pr69558.c: ...here.  Add dg-bogus directives, with
xfail for c++.


Added:
trunk/gcc/testsuite/c-c++-common/pr69543-1.c
trunk/gcc/testsuite/c-c++-common/pr69543-2.c
trunk/gcc/testsuite/c-c++-common/pr69543-3.c
trunk/gcc/testsuite/c-c++-common/pr69543-4.c
trunk/gcc/testsuite/c-c++-common/pr69558-1.c
trunk/gcc/testsuite/c-c++-common/pr69558-2.c
trunk/gcc/testsuite/c-c++-common/pr69558-3.c
trunk/gcc/testsuite/c-c++-common/pr69558-4.c
trunk/gcc/testsuite/c-c++-common/pr69558.c
  - copied, changed from r233636, trunk/gcc/testsuite/gcc.dg/pr69558.c
Removed:
trunk/gcc/testsuite/gcc.dg/pr69558.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr69126.c

[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro

[dmalcolm at gcc dot gnu.org]

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

--- Comment #28 from David Malcolm  ---
Author: dmalcolm
Date: Tue Feb 23 17:39:16 2016
New Revision: 233637

URL: https://gcc.gnu.org/viewcvs?rev=233637=gcc=rev
Log:
Add test coverage for _Pragma (PR preprocessor 69126, 69543, 69558)

We had some regressions in the ability for _Pragma to disable a warning
(PR preprocessor/69126, PR preprocessor/69543, PR preprocessor/69558).

This patch attempts to add more test coverage for this, for the
various combinations of:
  - various warnings:
-Wunused-variable
-Wuninitialized
-Wdeprecated-declarations
  - various combinations of location of _Pragma relative to location of
the warning:
 - _Pragma is in a macro, warning isn't a macro
 - neither is in a macro
 - _Pragma isnt't in a macro, warning is in a macro
 - in different macros
 - both in the same macro
  - C vs C++ frontend.

It adds some XFAILs:
  - pr69543-1.c for C++ (fixed in the followup patch)
  - pr69543-3.c for both C and C++
  - pr69543-4.c for both C and C++
  - pr69558.c for C++ (moving it from gcc.dg to c-c++-common,
marking it as xfail for C++ for now)

gcc/testsuite/ChangeLog:
PR preprocessor/69126
PR preprocessor/69543
PR preprocessor/69558
* c-c++-common/pr69126.c (MACRO_1, test_1): New.
(f): Rename to...
(test_2): ...this, and add leading comment.
(MACRO_3, test_3): New.
(MACRO_4A, MACRO_4B, test_4): New.
(MACRO): Rename to...
(MACRO_5): ...this.
(g): Rename to...
(test_5): ...this, updating for renaming of MACRO, and
add leading comment.
* c-c++-common/pr69543-1.c: New.
* c-c++-common/pr69543-2.c: New.
* c-c++-common/pr69543-3.c: New.
* c-c++-common/pr69543-4.c: New.
* c-c++-common/pr69558-1.c: New.
* c-c++-common/pr69558-2.c: New.
* c-c++-common/pr69558-3.c: New.
* c-c++-common/pr69558-4.c: New.
* gcc.dg/pr69558.c: Move to...
* c-c++-common/pr69558.c: ...here.  Add dg-bogus directives, with
xfail for c++.


Added:
trunk/gcc/testsuite/c-c++-common/pr69543-1.c
trunk/gcc/testsuite/c-c++-common/pr69543-2.c
trunk/gcc/testsuite/c-c++-common/pr69543-3.c
trunk/gcc/testsuite/c-c++-common/pr69543-4.c
trunk/gcc/testsuite/c-c++-common/pr69558-1.c
trunk/gcc/testsuite/c-c++-common/pr69558-2.c
trunk/gcc/testsuite/c-c++-common/pr69558-3.c
trunk/gcc/testsuite/c-c++-common/pr69558-4.c
trunk/gcc/testsuite/c-c++-common/pr69558.c
  - copied, changed from r233636, trunk/gcc/testsuite/gcc.dg/pr69558.c
Removed:
trunk/gcc/testsuite/gcc.dg/pr69558.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr69126.c

[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508

[tkoenig at gcc dot gnu.org]

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

--- Comment #80 from Thomas Koenig  ---
(In reply to alalaw01 from comment #79)

> Is the concern that we can't hide this behind an option, as that would
> "drive people away from gfortran" ? If that's the case, can we hide it
> behind an option that defaults to pessimization (?? at least for fortran)??

The concern would be if we did not provide a reasonable way around this.

I am not in favor of pessimizing valid code by default :-)

My preference would be to hide it behind an option, include this
option in -std=legacy, and warn from the gfortran front end (with -Wall)
if the construct in question (or questionable construct) is encountered.
The warning could tell the user which option to select in this case.

A one-element array trailing a common block is legal, but its normal
use should be quite rare, because it can be replaced without problems
with a scalar variable, so I doubt we will generate many false positives.
And even if we do, we now have the nice feature of displaying the
option which issued the warning, so people should have no problem
turning it off.

[Bug c++/69924] gcc5.2 compile Error: std::basic_istream: no match for 'operator>>', while gcc 4.8 works

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Jonathan Wakely  ---
Ah yes, or you wouldn't get the rvalue overload.

Please makes sure you state the relevant compiler flags so we don't have to
guess.

This is not valid C++11 code, there is no implicit conversion from streams to
void* or bool in C++11.

[Bug c++/69924] gcc5.2 compile Error: std::basic_istream: no match for 'operator>>', while gcc 4.8 works

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I assume you're compiling as C++11?

Re: [RFC] [PATCH] Add __array_size keyword

[Stuart Brady]

On Wed, Feb 17, 2016 at 12:29:34AM +, Stuart Brady wrote:
> > - should __array_size (b) be an integer constant (size_t)2, or should it 
> > be non-constant (size_t)2 because the argument is a VLA (albeit a VLA 
> > whose top-level dimension is an integer constant expression)?
> 
> Ouch.  I would say it should be an integer constant (size_t)2, simply as
> that seems to me to be a reasonable expectation.  Unfortunately, this is
> not what happens with my patch, as I get a -Wint-conversion warning. :-(

[snip]

Okay.  So, unsurprisingly, it turns out the problem here was in my code.
When I added c_expr_array_size_expr() and c_expr_array_size_type() it
seems I had not understood that C_TYPE_VARIABLE_SIZE and therefore also
c_vla_type_p are non-zero (true) for VLAs where the outermost subscript
is not variable, behaviour I can now clearly see in grokdeclarator().

This certainly supports the notion that test cases and documentation are
of greater importance than the patch itself, at this stage.

I now seem to have an __array_size keyword that behaves as I would expect
in this case, too.  I'll resubmit the patch once I have gone through the
final draft of C11.

It is still not entirely clear to me whether I must do something to
prevent constant folding for use of __array_size with VLAs, but I am not
so highly concerned just at the moment.
-- 
Many thanks,
Stuart Brady

[Bug c++/69925] No warning for uninitialized char * passing to function as const char *

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
There is another bug about this specific thing already.  But note someone can
do a const_cast and remove the const part and start assigning values to the
array so it is not always considered as unitialized.

[Bug c++/69925] New: No warning for uninitialized char * passing to function as const char *

[developm...@faf-ltd.com]

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

Bug ID: 69925
   Summary: No warning for uninitialized char * passing to
function as const char *
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: developm...@faf-ltd.com
  Target Milestone: ---

auto foo( const char * ) -> void;

int main()
{
char bar [100];

foo( bar );
}

In my opinion gcc should warn that bar is uninitialized used due to the fact it
is used as const in foo().

g++ -Wall -Wextra -Werror -c foo.cpp

I have to admit that I could not find any compiler which warns about this:
https://goo.gl/0d6KU4

[Bug c++/69922] [6 Regression] Bogus -Wnonnull-compare for: ... ? static_cast<T*>(this) : nullptr

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
   Target Milestone|--- |6.0
Summary|Bogus -Wnonnull-compare |[6 Regression] Bogus
   |for: ... ?  |-Wnonnull-compare for: ...
   |static_cast(this) : |? static_cast(this) :
   |nullptr |nullptr

--- Comment #3 from Andrew Pinski  ---
Most likely it is due to multiple inheritance which causes GCC internally to
emit a comparison and GCC decides to warn about that comparison when it should
not.

[Bug c++/69924] New: gcc5.2 compile Error: std::basic_istream: no match for 'operator>>', while gcc 4.8 works

[derrick at ca dot ibm.com]

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

Bug ID: 69924
   Summary: gcc5.2 compile Error: std::basic_istream: no match for
'operator>>', while gcc 4.8 works
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: derrick at ca dot ibm.com
  Target Milestone: ---

For the following code, it compiles successfully on gcc 4.8, but fails on gcc
5.2

#include 
#include 

inline int operator<<(void*,   const std::locale&) { return 1; }
inline int operator>>(void*,   const std::locale&) { return 1; }
inline int operator<<(bool,const std::locale&) { return 2; }
inline int operator>>(bool,const std::locale&) { return 2; }

int main(int argc, char *argv[])
{

  std::locale loc;
  if((std::cin  >> loc)!=1)
 return 1;
  if((std::cout << loc)!=1);
 return 1;

  return 0;
}

error: no match for 'operator>>' (operand types are 'std::istream {aka
std::basic_istream}' and 'std::locale')
if((std::cin  >> loc)!=1)
error: cannot bind 'std::istream {aka std::basic_istream}' lvalue to
'std::basic_istream&&'
if((std::cin  >> loc)!=1)

Re: increase alignment of global structs in increase_alignment pass

[Marek Polacek]

On Tue, Feb 23, 2016 at 09:49:37PM +0530, Prathamesh Kulkarni wrote:

> diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
> index 2b25b45..a6af535 100644
> --- a/gcc/tree-vectorizer.c
> +++ b/gcc/tree-vectorizer.c
> @@ -794,6 +794,75 @@ make_pass_slp_vectorize (gcc::context *ctxt)
>   This should involve global alignment analysis and in the future also
>   array padding.  */
> 
> +static unsigned get_vec_alignment_for_decl (tree);

Why the forward decl?  Better to topologically sort the functions.

Also, the functions are missing comments.

> +static unsigned
> +get_vec_alignment_for_array_decl (tree array_decl)
> +{
> +  tree type = TREE_TYPE (array_decl);
> +  gcc_assert (TREE_CODE (type) == ARRAY_TYPE);
> +
> +  tree vectype = get_vectype_for_scalar_type (strip_array_types (type));
> +  return (vectype) ? TYPE_ALIGN (vectype) : 0;
> +}
> +
> +static unsigned
> +get_vec_alignment_for_record_decl (tree record_decl)
> +{
> +  tree type = TREE_TYPE (record_decl);
> +  gcc_assert (TREE_CODE (type) == RECORD_TYPE);
> +  unsigned max_align = 0, alignment;
> +  HOST_WIDE_INT offset;
> +
> +  if (DECL_ARTIFICIAL (record_decl) || TYPE_PACKED (type))
> +return 0;
> +
> +  for (tree field = first_field (type);
> +   field != NULL_TREE;
> +   field = DECL_CHAIN (field))
> +{
> +  /* C++FE puts node "._0" of code TYPE_DECL. skip that.  */
> +  if (TREE_CODE (field) != FIELD_DECL)
> + continue;
> +
> +  offset = int_byte_position (field);
> +  alignment = get_vec_alignment_for_decl (field);
> +  if (alignment
> +   && (offset % (alignment / BITS_PER_UNIT) == 0)
> +   && (alignment > max_align))
> + max_align = alignment;
> +}
> +
> +  return max_align;
> +}
> +
> +static unsigned
> +get_vec_alignment_for_decl (tree decl)
> +{
> +  if (decl == NULL_TREE)
> +return 0;
> +
> +  gcc_assert (DECL_P (decl));
> +
> +  static unsigned alignment = 0;
> +  tree type = TREE_TYPE (decl);
> +
> +  switch (TREE_CODE (type))
> +{
> +  case ARRAY_TYPE:
> + alignment = get_vec_alignment_for_array_decl (decl);
> + break;
> +  case RECORD_TYPE:
> + alignment = get_vec_alignment_for_record_decl (decl);
> + break;
> +  default:
> + alignment = 0;
> + break;
> +}
> +
> +  return (alignment > DECL_ALIGN (decl)) ? alignment : 0;
> +}
> +
>  static unsigned int
>  increase_alignment (void)
>  {
> @@ -804,23 +873,14 @@ increase_alignment (void)
>/* Increase the alignment of all global arrays for vectorization.  */
>FOR_EACH_DEFINED_VARIABLE (vnode)
>  {
> -  tree vectype, decl = vnode->decl;
> -  tree t;
> +  tree decl = vnode->decl;
>unsigned int alignment;
> 
> -  t = TREE_TYPE (decl);
> -  if (TREE_CODE (t) != ARRAY_TYPE)
> -continue;
> -  vectype = get_vectype_for_scalar_type (strip_array_types (t));
> -  if (!vectype)
> -continue;
> -  alignment = TYPE_ALIGN (vectype);
> -  if (DECL_ALIGN (decl) >= alignment)
> -continue;
> +  alignment = get_vec_alignment_for_decl (decl);
> 
> -  if (vect_can_force_dr_alignment_p (decl, alignment))
> +  if (alignment && vect_can_force_dr_alignment_p (decl, alignment))
>  {
> -   vnode->increase_alignment (TYPE_ALIGN (vectype));
> +   vnode->increase_alignment (alignment);
>dump_printf (MSG_NOTE, "Increasing alignment of decl: ");
>dump_generic_expr (MSG_NOTE, TDF_SLIM, decl);
>dump_printf (MSG_NOTE, "\n");


Marek

Re: [PATCH] gcov: Configurable destination for error output

[Nathan Sidwell]

On 02/23/16 11:04, Aaron Conole wrote:


Before I start cooking up this change, is it possible I need to worry about
gcov_error being invoked from multiple threads? If so, I'll need some
kind of mutex which I think is not needed with the current design.


As I recall the main entry points to the gcov machinery (__gcov_dump etc) have a 
lock already.  So I think you're ok.


nathan

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu]

On Tue, Feb 23, 2016 at 8:15 AM, Michael Matz  wrote:
> Hi,
>
> On Tue, 23 Feb 2016, H.J. Lu wrote:
>
>> I thought
>>
>> ---
>> An empty type is a type where it and all of its subobjects (recursively)
>> are of class, structure, union, or array type.
>> ---
>>
>> excluded
>>
>> struct empty
>> {
>> empty () = default;
>> };
>
>
> Why would that be excluded?  There are no subobjects, hence all of them
> are of class, structure, union or array type, hence this is an empty type.
> (And that's good, it indeed looks quite empty to me).  Even if you would
> add a non-trivial copy ctor, making this thing not trivially copyable
> anymore, it would still be empty.  Hence, given your proposed language in
> the psABI, without reference to any other ABI (in particular not to the
> Itanium C++ ABI), you would then need to pass it without registers.  That
> can't be done, and that's exactly why I find that wording incomplete.  It
> needs implicit references to other languages ABIs to work.
>

It is clear to me now.  Let's go with

---
An empty type is a type where it and all of its subobjects (recursively)
are of class, structure, union, or array type.  No memory slot nor
register should be used to pass or return an object of empty type that's
trivially copyable.
---

Any comments?


-- 
H.J.

RE: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support

[Faraz Shahbazker]

Bump.

From: Faraz Shahbazker [faraz.shahbaz...@imgtec.com]
Sent: 05 February 2016 10:36
To: gcc-patches@gcc.gnu.org
Cc: Matthew Fortune
Subject: [RFC] [MIPS] Enable non-executable PT_GNU_STACK support

Enable non-executable stack mode if assembler and linker support it.

Currently the MIPS FPU emulator uses eXecute Out of Line (XOL) on the stack to
handle instructions in the delay slots of FPU branches.  Because of this MIPS
cannot have a non-executable stack. While the solution on the kernel side is
not yet finalized, we propose changes required on the tools-side to make them
ready for a seamless transition whenever a fixed kernel becomes available.

glibc/dynamic linker:

* When non-executable stack is requested, first check AT_FLAGS in the
  auxiliary vector to decide if this kernel supports a non-executable
  stack. Persist with the non-executable mode specified on the
  PT_GNU_STACK segment only if kernel supports it, else revert to an
  executable stack.

* The 25th bit (1<<24) in AT_FLAGS is reserved for use by the kernel to
  indicate that it supports a non-executable stack on MIPS.

* glibc's ABIVERSION is incremented from 3 to 5, so that applications linked
  for this glibc can't be accidentally run against older versions. ABIVERSION
  4 has been skipped over because it was chosen for IFUNC support, which is
  still under review.

Patch under review: https://sourceware.org/ml/libc-alpha/2016-01/msg00567.html

binutils:

* Increment the ABIVERSION to 5 for objects with non-executable stacks.

Patch under review: https://sourceware.org/ml/binutils/2016-02/msg00087.html

gcc:

* Check if assembler/dynamic linker support the new behaviour
  (ABIVERSION >= 5). If yes, enable non-executable stack by default
  for all objects.

gcc/ChangeLog
* configure.ac: Check if assembler supports the new PT_GNU_STACK
ABI change; if yes, enable non-executable stack mode by default.
* configure: Regenerate.
* config.in: Regenerate.
* config/mips/mips.c: Define TARGET_ASM_FILE_END to indicate
stack mode for each C file if LD_MIPS_GNUSTACK is enabled.

libgcc/ChangeLog
config/mips/crti.S: Add .note.GNU-stack marker if LD_MIPS_GNUSTACK
support is enabled.
config/mips/crtn.S: Add .note.GNU-stack marker if LD_MIPS_GNUSTACK
support is enabled.
config/mips/mips16.S: Add .note.GNU-stack marker if
LD_MIPS_GNUSTACK support is enabled.
config/mips/vr4120-div.S: Add .note.GNU-stack marker if
LD_MIPS_GNUSTACK support is enabled.

-- gcc/configure.ac gcc/config/mips/mip.c config/mips/crti.S config/mips/crtn.S 
config/mips/mips16.S config/mips/vr4120-div.S
---
 gcc/config/mips/mips.c  |5 +
 gcc/configure.ac|   23 +++
 libgcc/config/mips/crti.S   |6 ++
 libgcc/config/mips/crtn.S   |6 ++
 libgcc/config/mips/mips16.S |7 +++
 libgcc/config/mips/vr4120-div.S |7 +++
 6 files changed, 54 insertions(+)

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index ea18ad6..c3eefc0 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -20194,6 +20194,11 @@ mips_promote_function_mode (const_tree type 
ATTRIBUTE_UNUSED,
 #undef TARGET_HARD_REGNO_SCRATCH_OK
 #define TARGET_HARD_REGNO_SCRATCH_OK mips_hard_regno_scratch_ok

+#if HAVE_LD_MIPS_GNUSTACK
+#undef TARGET_ASM_FILE_END
+#define TARGET_ASM_FILE_END file_end_indicate_exec_stack
+#endif
+
 struct gcc_target targetm = TARGET_INITIALIZER;

 #include "gt-mips.h"
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 0a626e9..9b8190e 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -4562,6 +4562,29 @@ pointers into PC-relative form.])
   AC_MSG_ERROR(
[Requesting --with-nan= requires assembler support for -mnan=])
 fi
+
+AC_CACHE_CHECK([linker for GNU-stack ABI support],
+  [gcc_cv_ld_mips_gnustack],
+  [gcc_cv_ld_mips_gnustack=no
+   if test x$gcc_cv_as != x \
+  -a x$gcc_cv_ld != x \
+  -a x$gcc_cv_readelf != x ; then
+cat > conftest.s < /dev/null 2>&1 \
+   && $gcc_cv_ld -o conftest conftest.o > /dev/null 2>&1; then
+  abi_version=`$gcc_cv_readelf -h conftest 2>&1 | grep "ABI Version:" 
| cut -d: -f2 | tr -d '[[:space:]]'`
+  if test "$abi_version" -ge 5; then
+gcc_cv_ld_mips_gnustack=yes
+  fi
+fi
+   fi
+   rm -f conftest.s conftest.o conftest])
+if test x$gcc_cv_ld_mips_gnustack = xyes; then
+   AC_DEFINE(HAVE_LD_MIPS_GNUSTACK, 1,
+  [Define if your linker can handle PT_GNU_STACK segments correctly.])
+fi
 ;;
 s390*-*-*)
 gcc_GAS_CHECK_FEATURE([.gnu_attribute support],
diff --git a/libgcc/config/mips/crti.S b/libgcc/config/mips/crti.S
index 8521d3c..aa85d94 100644
--- a/libgcc/config/mips/crti.S
+++ b/libgcc/config/mips/crti.S
@@ -21,6 +21,12 @@ a copy 

[Bug tree-optimization/65963] Missed vectorization of loads strided with << when equivalent * succeeds

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from alalaw01 at gcc dot gnu.org ---
Can I class this as fixed?

[Bug middle-end/66877] [6 Regression] FAIL: gcc.dg/vect/vect-over-widen-3-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_over_widening_pattern: detected" 2

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from alalaw01 at gcc dot gnu.org ---
Fix committed r232720.

Re: [PATCH] Fix PR c++/69736

[Patrick Palka]

On Tue, 23 Feb 2016, Patrick Palka wrote:


On Tue, 23 Feb 2016, Marek Polacek wrote:


On Tue, Feb 23, 2016 at 09:58:41AM -0500, Patrick Palka wrote:

finish_call_expr thinks that a call to a function which has been
obfuscated by force_paren_expr is a call to an unknown function.  This
eventually leads us to not make use of the function's default arguments
when processing the argument list.  So a function call like f() may
compile and yet (f)() may not, if f has defaulted arguments.

This patch fixes this inconsistency by making finish_call_expr undo the
obfuscation performed by force_paren_expr.


Thanks for the fix.


new file mode 100644
index 000..12462be
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/paren2.C
@@ -0,0 +1,25 @@
+// PR c++/69736
+


I'd expect
// { dg-do compile { target c++14 } }
here.


Okay.




+void fn1(bool = true)
+{
+  (fn1)();
+}
+
+template 
+void fn2()
+{
+  (fn1)();
+}


The test seems to fail here though because of
testsuite/g++.dg/cpp1y/paren2.C:11:9: error: too few arguments to function
Why's that?


Oops... The call to maybe_undo_parenthesized_ref managed to mysteriously
move itself to the wrong place.  It should be called before the
processing_template_decl logic, before FN gets wrapped in a
NON_DEPENDENT_EXPR.

Here's the updated patch, which I'm going to retest just in case.



Actually, this patch is also wrong since we later reject the function
call (fn1)() when we attempt to instantiate the enclosing template function
fn2<>.  Example:

template 
void fn2(T a)
{
  (fn1)();
}

void foo ()
{
  fn2 (true);
}

This happens because when processing_template_decl, in finish_call_expr we
build a non-dependent CALL_EXPR using the obfuscated orig_fn.  Then during
instantiation, when tsubst_copy_and_build rebuilds this INDIRECT_REF (which is
the orig_fn) it does not copy the REF_PARENTHESIZED_P flag to the newly built
INDIRECT_REF.  So in the subsequent call to finish_call_expr FN is no longer
considered to be a parenthesized ref so maybe_undo_parenthesized_ref becomes a
no-op.

So this can be fixed either by

1. making tsubst_copy_and_build retain the REF_PARENTHESIZED_P flag when
processing an INDIRECT_REF, or by

2. moving the call to maybe_undo_parenthesized_ref in finish_call_expr before
the assignment of orig_fn so that orig_fn will be un-obfuscated as well, or by

3. making tsubst_copy_and_build call maybe_undo_parenthesized_ref when
processing a CALL_EXPR.

I don't know which solution is better.

[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
FYI, profiledbootstrap works for me including Ada,
see
http://s390.koji.fedoraproject.org/packages/gcc/6.0.0/0.12.fc24/data/logs/s390x/build.log

[Bug c++/69889] [6 Regression] ICE: in assign_temp, at function.c:961

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
This looks like a C++ FE bug to me, the operator() method is called with
TREE_ADDRESSABLE argument by value, rather than by reference.
Normally, when the C++ FE goes through build_over_call, convert_for_arg_passing
(or earlier code) should change those arguments to reference passing.
On this testcase the call is generated from simplify_aggr_init_expr, and is
passed by value instead.  I don't know the FE enough to know if it should be
already aggr_init_expr AGGR_INIT_EXPR_ARGP argument to be actually the
reference, or if it is a simplify_aggr_init_expr bug.
Jason, can you please have a look?