[Bug c++/68006] [6 Regression] [C++14] Incorrect aggregate initialization from empty initializer list with NSDMI

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
It looks like trunk/gcc/testsuite/g++.dg/opt/flifetime-dse3.C doesn't work
as expected. It already succeeds before your patch.

[Bug c++/68006] [6 Regression] [C++14] Incorrect aggregate initialization from empty initializer list with NSDMI

[trippels at gcc dot gnu.org]

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

--- Comment #6 from Markus Trippelsdorf  ---
(In reply to Markus Trippelsdorf from comment #5)
> It looks like trunk/gcc/testsuite/g++.dg/opt/flifetime-dse3.C doesn't work
> as expected. It already succeeds before your patch.

Please ignore. I used the wrong compiler to check...

[Bug fortran/63469] Automatic reallocation of allocatable scalar length even when substring implicitly specified

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Dear David,

As you have pointed out, this is identical to PR 67977. This is now fixed on
trunk and will be fixed on 5 branch next weekend.

Thanks for the report

Paul

[Bug fortran/67977] allocatable strings, array section reallocated - non-standard behaviour

[davidgkinniburgh at yahoo dot co.uk]

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

David Kinniburgh  changed:

   What|Removed |Added

 CC||davidgkinniburgh at yahoo dot 
co.u
   ||k

--- Comment #4 from David Kinniburgh  ---
Does this fix 63469?

[Bug target/67995] __attribute__ ((target("arch=XXX"))) enables unsupported ISA

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Oct 19 11:18:14 2015
New Revision: 228967

URL: https://gcc.gnu.org/viewcvs?rev=228967=gcc=rev
Log:
Don't leak ISA to __attribute__ ((target("arch=XXX")))

When processing __attribute__ ((target("arch=XXX"))), we should clear
the ISA bits in x_ix86_isa_flags first to avoid leaking ISA from
command line.

gcc/

PR target/67995
* config/i386/i386.c (ix86_valid_target_attribute_tree): If
arch= is set,  clear all bits in x_ix86_isa_flags, except for
ISA_64BIT, ABI_64, ABI_X32, and CODE16.

gcc/testsuite/

PR target/67995
* gcc.target/i386/pr67995-1.c: New test.
* gcc.target/i386/pr67995-2.c: Likewise.
* gcc.target/i386/pr67995-3.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr67995-1.c
trunk/gcc/testsuite/gcc.target/i386/pr67995-2.c
trunk/gcc/testsuite/gcc.target/i386/pr67995-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/67818] [5 Regression] FAIL: libgomp.fortran/alloc-comp-[23].f90

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |mikael at gcc dot 
gnu.org

--- Comment #10 from Mikael Morin  ---
(In reply to H.J. Lu from comment #8)
> Yes, r222477 fixed the regression on gcc-5-branch without any new
> testsuite failures.

The patch has been backported.
Closing.

[Bug fortran/67721] deep copy missing when assigning a derived type constructor to an array

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Mikael Morin  ---
(In reply to H.J. Lu from comment #8)
> On Linux/x86-64, gfortran.dg/alloc_comp_deep_copy_3.f03 failed
> on gcc-5-branch branch:

Fixed with r228945.
Closing again.

[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #3)
> The problem is that we don't have a POINTER_DIFF_EXPR similar to
> POINTER_PLUS_EXPR, which would take two pointers and return an integer, and
> the FEs emit pointer difference as cast of both the pointers to signed
> integral type
> and subtracts the integers.
> If
> ssize_t foo (char *p, char *q) { return p - q; }
> is changed into
> ssize_t foo (char *p, char *q) { return (ssize_t) p - (ssize_t) q; }
> by the FE, then indeed if you have array starting at 0x7fff and ending
> at 0x8001 and subtract those two pointers, you get undefined behavior.
> That is undefined behavior not just for ubsan, but for anything else in the
> middle-end.
> So, if pointer difference is supposed to behave differently, then
> we'd either need to represent pointer difference as
> ssize_t foo (char *p, char *q) { return (ssize_t) ((size_t) p - (size_t) q);
> }
> (but we risk missed optimizations that way I'd say), or we'd need a better
> representation of it in the middle-end.

Note that apart from missing POINTER_DIFF this isn't a middle-end but a
frontend
issue.

[Bug rtl-optimization/68011] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu in 64-bit mode

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
So likely a target bug.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[josephpattara at gmail dot com]

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

--- Comment #5 from Joseph John  ---
I am still struggling to compiler any version giver than GCC 4.9.0 on ia64
platform still but as far as this issue is concerned I was able to get pass the
LD abort when I used the below options for configure:

CC="gcc -mlp64" CXX="g++ -mlp64"

With this option I was able to pass the linker abort just after the
libbackend.a creation but I run into a segmentation error which I believe is
the documented issue at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919

[Bug rtl-optimization/68011] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu in 64-bit mode

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-19
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r225852.

[Bug tree-optimization/45397] [4.9/5/6 Regression] Issues with integer narrowing conversions

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #19 from Marek Polacek  ---
When this deficiency is finally resolved, we should be able to remove the code
in convert_to_integer dealing with narrowing operands:

 738 case PLUS_EXPR:
 739 case MINUS_EXPR:
 740 case BIT_AND_EXPR:
 741 case BIT_IOR_EXPR:
 742 case BIT_XOR_EXPR:
 743 trunc1:
 744   {
 ...
 821 return convert (type,
 822 fold_build2 (ex_form, typex,
 823  convert (typex, arg0),
 824  convert (typex, arg1)));

[Bug target/67995] __attribute__ ((target("arch=XXX"))) enables unsupported ISA

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-19
  Known to work||6.0
 Ever confirmed|0   |1
  Known to fail||4.9.4, 5.3.0

--- Comment #4 from H.J. Lu  ---
Fixed on trunk so far.

[Bug fortran/67977] allocatable strings, array section reallocated - non-standard behaviour

[paul.richard.thomas at gmail dot com]

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

--- Comment #5 from paul.richard.thomas at gmail dot com  ---
Hi David,

Yes it does. Thank you for bring this PR to my attention. I'll mark it
appropriately.

Cheers

Paul

On 19 October 2015 at 13:42, davidgkinniburgh at yahoo dot co.uk
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67977
>
> David Kinniburgh  changed:
>
>What|Removed |Added
> 
>  CC||davidgkinniburgh at yahoo 
> dot co.u
>||k
>
> --- Comment #4 from David Kinniburgh  ---
> Does this fix 63469?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug c++/67466] Project segfaulting, working with other compilers

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Severity|critical|normal

[Bug c/67999] Wrong optimization of pointer comparisons

[fw at gcc dot gnu.org]

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

--- Comment #11 from Florian Weimer  ---
(In reply to Daniel Micay from comment #9)

> I don't think there's much of a use case for allocating a single >2G
> allocation in a 3G or 4G address space.

The main OpenJDK heap (well, it was Java back then) has to be once contiguous
memory mapping, and there was significant demand to get past 2 GiB.  For users
who are tied to 32-bit VMs due to JNI and other considerations, this demand
probably still exists.

Oracle database apparently tried to use large shared-memory mappings as well. 
If I read the old documentation correctly, it actually had to be in one piece,
too.  (The documentation talks about changing the SHMMAX parameter to a large
value, not just SHMALL.)

PostgreSQL definitely needs a single large shared-memory mapping, but its
buffering behavior is significantly different, so I think there was less demand
to create these huge mappings.

> It has a high chance of failure
> simply due to virtual memory fragmentation, especially since the kernel's
> mmap allocation algorithm is so naive (keeps going downwards and ignores
> holes until it runs out, rather than using first-best-fit).

The mappings are created early during process life-time, and if I recall
correctly, this requirement limited ASLR for 32-bit processes quite
significantly.

> Was the demand for a larger address space or was it really for the ability
> to allocate all that memory in one go?

In the Java case, it was for a contiguous memory mapping larger than 2 GiB. 
I'm less sure about the Oracle use case.

[Bug c/67999] Wrong optimization of pointer comparisons

[danielmicay at gmail dot com]

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

--- Comment #14 from Daniel Micay  ---
(In reply to Florian Weimer from comment #12)
> (In reply to Daniel Micay from comment #10)
> > (In reply to Florian Weimer from comment #7)
> > > If this is not a GCC bug and it is the responsibility of allocators not to
> > > produce huge objects, do we also have to make sure that no object crosses
> > > the boundary between 0x7fff_ and 0x8000_?  If pointers are treated
> > > as de-facto signed, this is where signed overflow would occur.
> > 
> > No, that's fine.
> 
> Is this based on your reading of the standard, the GCC sources, or both? 
> (It is unusual to see people making such definite statements about
> middle-end/back-end behavior, that's why I have to ask.)

It's not the kind of thing the standard is concerned with: it'd be perfectly
valid for an implementation to forbid that, as long as it was enforced
throughout the implementation. It would be just crazy to have a requirement
like that. As far as I know, the use of signed offsets for pointer arithmetic
in GCC is just a design decision with known consequences. That's definitely the
case in LLVM, since it's very explicitly documented as being a signed offset
with undefined overflow.

[Bug c/67999] Wrong optimization of pointer comparisons

[danielmicay at gmail dot com]

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

--- Comment #15 from Daniel Micay  ---
i.e. AFAIK the offsets are intended to be treated as signed but treating
pointers as signed would be a serious bug rather than a design choice

[Bug c++/67860] [concepts] bug with overloaded, refined function with explicit and variadic template arguments

[chrisb2244 at gmail dot com]

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

Christian Butcher  changed:

   What|Removed |Added

 CC||chrisb2244 at gmail dot com

--- Comment #1 from Christian Butcher  ---
A (I hope) similar (and perhaps simpler) code producing this result is

###
#include 

template 
concept bool AreType() {
return (std::is_same::value && ...);
// return true; gives the same overloaded error
}

// Function with constraint
template... U>
bool isValid(U... u) {
return true;
}

// Function with no constraint
template
bool isValid(U... u) {
return false;
}

int main() {
isValid(1); // also isValid(1, 2, 3); etc
}

###

[Bug c/67999] Wrong optimization of pointer comparisons

[fw at gcc dot gnu.org]

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #7 from Florian Weimer  ---
If this is not a GCC bug and it is the responsibility of allocators not to
produce huge objects, do we also have to make sure that no object crosses the
boundary between 0x7fff_ and 0x8000_?  If pointers are treated as
de-facto signed, this is where signed overflow would occur.

[Bug c/67999] Wrong optimization of pointer comparisons

[fw at gcc dot gnu.org]

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

--- Comment #12 from Florian Weimer  ---
(In reply to Daniel Micay from comment #10)
> (In reply to Florian Weimer from comment #7)
> > If this is not a GCC bug and it is the responsibility of allocators not to
> > produce huge objects, do we also have to make sure that no object crosses
> > the boundary between 0x7fff_ and 0x8000_?  If pointers are treated
> > as de-facto signed, this is where signed overflow would occur.
> 
> No, that's fine.

Is this based on your reading of the standard, the GCC sources, or both?  (It
is unusual to see people making such definite statements about
middle-end/back-end behavior, that's why I have to ask.)

[Bug c++/68012] g++ incorrectly accepts forward declaration of constexpt variable template

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-19
 CC|morwenn29 at hotmail dot fr|
 Blocks||55004
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug tree-optimization/68013] [6 Regression] ICE on valid code at -O2 on x86_64-linux-gnu in duplicate_thread_path, at tree-ssa-threadupdate.c:2469

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|ICE on valid code at -O2 on |[6 Regression] ICE on valid
   |x86_64-linux-gnu in |code at -O2 on
   |duplicate_thread_path, at   |x86_64-linux-gnu in
   |tree-ssa-threadupdate.c:246 |duplicate_thread_path, at
   |9   |tree-ssa-threadupdate.c:246
   ||9

[Bug gcov-profile/67992] GCOV takes an absurdly long time to process a file

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
I think there is a duplicate about gcov slowness for some sort of CFGs.

[Bug middle-end/68002] retaining unused static functions at -O1

[vondele at gcc dot gnu.org]

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

--- Comment #2 from vondele at gcc dot gnu.org ---
Author: vondele
Date: Mon Oct 19 10:24:37 2015
New Revision: 228965

URL: https://gcc.gnu.org/viewcvs?rev=228965=gcc=rev
Log:
Fix PR68002, add -fkeep-static-functions

gcc/ChangeLog:

2015-10-17  Joost VandeVondele  

PR middle-end/68002
* common.opt (fkeep-static-functions): New option.
* doc/invoke.texi: Document it.
* cgraphunit.c (cgraph_node::finalize_function): Use it.

gcc/testsuite/ChangeLog:

2015-10-17  Joost VandeVondele  

PR middle-end/68002
* gcc.dg/PR68002.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/PR68002.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/common.opt
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c/67999] Wrong optimization of pointer comparisons

[fw at gcc dot gnu.org]

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

--- Comment #8 from Florian Weimer  ---
(In reply to Alexander Cherepanov from comment #4)

> Am I right that the C standards do not allow for such a limitation (and
> hence this should not be reported to glibc as a bug) and gcc is not
> standards-compliant in this regard? Or I'm missing something?

The standard explicitly acknowledges the possibility of arrays that have more
than PTRDIFF_MAX elements (it says that the difference of two pointers within
the same array is not necessarily representable in ptrdiff_t).

I'm hesitant to put in artificial limits into glibc because in the mast, there
was significant demand for huge mappings in 32-bit programs (to the degree that
Red Hat even shipped special kernels for this purpose).

[Bug c/67999] Wrong optimization of pointer comparisons

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #17 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #16)
> GCC assumes objects will not wrap around zero only (well, it assumes objects
> cannot live at address zero but it also assumes that the
> pointer-to-one-element-after isn't zero or wraps around zero).

Well, we still have a bug mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303#c3
for pointer subtraction, though perhaps it is hard to construct a testcase
where it would make a difference except for the sanitizers.

[Bug tree-optimization/67975] Failure to optimise equality between two call sequences

[rsandifo at gcc dot gnu.org]

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #4)
> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01580.html
> 
> Hope that fixes all cases you ran into.

Yeah, thanks.  That fixes the builtins-20.c failures that I was seeing
after moving fold_strip_sign_ops to gimple.

[Bug c/67999] Wrong optimization of pointer comparisons

[danielmicay at gmail dot com]

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

--- Comment #9 from Daniel Micay  ---
(In reply to Florian Weimer from comment #8)
> (In reply to Alexander Cherepanov from comment #4)
> 
> > Am I right that the C standards do not allow for such a limitation (and
> > hence this should not be reported to glibc as a bug) and gcc is not
> > standards-compliant in this regard? Or I'm missing something?
> 
> The standard explicitly acknowledges the possibility of arrays that have
> more than PTRDIFF_MAX elements (it says that the difference of two pointers
> within the same array is not necessarily representable in ptrdiff_t).
> 
> I'm hesitant to put in artificial limits into glibc because in the mast,
> there was significant demand for huge mappings in 32-bit programs (to the
> degree that Red Hat even shipped special kernels for this purpose).

I don't think there's much of a use case for allocating a single >2G allocation
in a 3G or 4G address space. It has a high chance of failure simply due to
virtual memory fragmentation, especially since the kernel's mmap allocation
algorithm is so naive (keeps going downwards and ignores holes until it runs
out, rather than using first-best-fit).

Was the demand for a larger address space or was it really for the ability to
allocate all that memory in one go?

[Bug c++/67529] rx-elf C++ inherited class malformed call to overridden methods

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Severity|critical|normal

[Bug c/67999] Wrong optimization of pointer comparisons

[danielmicay at gmail dot com]

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

--- Comment #10 from Daniel Micay  ---
(In reply to Florian Weimer from comment #7)
> If this is not a GCC bug and it is the responsibility of allocators not to
> produce huge objects, do we also have to make sure that no object crosses
> the boundary between 0x7fff_ and 0x8000_?  If pointers are treated
> as de-facto signed, this is where signed overflow would occur.

No, that's fine. It's the offsets that are treated as ptrdiff_t. Clang/LLVM
handle it the same way. There's a very important assumption for optimizations
that pointer arithmetic cannot wrap (per the standard) and all offsets are
treated as signed integers. AFAIK, `ptr + size` is equivalent to `ptr +
(ptrdiff_t)size` in both Clang and GCC.

There's documentation on how this is handled in LLVM IR here, specifically the
inbounds marker which is added to all standard C pointer arithmetic:

http://llvm.org/docs/LangRef.html#getelementptr-instruction

I expect GCC works very similarly, but I'm not familiar with the GCC internals.

It's not really a compiler bug because the standard allows object size limits,
but the compiler and standard C library both need to be aware of those limits
and enforce them if they exist. So it's a bug in GCC + glibc or Clang + glibc,
not either of them alone. I think dealing with it in libc is the only full
solution though due to issues like `p - q` and the usage of ssize_t for sizes
in functions like read/write.

[Bug c/67999] Wrong optimization of pointer comparisons

[danielmicay at gmail dot com]

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

--- Comment #13 from Daniel Micay  ---
They'd still be able to make a mmap system call via syscall(...) to avoid the
check, so it seems like it's mostly an ABI compatibility issue. Of course,
they'd have to be very careful to avoid all of the caveats of a mapping that
large too. It could be dealt with as it usually is by making new symbols with
the checks to avoid changing anything for old binaries.

And yeah, the vanilla kernel ASLR is incredibly weak. It only uses up to 1MiB
of virtual memory (8-bit ASLR) rather than 256MiB (16-bit) like PaX.

[Bug rtl-optimization/68011] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu in 64-bit mode

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|wrong code at -O1 and above |[6 Regression] wrong code
   |on x86_64-linux-gnu in  |at -O1 and above on
   |64-bit mode |x86_64-linux-gnu in 64-bit
   ||mode

[Bug c++/67687] [c++0x][constexpr] initialize constexpr member with constexpr constructor

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Severity|critical|normal

[Bug c++/67687] [c++0x][constexpr] initialize constexpr member with constexpr constructor

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-19
 Blocks||55004
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
[Bug 55004] [meta-bug] constexpr issues

[Bug c/67999] Wrong optimization of pointer comparisons

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
GCC assumes objects will not wrap around zero only (well, it assumes objects
cannot live at address zero but it also assumes that the
pointer-to-one-element-after isn't zero or wraps around zero).

[Bug tree-optimization/67975] Failure to optimise equality between two call sequences

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug tree-optimization/67975] Failure to optimise equality between two call sequences

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 19 14:00:28 2015
New Revision: 228971

URL: https://gcc.gnu.org/viewcvs?rev=228971=gcc=rev
Log:
2015-10-19  Richard Biener  

PR tree-optimization/67975
* tree-cfg.h (extract_true_false_controlled_edges): Declare.
* tree-cfg.c (extract_true_false_controlled_edges): Split out
core worker from ...
* tree-ssa-loop-im.c (extract_true_false_args_from_phi): ... here.
* tree-ssa-sccvn.c (vn_phi_compute_hash): Hash number of args
instead of block number for PHIs with two or one args.
(vn_phi_eq): Compare edge predicates of PHIs that are in different
blocks.

* gcc.dg/tree-ssa/ssa-fre-50.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-50.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c
trunk/gcc/tree-cfg.h
trunk/gcc/tree-ssa-loop-im.c
trunk/gcc/tree-ssa-sccvn.c

[Bug rtl-optimization/68011] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu in 64-bit mode

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Possibly a dup of that reload/LRA issue

[Bug fortran/67933] [4.9/5/6 Regression] ICE for array of a derived type with allocatable class in derived type object

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas  ---
(In reply to Mikael Morin from comment #2)
> The generated finalization wrapper has code doing
>   deallocate(ptr2%classes(:)%class_var)
> where ptr2 is a pointer of type list_t to be finalized.
> This is missing scalarization, a correct code would do instead:
>   do i=1,size(ptr2)
> ptr3 => ptr2%classes(i)
> deallocate (ptr3%class_var)
>   end do

Hi Mikael,

This does not seem to be the problem. It is actually the
  gfc_reset_vptr (, al->expr);
at trans-stmt.c:6048.

Once gfc_reset_vptr is modified to quit if it doesn't find a vptr, compilation
succeeds and the finalizer has:

S.7 = 0;
while (1)
  {
if (S.7 > 9) goto L.11;
if (ptr2->classes[S.7].class_var._data != 0B &&
   ptr2->classes[S.7].class_var._vptr->_final != 0B)
  {
desc.8.dtype = 296;
desc.8.data = (void * restrict) ptr2->classes[S.7].class_var._data;
ptr2->classes[S.7].class_var._vptr->_final (, (integer(kind=8)) 
ptr2->classes[S.7].class_var._vptr->_size, 1);
  }
if (ptr2->classes[S.7].class_var._data != 0B)
  {
 __builtin_free ((void *) ptr2->classes[S.7].class_var._data);
  }
ptr2->classes[S.7].class_var._data = 0B;
S.7 = S.7 + 1;
  }
L.11:;

I'll post the patch as soon as I understand where the vptr's go to.

Cheers

Paul

[Bug target/68015] New: ICE in s390_emit_compare

[matz at gcc dot gnu.org]

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

Bug ID: 68015
   Summary: ICE in s390_emit_compare
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matz at gcc dot gnu.org
  Target Milestone: ---

$ cat s390x-ice-datetime.i
/* -O2 -march=z196 --> ICE in s390_emit_compare */
extern long useme (long, ...);

void foo (void)
{
long secs = useme (41);
long utc_secs = useme (42);
long h, m;

utc_secs = useme (42);
h = secs / 3600;
m = secs / 60;
if (utc_secs >= 86400) {
m = 59;
h--;
if (h < 0) {
h = 23;
}
}
useme(h,m);
}

$ ./cc1 -fpreprocessed -march=z196 -O2 s390x-ice-datetime.i 
s390x-ice-datetime.i: In function ‘foo’:
s390x-ice-datetime.i:21:1: internal compiler error: in s390_emit_compare, at
config/s390/s390.c:1708
 }
 ^
0x10f3155 s390_emit_compare(rtx_code, rtx_def*, rtx_def*)
../../gcc/gcc/config/s390/s390.c:1707
0x1262985 gen_movdicc(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
../../gcc/gcc/config/s390/s390.md:6112
0xc2beb2 insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*) const
../../gcc/gcc/recog.h:303
0xc2b98e maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../gcc/gcc/optabs.c:6721
0xc2bc8b maybe_expand_insn(insn_code, unsigned int, expand_operand*)
../../gcc/gcc/optabs.c:6751
0xc259b8 emit_conditional_move(rtx_def*, rtx_code, rtx_def*, rtx_def*,
machine_mode, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/gcc/optabs.c:4201
0x13d8f38 noce_emit_cmove
../../gcc/gcc/ifcvt.c:1607
0x13dd882 cond_move_convert_if_block
../../gcc/gcc/ifcvt.c:3449
0x13ddc09 cond_move_process_if_block
../../gcc/gcc/ifcvt.c:3536
0x13de284 noce_find_if_block
../../gcc/gcc/ifcvt.c:3704
0x13de93b find_if_header
../../gcc/gcc/ifcvt.c:3905
0x13e1434 if_convert
../../gcc/gcc/ifcvt.c:5051
0x13e1773 execute
../../gcc/gcc/ifcvt.c:5198

[Bug target/68015] ICE in s390_emit_compare

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org

--- Comment #1 from Michael Matz  ---
This also happens on the gcc-5-branch (as of now, i.e. r228958).  It requires
the -march=z196, and it hits us in multiple packages (the testcase extracted
from perl-DateTime, but e.g. also in qt3).  This -march level is the
default for us.

[Bug sanitizer/68016] New: ASan doesn't catch overflow in globals when COPY relocation is involved.

[chefmax at gcc dot gnu.org]

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

Bug ID: 68016
   Summary: ASan doesn't catch overflow in globals when COPY
relocation is involved.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chefmax at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
y.gribov at samsung dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Consider:

max@max:~/workspace/downloads/gcc$ cat libfoo.c
int f[5] = {1};

max@max:~/workspace/downloads/gcc$ cat main.c
extern int f[5];
int main ()
{
  return f[5];
}

max@max:~/workspace/downloads/gcc$ ~/install/master-ref/bin/gcc
-fsanitize=address libfoo.c -shared -fpic -fsanitize=address -o libfoo.so
max@max:~/workspace/downloads/gcc$ ~/install/master-ref/bin/gcc
-fsanitize=address  main.c -c  -o main.o
max@max:~/workspace/downloads/gcc$ ~/install/master-ref/bin/gcc
-fsanitize=address main.o ./libfoo.so -o main
max@max:~/workspace/downloads/gcc$ LD_LIBRARY_PATH=~/install/master-ref/lib64
ASAN_OPTIONS=report_globals=3  ./main
#0 0x7f73cc9bfdde in __asan_register_globals
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_globals.cc:228
#1 0x7f73cc796800 in _GLOBAL__sub_I_00099_1_libfoo.c (libfoo.so+0x800)
#2 0x7f73cd910139  (/lib64/ld-linux-x86-64.so.2+0x10139)
#3 0x7f73cd910222  (/lib64/ld-linux-x86-64.so.2+0x10222)
#4 0x7f73cd901309  (/lib64/ld-linux-x86-64.so.2+0x1309)

=== ID 738197505; 0x7f73cc996bc0 0x7f73cc996bc0
==16063==Added Global[0x7f73cc996bc0]: beg=0x7f73cc996b60 size=20/64 name=f
module=libfoo.c dyn_init=0
==16063==  location (0x7f73cc996ba0): name=libfoo.c[0x7f73cc79680d], 1 5

max@max:~/workspace/downloads/gcc$ readelf -r main | grep COPY
0070eac0  02540005 R_X86_64_COPY 0070eac0 f + 0 

This happens due to private aliases, used by GCC to register globals. LLVM
catches this overflow, but it has another drawback - mixing sanitized and
non-sanitized code may lead to application crash.

Don't know if there is a good fix for both issues. Any thoughts? IMHO, false
negatives are more preferable than application crash.

[Bug c++/67847] ICE on (invalid) nested enum declaration on x86_64-linux-gnu in is_ancestor, at cp/name-lookup.c:2771

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

[Bug rtl-optimization/67635] [SH] ifcvt missed optimization

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
I had a look at:
unsigned int test_03 (unsigned int x)
{
  return x > 0 ? x + 1 : x;
}

The cse1 pass transforms this into something not quite comfortable for ifcvt.
Basically, it transforms the RTL equivalent of:

compare (x, 0);
if (x > 0)
  temp := x + 1;
else
  temp := x;
return temp;

into:
compare (x, 0);
if (x > 0)
  temp := x + 1;
else
  temp := 0;
return temp;

which is a valid transformation to make as far as cse is concerned.
Unfortunately, when ifcvt comes along, it's asked to optimise a conditional
select between '0' and 'x + 1', which is not something it can do with an
addc-style pattern.

I initially thought of looking into the condition to see if it contains x (so
that we can deduce that the 'else' arm could actually be replaced with x,
undoing the cse in that case), but the condition rtl contains a comparison with
the T-register, rather than the original comparison with 0.

Perhaps we can consider teaching cse to not transform these kinds of
expressions (c ? x : x + a) if the target has a store_flag/addcc instruction of
the appropriate mode?

But I'm not familiar with the cse code, so I don't know how easy/clean that is

[Bug fortran/67987] ICE on declaring and initializing character with negative len

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug fortran/68019] ICE on rank mismatch of implied-shape array of user-defined type

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Oct 19 21:09:21 2015
New Revision: 229003

URL: https://gcc.gnu.org/viewcvs?rev=229003=gcc=rev
Log:
2015-10-19  Steven G. Kargl  

PR fortran/68019
* decl.c (add_init_expr_to_sym): Remove an assert() to allow an error
message to be issued.

2015-10-19  Steven G. Kargl  

PR fortran/68019
* gfortran.dg/pr68019.f90: new test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr68019.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/68019] ICE on rank mismatch of implied-shape array of user-defined type

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Thanks for the bug report.  Fixed on trunk and 5-branch.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #20)
> (In reply to Giuseppe Ottaviano from comment #19)
> > The regression might have been already solved in r225244, which uses yet
> > another SFINAE pattern without extra template arguments, which I believe are
> > the cause of the regression. However I haven't tested it yet.
> 
> That would be nice to know, because I now use that kind of void_t-style
> constraint in a few places, and plan to use it more widely. My measurements
> do show that using void_t-style constraints result in small but measurable
> reductions in compile time and memory use.

Oh, I looked at the wrong bit of r225244, it's using SFINAE in a
trailing-return-type that matters here, not the __detected_or_t_ changes.

[Bug fortran/68019] ICE on rank mismatch of implied-shape array of user-defined type

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Oct 19 21:29:15 2015
New Revision: 229005

URL: https://gcc.gnu.org/viewcvs?rev=229005=gcc=rev
Log:
2015-10-19  Steven G. Kargl  

PR fortran/68019
* decl.c (add_init_expr_to_sym): Remove an assert() to allow an error
message to be issued.

2015-10-19  Steven G. Kargl  

PR fortran/68019
* gfortran.dg/pr68019.f90: new test.

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

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #20 from Jonathan Wakely  ---
(In reply to Giuseppe Ottaviano from comment #19)
> At Facebook we experienced a similar regression, compilation times more than
> doubled for several large C++ files.
> We found that the regression was mostly caused by r207240, specifically to
> the changes in bits/alloc_traits.h. Just reverting that file brought back
> build times almost to previous levels.
> 
> By looking at GCC profiles, a disproportionate amount of time is spent in
> structural_comptypes and template_args_equal (which doesn't happen before
> the change). The revision only changes the way some traits are selected
> through SFINAE, specifically the pattern:
> 
> template  enable_if<..., R>::type f();
> 
> became
> 
> template > R f();
> 
> and _Require is just a wrapper around enable_if.

Jason, this is an interesting observation about where time is spent in the FE
for this common SFINAE technique. I use it for constructors, where there is no
return value on which to put the enable_if, and where adding an extra
constructor parameter with a default argument would change the signature (or be
impossible, due to the constructor being a variadic template).

Any chance this is low-hanging fruit and could be avoided fairly easily, or
should I stop using this technique in bits of the library that are compiled as
often as allocator_traits?

> I don't know why this change has such a large impact on compilation times,
> it would deserve some investigation. Other parts of the standard library
> might be affected by this.

Very probably, I have used that pattern widely.

> The regression might have been already solved in r225244, which uses yet
> another SFINAE pattern without extra template arguments, which I believe are
> the cause of the regression. However I haven't tested it yet.

That would be nice to know, because I now use that kind of void_t-style
constraint in a few places, and plan to use it more widely. My measurements do
show that using void_t-style constraints result in small but measurable
reductions in compile time and memory use.

[Bug target/68018] [6 Regression] ICE: in ix86_compute_frame_layout, at config/i386/i386.c:11308 with -mstackrealign

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Some parts of gcc still assume that MS_ABI stack is always aligned to 128bits.

Proposed patch:

--cut here--
@@ -11283,7 +11296,8 @@ ix86_compute_frame_layout (struct ix86_frame *fram
  function prologues and leaf.  */
   if ((TARGET_64BIT_MS_ABI && crtl->preferred_stack_boundary < 128)
   && (!crtl->is_leaf || cfun->calls_alloca != 0
-  || ix86_current_function_calls_tls_descriptor))
+ || ix86_current_function_calls_tls_descriptor
+ || ix86_incoming_stack_boundary < 128))
 {
   crtl->preferred_stack_boundary = 128;
   crtl->stack_alignment_needed = 128;
--cut here--

[Bug debug/68010] internal compiler error: in tree_to_shwi, at tree.h:3661

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

  Known to work|5.2.1, 6.0  |
  Known to fail||5.2.1, 6.0

--- Comment #5 from Markus Trippelsdorf  ---
Reduced testcase ICEs with all supported versions:

markus@x4 tmp % cat c.ii
template 
auto begin(_Container __cont) -> decltype(__cont.begin());
template 
auto end(_Container __cont) -> decltype(__cont.end());
class A {
public:
  int begin();
  int end();
};
namespace boost {}
namespace b = boost;
namespace boost {
template 
struct B;
template  struct C;
template  struct B {};
template  struct C {
  typedef C base_type;
  template 
  C(B);
};
}
template  class StructDecoder : boost::C {
public:
  StructDecoder() : StructDecoder::base_type(start_rule) {
namespace bs = boost;
using namespace bs;
  }
  b::B start_rule;
};
namespace qi = boost;
class D {
public:
  D(int, int);
};
struct F : qi::C<> {
  F(int, D func) : base_type(program), report_error(func) {}
  qi::B program;
  StructDecoder q_syslog_desc;
  D report_error;
};
int NFGParserparse_tokens;
void NFGParserparse() {
  A str;
  D error_report(begin(str), end(str));
  F(NFGParserparse_tokens, error_report);
}

markus@x4 tmp % g++ -c -g -std=c++11 c.ii
c.ii: In constructor ‘StructDecoder::StructDecoder() [with Skipper =
int]’:
c.ii:49:1: internal compiler error: in tree_to_shwi, at tree.c:7289
 }
 ^
0xf22ae2 tree_to_shwi(tree_node const*)
../../gcc/gcc/tree.c:7289
0x983033 add_data_member_location_attribute
../../gcc/gcc/dwarf2out.c:15480
0x98c748 gen_inheritance_die
../../gcc/gcc/dwarf2out.c:20345
0x98c748 gen_member_die
../../gcc/gcc/dwarf2out.c:20397
0x98c748 gen_struct_or_union_type_die
../../gcc/gcc/dwarf2out.c:20517
0x98c748 gen_tagged_type_die
../../gcc/gcc/dwarf2out.c:20718
0x98b1cd gen_type_die_with_usage
../../gcc/gcc/dwarf2out.c:20880
0x98c036 gen_type_die
../../gcc/gcc/dwarf2out.c:20935
0x9948fa modified_type_die
../../gcc/gcc/dwarf2out.c:10950
0x99404b force_type_die
../../gcc/gcc/dwarf2out.c:21265
0x99378d get_context_die
../../gcc/gcc/dwarf2out.c:21180
0x99378d force_decl_die
../../gcc/gcc/dwarf2out.c:21199
0x993894 get_context_die
../../gcc/gcc/dwarf2out.c:21183
0x993894 force_decl_die
../../gcc/gcc/dwarf2out.c:21199
0x98e2a7 dwarf2out_imported_module_or_decl_1
../../gcc/gcc/dwarf2out.c:21752
0x98e592 process_scope_var
../../gcc/gcc/dwarf2out.c:21053
0x98e807 decls_for_scope
../../gcc/gcc/dwarf2out.c:21081
0x9a4b9d gen_lexical_block_die
../../gcc/gcc/dwarf2out.c:19950
0x9a4b9d gen_block_die
../../gcc/gcc/dwarf2out.c:21025
0x98e892 decls_for_scope
../../gcc/gcc/dwarf2out.c:21095

[Bug fortran/68019] New: ICE on rank mismatch of implied-shape array of user-defined type

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

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

Bug ID: 68019
   Summary: ICE on rank mismatch of implied-shape array of
user-defined type
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With a rank mismatch of "arr" :

$ cat z1.f90
program p
   integer :: i
   type t
  integer :: n
   end type
   type(t), parameter :: vec(*) = [(t(i), i = 1, 4)]
   type(t), parameter :: arr(*) = reshape(vec, [2, 2])
end


$ gfortran -g -O0 -Wall -fcheck=all z1.f90
f951: internal compiler error: in add_init_expr_to_sym, at fortran/decl.c:1457

---

Whereas :

$ cat z2.f90
program p
   integer :: i
   integer, parameter :: vec(*) = [(i, i = 1, 4)]
   integer, parameter :: arr(*) = reshape(vec, [2, 2])
end


$ gfortran -g -O0 -Wall -fcheck=all z2.f90
z2.f90:4:31:

integer, parameter :: arr(*) = reshape(vec, [2, 2])
   1
Error: Incompatible ranks 1 and 2 in assignment at (1)

[Bug rtl-optimization/68011] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu in 64-bit mode

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #3)
> Possibly a dup of that reload/LRA issue

Exactly.

We start with:

(insn 18 17 19 2 (parallel [
(set (subreg:DI (reg/v:TI 92 [ e ]) 0)
(ior:DI (reg:DI 100)
(reg:DI 98 [ _3 ])))
(clobber (reg:CC 17 flags))
]) pr68011.c:18 398 {*iordi_1}
 (expr_list:REG_DEAD (reg:DI 100)
(expr_list:REG_DEAD (reg:DI 98 [ _3 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
(insn 19 18 21 2 (set (reg:V8HI 103)
(vec_merge:V8HI (vec_duplicate:V8HI (reg:HI 91 [ e$12 ]))
(subreg:V8HI (reg/v:TI 92 [ e ]) 0)
(const_int 64 [0x40]))) pr68011.c:18 3597 {sse2_pinsrw}

and reload generates (insn 41) that clears high word:

(insn 18 39 40 2 (parallel [
(set (reg:DI 0 ax [100])
(ior:DI (reg:DI 0 ax [100])
(reg:DI 2 cx [orig:98 _3 ] [98])))
(clobber (reg:CC 17 flags))
]) pr68011.c:18 398 {*iordi_1}
 (nil))

...

(insn 41 40 19 2 (set (reg:DI 21 xmm0 [orig:92 e ] [92])
(mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [0 %sfp+-8 S8 A64])) pr68011.c:18 85
{*movdi_internal}
 (nil))
(insn 19 41 21 2 (set (reg:V8HI 21 xmm0 [103])
(vec_merge:V8HI (vec_duplicate:V8HI (reg:HI 1 dx [orig:91 e$12 ] [91]))
(reg:V8HI 21 xmm0 [orig:92 e ] [92])
(const_int 64 [0x40]))) pr68011.c:18 3597 {sse2_pinsrw}

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

[Bug rtl-optimization/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[ubizjak at gmail dot com]

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

--- Comment #14 from Uroš Bizjak  ---
*** Bug 68011 has been marked as a duplicate of this bug. ***

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[ott at fb dot com]

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

Giuseppe Ottaviano  changed:

   What|Removed |Added

 CC||ott at fb dot com

--- Comment #19 from Giuseppe Ottaviano  ---
At Facebook we experienced a similar regression, compilation times more than
doubled for several large C++ files.
We found that the regression was mostly caused by r207240, specifically to the
changes in bits/alloc_traits.h. Just reverting that file brought back build
times almost to previous levels.

By looking at GCC profiles, a disproportionate amount of time is spent in
structural_comptypes and template_args_equal (which doesn't happen before the
change). The revision only changes the way some traits are selected through
SFINAE, specifically the pattern:

template  enable_if<..., R>::type f();

became

template > R f();

and _Require is just a wrapper around enable_if.

I don't know why this change has such a large impact on compilation times, it
would deserve some investigation. Other parts of the standard library might be
affected by this.

The regression might have been already solved in r225244, which uses yet
another SFINAE pattern without extra template arguments, which I believe are
the cause of the regression. However I haven't tested it yet.

[Bug fortran/56852] [4.9 Regression] ICE on invalid: "Bad array reference" for an undeclared loop variable

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  ---
Author: pault
Date: Mon Oct 19 19:32:52 2015
New Revision: 229000

URL: https://gcc.gnu.org/viewcvs?rev=229000=gcc=rev
Log:
2013-10-19  Paul Thomas  

PR fortran/56852
* primary.c (gfc_variable_attr): Avoid ICE on AR_UNKNOWN if any
of the index variables are untyped and errors are present.

2013-10-19  Paul Thomas  

PR fortran/56852
* gfortran.dg/pr56852.f90 : New test

Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/pr56852.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/primary.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/68020] New: Issue with implied-shape array parameter of rank > 2

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

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

Bug ID: 68020
   Summary: Issue with implied-shape array parameter of rank > 2
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Based on f2008 (5.3.8.6), an implied-shape array is declared with
an implied-shape-spec-list. This works excellent for rank 1 and 2,
but is rejected for higher ranks.


$ cat z2.f90
program p
   integer, parameter :: a(1, 2) = 0
   integer, parameter :: x(*, *) = a
   integer, parameter :: y(11:*, 12:*) = a
   integer :: k
   do k = 1, 2
  print *, k, lbound(x, dim=k), ubound(x, dim=k)
  print *, k, lbound(y, dim=k), ubound(y, dim=k)
   end do
end


$ gfortran z2.f90
$ a.out
   1   1   1
   1  11  11
   2   1   2
   2  12  13

---

$ cat z3.f90
program p
   integer, parameter :: a(1, 2, 3) = 0
   integer, parameter :: x(*, *, *) = a
   integer, parameter :: y(11:*, 12:*, 13:*) = a
   integer :: k
   do k = 1, 3
  print *, k, lbound(x, dim=k), ubound(x, dim=k)
  print *, k, lbound(y, dim=k), ubound(y, dim=k)
   end do
end


$ gfortran z3.f90
z3.f90:3:34:

integer, parameter :: x(*, *, *) = a
  1
Error: Bad array specification for implied-shape array at (1)
z3.f90:4:43:

integer, parameter :: y(11:*, 12:*, 13:*) = a
   1
Error: Bad array specification for implied-shape array at (1)

---

$ cat z4.f90
program p
   integer, parameter :: a(1, 2, 3, 4) = 0
   integer, parameter :: x(*, *, *, *) = a
   integer, parameter :: y(11:*, 12:*, 13:*, 14:*) = a
   integer :: k
   do k = 1, 4
  print *, k, lbound(x, dim=k), ubound(x, dim=k)
  print *, k, lbound(y, dim=k), ubound(y, dim=k)
   end do
end

...

[Bug c++/68021] New: ice in rewrite_use_nonlinear_expr with -O3

[dcb314 at hotmail dot com]

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

Bug ID: 68021
   Summary: ice in rewrite_use_nonlinear_expr with -O3
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 36540
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36540=edit
C++ source code

For today's trunk gcc on x64_64

$ ../results/bin/g++ -O3 -c bug237.cc
svga_cirrus.cc: In function ‘void bitblt_rop_bkwd_src_and_dst(Bit8u*, const
Bit8u*, int, int, int, int)’:
svga_cirrus.cc:3304:13: internal compiler error: in rewrite_use_nonlinear_expr,
at tree-ssa-loop-ivopts.c:6916
0xf044d4 rewrite_use_nonlinear_expr
../../src/trunk/gcc/tree-ssa-loop-ivopts.c:6916
0xf044d4 rewrite_use
../../src/trunk/gcc/tree-ssa-loop-ivopts.c:7177
0xf044d4 rewrite_uses
../../src/trunk/gcc/tree-ssa-loop-ivopts.c:7210
0xf0b190 tree_ssa_iv_optimize_loop
../../src/trunk/gcc/tree-ssa-loop-ivopts.c:7550
0xf0b190 tree_ssa_iv_optimize()
../../src/trunk/gcc/tree-ssa-loop-ivopts.c:7582
0xf24fc0 execute
../../src/trunk/gcc/tree-ssa-loop.c:412
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

tree-ssa-loop-ivopts.c:6916 is

  gcc_assert (comp != NULL_TREE);

[Bug fortran/58754] [4.9/5 Regression] ICE on allocating character array with source

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] ICE on |[4.9/5 Regression] ICE on
   |allocating character array  |allocating character array
   |with source |with source

--- Comment #12 from Paul Thomas  ---
This is fixed on trunk - I suspect that Andre has put it right. I have applied
my patch to 5 branch and am regtesting it right now.

Paul

[Bug fortran/67987] ICE on declaring and initializing character with negative len

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Oct 19 18:15:36 2015
New Revision: 228999

URL: https://gcc.gnu.org/viewcvs?rev=228999=gcc=rev
Log:
2015-10-19  Steven G. Kargl  

PR fortran/67987
* decl.c (char_len_param_value): Unwrap unlong line.  If LEN < 0,
force it to zero per the Fortran 90, 95, 2003, and 2008 Standards. 
* resolve.c (gfc_resolve_substring_charlen): Unwrap unlong line.
If 'start' is larger than 'end', length of substring is negative,
so explicitly set it to zero.
(resolve_charlen): Remove -Wsurprising warning.  Update comment to
reflect that the text is from the F2008 standard.

2015-10-19  Steven G. Kargl  

PR fortran/67987
* gfortran.df/pr67987.f90: New test.
* gfortran.dg/char_length_2.f90: Update testcase.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67987.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/decl.c
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/char_length_2.f90

[Bug c/68022] -O2 breaks computed signed integer comparison for AVR

[tom at tommay dot net]

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

--- Comment #1 from Tom May  ---
Created attachment 36542
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36542=edit
avr-gcc -v output

[Bug middle-end/68022] -O2 breaks computed signed integer comparison for AVR

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|c   |middle-end
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
Signed integer overflow is undefined.

[Bug tree-optimization/68021] [6 Regression] ice in rewrite_use_nonlinear_expr with -O3

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||4.9.3, 5.2.0
   Last reconfirmed||2015-10-19
  Component|c++ |tree-optimization
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|ice in  |[6 Regression] ice in
   |rewrite_use_nonlinear_expr  |rewrite_use_nonlinear_expr
   |with -O3|with -O3
  Known to fail||6.0

--- Comment #1 from Markus Trippelsdorf  ---
Needs -O3:

char a;
int b;
void fn1(char *p1, int p2, int p3) {
  int x;
  for (; b;) {
for (x = 0; x < p3; x++) {
  *p1 = a;
  p1--;
}
p1 += p2;
  }
}

[Bug fortran/56852] [4.9 Regression] ICE on invalid: "Bad array reference" for an undeclared loop variable

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #13 from Paul Thomas  ---
Sorry about the long delay in closing this PR. I have been heavily distracted
by the likes of submodules.

Thanks for the report.

Paul

[Bug target/68018] New: [6 Regression] ICE: in ix86_compute_frame_layout, at config/i386/i386.c:11308 with -mstackrealign

[zsojka at seznam dot cz]

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

Bug ID: 68018
   Summary: [6 Regression] ICE: in ix86_compute_frame_layout, at
config/i386/i386.c:11308 with -mstackrealign
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 36539
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36539=edit
reduced testcase

Compiler output:
$ gcc -O -mabi=ms -mstackrealign testcase.c 
testcase.c: In function 'fn1':
testcase.c:7:1: internal compiler error: in ix86_compute_frame_layout, at
config/i386/i386.c:11308
 }
 ^
0xe73ea0 ix86_compute_frame_layout
/mnt/svn/gcc-trunk/gcc/config/i386/i386.c:11308
0xe97196 ix86_expand_prologue()
/mnt/svn/gcc-trunk/gcc/config/i386/i386.c:12578
0x10453ba gen_prologue()
/mnt/svn/gcc-trunk/gcc/config/i386/i386.md:12282
0xe704b8 target_gen_prologue
/mnt/svn/gcc-trunk/gcc/config/i386/i386.md:18335
0x89a5af thread_prologue_and_epilogue_insns()
/mnt/svn/gcc-trunk/gcc/function.c:5972
0x89b1f2 rest_of_handle_thread_prologue_and_epilogue
/mnt/svn/gcc-trunk/gcc/function.c:6523
0x89b1f2 execute
/mnt/svn/gcc-trunk/gcc/function.c:6565
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-228793-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-228793-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl --without-isl
Thread model: posix
gcc version 6.0.0 20151014 (experimental) (GCC) 

Tested revisions:
r228793 - ICE
5_branch r228441 - OK

[Bug fortran/68019] ICE on rank mismatch of implied-shape array of user-defined type

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-19
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.4, 5.2.1, 6.0

--- Comment #1 from kargl at gcc dot gnu.org ---
An assert() is being triggered.  If I comment out the
assert(), I get 

% gfc6 -c g9.f90
g9.f90:7:31:

type(t), parameter :: arr(*) = reshape(vec, [2, 2])
   1
Error: Incompatible ranks 1 and 2 in assignment at (1)

[Bug c/68022] New: -O2 breaks computed signed integer comparison for AVR

[tom at tommay dot net]

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

Bug ID: 68022
   Summary: -O2 breaks computed signed integer comparison for AVR
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tom at tommay dot net
  Target Milestone: ---

Created attachment 36541
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36541=edit
Short .c file with the code in question

The attached very short .c file has some code that gets compiled ok with -O0
and -O1 but doesn't execute correctly when compiled with -O2:

(n + 16384) < 0

When n >= 16384 the addition will overflow and the result will be negative, but
the addition is being replaced with a comparison which doesn't detect this
case.

I noticed this behavior in 4.8.2, but it still exists in 6.0.0.

Here is the avr-gcc -v output:

Using built-in specs.
Reading specs from /home/tom/avr-gcc/lib/gcc/avr/6.0.0/device-specs/specs-avr2
COLLECT_GCC=/home/tom/avr-gcc/bin/avr-gcc
Target: avr
Configured with: ../configure --prefix=/home/tom/avr-gcc --target=avr
--enable-languages=c --disable-nls --disable-libssp --with-dwarf2
Thread model: single
gcc version 6.0.0 20151019 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-c'
'-specs=device-specs/specs-avr2'
 /home/tom/avr-gcc/libexec/gcc/avr/6.0.0/cc1 -E -quiet -v bug.c -mn-flash=6
-mskip-bug -O2 -fpch-preprocess -o bug.i
ignoring nonexistent directory
"/home/tom/avr-gcc/lib/gcc/avr/6.0.0/../../../../avr/sys-include"
ignoring nonexistent directory
"/home/tom/avr-gcc/lib/gcc/avr/6.0.0/../../../../avr/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/tom/avr-gcc/lib/gcc/avr/6.0.0/include
 /home/tom/avr-gcc/lib/gcc/avr/6.0.0/include-fixed
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-c'
'-specs=device-specs/specs-avr2'
 /home/tom/avr-gcc/libexec/gcc/avr/6.0.0/cc1 -fpreprocessed bug.i -mn-flash=6
-mskip-bug -quiet -dumpbase bug.c -auxbase bug -O2 -version -o bug.s
GNU C11 (GCC) version 6.0.0 20151019 (experimental) (avr)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C11 (GCC) version 6.0.0 20151019 (experimental) (avr)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 7479be6e1c4383a253f21f5ad7bcd496
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-c'
'-specs=device-specs/specs-avr2'
 as -mmcu=avr2 -o bug.o bug.s
as: unrecognized option '-mmcu=avr2'

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[ott at fb dot com]

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

--- Comment #22 from Giuseppe Ottaviano  ---
>> The regression might have been already solved in r225244, which uses
>> yet another SFINAE pattern without extra template arguments, which I
>> believe are the cause of the regression. However I haven't tested it
>> yet.


> That would be nice to know, because I now use that kind of
> void_t-style constraint in a few places, and plan to use it more
> widely. My measurements do show that using void_t-style constraints
> result in small but measurable reductions in compile time and memory
> use.
> Oh, I looked at the wrong bit of r225244, it's using SFINAE in a
> trailing-return-type that matters here, not the __detected_or_t_
> changes.

Yes I referred to the trailing return type. Unfortunately it's not trivial to
test it with our code because alloc_traits.h is not anymore a drop-in
replacement. Maybe the test code included in this bug is enough? Is r225244
already included in a GCC release?

[Bug c++/68023] 4.8.4 generates good code where 5.2 generates bad code

[barto at cambridgesemantics dot com]

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

--- Comment #1 from David Barto  ---
Created attachment 36544
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36544=edit
Configuration for GCC 5.2

[Bug c++/68023] New: 4.8.4 generates good code where 5.2 generates bad code

[barto at cambridgesemantics dot com]

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

Bug ID: 68023
   Summary: 4.8.4 generates good code where 5.2 generates bad code
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barto at cambridgesemantics dot com
  Target Milestone: ---

Created attachment 36543
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36543=edit
Configuration for GCC 4.8.4

The following code:
template 
 inline
 SPORef::SPORef
  /// Constructor: increment pointed to T's reference count.
  ( T* p///< Pointer to the T to be managed
  )
  : rep_(p)
{
  badcode();
  if (rep_)
rep_->incReferences();
}

template 
 inline
 SPORef::~SPORef
  /// Destructor: decrement pointed to T's reference count, possibly
  /// triggering its destruction.
  ()
{
  badcode();
  if (rep_) {
rep_->decReferences();
rep_ = 0;
  }
}

when compiled optimized with GCC 4.8.4 runs properly when compiled -O3.
Changing the compiler (and associated tool chain) from 4.8 to 5.2 causes the
code generated from these functions to cause the system to crash. Changing the
optimization around these 2 methods only by using:

#pragma GCC push_options
#pragma GCC optimize("O0")

#pragma GCC pop_options

and the gcc 5.2 compiler will successfully compile the code.

Attached are the .ii files for 4.8 and 5.2 as well as the configuration files
for 4.8 and 5.2.

[Bug c/68024] New: Diagnose variadic functions defined without prototypes

[jsm28 at gcc dot gnu.org]

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

Bug ID: 68024
   Summary: Diagnose variadic functions defined without prototypes
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

As a quality-of-implementation-issue, we should diagnose code such as:

void f (int, ...);
void f (a) int a; {}

which defines a variadic function without using "...".

The types are compatible as defined by ISO C (see C11 6.7.6.3#15), so no
diagnostic is required.  However, this case is explicitly undefined behavior
(C11 6.9.1#8: "If a function that accepts a variable number of arguments is
defined without a parameter type list that ends with the ellipsis notation, the
behavior is undefined."; likewise back to C90).  So it is valid to reject it
(this is undefined behavior as a property of a program, not of a particular
execution of a program), and certainly seems a good idea at least to give a
diagnostic.

This showed up with such a (declaration, definition) pair in glibc only being
diagnosed after converting the definition from K style to prototype-style.

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

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

--- Comment #23 from Jonathan Wakely  ---
(In reply to Giuseppe Ottaviano from comment #22)
> Yes I referred to the trailing return type. Unfortunately it's not trivial
> to test it with our code because alloc_traits.h is not anymore a drop-in
> replacement. Maybe the test code included in this bug is enough? Is r225244
> already included in a GCC release?

No, only on trunk. It depends on the additions in r225242, so to use the new
alloc_traits.h you would only need the new code in
https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/type_traits?r1=225242=225241=225242
(which could be added to the top of alloc_traits.h just in order to test, if
that's easier).

[Bug c++/68023] 4.8.4 generates good code where 5.2 generates bad code

[barto at cambridgesemantics dot com]

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

--- Comment #3 from David Barto  ---
Created attachment 36546
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36546=edit
Compressed gcc 5.2 output

[Bug c++/68023] 4.8.4 generates good code where 5.2 generates bad code

[barto at cambridgesemantics dot com]

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

--- Comment #2 from David Barto  ---
Created attachment 36545
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36545=edit
compressed gcc 4.8 output

[Bug go/66870] split stack issues on ppc64le and ppc64

[amodra at gcc dot gnu.org]

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

--- Comment #32 from Alan Modra  ---
Author: amodra
Date: Mon Oct 19 23:50:30 2015
New Revision: 229009

URL: https://gcc.gnu.org/viewcvs?rev=229009=gcc=rev
Log:
PR66870 PowerPC64 Enable gold linker with split stack

A powerpc-linux/powerpc64-linux biarch compiler can default to either
-m32 or -m64, and we need to notice both -m32 and -m64 on the gccgo
command line.  It's also possible to build a -m64 only compiler, so in
that case we can define TARGET_CAN_SPLIT_STACK.

gcc/
PR go/66870
* config/rs6000/sysv4.h (TARGET_CAN_SPLIT_STACK_64BIT): Don't define.
* config/rs6000/linux64.h (TARGET_CAN_SPLIT_STACK): Define.
(TARGET_CAN_SPLIT_STACK_64BIT): Define.
gcc/go/
PR go/66870
* gospec.c (saw_opt_m32): Rename to..
(is_m64): ..this, initialised by TARGET_CAN_SPLIT_STACK_64BIT.
Update uses.
(lang_specific_driver): Set is_m64 if OPT_m64, clear if OPT_m32.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/linux64.h
trunk/gcc/config/rs6000/sysv4.h
trunk/gcc/go/ChangeLog
trunk/gcc/go/gospec.c

[Bug c++/67927] array new expression with excessive number of elements not diagnosed

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Complete patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01803.html

[Bug c++/67913] new expression with negative size not diagnosed

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Complete patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01803.html

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

[pmderodat at gcc dot gnu.org]

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

--- Comment #44 from pmderodat at gcc dot gnu.org ---
Author: pmderodat
Date: Mon Oct 19 23:47:35 2015
New Revision: 229008

URL: https://gcc.gnu.org/viewcvs?rev=229008=gcc=rev
Log:
REE: fix uninitialized registers handling

gcc/ChangeLog:

PR rtl-optimization/66790
* df.h (DF_MIR): New macro.
(DF_LAST_PROBLEM_PLUS1): Update to be past DF_MIR
(DF_MIR_INFO_BB): New macro.
(DF_MIR_IN, DF_MIR_OUT): New macros.
(struct df_mir_bb_info): New.
(df_mir): New macro.
(df_mir_add_problem, df_mir_simulate_one_insn): New forward
declarations.
(df_mir_get_bb_info): New.
* df-problems.c (struct df_mir_problem_data): New.
(df_mir_free_bb_info, df_mir_alloc, df_mir_reset,
df_mir_bb_local_compute, df_mir_local_compute, df_mir_init,
df_mir_confluence_0, df_mir_confluence_n,
df_mir_transfer_function, df_mir_free, df_mir_top_dump,
df_mir_bottom_dump, df_mir_verify_solution_start,
df_mir_verify_solution_end): New.
(problem_MIR): New.
(df_mir_add_problem, df_mir_simulate_one_insn): New.
* timevar.def (TV_DF_MIR): New.
* ree.c: Include bitmap.h
(add_removable_extension): Add an INIT_REGS parameter.  Use it
to skip zero-extensions that may get an uninitialized register.
(find_removable_extensions): Compute must-initialized registers
using the MIR dataflow problem. Update the call to
add_removable_extension.
(find_and_remove_re): Call df_mir_add_problem.

gcc/testsuite/ChangeLog:

* gnat.dg/opt50.adb: New test.
* gnat.dg/opt50_pkg.adb: New helper.
* gnat.dg/opt50_pkg.ads: New helper.

Added:
trunk/gcc/testsuite/gnat.dg/opt50.adb
trunk/gcc/testsuite/gnat.dg/opt50_pkg.adb
trunk/gcc/testsuite/gnat.dg/opt50_pkg.ads
Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-problems.c
trunk/gcc/df.h
trunk/gcc/ree.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/timevar.def

[Bug fortran/67900] [4.9/5/6 Regression] Interface bug: Binding parameters to C causes a compiler segmentation fault.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|4.9.4   |5.3

--- Comment #6 from kargl at gcc dot gnu.org ---
Fixed on trunk and 5-branch.  Thanks for the bug report.

[Bug fortran/67900] [4.9/5/6 Regression] Interface bug: Binding parameters to C causes a compiler segmentation fault.

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Oct 20 00:45:48 2015
New Revision: 229014

URL: https://gcc.gnu.org/viewcvs?rev=229014=gcc=rev
Log:
2015-10-19  Steven G. Kargl  

PR fortran/67900
* resolve.c (gfc_verify_binding_labels): Check for NULL pointer.

2015-10-19  Steven G. Kargl  

PR fortran/67900
* gfortran.dg/pr67900.f90: New tests.

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

[Bug rtl-optimization/67037] [4.9/5 Regression] Wrong code at -O1 and above on ARM

[notasas at gmail dot com]

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

--- Comment #7 from notasas at gmail dot com ---
Anyone's up for the backports? The patch applies cleanly on both gcc-4_9 and
gcc-5 branches.
I've tested patched 4.9.3 and wine no longer crashes when built with it.

[Bug tree-optimization/68026] Regression in GCC-6.0.0's optimizer

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c   |tree-optimization

--- Comment #1 from Andrew Pinski  ---

t = 3<=(x2|1|x3|x1-1U);
Doing the non-volatile sub:
t = 3 <= (x2 | 1 | 2 | (x1 - 1u))
...

t = 3 <= (x2 | 3 | (x1 - 1u))
or:
t = 3 <= 3 | x2 | (x1 - 1u)
Which is:

t = true, x1, x2.

Only if re-association happens with casts thrown in too which might be the 
case of the  regression.

[Bug middle-end/68027] conditional statement and unnecessary register assignment

[SztfG at yandex dot ru]

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

--- Comment #1 from SztfG at yandex dot ru ---
># no need to do this, eax is equal $100 at this point
I mean edi. after this part:
cmpl$100, %edi
jg  .L5
jne .L6
if it passed this jg jne instruction without conditional jump, edi shoud be 100

[Bug gcov-profile/68025] New: pragma/attribute optimize("profile-arcs") does not work as intended

[coolypf at qq dot com]

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

Bug ID: 68025
   Summary: pragma/attribute optimize("profile-arcs") does not
work as intended
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: coolypf at qq dot com
  Target Milestone: ---

Case 1. The following code, when compiled, both x and y are instrumented:

#pragma GCC push_options
#pragma GCC optimize("profile-arcs")

int x(int p)
{
if (p > 0) return 1;
return 0;
}

#pragma GCC pop_options

int y(int q)
{
if (q < 0) return 0;
return 1;
}


Case 2. The following code, when compiled, both x and y are instrumented:

int x(int) __attribute__ ((optimize("profile-arcs")));

int x(int p)
{
if (p > 0) return 1;
return 0;
}

int y(int q)
{
if (q < 0) return 0;
return 1;
}


Case 3. The following code, when compiled, both x and y are instrumented:

int x(int p)
{
if (p > 0) return 1;
return 0;
}

#pragma GCC push_options
#pragma GCC optimize("profile-arcs")

int y(int q)
{
if (q < 0) return 0;
return 1;
}

#pragma GCC pop_options


Case 4. The following code, when compiled, both x and y are instrumented:

int x(int p)
{
if (p > 0) return 1;
return 0;
}

int y(int) __attribute__ ((optimize("profile-arcs")));

int y(int q)
{
if (q < 0) return 0;
return 1;
}

[Bug c/68026] New: Regression in GCC-6.0.0's optimizer

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

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

Bug ID: 68026
   Summary: Regression in GCC-6.0.0's optimizer
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

We compiled a program (A.c) by GCC-5.1.0 and GCC-6.0.0 with -O3 option.
GCC-5.1.0 performed better optimization than GCC-6.0.0.

(A.c)
int main (void)
{
volatile int x1 = 1;
volatile int x2 = 1;
int x3 = 2;
int t = 1;

t = 3<=(x2|1|x3|x1-1U);

if (t == 1) {} 
else { __builtin_abort(); }

return 0;
}

+--+--+
|  gcc-5.1.0.s (gcc-5.1.0 A.c -O3 -S)  |  gcc-6.0.0.s (gcc-6.0.0 A.c -O3 -S)  |
+--+--+
|main: |main: |
|.LFB0:|.LFB0:|
|.cfi_startproc|.cfi_startproc|
|movl$1, -8(%rsp)  |subq$24, %rsp |
|movl$1, -4(%rsp)  |.cfi_def_cfa_offset 32|
|movl-4(%rsp), %eax|movl$1, 8(%rsp)   |
|movl-8(%rsp), %eax|movl$1, 12(%rsp)  |
|  |movl12(%rsp), %eax|
|  |movl8(%rsp), %edx |
|  |orl $3, %eax  |
|  |movl%eax, %ecx|
|  |leal-1(%rdx), %eax|
|  |orl %ecx, %eax|
|  |cmpl$2, %eax  |
|  |jbe .L5   |
|xorl%eax, %eax|xorl%eax, %eax|
|  |addq$24, %rsp |
|  |.cfi_remember_state   |
|  |.cfi_def_cfa_offset 8 |
|ret   |ret   |
|  |.L5:  |
|  |.cfi_restore_state|
|  |callabort |
|.cfi_endproc  |.cfi_endproc  |
|.LFE0:|.LFE0:|
|.size   main, .-main  |.size   main, .-main  |
|.section.text.unlikely|.ident  "GCC: (GNU) 6.0.0  ...|
|.LCOLDE0: |  |
|.section.text.startup |  |
|.LHOTE0:  |  |
|.ident  "GCC: (Ubuntu 5.1.0...|  |
|.section.note.GNU-s...|.section.note.GNU-s...|
+--+--+

Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.1.0-0ubuntu11~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --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-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--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 

[Bug target/68018] [6 Regression] ICE: in ix86_compute_frame_layout, at config/i386/i386.c:11308 with -mstackrealign

[zsojka at seznam dot cz]

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

--- Comment #2 from Zdenek Sojka  ---
I am also seeing this (or another in ix86_compute_frame_layout) ICE when
running the gfortran testsuite. Again with -mstackrealing. I will post the
testcase when I get home.

[Bug c/67925] docs lie about being unable to inline function call before definition

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #11 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug middle-end/68027] New: conditional statement and unnecessary register assignment

[SztfG at yandex dot ru]

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

Bug ID: 68027
   Summary: conditional statement and unnecessary register
assignment
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SztfG at yandex dot ru
  Target Milestone: ---

C source code:

int a1(int);
int a2(int);
int a3(int);

int test1(int a)
{
  if (a > 100) return a1(a);
  else if (a < 100) return a2(a);
  return a3(a);
}

---

Assembly output:


test1:
.LFB0:
.cfi_startproc
cmpl$100, %edi
jg  .L5
jne .L6
movl$100, %edi   # no need to do this, eax is equal $100 at this
point
jmp a3
.p2align 4,,10
.p2align 3
.L6:
jmp a2
.p2align 4,,10
.p2align 3
.L5:
jmp a1
.cfi_endproc

---

Tested on http://gcc.godbolt.org/ : gcc versions 4.4.7 - 5.2.0 have this
problem.

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[alm at sibmail dot ru]

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

--- Comment #12 from Alexander  ---

> SED=/usr/local/bin/sed CC="gcc -mlp64" CXX="g++ -mlp64"

Unfortunetly, gcc for HPUX is a still 32-bit toolchain, sou should build it by 
default 32bit options (without -mlp64)

[Bug tree-optimization/68017] New: ICE on valid code at -O3 with -g enabled on x86_64-linux-gnu: cannot update SSA form

[su at cs dot ucdavis.edu]

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

Bug ID: 68017
   Summary: ICE on valid code at -O3 with -g enabled on
x86_64-linux-gnu: cannot update SSA form
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

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

It is a regression from 5.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151019 (experimental) [trunk revision 228969] (GCC) 
$ 
$ gcc-trunk -O3 -c small.c
$ gcc-trunk -O2 -g -c small.c 
$ gcc-5.2 -O3 -g -c small.c
$ 
$ gcc-trunk -O3 -g -c small.c
small.c: In function ‘fn2’:
small.c:10:1: error: statement uses released SSA name:
 fn2 ()
 ^
# DEBUG D#4 => _5 + _24
The use of _24 should have been replaced
small.c:10:1: error: statement uses released SSA name:
# DEBUG D#5 => _5 + _25
The use of _25 should have been replaced
small.c:10:1: internal compiler error: cannot update SSA form
0xb5fc1c update_ssa(unsigned int)
../../gcc-trunk/gcc/tree-into-ssa.c:3206
0xa0ccbf execute_function_todo
../../gcc-trunk/gcc/passes.c:1943
0xa0d5a3 execute_todo
../../gcc-trunk/gcc/passes.c:2033
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.
$ 





long long a;

short
fn1 (short p1, unsigned short p2)
{
  return p1 + p2;
}

short
fn2 ()
{
  int b = a ? fn1 (fn2 (), a) : 0;
  return b;
}

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[chefmax at gcc dot gnu.org]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 CC||chefmax at gcc dot gnu.org

--- Comment #40 from Maxim Ostapenko  ---
Just a little bit more fuel to the flames:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68016

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

[josephpattara at gmail dot com]

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

Joseph John  changed:

   What|Removed |Added

 CC||josephpattara at gmail dot com

--- Comment #11 from Joseph John  ---
I tried to use the work around suggested by John but was not succesful in
making the 4.9.2 compilation. I applied the patch to the 4.7.4 and made a
succesful build of 4.7.4. I then installed the 4.7.4 and used to compile 4.9.2
which run into the below error:

home/jjohn/hpux/gcc_492/gcc-build/./gcc/xgcc -shared-libgcc
-B/home/jjohn/hpux/gcc_492/gcc-build/./gcc -nostdinc++
 -L/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/src
-L/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/src/.libs

-L/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/libsupc++/.libs
-B/opt/gcc_492/ia64-hp-hpux11.31/bin/ -B/opt/gcc_492/ia64-hp-hpux11.31/lib/ 
 -isystem /opt/gcc_492/ia64-hp-hpux11.31/include -isystem
/opt/gcc_492/ia64-hp-hpux11.31/sys-include-x c++-header -nostdinc++ -g -O2 

-I/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/ia64-hp-hpux11.31
-I/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include
 -I/home/jjohn/hpux/gcc_492/gcc-4.9.2/libstdc++-v3/libsupc++ -O2 -g
-std=gnu++0x
/home/jjohn/hpux/gcc_492/gcc-4.9.2/libstdc++-v3/include/precompiled/stdc++.h
 -o ia64-hp-hpux11.31/bits/stdc++.h.gch/O2ggnu++0x.gch


In file included from
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/bits/move.h:57:0,
 from
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/bits/stl_pair.h:59,
 from
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/bits/stl_algobase.h:64,
 from
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/bits/char_traits.h:39,
 from
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/ios:40,
 from
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/istream:38,
 from
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/sstream:38,
 from
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/complex:45,
 from
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/ccomplex:38,
 from
/home/jjohn/hpux/gcc_492/gcc-4.9.2/libstdc++-v3/include/precompiled/stdc++.h:52:
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:395:44:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:399:45:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:407:47:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:411:48:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:419:50:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:423:51:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:431:53:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:435:54:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:443:53:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:447:54:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:455:56:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:459:57:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:467:59:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:471:60:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:479:62:
error: template argument 1 is invalid
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/type_traits:483:63:
error: template argument 1 is invalid
In file included from
/home/jjohn/hpux/gcc_492/gcc-4.9.2/libstdc++-v3/include/precompiled/stdc++.h:103:0:
/home/jjohn/hpux/gcc_492/gcc-build/ia64-hp-hpux11.31/libstdc++-v3/include/future:1509:5:
error: looser throw specifier for 'virtual