Re: [PATCH, libgfortran] PR68867 numeric formatting problem in the fortran library

[Steve Kargl]

On Sat, Dec 12, 2015 at 08:14:39PM -0800, Jerry DeLisle wrote:
>  case 16:
> +  /* Adjust decimal precision depending on binary precision, 103 or 113. 
>  */


s/103/106

I suspect that this is simply a bandaid on a much bigger
problem.  Namely, few of the intrinsic functions for 
REAL(16) expect 106 bits instead of 113 bits.

-- 
Steve

[Bug libstdc++/68880] New: [4.9 Regression][Bisected to r202992] std::operator< overload ignored when using std::lower_bound

[david.ward at ll dot mit.edu]

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

Bug ID: 68880
   Summary: [4.9 Regression][Bisected to r202992] std::operator<
overload ignored when using std::lower_bound
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.ward at ll dot mit.edu
CC: fdumont at gcc dot gnu.org
  Target Milestone: ---

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

Prior to r202992 the following compiles without any warning:



#include 
#include 

namespace N
{
struct S
{
int x;
int y;
};
}

namespace std
{
bool operator< (const N::S ,
const N::S )
{
return lhs.y < rhs.y;
}
}

class C
{
public:
void f()
{
std::deque deq;

N::S val;
val.y = 10;

std::deque::iterator it = std::lower_bound(deq.begin(),
 deq.end(),
 val);
}
};

int main()
{
C obj;
obj.f();
}



Now it fails, as it no longer recognizes the std::operator< overload. The
output below is from gcc 5.3.0, but I just checked that it is still broken in
SVN trunk:



# g++ -v -save-temps svn-r202992-regression.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-5.3.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 5.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1plus -E -quiet -v -D_GNU_SOURCE
svn-r202992-regression.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o
svn-r202992-regression.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0

/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/x86_64-unknown-linux-gnu

/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/../../../../include/c++/5.3.0/backward
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/cc1plus -fpreprocessed
svn-r202992-regression.ii -quiet -dumpbase svn-r202992-regression.cpp
-mtune=generic -march=x86-64 -auxbase svn-r202992-regression -version -o
svn-r202992-regression.s
GNU C++ (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p5, MPC version 1.0.3
warning: MPFR header version 3.1.3-p5 differs from library version 3.1.3-p4.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127710
GNU C++ (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p5, MPC version 1.0.3
warning: MPFR header version 3.1.3-p5 differs from library version 3.1.3-p4.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=127710
Compiler executable checksum: f5781c340dcd4c5ddaa4fbe9faee3243
In file included from /usr/include/c++/5.3.0/bits/stl_algobase.h:71:0,
 from /usr/include/c++/5.3.0/deque:60,
 from svn-r202992-regression.cpp:1:
/usr/include/c++/5.3.0/bits/predefined_ops.h: In instantiation of ‘bool
__gnu_cxx::__ops::_Iter_less_val::operator()(_Iterator, _Value&) const [with
_Iterator = std::_Deque_iterator; _Value = const N::S]’:
/usr/include/c++/5.3.0/bits/stl_algobase.h:971:14:   required from
‘_ForwardIterator std::__lower_bound(_ForwardIterator, _ForwardIterator, const
_Tp&, _Compare) [with 

Re: basic asm and memory clobbers - Proposed solution

[David Wohlferd]

On 12/12/2015 1:51 AM, Andrew Haley wrote:

Solution 2:
Change the docs to say that basic asm clobbers everything (memory, all
registers, etc) or perhaps just memory (some debate here), but that due
to bugs that will eventually be addressed, it doesn't currently work
this way.

You've missed the most practical solution, which meets most common
usage: clobber memory, but not registers.


Actually, that's intended to be part of Solution #2 ("or perhaps just 
memory").  Sorry if that wasn't clear.



That allows most of the
effects that people intuitively want and expect,


The nice thing about guessing what people want and expect is that it can 
be molded however we need to suit our point of view.  I could make a 
similar case that what people want is the behavior from other compilers 
that have built-in assemblers.  Those compilers can 'see' what registers 
are being used by the asm and adapt.  Since GCC can't provide that 
capability, people might 'expect' it to clobber every register if that's 
what is needed to support the same behavior.


I'm not trying to advocate for clobbering registers.  My point is simply 
that I don't see how we can *know* what people want and expect.  You can 
say they expect memory.  Jeff can say they expect memory+registers.  I 
can say they expect it to work the same way tomorrow that it did 
yesterday.  Who's right?  I'm not prepared to say.  But I don't think 
any of us are wrong.



but avoids the breakage of register clobbers.


You are right "just memory clobber" does remove some performance issues, 
and the breakage that could result from clobbering registers.  Also, 
while I have never written nor read an optimizer, my guess is that the 
biggest 'win' as far as positioning the basic asm comes from the memory 
clobber (compared to clobbering registers).  So this does get us most of 
the benefits of "clobber everything" with less effort and fewer 
consequences.


However breakage and performance issues can still result solely from 
adding memory clobbers.  And as I mentioned, "just memory clobber" may 
not be the behavior people expect.  And if we aren't solving that, might 
there be a second update later to add registers?  Talk about confusing 
semantics...



It allows basic asm to be used in a
sensible way by pushing and popping all used registers.


If I were using basic asm, this would indeed seem like a sensible approach.

However, it is not the most efficient.  If I can clobber registers, 
push/pop are just wasted cycles.  This just seems like another argument 
for deprecating basic asm and pushing people to extended.


--
Imagine for a moment:

If the only way right now to do inline asm in gcc was extended, and I 
proposed adding basic, how could I justify this 'new' feature? Other 
than 'top-level,' I can't think of a single benefit that it would 
provide.  Pointless push/pops, problems with positioning and the other 
headaches it causes have no upside.


Contra-wise, what if starting today all new inline asm were written 
using extended?  How would that be a bad thing?  What would be the 
downside?  Yes, people can still write bad code with extended, but its 
semantics are well-understood and have been for a long time (certainly 
compared to basic).  Additionally, the abilities it provides allow 
people to solve problems that basic never will.


Which means (to me), the only real justification for the continued 
existence of basic asm is backward compatibility.  Which makes the 
arguments for changing its behavior (whether a little or a lot) kinda weird.


I still vote for doing everything we can think of to discourage people 
from using basic and begin using extended:


- Change the docs to flat out deprecate basic (excluding top-level).
- Add the warning so people's integrated dev environments will show the 
suspect lines.
- Make the warning a default, but overridable (-Wno-only-top-basic-asm), 
so people who HAVE to support the old syntax still can.
- Make sure the docs for the warning describe (link to?) how to change 
asm from basic to extended and why.
- Any bugs people report or posts people make involving basic asm get 
resolved as 'Try it with extended.'


Every year these items are in place would make basic asm less important 
as people slowly move to extended.  Maybe by the time we get around to 
flagging it as a fatal error (say in 2025), no one will care.


True, this won't magically solve people's problems for them if they've 
been using basic asm wrong.  But it does point out that there are 
(potential) problems, where those problems are and motivates people to 
fix them (which seems like quite reasonable behavior for a compiler).  
More importantly, we haven't broken or degraded anything that was 
already working.


I'm just afraid that instead of pursuing any of these solutions, we are 
going to pursue Solution #0: Do nothing.  A rather unsatisfying outcome 
after all this effort.


dw

PS I was surprised by how many people 

[PATCH, libgfortran] PR68867 numeric formatting problem in the fortran library

[Jerry DeLisle]

Hi all,

This PR is about different binary precision of quad floats on different 
platforms.

X86 uses libquadmath with 113 bits, PowerPC uses IBM 106 bits.

For list directed output we set the default decimal precision to use.  Because
the PowerPC has fewer significant bits, we need to adjust the formatting for
kind=16 accordingly or we are just getting junk in the last few digits emitted
(consistent junk).  This patch reduces the width and precision via conditional
compilation depending on the bit precision.

Regression tested on X86_64 and PowerPC (Power7) Linux.  The patch includes the
necessary updates of the testsuite quad_2.f90.

OK for trunk?

Regards,

Jerry

2015-12-12  Jerry DeLisle  

PR libfortran/pr68867
* io/write.c (set_fnode_default): For kind=16, set the decimal precision
depending on the platform binary precision, 106 or 113.


Index: gcc/testsuite/gfortran.dg/quad_2.f90
===
--- gcc/testsuite/gfortran.dg/quad_2.f90	(revision 231314)
+++ gcc/testsuite/gfortran.dg/quad_2.f90	(working copy)
@@ -49,18 +49,19 @@ program test_qp
if (str4 /= "1.41421356237309504876") call abort()
 
  case (16)
-   if (str1 /= "   1.000") call abort()
-   if (str2 /= "1.000") call abort()
-
if (digits(1.0_qp) == 113) then
  ! IEEE 754 binary 128 format
  ! e.g. libquadmath/__float128 on i686/x86_64/ia64
+ if (str1 /= "   1.000") call abort()
+ if (str2 /= "1.000") call abort()
  if (str3 /= "   1.41421356237309504880168872420969798") call abort()
  if (str4 /= "1.41421356237309504880168872420969798") call abort()
else if (digits(1.0_qp) == 106) then
  ! IBM binary 128 format
- if (str3(1:37) /= "   1.41421356237309504880168872420969") call abort()
- if (str4(1:34) /= "1.41421356237309504880168872420969") call abort()
+ if (str1 /= "   1.000") call abort()
+ if (str2 /= "1.000") call abort()
+ if (str3(1:37) /= "   1.4142135623730950488016887242097") call abort()
+ if (str4(1:34) /= "1.4142135623730950488016887242097") call abort()
end if
 
! Do a libm run-time test
Index: libgfortran/io/write.c
===
--- libgfortran/io/write.c	(revision 231314)
+++ libgfortran/io/write.c	(working copy)
@@ -1405,9 +1405,16 @@ set_fnode_default (st_parameter_dt *dtp, fnode *f,
   f->u.real.e = 4;
   break;
 case 16:
+  /* Adjust decimal precision depending on binary precision, 103 or 113.  */
+#if GFC_REAL_16_DIGITS == 113
   f->u.real.w = 45;
   f->u.real.d = 36;
   f->u.real.e = 4;
+#else
+  f->u.real.w = 41;
+  f->u.real.d = 32;
+  f->u.real.e = 4;
+#endif
   break;
 default:
   internal_error (>common, "bad real kind");

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
A Patch has been submitted for approval.

https://gcc.gnu.org/ml/fortran/2015-12/msg00080.html

[Bug target/68865] [6 regression] gcc.dg/atomic/c11-atomic-exec-2.c fails since r231165

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||anton at samba dot org

--- Comment #3 from Segher Boessenkool  ---
*** Bug 68879 has been marked as a duplicate of this bug. ***

[Bug target/68879] PowerPC: SImode cstore optimisation produces bad code

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #1 from Segher Boessenkool  ---
Dup.

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

[Bug target/68879] New: PowerPC: SImode cstore optimisation produces bad code

[anton at samba dot org]

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

Bug ID: 68879
   Summary: PowerPC: SImode cstore optimisation produces bad code
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at samba dot org
  Target Milestone: ---

Created attachment 37017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37017=edit
Test case

csmith found an issue that bisects to "rs6000: Optimise SImode cstore on
64-bit"

Attached is a simplified test case. A diff shows:

-   addi 9,10,2
-   orc 9,9,10
-   srwi 9,9,31

+   subf 9,9,6
+   srdi 9,9,63
+   xori 9,9,0x1

[Bug sanitizer/68418] ubsan complains about left shifts even with -fwrapv

[bonzini at gnu dot org]

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

--- Comment #2 from Paolo Bonzini  ---
Author: bonzini
Date: Sat Dec 12 08:29:27 2015
New Revision: 231582

URL: https://gcc.gnu.org/viewcvs?rev=231582=gcc=rev
Log:
gcc:
PR sanitizer/68418
* c-family/c-ubsan.c (ubsan_instrument_shift): Disable
sanitization of left shifts for wrapping signed types as well.

gcc/testsuite:
PR sanitizer/68418
* gcc.dg/ubsan/c99-wrapv-shift-1.c,
gcc.dg/ubsan/c99-wrapv-shift-2.c: New testcases.

Added:
trunk/gcc/testsuite/gcc.dg/ubsan/c99-wrapv-shift-1.c
trunk/gcc/testsuite/gcc.dg/ubsan/c99-wrapv-shift-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/c-ubsan.c
trunk/gcc/testsuite/ChangeLog

[PATCH] g++.dg/cpp1y/pr58708.C testcase fix for AIX

[David Edelsohn]

I previously updated the assignment to correct the compile-time error,
but the runtime check of values also needs to be updated for 16 bit
wchar_t.

Tested on powerpc-ibm-aix7.1.0.0.

Committed.

Thanks, David

* g++.dg/cpp17/pr58708.C: Test appropriate value for size of wchar_t.

Index: pr58708.C
===
--- pr58708.C   (revision 231582)
+++ pr58708.C   (working copy)
@@ -50,8 +50,13 @@
 #endif
   if (is_same::value != true)
__builtin_abort();
   if (sizeof(wfoo.chars)/sizeof(wchar_t) != 2) __builtin_abort();
+#if __SIZEOF_WCHAR_T__ == 2
+  if (wfoo.chars[0] != 258) __builtin_abort();
+  if (wfoo.chars[1] != 772) __builtin_abort();
+#else
   if (wfoo.chars[0] != 16909060) __builtin_abort();
   if (wfoo.chars[1] != 84281096) __builtin_abort();
+#endif

   auto foou = u"\x0102\x0304\x0506\x0708"_foo;
   if (is_same::value != true)
__builtin_abort();

[Bug ipa/68871] New: fipa-pta tracks function-level nonlocal

[vries at gcc dot gnu.org]

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

Bug ID: 68871
   Summary: fipa-pta tracks function-level nonlocal
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I. one function, ealias

Consider testcase ealias.c:
...
void
foo (int *a)
{
  int b;
  int *c = a;
  int *d = 
  *c = 1;
  *d = 2;
  *c = *c + 1;
}
...

compiled with
...
$ gcc ealias.c -O2 -S -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre
...

At ealias, we have:
...
  intD.6 bD.1758;

  # PT = nonlocal
  c_2 = a_1(D);
  # PT = { D.1758 }
  d_3 = 
...

So:
- c_2 points-to something nonlocal, and 
- d_3 points to local b.

This allows disambiguation of the store '*d = 2' with the load in '*c = *c +
1', and dse removes the store:
...
  Deleted dead store *d_3 = 2;
...


II. two functions, ealias

Now, consider example ealias-2.c:
...
static void __attribute__((noinline, noclone))
bar (int *c, int *d)
{
  *c = 1;
  *d = 2;
  *c = *c + 1;
}

void
foo (int *a)
{
  int b;
  bar (a, );
}
...

When compiled at -O2, at ealias we have (using the patch at
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01282.html to get ssa-name info
for default defs):
...
__attribute__((noclone, noinline))
bar (intD.6 * cD.1755, intD.6 * dD.1756)
# PT = nonlocal
# DEFAULT_DEF c_2(D)
# PT = nonlocal
# DEFAULT_DEF d_4(D)
...

So both pointers point to a non-local, and cannot be disambiguated.


III. two functions, fipa-pta

Now, consider example ipa-pta.c (the same as ealias-2.c, but with  assigned
to a pointer, to expose the points-to info).
...
static void __attribute__((noinline, noclone))
bar (int *c, int *d)
{
  *c = 1;
  *d = 2;
  *c = *c + 1;
}

void
foo (int *a)
{
  int b;
  int *bp = 
  bar (a, bp);
}
...

When compiled at -O2 -fipa-pta-fno-tree-ccp -fno-tree-forwprop -fno-tree-fre
-fno-tree-pre, at pta we have:
...
__attribute__((noclone, noinline))
bar (intD.6 * cD.1755, intD.6 * dD.1756)
# PT = nonlocal
# DEFAULT_DEF c_2(D)
# PT = { D.1762 } (nonlocal)
# ALIGN = 4, MISALIGN = 0
# DEFAULT_DEF d_4(D)
...

c_2 points to a nonlocal.

d_4 points to D.1762, which is b in foo:
...
foo (intD.6 * aD.1759)
# PT = nonlocal
# DEFAULT_DEF a_2(D)
{
  intD.6 bD.1762;
...

The disambiguation of the memory references relative to the two pointers does
not take place, because:
- b is nonlocal in bar, and
- the nonlocal of c_2 refers to nonlocal to bar.

Still:
- c_2 has the same value as a_3, which is nonlocal to foo, and 
- d_2 has the same value as bp_1, which is local to foo
as we can see here:
...
foo (intD.6 * aD.1759)
# PT = nonlocal
# DEFAULT_DEF a_3(D)
{
  intD.6 * bpD.1763;
  intD.6 bD.1762;

  # PT = { D.1762 }
  bp_1 = 
...
So it seems the information to make the disambiguation is there in principle.


A more precise analysis could give something along the lines of:
...
__attribute__((noclone, noinline))
bar (intD.6 * cD.1755, intD.6 * dD.1756)
# PT = nonlocal(bar, foo)
# DEFAULT_DEF c_2(D)
# PT = { D.1762 } (local(foo))
# ALIGN = 4, MISALIGN = 0
# DEFAULT_DEF d_4(D)
...

And we could disambiguate c_2 and d_4 because:
- c_2 is nonlocal(foo), and 
- d_4 is local(foo).

[Bug lto/68799] lto ICE on powerpc64le-linux-gnu builing python 2.7.x

[doko at gcc dot gnu.org]

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

--- Comment #5 from Matthias Klose  ---
> Matthias, can you please incorporate th3 debug patch
> from the previous comment into your source

done.

[Bug middle-end/68870] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-12
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE on valid code at -O1,   |[6 Regression] ICE on valid
   |-O2 and -O3 on  |code at -O1, -O2 and -O3 on
   |x86_64-linux-gnu|x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r231527.
Though it seems to be yet another case of gimple_simplify during cfg cleanup
finding in-free-list SSA_NAMEs.

RE: [Patch, MIPS] Remove definition of TARGET_PROMOTE_PROTOTYPES

[Matthew Fortune]

Steve Ellcey  writes:
> On Tue, 2015-11-10 at 15:57 -0800, Steve Ellcey wrote:
> > 2015-11-10  Steve Ellcey  
> >
> > * config/mips/mips.c (mips_promote_function_mode): New function.
> > (TARGET_PROMOTE_FUNCTION_MODE): Define as above function.
> > (TARGET_PROMOTE_PROTOTYPES): Remove.

I'm OK with this change on the basis that MIPS has been providing stronger
guarantees than required by the various standards. I.e. after this change
MIPS will have undefined behaviour for a mismatch in types between a
call to an un-prototyped function and its definition:

extern void foo();

void caller(int a)
{
  foo(a);
}

--

void foo(short a)
{
  // the value of 'a' can be out of range of a short because the caller
  // did not get the right type for the argument.
}

Thanks,
Matthew

[Bug libfortran/68867] numeric formatting problem in the fortran library

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Removing the comment gives:
>
>   3  39 0.6919E-0001

> In the test case, I need to adjust the line;
>
> if (astring(2:2) /= '9') then
>
> to:
>
> if (astring(3:3) /= '9') then
>
> since the previous patch corrected a missing leading zero on the formatting.
>
> I will do so tomorrow.

I doubt that will fix the problem: it seems related to to a rounding issue with
REAL(16). Which REAL(16) is used? "IBM" one or float_128?

[Bug other/68875] Add pass parameter to TERMINATE_PASS_LIST

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
ok-ed for stage1: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01305.html

[Bug other/68875] New: Add pass parameter to TERMINATE_PASS_LIST

[vries at gcc dot gnu.org]

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

Bug ID: 68875
   Summary: Add pass parameter to TERMINATE_PASS_LIST
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01245.html :
...
This patch adds a parameter to TERMINATE_PASS_LIST, that should match the pass
list it's supposed to terminate.

The intention of the patch is that it:
- makes it easier to understand the top-level hierarchy of the pass
  list (given that the top-level list may be quite long).
- ensures that INSERT_PASSES_AFTER and TERMINATE_PASS_LIST are paired.
...

[Bug libstdc++/68869] map::insert(P&&) broken in some cases

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-12
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/67781] Wrong code generated on mips32 with -O1 -fexpensive-optimizations

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #3 from Mikael Pettersson  ---
SPARC (big-endian) is also affected.  gcc-6 and gcc-5 generate wrong code with
-O2 or -O1 -fexpensive-optimizations, but working code with just -O1.  gcc-4.9
generates working code at all optimization levels.

Re: basic asm and memory clobbers - Proposed solution

[Andrew Haley]

On 11/12/15 22:18, David Wohlferd wrote:

> And here are the three solutions that have been proposed:
> 
> Solution 1:
> Just document the current behavior of basic asm.
> 
> People who have written incorrect code can be pointed at the text and 
> told to fix their code.  People whose code is damaged by optimizations 
> can rewrite using extended to add dependencies (possibly doc this?).
> 
> Solution 2:
> Change the docs to say that basic asm clobbers everything (memory, all 
> registers, etc) or perhaps just memory (some debate here), but that due 
> to bugs that will eventually be addressed, it doesn't currently work 
> this way. 

It's not just bugs which make clobbering all registers unwise and/or
impossible.

> Eventually (presumably in a future phase 1) modify the code to
> implement this.
> 
> People who have written their code incorrectly may have some 
> hard-to-find problems solved for them.  This is particularly valuable 
> for projects that are no longer being maintained.  And while clobbers 
> aren't the best solution to dependencies, they can help.
> 
> Solution 3:
> Deprecate (and eventually disallow) the use of basic asm within 
> functions (perhaps excluding asm("") and naked functions).  Do this by 
> emitting warnings (and eventually fatal errors).  Doc this plan.

You've missed the most practical solution, which meets most common
usage: clobber memory, but not registers.  That allows most of the
effects that people intuitively want and expect, but avoids the
breakage of register clobbers.  It allows basic asm to be used in a
sensible way by pushing and popping all used registers.

Andrew.

[Bug other/68874] New: Allow pass groups to be cloned

[vries at gcc dot gnu.org]

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

Bug ID: 68874
   Summary: Allow pass groups to be cloned
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

A pass group in passes.def is declared like this:
...
  NEXT_PASS (pass_build_ssa_passes);
  PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes)
  NEXT_PASS (pass_fixup_cfg);
  NEXT_PASS (pass_init_datastructures);
  NEXT_PASS (pass_build_ssa);
  NEXT_PASS (pass_ubsan);
  NEXT_PASS (pass_early_warn_uninitialized);
  NEXT_PASS (pass_nothrow);
  POP_INSERT_PASSES ()
...

Sometimes it's needed to split a pass group in two.

This could be done by cloning the pass group:
...
  NEXT_PASS (pass_build_ssa_passes);
  PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes)
  NEXT_PASS (pass_fixup_cfg);
  NEXT_PASS (pass_init_datastructures);
  NEXT_PASS (pass_build_ssa);
  POP_INSERT_PASSES ()
  ...
  NEXT_PASS (pass_build_ssa_passes);
  PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes)
  NEXT_PASS (pass_ubsan);
  NEXT_PASS (pass_early_warn_uninitialized);
  NEXT_PASS (pass_nothrow);
  POP_INSERT_PASSES ()
...

But atm, this is not supported, because PUSH_INSERT_PASSES_WITHIN hardcodes
that the pass instance is instance 1:
...
#define PUSH_INSERT_PASSES_WITHIN(PASS) \
  { \
opt_pass **p = &(PASS ## _1)->sub;
...

So we have to revert to copy-pasting the pass group, appending 2 everywhere and
then using:
...
  NEXT_PASS (pass_build_ssa_passes);
  PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes)
  NEXT_PASS (pass_fixup_cfg);
  NEXT_PASS (pass_init_datastructures);
  NEXT_PASS (pass_build_ssa);
  POP_INSERT_PASSES ()
  ...
  NEXT_PASS (pass_build_ssa_passes2);
  PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes2)
  NEXT_PASS (pass_ubsan);
  NEXT_PASS (pass_early_warn_uninitialized);
  NEXT_PASS (pass_nothrow);
  POP_INSERT_PASSES ()
...

[Bug other/68874] Allow pass groups to be cloned

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 37009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37009=edit
tentative patch

This tentative patch introduces a prev variable (maintained in NEXT_PASS) and
uses that to get to the previous pass instance in PUSH_INSERT_PASSES_WITHIN.

Note that this ignores the pass argument to PUSH_INSERT_PASSES_WITHIN, so we
could go to the point of removing it:
...
  NEXT_PASS (pass_build_ssa_passes);
  PUSH_INSERT_PASSES_WITHIN ()
  NEXT_PASS (pass_fixup_cfg);
  NEXT_PASS (pass_init_datastructures);
  NEXT_PASS (pass_build_ssa);
  POP_INSERT_PASSES ()
  ...
  NEXT_PASS (pass_build_ssa_passes);
  PUSH_INSERT_PASSES_WITHIN ()
  NEXT_PASS (pass_ubsan);
  NEXT_PASS (pass_early_warn_uninitialized);
  NEXT_PASS (pass_nothrow);
  POP_INSERT_PASSES ()
...

[Bug target/68872] New: -mcpu=powerpc64le does not pass -mpower8 to gas

[amodra at gmail dot com]

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

Bug ID: 68872
   Summary: -mcpu=powerpc64le does not pass -mpower8 to gas
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

This results in failures assembling "mfcr r,mask" and also wrong "at" branch
hints.  See https://sourceware.org/bugzilla/show_bug.cgi?id=19359 for a
testcase.

[Bug other/68873] New: excessive duplicate checking during build

[dcb314 at hotmail dot com]

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

Bug ID: 68873
   Summary: excessive duplicate checking during build
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I just did a non-bootstrap build of gcc trunk.

Configure line used was 

../src/trunk/configure --prefix=/home/dcb/gcc/results \
--disable-bootstrap \
--disable-multilib \
--disable-werror \
--enable-checking=yes \
--enable-languages=c,c++,fortran 

I also did

sed 's/-O2/-O3 -march=native -Wlogical-op/' < Makefile > Makefile.tmp
mv Makefile.tmp Makefile

and I collected the results of the build into a file called mk.out

$ (date;ulimit -t 1200;make -j 2;date) > mk.out 2>&1 &

Then I did

$ grep "^checking" mk.out  | sort | uniq -c | sort -rn > /tmp/00
$ head /tmp/00
 26 checking how to hardcode library paths into programs... immediate
 24 checking whether we are cross compiling... no
 23 checking whether the C compiler works... yes
 23 checking for x86_64-pc-linux-gnu-ranlib... ranlib
 23 checking for egrep... /usr/bin/grep -E
 21 checking whether to enable maintainer-specific portions of Makefiles...
no
 21 checking for a BSD-compatible install... /usr/bin/install -c
 19 checking whether to build shared libraries... yes
 19 checking whether ln -s works... yes
 19 checking for x86_64-pc-linux-gnu-ar... ar
$

which means that a non-bootstrap build checks 26 times how to hardcode
library paths into programs, checks 24 times if we are cross compiling etc

Seems like a lot of pointless duplication to me. I can only
assume a bootstrap build would have bigger duplication.

I suspect a small shell or perl script could collect this information
into a file once at the start, and various parts of the build could 
interrogate the data file when they need to.

Re: [PATCH][ARC] Refurbish emitting DWARF2 for epilogue.

[Joern Wolfgang Rennecke]

On 11/12/15 10:29, Claudiu Zissulescu wrote:

I did some testing here. For size, I used CSiBE testbench, and for speed, I 
used coremark and dhrystone. Using a blockage or not, doesn't affect the size 
or speed figures. However, using TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P hook 
betters the size figures (not much, just .1%), and improves the coremark by 2% 
and Dhrystone by 1%.

Hence, in the light of the new figures, I favor the above two patch solution. 
Both patches are checked using dg.exp and compile.exp. Ok to submit?

Both patches are OK.

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[H.J. Lu]

On Sat, Dec 12, 2015 at 7:27 AM, Jakub Jelinek  wrote:
> On Sat, Dec 12, 2015 at 09:51:23AM -0500, Jason Merrill wrote:
>> On 12/11/2015 06:52 PM, H.J. Lu wrote:
>> >On Thu, Dec 10, 2015 at 3:24 AM, Richard Biener
>> > wrote:
>> >>On Wed, Dec 9, 2015 at 10:31 PM, Markus Trippelsdorf
>> >> wrote:
>> >>>On 2015.12.09 at 10:53 -0800, H.J. Lu wrote:
>> 
>> Empty C++ class is a corner case which isn't covered in psABI nor C++ 
>> ABI.
>> There is no mention of "empty record" in GCC documentation.  But there 
>> are
>> plenty of "empty class" in gcc/cp.  This change affects all targets.  
>> C++ ABI
>> should specify how it should be passed.
>> >>>
>> >>>There is a C++ ABI mailinglist, where you could discuss this issue:
>> >>>http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>> >>
>> >>Yep.  As long as the ABI doesn't state how to pass those I'd rather _not_ 
>> >>change
>> >>GCCs way.
>> >
>> >It is agreed that GCC is wrong on this:
>> >
>> >http://sourcerytools.com/pipermail/cxx-abi-dev/2015-December/002876.html
>>
>> Yes, I think this is just a (nasty) bug on some GCC targets.
>
> Well, the argument in that thread is weird, because C and C++ empty structs
> are different, so it isn't surprising they are passed differently.
> C++ makes those sizeof == 1, while C has them sizeof == 0.
> So I rather think clang should change rather than GCC.
>

But according to x86-64 psABI,  sizeof == 1 should be passed in register,
not on stack.  This leads to weird GCC bugs like:

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


-- 
H.J.

[Bug tree-optimization/67781] Wrong code generated on mips32 with -O1 -fexpensive-optimizations

[mikpelinux at gmail dot com]

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

--- Comment #5 from Mikael Pettersson  ---
m68k is also affected, so it looks like all big-endian targets have this bug:

--- shift.s-m68k-r2108422015-12-12 18:50:53.358503028 +0100
+++ shift.s-m68k-r2108432015-12-12 18:54:43.938357653 +0100
@@ -9,10 +9,7 @@
.type   main, @function
 main:
link.w %fp,#0
-   move.l s,%d0
-   lsl.l #8,%d0
-   or.b s+4,%d0
-   move.l %d0,-(%sp)
+   move.l s,-(%sp)
pea .LC0
jsr printf
clr.l %d0

Re: update_vtable_references segfault

[Nathan Sidwell]

On 12/11/15 13:15, Jan Hubicka wrote:

Jan,



b) augment can_replace_by_local_alias_in_vtable to check whether
aliases can be created?


I think this is best: can_replace_by_local_alias_in_vtable exists to prevent the
body walk in cases we are not going to create the alias.  This is because in LTO
we may need to stream in the constructor from the object file that is not 
copletely
free and thus it is better to not touch it unless necessary.


I went with augmenting can_replace_by_local_alias, which 
can_replace_by_local_alias_in_vtable calls.  I also noticed that both should be 
static, which  I suspect will encourage the inliner to go inline them and then 
determine a bunch of code is unreachable.


tested on x86-linux and ptx-none.

ok?

nathan
2015-12-12  Nathan Sidwell  

	* ipa-visibility.c (can_replace_by_local_alias): Make static,
	check ASM_OUTPUT_DEF.
	(can_replace_by_local_alias_in_vtable): Make static.
	(function_and_variable_visibility): Reformat overlong comment.

Index: ipa-visibility.c
===
--- ipa-visibility.c	(revision 231571)
+++ ipa-visibility.c	(working copy)
@@ -329,9 +329,13 @@ varpool_node::externally_visible_p (void
Local aliases save dynamic linking overhead and enable more optimizations.
  */
 
-bool
+static bool
 can_replace_by_local_alias (symtab_node *node)
 {
+#ifndef ASM_OUTPUT_DEF
+  /* If aliases aren't supported, we can't do replacement.  */
+  return false;
+#endif
   /* Weakrefs have a reason to be non-local.  Be sure we do not replace
  them.  */
   while (node->transparent_alias && node->definition && !node->weakref)
@@ -344,11 +348,11 @@ can_replace_by_local_alias (symtab_node
 	  && !node->can_be_discarded_p ());
 }
 
-/* Return true if we can replace refernece to NODE by local alias
+/* Return true if we can replace reference to NODE by local alias
within a virtual table.  Generally we can replace function pointers
and virtual table pointers.  */
 
-bool
+static bool
 can_replace_by_local_alias_in_vtable (symtab_node *node)
 {
   if (is_a  (node)
@@ -592,10 +596,11 @@ function_and_variable_visibility (bool w
   if (!node->local.local)
 node->local.local |= node->local_p ();
 
-  /* If we know that function can not be overwritten by a different semantics
-	 and moreover its section can not be discarded, replace all direct calls
-	 by calls to an noninterposable alias.  This make dynamic linking
-	 cheaper and enable more optimization.
+  /* If we know that function can not be overwritten by a
+	 different semantics and moreover its section can not be
+	 discarded, replace all direct calls by calls to an
+	 noninterposable alias.  This make dynamic linking cheaper and
+	 enable more optimization.
 
 	 TODO: We can also update virtual tables.  */
   if (node->callers 

[Bug libfortran/68867] numeric formatting problem in the fortran library

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #8)
> 
> I doubt that will fix the problem: it seems related to to a rounding issue
> with REAL(16). Which REAL(16) is used? "IBM" one or float_128?

True, it only fixes the work around code in fmt_g0_7.f08.  The underlying
problem is powerpc specific.  I do not know if it is we are using too may
default digits for kind=16?

[Bug rtl-optimization/67477] [6 Regression] ICE in cselib_record_set, at cselib.c:2388

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
The ICE has been on
(insn 105 746 971 5 (parallel [
(set (reg:V16QI 60 d22 [720])
(unspec:V16QI [
(reg:V16QI 60 d22 [720])
(reg:V16QI 60 d22 [720])
] UNSPEC_VTRN1))
(set (reg:V16QI 60 d22 [720])
(unspec:V16QI [
(reg:V16QI 60 d22 [720])
(reg:V16QI 60 d22 [720])
] UNSPEC_VTRN2))
]) pr67477.c:63 1972 {*neon_vtrnv16qi_insn}
 (nil))
which was clearly invalid RTL, multiple sets of the same register.  The insn
was still ok in the *.ira dump and broken in *.reload dump.
(define_insn "*neon_vtrn_insn"
  [(set (match_operand:VDQW 0 "s_register_operand" "=w")
(unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")
  (match_operand:VDQW 3 "s_register_operand" "2")]
 UNSPEC_VTRN1))
   (set (match_operand:VDQW 2 "s_register_operand" "=w")
 (unspec:VDQW [(match_dup 1) (match_dup 3)]
 UNSPEC_VTRN2))]
  "TARGET_NEON"
  "vtrn.\t%0, %2"
  [(set_attr "type" "neon_permute")]
doesn't look like a target bug that would allow 2 same set destinations.

[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I'd add this regressed with r229128, and indeed before that change reassoc has
been able to optimize the comparisons, but now it is not.  So, either we defer
the creation of vec_cond_expr until later time, or need to teach at least
reassoc pass about COND_EXPRs and VEC_COND_EXPRs.

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[Jakub Jelinek]

On Sat, Dec 12, 2015 at 09:51:23AM -0500, Jason Merrill wrote:
> On 12/11/2015 06:52 PM, H.J. Lu wrote:
> >On Thu, Dec 10, 2015 at 3:24 AM, Richard Biener
> > wrote:
> >>On Wed, Dec 9, 2015 at 10:31 PM, Markus Trippelsdorf
> >> wrote:
> >>>On 2015.12.09 at 10:53 -0800, H.J. Lu wrote:
> 
> Empty C++ class is a corner case which isn't covered in psABI nor C++ ABI.
> There is no mention of "empty record" in GCC documentation.  But there are
> plenty of "empty class" in gcc/cp.  This change affects all targets.  C++ 
> ABI
> should specify how it should be passed.
> >>>
> >>>There is a C++ ABI mailinglist, where you could discuss this issue:
> >>>http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
> >>
> >>Yep.  As long as the ABI doesn't state how to pass those I'd rather _not_ 
> >>change
> >>GCCs way.
> >
> >It is agreed that GCC is wrong on this:
> >
> >http://sourcerytools.com/pipermail/cxx-abi-dev/2015-December/002876.html
> 
> Yes, I think this is just a (nasty) bug on some GCC targets.

Well, the argument in that thread is weird, because C and C++ empty structs
are different, so it isn't surprising they are passed differently.
C++ makes those sizeof == 1, while C has them sizeof == 0.
So I rather think clang should change rather than GCC.

Jakub

[Bug rtl-optimization/67477] [6 Regression] ICE in cselib_record_set, at cselib.c:2388

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This indeed started with r227382 and got fixed (or made latent) with r228097.

Re: [PATCH 6/6] [DJGPP] configure.ac: enable LTO

[Andris Pavenis]

On 12/11/2015 12:32 AM, Jeff Law wrote:

On 12/05/2015 10:25 AM, Andris Pavenis wrote:

Patch enables LTO support for DJGPP in top level configure.ac

Andris

2015-12-05 Andris Pavenis 

* configure.ac: enable LTO for *-*-msdosdjgpp
OK once prereqs have gone in.  Note you should to the autoconf dance to update the generated 
files.  Mention them in your ChangeLog as

* configure: Regenerated

jeff



Updated patch is in attachment.

Andris

PS. Somebody other should apply this and my other DJGPP related patches as I do not have SVN write 
access.


2015-12-05 Andris Pavenis 

* configure.ac: Enable LTO for *-*-msdosdjgpp.
* configure: Regenerate.

>From d001fa0866e6bf1f4b879329841f7674f0e90eab Mon Sep 17 00:00:00 2001
From: Andris Pavenis 
Date: Sat, 12 Dec 2015 10:15:42 +0200
Subject: [PATCH 6/6] [DJGPP] configure.ac: enable LTO

---
 configure| 4 ++--
 configure.ac | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index 090615f..0cde5a2 100755
--- a/configure
+++ b/configure
@@ -6122,7 +6122,7 @@ if test $target_elf = yes; then :
 else
   if test x"$default_enable_lto" = x"yes" ; then
 case $target in
-  *-apple-darwin9* | *-cygwin* | *-mingw*) ;;
+  *-apple-darwin9* | *-cygwin* | *-mingw* | *djgpp*) ;;
   # On other non-ELF platforms, LTO has yet to be validated.
   *) enable_lto=no ;;
 esac
@@ -6133,7 +6133,7 @@ else
   # warn during gcc/ subconfigure; unless you're bootstrapping with
   # -flto it won't be needed until after installation anyway.
 case $target in
-  *-cygwin* | *-mingw* | *-apple-darwin*) ;;
+  *-cygwin* | *-mingw* | *-apple-darwin* | *djgpp*) ;;
   *) if test x"$enable_lto" = x"yes"; then
 	as_fn_error "LTO support is not enabled for this target." "$LINENO" 5
 fi
diff --git a/configure.ac b/configure.ac
index a6998ff..ee4fd23 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1817,7 +1817,7 @@ ACX_ELF_TARGET_IFELSE([# ELF platforms build the lto-plugin always.
   build_lto_plugin=yes
 ],[if test x"$default_enable_lto" = x"yes" ; then
 case $target in
-  *-apple-darwin9* | *-cygwin* | *-mingw*) ;;
+  *-apple-darwin9* | *-cygwin* | *-mingw* | *djgpp*) ;;
   # On other non-ELF platforms, LTO has yet to be validated.
   *) enable_lto=no ;;
 esac
@@ -1828,7 +1828,7 @@ ACX_ELF_TARGET_IFELSE([# ELF platforms build the lto-plugin always.
   # warn during gcc/ subconfigure; unless you're bootstrapping with
   # -flto it won't be needed until after installation anyway.
 case $target in
-  *-cygwin* | *-mingw* | *-apple-darwin*) ;;
+  *-cygwin* | *-mingw* | *-apple-darwin* | *djgpp*) ;;
   *) if test x"$enable_lto" = x"yes"; then
 	AC_MSG_ERROR([LTO support is not enabled for this target.])
 fi
-- 
2.5.0

[Bug c++/68876] New: Segmentation fault with variadic templates, std::forward and decltype

[vittorio.romeo at outlook dot com]

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

Bug ID: 68876
   Summary: Segmentation fault with variadic templates,
std::forward and decltype
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

Not sure what's causing the segmentation fault, but here's a minimal example.
The segfault happens with g++ 5.1, 5.2 and 5.3.

gcc.godbolt.org link: https://goo.gl/eQhvm4



#include 

struct static_for_result
{
template 
constexpr decltype(auto) operator()(Ts&&... xs)
{
auto fn_call = [this, ]()
{
return ([](auto&&...)
{
})(std::forward(xs)...);
};

return int{};
}
};

template 
constexpr decltype(auto) static_for(TF&&)
{
return static_for_result{};
}

int main()
{
auto empty_for = static_for([&](auto, auto)
{
})(0);

return 0;
}

[Bug c++/68876] Segmentation fault with variadic templates, std::forward and decltype

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Looks like a dup of PR67247.

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

[Bug c++/67247] ICE on std::forward args&& inside nested lambda function

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||vittorio.romeo at outlook dot 
com

--- Comment #3 from Markus Trippelsdorf  ---
*** Bug 68876 has been marked as a duplicate of this bug. ***

Re: [PATCH 5/6] [DJGPP] gcc/config/i386: update DJGPP configuration related files

[Andris Pavenis]

On 12/11/2015 12:43 AM, Jeff Law wrote:

On 12/05/2015 10:22 AM, Andris Pavenis wrote:

Patch include updates to DJGPP related files in gcc/config/i386.

There are too many changes to gcc/config/i386/djgpp.h and
gcc/config/i386/xm-djgpp.h to list them completely in changelog
entry.

Andris

2015-11-25 Andris Pavenis 

Subject: [PATCH 6/6] [DJGPP] gcc/config/i386: update DJGPP configuration
  related files

* gcc/config/i386/djgpp.h: update
* gcc/config/i386/xm-djgpp.h: update
* gcc/config/i386/djgpp.c: new file
* gcc/config/i386/djgpp.opt: remove obsolete option -mbnu210
* gcc/config/i386/t-djgpp: new file
* gcc/config.gcc: use i386/t-djgpp for DJGPP target

0005-DJGPP-gcc-config-i386-update-DJGPP-configuration-rel.patch


 From 367432d08b4a00f180c3d0710a0f34cda1b6 Mon Sep 17 00:00:00 2001
From: Andris Pavenis
Date: Sat, 5 Dec 2015 08:49:12 +0200
Subject: [PATCH 5/6] [DJGPP] gcc/config/i386: update DJGPP configuration 
related files

* gcc/config/i386/djgpp.h: update
* gcc/config/i386/xm-djgpp.h: update

You should describe what you updated.  SImply saying "update" is insufficient 
here.

Updated ChangeLog entry included


diff --git a/gcc/config/i386/djgpp.c b/gcc/config/i386/djgpp.c
new file mode 100644
index 000..29dad33
--- /dev/null
+++ b/gcc/config/i386/djgpp.c
@@ -0,0 +1,50 @@
+/* Subroutines for DJGPP.
+   Contributed by Andris Pavenis
+   Copyright (C) 2013 Free Software Foundation, Inc.

Copyright date needs updating.

I also removed direct reference to me. One can check search ChangeLog if 
interested



+
+void
+i386_djgpp_asm_named_section(const char *name, unsigned int flags,
+ tree decl)
+{
+  char flagchars[8], *f = flagchars;
+
+(void)decl; /* silence warning. */
The way to do this now is to not give a name to the parameter. So remove "decl" from the function 
signature (leaving its type though). Then you can remove this line.


OK



--- a/gcc/config/i386/djgpp.h
+++ b/gcc/config/i386/djgpp.h
@@ -17,12 +17,27 @@ You should have received a copy of the GNU General Public 
License
  along with GCC; see the file COPYING3.  If not see
  .  */

+#define DBX_DEBUGGING_INFO 1
+#define SDB_DEBUGGING_INFO 1
?  Really,  do you *really* need this.  I'd really like to see DBX and SDB debugging info die, 
not propagate into more targets.

They were missing for some versions of DJGPP builds and re-added after some 
discussion.
DJGPP port of Emacs depends on COFF debugging information. Building it with recent versions of GCC 
do not however work, so

no harm from removing it




-#define IX86_MAYBE_NO_LIBGCC_TFMODE
+#undef DBX_REGISTER_NUMBER
+#define DBX_REGISTER_NUMBER(n) svr4_dbx_register_map[n]

And if the DBX_DEBUGGING_INFO goes away, can't this go away too?
Not according GCC internal docs 
(https://gcc.gnu.org/onlinedocs/gccint/All-Debuggers.html#All-Debuggers).

It is also rather widely used for other targets


Jeff




Andris


New ChangeLog entry:

015-12-12 Andris Pavenis 

   [DJGPP] gcc/config/i386: update DJGPP configuration related files

   * config/i386/djgpp.h (PREFERRED_DEBUGGING_TYPE): Define to DWARF2
   (TARGET_ASM_OUTPUT_IDENT): Define to default_asm_output_ident_directive
   (MD_EXEC_PREFIX): Remove.
   (MD_STARTFILE_PREFIX) Removee.
   (FILE_NAME_ABSOLUTE_P): Remove.
   (CPP_SPEC): Do not read macros from sys/version.h.
   (LINK_COMMAND_SPEC): Remove.
   (LOCAL_INCLUDE_DIR): Remove.
   (TARGET_ASM_NAMED_SECTION): Define to i386_djgpp_asm_named_section
   (TARGET_OS_CPP_BUILTINS): Add DJGPP (non ISO only), __DJGPP, __DJGPP__, 
unix.
   (POST_LINK_SPEC): Define to invoke stubify after linker
   (LIBSTDCXX): Remove define
   (DBX_REGISTER_NUMBER): Define to svr4_dbx_register_map.
   (DEFAULT_PCC_STRUCT_RETURN): Define to 1.
   (SUBTARGET_OVERRIDE_OPTIONS): Remove warning about -mbnu2210.
   (SUBTARGET_OVERRIDE_OPTIONS): Ignore -fPIC and generate message.
   (SUBTARGET_OVERRIDE_OPTIONS): Default to DWARF2 debugging info.
   (IX86_MAYBE_NO_LIBGCC_TFMODE): Remove.
   (i386_djgpp_asm_named_section): Add propotype of new procedure

   * config/i386/xm-djgpp.h (NATIVE_SYSTEM_HEADER_DIR): Define.
   (MD_EXEC_PREFIX): Define (moved from config/i386/djgpp.h).
   (STANDARD_STARTFILE_PREFIX_1): Define (moved from MD_STARTFILE_PREFIX in 
config/i386/djgpp.h).
   (STANDARD_STARTFILE_PREFIX_2): Define identical to 
STANDARD_STARTFILE_PREFIX_1.
   (LOCAL_INCLUDE_DIR): Define (moved from config/i386/djgpp.h).
   (GCC_DRIVER_HOST_INITIALIZATION): Fix reporting fatal installation 
errors.
   (MAX_OFILE_ALIGNMENT): Define to 128.
   (HAVE_FTW_H): Undefine as DJGPP do not have nftw, but have ftw.h.

   * config/i386/djgpp.c: New file. Add implementation of 
i386_djgpp_asm_named_section.

   * config/i386/djgpp.opt: Remove obsolete option 

Re: [PATCH] v2 Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

[Bernhard Reutner-Fischer]

On December 9, 2015 2:07:05 AM GMT+01:00, David Malcolm  
wrote:

>I can't comment on Mikael's observations, but here's an updated version
>of Bernhard's patch which moves the duplicated code into a new
>"find_closest_string" function in gcc/spellcheck.c.  
>With that, the lookup_*_fuzzy functions are all of the form:
>
>{
>  auto_vec  candidates;
>
>  /* call something to populate candidates e.g.: */
>  lookup_function_fuzzy_find_candidates (fun, );
>
>  return find_closest_string (fn, );
>}
>
>where, as before, the auto_vec is implicitly cleaned up via a
>C++ destructor as the function exits.  Hopefully with this change it
>reduces the amount of proposed C++ in the fortran subdirectory to an
>palatable amount.
>
>That's all I did; I didn't address the other issues seen in this thread
>(e.g. Mikael's notes above).
>
>Not yet well-tested; it compiles and passes the new test cases; I'm
>posting it here in case someone more familiar with the Fortran FE wants
>to take this forward (Bernhard?)

I have rewritten the autovec to plain c, will send an updated patch including 
current comments and maybe the parameter handling as suggested by Joost when 
done.

Thanks,
>
>Hope this is constructive
>Dave

[Bug tree-optimization/67781] Wrong code generated on mips32 with -O1 -fexpensive-optimizations

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||thomas.preudhomme at arm dot 
com

--- Comment #4 from Mikael Pettersson  ---
A bisection using a cross to sparc64-linux identified r210843 as the starting
point of this wrong-code regression.  The code generation difference at that
revision for this test case is:

--- shift.s-r210842 2015-12-12 18:39:22.878875236 +0100
+++ shift.s-r210843 2015-12-12 18:36:37.938974547 +0100
@@ -15,12 +15,8 @@
sethi   %hi(.LC0), %o0
lduw[%g1+%lo(s)], %o1
or  %o0, %lo(.LC0), %o0
-   mov 0, %i0
-   ldub[%g1+%lo(s)+4], %g1
-   sll %o1, 8, %o1
-   or  %g1, %o1, %o1
callprintf, 0
-srl%o1, 0, %o1
+mov0, %i0
return  %i7+8
 nop
.size   main, .-main

that is, the "<< 8" and "| s.b" parts of the expression were lost.

Adding author to CC.

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[Jason Merrill]

On 12/11/2015 06:52 PM, H.J. Lu wrote:

On Thu, Dec 10, 2015 at 3:24 AM, Richard Biener
 wrote:

On Wed, Dec 9, 2015 at 10:31 PM, Markus Trippelsdorf
 wrote:

On 2015.12.09 at 10:53 -0800, H.J. Lu wrote:


Empty C++ class is a corner case which isn't covered in psABI nor C++ ABI.
There is no mention of "empty record" in GCC documentation.  But there are
plenty of "empty class" in gcc/cp.  This change affects all targets.  C++ ABI
should specify how it should be passed.


There is a C++ ABI mailinglist, where you could discuss this issue:
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev


Yep.  As long as the ABI doesn't state how to pass those I'd rather _not_ change
GCCs way.


It is agreed that GCC is wrong on this:

http://sourcerytools.com/pipermail/cxx-abi-dev/2015-December/002876.html


Yes, I think this is just a (nasty) bug on some GCC targets.


Here is the updated patch.   I updated -WpsABI to warn empty
record which are passed in a variable argument list or aren't the last
arguments.   They are triggered in:

/export/build/gnu/gcc-x32/build-x86_64-linux/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/hashtable.h:1507:7:
note: the ABI of passing empty record has changed in GCC 6

>

Oof.  Well, at least it's all C++11 stuff, and GCC 5 still defaulted to 
C++98...


Jason

Re: [Patch, Fortran] PR45859 - Permit array elements to coarray dummy arguments

[Steve Kargl]

On Wed, Dec 09, 2015 at 08:24:39AM +0100, Tobias Burnus wrote:
> PING
> 

OK.

-- 
Steve

[Bug c/42979] OpenMP #pragma omp taskwait after a label is not permitted - should fail at compile time

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
r230999 should fix this.

[Bug tree-optimization/67781] [5/6 Regression] Wrong code generated on mips32 with -O1 -fexpensive-optimizations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |5.4
Summary|Wrong code generated on |[5/6 Regression] Wrong code
   |mips32 with -O1 |generated on mips32 with
   |-fexpensive-optimizations   |-O1
   ||-fexpensive-optimizations
   Severity|normal  |critical

[Bug fortran/68815] Error/warning diagnostic: '%s' should be converted to %qs-like or %<%s%>-like string strings

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  ---
Author: burnus
Date: Sat Dec 12 18:55:25 2015
New Revision: 231584

URL: https://gcc.gnu.org/viewcvs?rev=231584=gcc=rev
Log:
2014-12-12  Tobias Burnus  

gcc/c-family/
PR fortran/68815
* c-format.c (gcc_gfc_char_table): Add 'q' flag to remaining
specifiers (%d, %i,%u and %c).

gcc/fortran/
PR fortran/68815
* check.c (gfc_check_reshape): Replace %<%d%> by %qd.
* matchexp.c (gfc_match_defined_op_name): Use %qc.
* symbol.c (gfc_add_new_implicit_range,
gfc_merge_new_implicit): Ditto.


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-format.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/matchexp.c
trunk/gcc/fortran/symbol.c

[Bug middle-end/68878] [6 Regression] 471.omnetpp in SPEC CPU 2006 is miscompiled with LTO

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #1 from Jan Hubicka  ---
HJ,
can you please check if the earlier revision is good?  I do not have omnetpp
sources from spec2k6 and wonder how this particular revision can lead to a
wrong code... It only slightly changes the way we merge builtin decls that
should be a no-op because we already merge them at the streaming time.

You can build with -fdump-ipa-cgraph and look if there are any transparent
aliases introduced. (just grep the dumps for transparent_alias)

[Bug fortran/68743] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2015-12-07, at 5:58 PM, dominiq at lps dot ens.fr wrote:

> Could you
> please investigate what is wrong with your libs?

There is a problem with the call to floor in the floorf function at
c99_functions.c:293.
Somehow, it calls floorf instead and this causes a stack overflow:

Pid 12028 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz. 

Program received signal SIGSEGV, Segmentation fault.
floorf (x=42.708, 
x@entry=) at ../../../gcc/libgfortran/intrinsics/c99_functions.c:293

Relocation section '.rela.text.floorf' at offset 0xde70 contains 1 entries:
  Offset  Info   Type   Sym. ValueSym. Name +
Addend
000c  00d0004a R_PARISC_PCREL22F  floorf + 0

It's like floor is aliased to floorf.

--
John David Anglin   dave.ang...@bell.net

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-12
 CC||Hans.Boehm at hp dot com
 Ever confirmed|0   |1

--- Comment #21 from Dominique d'Humieres  ---
Confirmed.

I also get 20 failures for the libjava tests

WARNING: program timed out.
FAIL: TestClosureGC run
WARNING: program timed out.
FAIL: libjava.jar/TestClosureGC.jar execution - gij test
WARNING: program timed out.
FAIL: FileHandleGcTest execution - source compiled test
WARNING: program timed out.
FAIL: FileHandleGcTest -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: FileHandleGcTest -O3 execution - source compiled test
WARNING: program timed out.
FAIL: FileHandleGcTest -O3 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: PR18699 execution - source compiled test
WARNING: program timed out.
FAIL: PR18699 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: PR18699 -O3 execution - source compiled test
WARNING: program timed out.
FAIL: PR18699 -O3 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: PR36252 execution - source compiled test
WARNING: program timed out.
FAIL: PR36252 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: PR36252 -O3 execution - source compiled test
WARNING: program timed out.
FAIL: PR36252 -O3 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: md5test execution - source compiled test
WARNING: program timed out.
FAIL: md5test -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: md5test -O3 execution - source compiled test
WARNING: program timed out.
FAIL: md5test -O3 -findirect-dispatch execution - source compiled test
WARNING: program timed out.
FAIL: TestEarlyGC execution - source compiled test
WARNING: program timed out.
FAIL: TestLeak execution - source compiled test

for both -m32 and -m64. Are they related?

Re: Transparent alias suport part 7 (lto-symtab support)

[H.J. Lu]

On Tue, Dec 8, 2015 at 2:30 PM, Jan Hubicka  wrote:
> Hi,
> this patch adds support to lto-symtab.c to prevent merging of certain
> declarations.  The new predicate lto_symtab_merge_p can be used to decide
> about this.   The change is pretty straigforward.  lto_symtab_merge_decls_2
> makes the decisions about what decls to merge and lto_symtab_merge_symbols_1
> does the corresponding symbol merging/creation of transparent aliases.
>
> I re-implemented lto_symtab_prevailing_decl and moved it to inline so the
> merging pass is also considerably faster (it used to do quite expensive
> assembler name hash lookup on every occurenceof the decl).  Merging decisions
> are represented by setting DECL_ABSTRACT_ORIGIN to error_mark_node and
> DECL_CHAIN to the replacement decl.  This is quite arbitrary decision - I 
> needed
> a pointer and flag that is not going to mess with the warnings we output
> during the lto-symtab's operation.
>
> The patch does not disable any of the wrong merging we are hitting.  I will
> dot hat separately and with a testcases.  I only revisited a bit the way
> builtins are handled.
>
> Bootstrapped/regtested x86_64-linux. I am re-running the lto-bootstrap after
> some last minute changes and plan commit once it converges.
>
> Honza
>
> PR ipa/61886
> * lto-streamer.h (lto_symtab_merge_decls, lto_symtab_merge_symbols,
> lto_symtab_prevailing_decl): MOve to lto-symtab.h.
>
> * lto-symtab.c: Include lto-symtab.h.
> (lto_cgraph_replace_node): Do not merge profiles here.
> (lto_symtab_merge_p): New function.
> (lto_symtab_merge_decls_2): Honor lto_symtab_merge_p.
> (lto_symtab_merge_symbols_1): Turn unmerged decls into transparent
> aliases.
> (lto_symtab_merge_symbols): Do not clear node->aux; we no longer use 
> it.
> (lto_symtab_prevailing_decl): Move to lto-symtab.h; rewrite.
> * lto.c: Include lto-symtab.h
> * lto-symtab.h: New.
>

This caused:

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


-- 
H.J.

[Bug fortran/45859] [Coarray, F2008, IR] Rejects valid actuals to coarray dummies

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
Author: burnus
Date: Sat Dec 12 19:00:32 2015
New Revision: 231585

URL: https://gcc.gnu.org/viewcvs?rev=231585=gcc=rev
Log:
2014-12-12  Tobias Burnus  

gcc/fortran
PR fortran/45859
* expr.c (gfc_is_simply_contiguous): Optionally permit array
* elements.
(gfc_check_pointer_assign): Update call.
* interface.c (compare_parameter): Ditto.
* trans-array.c (gfc_conv_array_parameter): Ditto.
* trans-intrinsic.c (gfc_conv_intrinsic_transfer,
conv_isocbinding_function): Ditto.
* gfortran.h (gfc_is_simply_contiguous): Update prototype.

gcc/testsuite/
PR fortran/45859
* gcc/testsuite/gfortran.dg/coarray_args_2.f90: Remove dg-error.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray_args_2.f90

[Bug libstdc++/68877] swap for multidimensional array of int ill-formed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-12
   Assignee|unassigned at gcc dot gnu.org  
|daniel.kruegler@googlemail.
   ||com
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Sounds good to me, thanks! :-)

[Bug libstdc++/68877] [6 Regression] swap for multidimensional array of int ill-formed

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
I suggest (this is not a joke) that the right fix is to implement
noexcept(auto) as an extension (possibly available only in system headers for
now), and use it inside the library.

[Bug libstdc++/68877] New: swap for multidimensional array of int ill-formed

[daniel.kruegler at googlemail dot com]

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

Bug ID: 68877
   Summary: swap for multidimensional array of int ill-formed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.kruegler at googlemail dot com
  Target Milestone: ---

The following code example (A reduced form of an example from a recent LWG
issue http://cplusplus.github.io/LWG/lwg-active.html#2554)

/---
#include 

int main() 
{
  int x[2][3];
  int y[2][3];

  std::swap(x, y);
}
/---

compiled with the flags

-Wall -Wextra

and targetting any of C++1z, C++14, or C++11 with or without GNU extensions is
rejected in 

gcc HEAD 6.0.0 20151207 (experimental)

(but not in previous releases such as 5.2.0) with the compiler diagnostics:


In file included from /usr/local/gcc-head/include/c++/6.0.0/bits/move.h:57:0,
 from /usr/local/gcc-head/include/c++/6.0.0/bits/stl_pair.h:59,
 from /usr/local/gcc-head/include/c++/6.0.0/utility:70,
 from prog.cc:1:
/usr/local/gcc-head/include/c++/6.0.0/type_traits: In instantiation of
'typename
std::enable_if::value>::type
std::swap(_Tp (&)[_Nm], _Tp (&)[_Nm]) [with _Tp = int [2]; long unsigned int
_Nm = 1ul; typename
std::enable_if::value>::type =
void]':
prog.cc:8:17:   required from here
/usr/local/gcc-head/include/c++/6.0.0/type_traits:2594:27: error: no matching
function for call to 'swap(int [2], int [2])'
 noexcept(noexcept(swap(*__a, *__b)));
   ^~~~

In file included from
/usr/local/gcc-head/include/c++/6.0.0/bits/stl_pair.h:59:0,
 from /usr/local/gcc-head/include/c++/6.0.0/utility:70,
 from prog.cc:1:
/usr/local/gcc-head/include/c++/6.0.0/bits/move.h:179:5: note: candidate:
template typename
std::enable_if,
std::is_move_assignable<_Tp> >::value>::type std::swap(_Tp&, _Tp&)
 swap(_Tp& __a, _Tp& __b)
 ^~~~

/usr/local/gcc-head/include/c++/6.0.0/bits/move.h:179:5: note:   template
argument deduction/substitution failed:
/usr/local/gcc-head/include/c++/6.0.0/bits/move.h: In substitution of
'template typename
std::enable_if,
std::is_move_assignable<_Tp> >::value>::type std::swap(_Tp&, _Tp&) [with _Tp =
int [2]]':
/usr/local/gcc-head/include/c++/6.0.0/type_traits:2594:27:   required from
'typename
std::enable_if::value>::type
std::swap(_Tp (&)[_Nm], _Tp (&)[_Nm]) [with _Tp = int [2]; long unsigned int
_Nm = 1ul; typename
std::enable_if::value>::type =
void]'
prog.cc:8:17:   required from here
/usr/local/gcc-head/include/c++/6.0.0/bits/move.h:179:5: error: no type named
'type' in 'struct std::enable_if'
In file included from /usr/local/gcc-head/include/c++/6.0.0/bits/move.h:57:0,
 from /usr/local/gcc-head/include/c++/6.0.0/bits/stl_pair.h:59,
 from /usr/local/gcc-head/include/c++/6.0.0/utility:70,
 from prog.cc:1:
/usr/local/gcc-head/include/c++/6.0.0/type_traits: In instantiation of
'typename
std::enable_if::value>::type
std::swap(_Tp (&)[_Nm], _Tp (&)[_Nm]) [with _Tp = int [2]; long unsigned int
_Nm = 1ul; typename
std::enable_if::value>::type =
void]':
prog.cc:8:17:   required from here
/usr/local/gcc-head/include/c++/6.0.0/type_traits:2594:27: error: no matching
function for call to 'swap(int [2], int [2])'
 noexcept(noexcept(swap(*__a, *__b)));
   ^~~~

In file included from
/usr/local/gcc-head/include/c++/6.0.0/bits/stl_pair.h:59:0,
 from /usr/local/gcc-head/include/c++/6.0.0/utility:70,
 from prog.cc:1:
/usr/local/gcc-head/include/c++/6.0.0/bits/move.h:179:5: note: candidate:
template typename
std::enable_if,
std::is_move_assignable<_Tp> >::value>::type std::swap(_Tp&, _Tp&)
 swap(_Tp& __a, _Tp& __b)
 ^~~~

/usr/local/gcc-head/include/c++/6.0.0/bits/move.h:179:5: note:   template
argument deduction/substitution failed:
/usr/local/gcc-head/include/c++/6.0.0/bits/move.h: In substitution of
'template typename
std::enable_if,
std::is_move_assignable<_Tp> >::value>::type std::swap(_Tp&, _Tp&) [with _Tp =
int [2]]':
/usr/local/gcc-head/include/c++/6.0.0/type_traits:2594:27:   required from
'typename
std::enable_if::value>::type
std::swap(_Tp (&)[_Nm], _Tp (&)[_Nm]) [with 

Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class

[Marc Glisse]

On Sat, 12 Dec 2015, Jakub Jelinek wrote:


On Sat, Dec 12, 2015 at 09:51:23AM -0500, Jason Merrill wrote:

On 12/11/2015 06:52 PM, H.J. Lu wrote:

On Thu, Dec 10, 2015 at 3:24 AM, Richard Biener
 wrote:

On Wed, Dec 9, 2015 at 10:31 PM, Markus Trippelsdorf
 wrote:

On 2015.12.09 at 10:53 -0800, H.J. Lu wrote:


Empty C++ class is a corner case which isn't covered in psABI nor C++ ABI.
There is no mention of "empty record" in GCC documentation.  But there are
plenty of "empty class" in gcc/cp.  This change affects all targets.  C++ ABI
should specify how it should be passed.



About this patch, aren't we supposed to enable new C++ ABIs with 
-fabi-version=42 (or whatever the next number is)?




There is a C++ ABI mailinglist, where you could discuss this issue:
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev


Yep.  As long as the ABI doesn't state how to pass those I'd rather _not_ change
GCCs way.


It is agreed that GCC is wrong on this:

http://sourcerytools.com/pipermail/cxx-abi-dev/2015-December/002876.html


Yes, I think this is just a (nasty) bug on some GCC targets.


Well, the argument in that thread is weird, because C and C++ empty structs
are different, so it isn't surprising they are passed differently.
C++ makes those sizeof == 1, while C has them sizeof == 0.


Maybe it isn't surprising, but it isn't particularly helpful either. It 
increases the number of places where the 2 are incompatible.

(I personally don't care about empty C structs)


So I rather think clang should change rather than GCC.


Passing empty arguments (with trivial copy constructor, etc) is a complete 
waste. Not passing them is strictly superior. The only reason to prefer 
passing them is that that's what gcc does and changing would break the 
ABI. I could understand clang being unhappy if they have to both break ABI 
compatibility with their older versions and move towards an inferior 
ABI... (arguably they could have copied the de facto gcc ABI to begin 
with) They might be willing to do it on linux-x86, but not on ios/mac 
where they dominate and compatibility with their own earlier versions 
matters more than compatibility with gcc?


--
Marc Glisse

[Bug bootstrap/68873] excessive duplicate checking during build

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|other   |bootstrap
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
Basically each library that uses libtool does this.  Each multilib could use
its own cache instead of each library which would improve this.  But with -j48,
the time spent in configure scripts is minor still.

[Bug middle-end/68878] New: [6 Regression] 471.omnetpp in SPEC CPU 2006 is miscompiled with LTO

[hjl.tools at gmail dot com]

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

Bug ID: 68878
   Summary: [6 Regression] 471.omnetpp in SPEC CPU 2006 is
miscompiled with LTO
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: hubicka at ucw dot cz
  Target Milestone: ---

On x86, r231438 miscompiled 471.omnetpp in SPEC CPU 2006:

g++  -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver
-fuse-linker-plugin  -DSPEC_CPU_LP64EtherAppCli.o EtherAppCli_n.o
EtherAppSrv.o EtherAppSrv_n.o EtherApp_m.o EtherBus.o EtherBus_n.o
EtherCtrl_m.o EtherEncap.o EtherEncap_n.o EtherFrame_m.o EtherHost_n.o
EtherHub.o EtherHub_n.o EtherLLC.o EtherLLC_n.o EtherMAC.o EtherMAC_n.o
EtherSwitch_n.o LargeNet_n.o MACAddress.o MACAddress_m.o MACRelayUnitBase.o
MACRelayUnitNP.o MACRelayUnitNP_n.o MACRelayUnitPP.o MACRelayUnitPP_n.o
MACRelayUnit_n.o Networks_n.o eth-index_n.o utils.o libs/cmdenv/cmdenv.o
libs/cmdenv/enumstr.o libs/cmdenv/heap.o libs/envir/akoutvectormgr.o
libs/envir/args.o libs/envir/cenvir.o libs/envir/cinifile.o
libs/envir/filemgrs.o libs/envir/main.o libs/envir/omnetapp.o
libs/envir/patmatch.o libs/envir/platdep.o libs/envir/seeds.o
libs/envir/slaveapp.o libs/envir/speedmtr.o libs/sim/carray.o
libs/sim/cexception.o libs/sim/cmessage.o libs/sim/cpar.o libs/sim/ctypes.o
libs/sim/task.o libs/sim/cchannel.o libs/sim/cfsm.o libs/sim/cmodule.o
libs/sim/cpsquare.o libs/sim/cvarhist.o libs/sim/util.o libs/sim/ccoroutine.o
libs/sim/cgate.o libs/sim/cmsgheap.o libs/sim/cqueue.o libs/sim/cwatch.o
libs/sim/cdensity.o libs/sim/chead.o libs/sim/cnetmod.o libs/sim/csimul.o
libs/sim/distrib.o libs/sim/cdetect.o libs/sim/chist.o libs/sim/cobject.o
libs/sim/cstat.o libs/sim/errmsg.o libs/sim/cdispstr.o libs/sim/cksplit.o
libs/sim/coutvect.o libs/sim/cstruct.o libs/sim/onstartup.o libs/sim/cenum.o
libs/sim/cllist.o libs/sim/cpacket.o libs/sim/ctopo.o libs/sim/random.o
libs/sim/std/netpack.o libs/spec/spec_qsort.o -o omnetpp
...
Running Benchmarks
  Running 471.omnetpp test peak lto default

471.omnetpp: copy 0 non-zero return code (exit code=6, signal=0)

Preparing for Run #1...
Setting up network `largeNet'...

Program received signal SIGSEGV, Segmentation fault.
0x006da660 in ?? ()
(gdb) bt
#0  0x006da660 in ?? ()
#1  0x77555092 in _Unwind_ForcedUnwind_Phase2 (exc=0x6db460, 
context=0x7fffd610) at ../../../src-trunk/libgcc/unwind.inc:163
#2  0x775554fd in _Unwind_Resume (exc=0x6db460)
at ../../../src-trunk/libgcc/unwind.inc:232
#3  0x0048532d in cSimpleModule::cSimpleModule(char const*, cModule*,
unsigned int) [clone .constprop.235] ()
#4  0x0047ef0f in MACRelayUnitNP__create(char const*, cModule*) ()
#5  0x0042c5b5 in cModuleType::create(char const*, cModule*, bool) ()
#6  0x00478f77 in EtherSwitch::doBuildInside() ()
#7  0x0044076f in cModule::buildInside() ()
#8  0x00407dcf in LargeNet::doBuildInside() ()
#9  0x0044076f in cModule::buildInside() ()
#10 0x00451bab in largeNet::setupNetwork() ()
#11 0x0044ca90 in cSimulation::setupNetwork(cNetworkType*, int) [clone
.constprop.64] ()
#12 0x004556be in TCmdenvApp::run() ()
#13 0x00405e48 in main ()
(gdb)

[Bug libstdc++/68877] [6 Regression] swap for multidimensional array of int ill-formed

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|swap for multidimensional   |[6 Regression] swap for
   |array of int ill-formed |multidimensional array of
   ||int ill-formed

[v3 PATCH] Document the implementation of Logical Operator Type Traits.

[Ville Voutilainen]

2015-11-12  Ville Voutilainen  

Document the implementation of Logical Operator Type Traits.

* doc/html/index.html: Regenerate.
* doc/html/manual/status.html: Likewise.
* doc/xml/manual/status_cxx2017.xml: Add P0013R1 to C++ 201z
and to Library Fundamentals 2 TS.
diff --git a/libstdc++-v3/doc/html/index.html b/libstdc++-v3/doc/html/index.html
index 1d2815c..d3570c4 100644
--- a/libstdc++-v3/doc/html/index.html
+++ b/libstdc++-v3/doc/html/index.html
@@ -23,7 +23,7 @@
 Table of 
ContentsThe GNU C++ Library 
ManualI. 
   Introduction
   
-1. StatusImplementation 
StatusC++ 
1998/2003Implementation 
StatusImplementation Specific 
BehaviorC++ 
2011Implementation Specific 
BehaviorC++ 2014C++ 
201zC++ 
TR1Implementation Specific 
BehaviorC++ TR 
24733LicenseThe Code: 
GPLThe Documentation: 
GPL, FDLBugsImplementation 
BugsStandard 
Bugs2. SetupPrerequisitesConfigureMake3. 
UsingCommand 
OptionsHeadersHeader 
FilesMixing 
HeadersThe C 
Headers and namespace stdPrecompiled 
HeadersMacrosDual 
ABITroubleshootingNamespacesAvailable 
Namespacesnamespace 
stdUsing 
Namespace CompositionLinkingAlmost
 NothingFinding
 Dynamic or Shared LibrariesConcurrencyPrerequisitesThread
 SafetyAtomicsIOStructureDefaultsFutureAlternativesContainersExceptionsException 
SafetyException 
NeutralityDoing 
withoutCompatibilityWith CWith POSIX thread 
cancellationDebugging SupportUsing g++Debug Versions of Library 
Binary FilesMemory Leak 
HuntingData Race HuntingUsing gdbTracking uncaught 
exceptionsDebug ModeCompile 
Time CheckingProfile-based Performance 
AnalysisII. 
+1. StatusImplementation 
StatusC++ 
1998/2003Implementation 
StatusImplementation Specific 
BehaviorC++ 
2011Implementation Specific 
BehaviorC++ 2014C++ 
201zC++ 
TR1Implementation Specific 
BehaviorC++ TR 
24733LicenseThe Code: 
GPLThe Documentation: 
GPL, FDLBugsImplementation 
BugsStandard 
Bugs2. SetupPrerequisitesConfigureMake3. 
UsingCommand 
OptionsHeadersHeader 
FilesMixing 
HeadersThe C 
Headers and namespace stdPrecompiled 
HeadersMacrosDual 
ABITroubleshootingNamespacesAvailable 
Namespacesnamespace 
stdUsing 
Namespace CompositionLinkingAlmost
 NothingFinding
 Dynamic or Shared LibrariesExperimental
 Library ExtensionsConcurrencyPrerequisitesThread
 SafetyAtomicsIOStructureDefaultsFutureAlternativesContainersExceptionsException 
SafetyException 
NeutralityDoing 
withoutCompatibilityWith CWith POSIX thread 
cancellationDebugging SupportUsing g++Debug Versions of Library 
Binary FilesMemory Leak 
HuntingData Race HuntingUsing gdbTracking uncaught 
exceptionsDebug ModeCompile 
Time CheckingProfile-based Performance 
AnalysisII. 
 Standard Contents
   4. 
   Support
@@ -31,7 +31,7 @@
 TypesFundamental 
TypesNumeric 
PropertiesNULLDynamic 
MemoryTerminationTermination 
HandlersVerbose Terminate 
Handler5. 
   Diagnostics
   
-ExceptionsAPI 
ReferenceAdding Data to 
exceptionConcept 
Checking6. 
+ExceptionsAPI 
ReferenceAdding Data to 
exceptionUse of errno by the 
libraryConcept 
Checking6. 
   Utilities
   
 FunctorsPairsMemoryAllocatorsRequirementsDesign 
IssuesImplementationInterface 
DesignSelecting Default Allocation 
PolicyDisabling Memory 
CachingUsing a Specific 
AllocatorCustom 
AllocatorsExtension 
Allocatorsauto_ptrLimitationsUse in 
Containersshared_ptrRequirementsDesign 
IssuesImplementationClass 
HierarchyThread 
SafetySelecting Lock 
PolicyRelated functions and 
classesUseExamplesUnresolved 
IssuesAcknowledgmentsTraits7. 
diff --git a/libstdc++-v3/doc/html/manual/status.html 
b/libstdc++-v3/doc/html/manual/status.html
index 91404aa..8c5a7c9 100644
--- a/libstdc++-v3/doc/html/manual/status.html
+++ b/libstdc++-v3/doc/html/manual/status.html
@@ -539,6 +539,12 @@ not in any particular release.

   
 Minimal incomplete type support for standard containers, revision 4
+  Y 
+   http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0013r1.html; 
target="_top">
+ P0013R1
+   
+  
+Logical Operator Type Traits (revision 1)
   Y 
Table 
1.6. C++ Technical Specifications Implementation StatusPaperTitleStatusComments
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4076.html; 
target="_top">
  N4076
@@ -579,7 +585,11 @@ not in any particular release.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4521.html; 
target="_top">
  N4521

-   Merge Fundamentals V1 into V2 NLibrary Fundamentals 2 
TSC++ TR1
+   Merge Fundamentals V1 into V2 NLibrary Fundamentals 2 TS
+   http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0013r1.html; 
target="_top">
+ P0013R1
+   
+  Logical Operator Type Traits (revision 1)YLibrary Fundamentals 2 
TSC++ TR1
 This table is based on the table of contents of ISO/IEC DTR 19768
 Doc No: N1836=05-0096 Date: 2005-06-24
 Draft Technical Report on C++ Library Extensions
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2017.xml 

[Bug fortran/68743] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> Program received signal SIGSEGV, Segmentation fault.
> floorf (x=42.708, 
> x@entry= (257).>)
> at ../../../gcc/libgfortran/intrinsics/c99_functions.c:293

AFAIU

#ifndef HAVE_FLOORF
#define HAVE_FLOORF 1
float floorf (float x);

float
floorf (float x)
{
  return (float) floor (x);
}
#endif

it means that HAVE_FLOORF is not defined. Do you see that in your
libgfortran/config.log?

Re: Do not decompress functions sections when copying them to ltrans

[Jan Hubicka]

> > So would the patch be a lot more difficult if you go down either of
> > the routes above?  (I think I prefer changing lto_header rather
> > than making main_size a bitfield)
> 
> Agreed ;)
Hmm, actually it seems things are difficult. All the headers are already 
compressed
by zlib:
Contents of section .gnu.lto_.inline.faa6142d1fc0c505:
  789c6362 6062c006 10a2 ba0007x.cb`b. 
Contents of section .gnu.lto_.symbol_nodes.faa6142d1fc0c505:
  789c6362 6062e060 80025606 06f67a06  x.cb`b.`..V...z.
 0010 0600029c 0098..  
Contents of section .gnu.lto_.refs.faa6142d1fc0c505:
  789c6362 60626064 8002 460006x.cb`b`dF.. 
Contents of section .gnu.lto_.decls.faa6142d1fc0c505:
  789c6362 6062d060 6060f80f 0461405a  x.cb`b.```...a@Z
 0010 10881981 d88e0115 80c496a2 8929312c  .)1,
 0020 6c5870e0 c1d2291c 131a1b1b feffaf4f  lXp...)O
 0030 6464e104 9ac7cec8 a0c5b0b2 a1a16142  ddaB
 0040 43c32336 142d118c 898c7c9c 0c0a6006  C.#6.-|...`.
 0050 0f27030b 58349171 1923135c 0d4b895e  .'..X4.q.#.\.K.^
 0060 32037359 620e9bbb 5fa88233 0300a167  2.sYb..._..3...g
 0070 1a7f ..  
Contents of section .gnu.lto_.symtab.faa6142d1fc0c505:
  76616c00 00040004  00a5  val.
 0010 00   ...  


Contents of section .gnu.lto_.opts: 


  272d6d74 756e653d 67656e65 72696327  '-mtune=generic' 


 0010 20272d6d 61726368 3d783836 2d363427   '-march=x86-64' 


 0020 20272d66 6c746f27 00  '-flto'.


Contents of section .comment:   


  00474343 3a202853 55534520 4c696e75  .GCC: (SUSE Linu 


 0010 78292034 2e382e33 20323031 34303632  x) 4.8.3 2014062 


 0020 37205b67 63632d34 5f382d62 72616e63  7 [gcc-4_8-branc
 0030 68207265 76697369 6f6e2032 31323036  h revision 21206
 0040 345d00   4]. 

as you can see only opts/comment and symtab sections come out decompressed.
The sequence x.cb`b is zlib's header.  The description is here:
https://tools.ietf.org/html/rfc1950#page-4

There don't seem to be unique identifier of the zlib header that would
allow us to tell lto_header apart from zlib, so I don't think I can play
a trick and auto-detect the compression.  As such, I do not think
we can get a header about compression into section w/o breaking
backward compatibility short of inventing our own mallformed zlib
header which we would be sure to be able to tell apart from zlib's.
That would defeat the plan to not increase the section sizes.

I would preffer to go with my current solution until we make a new
"major major" revision of the format where we will have a chance
to drop all this and cleanup other design mistakes of the original
LTO format.

Honza

[Bug fortran/68864] [6 Regression] ICE: in gfc_get_descriptor_dimension, at fortran/trans-array.c:268

[pault at gcc dot gnu.org]

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

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  ---
Created attachment 37010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37010=edit
Fix for the PR

The attached fixes the problem and bootstraps and regtests OK on FC21/x86_64.

Before committing, I want to understand better why the problem is occurring. It
is associated with the finalization routines but I cannot see why at the
moment.

That said, it is obvious that an ARRAY_TYPE should not be sent to any of the
functions that handle descriptors and that this fix cannot do any harm.

Cheers

Paul

PS this makes a nice change from PR54070, where I have a fix for all the
testcase but which fails at any level of optimization :-)

Re: Do not decompress functions sections when copying them to ltrans

[Richard Biener]

On December 12, 2015 7:47:39 PM GMT+01:00, Jan Hubicka  wrote:
>> > So would the patch be a lot more difficult if you go down either of
>> > the routes above?  (I think I prefer changing lto_header rather
>> > than making main_size a bitfield)
>> 
>> Agreed ;)
>Hmm, actually it seems things are difficult. All the headers are
>already compressed
>by zlib:
>Contents of section .gnu.lto_.inline.faa6142d1fc0c505:
>  789c6362 6062c006 10a2 ba0007x.cb`b. 
>Contents of section .gnu.lto_.symbol_nodes.faa6142d1fc0c505:
>  789c6362 6062e060 80025606 06f67a06  x.cb`b.`..V...z.
> 0010 0600029c 0098..  
>Contents of section .gnu.lto_.refs.faa6142d1fc0c505:
>  789c6362 60626064 8002 460006x.cb`b`dF.. 
>Contents of section .gnu.lto_.decls.faa6142d1fc0c505:
>  789c6362 6062d060 6060f80f 0461405a  x.cb`b.```...a@Z
> 0010 10881981 d88e0115 80c496a2 8929312c  .)1,
> 0020 6c5870e0 c1d2291c 131a1b1b feffaf4f  lXp...)O
> 0030 6464e104 9ac7cec8 a0c5b0b2 a1a16142  ddaB
> 0040 43c32336 142d118c 898c7c9c 0c0a6006  C.#6.-|...`.
> 0050 0f27030b 58349171 1923135c 0d4b895e  .'..X4.q.#.\.K.^
> 0060 32037359 620e9bbb 5fa88233 0300a167  2.sYb..._..3...g
> 0070 1a7f ..  
>Contents of section .gnu.lto_.symtab.faa6142d1fc0c505:
>  76616c00 00040004  00a5  val.
>0010 00   ...  
>   
>Contents of section .gnu.lto_.opts:
>   
> 272d6d74 756e653d 67656e65 72696327  '-mtune=generic' 
>   
>0010 20272d6d 61726368 3d783836 2d363427   '-march=x86-64' 
>   
>0020 20272d66 6c746f27 00  '-flto'.
>   
>Contents of section .comment:  
>   
> 00474343 3a202853 55534520 4c696e75  .GCC: (SUSE Linu 
>   
>0010 78292034 2e382e33 20323031 34303632  x) 4.8.3 2014062 
>   
> 0020 37205b67 63632d34 5f382d62 72616e63  7 [gcc-4_8-branc
> 0030 68207265 76697369 6f6e2032 31323036  h revision 21206
> 0040 345d00   4]. 
>
>as you can see only opts/comment and symtab sections come out
>decompressed.
>The sequence x.cb`b is zlib's header.  The description is here:
>https://tools.ietf.org/html/rfc1950#page-4
>
>There don't seem to be unique identifier of the zlib header that would
>allow us to tell lto_header apart from zlib, so I don't think I can
>play
>a trick and auto-detect the compression.  As such, I do not think
>we can get a header about compression into section w/o breaking
>backward compatibility short of inventing our own mallformed zlib
>header which we would be sure to be able to tell apart from zlib's.
>That would defeat the plan to not increase the section sizes.

Aww, yeah.  Now I remember.

>I would preffer to go with my current solution until we make a new
>"major major" revision of the format where we will have a chance
>to drop all this and cleanup other design mistakes of the original
>LTO format.

OK...

Richard.

>
>Honza

[Bug fortran/68744] FAIL: gfortran.dg/backtrace_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #7 from John David Anglin  ---
Created attachment 37012
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37012=edit
Patch

I don't expect this to work but it points at the problem.  The call to
backtrace_create_state() assumes threaded code.  backtrace_create_state()
returns NULL if HAVE_SYNC_FUNCTIONS is not defined.

[Bug middle-end/68878] [6 Regression] 471.omnetpp in SPEC CPU 2006 is miscompiled with LTO

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-13
 CC||miyuki at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Mikhail Maltsev  ---
Confirmed. I checked r231437, and it seems to be OK. "transparent_alias" is not
present in dumps (neither in bad revision, nor in good one). Here are some
dumps, which, I think, show the problem.

[Bug middle-end/68878] [6 Regression] 471.omnetpp in SPEC CPU 2006 is miscompiled with LTO

[miyuki at gcc dot gnu.org]

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

--- Comment #3 from Mikhail Maltsev  ---
Created attachment 37013
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37013=edit
cSimpleModule ctor before transformation - good revision

[Bug middle-end/68878] [6 Regression] 471.omnetpp in SPEC CPU 2006 is miscompiled with LTO

[miyuki at gcc dot gnu.org]

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

--- Comment #4 from Mikhail Maltsev  ---
Created attachment 37014
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37014=edit
cSimpleModule ctor after transformation - good revision

[Bug middle-end/68878] [6 Regression] 471.omnetpp in SPEC CPU 2006 is miscompiled with LTO

[miyuki at gcc dot gnu.org]

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

--- Comment #5 from Mikhail Maltsev  ---
Created attachment 37015
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37015=edit
cSimpleModule ctor before transformation - bad revision

Almost identical to "good revision"

[Bug middle-end/68878] [6 Regression] 471.omnetpp in SPEC CPU 2006 is miscompiled with LTO

[miyuki at gcc dot gnu.org]

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

--- Comment #6 from Mikhail Maltsev  ---
Created attachment 37016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37016=edit
cSimpleModule ctor after transformation - bad revision

Note that lots of code is removed and we fall through BB4 to an EH landing pad
(hence, _Unwind_Resume in the backtrace).

[Bug middle-end/68878] [6 Regression] 471.omnetpp in SPEC CPU 2006 is miscompiled with LTO

[hubicka at ucw dot cz]

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

--- Comment #7 from Jan Hubicka  ---
Looks like a result of redirection to builtin_unreachable.  Can you check the
WPA dumps if there
is difference in redirections, please?

Honza

[Bug tree-optimization/68743] [6 Regression] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #12 from John David Anglin  ---
libtool: compile:  /test/gnu/gcc/objdir/./gcc/xgcc
-B/test/gnu/gcc/objdir/./gcc/
 -B/opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/bin/
-B/opt/gnu64/gcc/gcc-6/hppa64-h
p-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/include
-isys
tem /opt/gnu64/gcc/gcc-6/hppa64-hp-hpux11.11/sys-include -DHAVE_CONFIG_H -I.
-I.
./../../gcc/libgfortran -iquote../../../gcc/libgfortran/io
-I../../../gcc/libgfo
rtran/../gcc -I../../../gcc/libgfortran/../gcc/config
-I../../../gcc/libgfortran
/../libquadmath -I../.././gcc -I../../../gcc/libgfortran/../libgcc -I../libgcc
-
I../../../gcc/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace
-s
td=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-
Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla
-fcx-fo
rtran-rules -ffunction-sections -fdata-sections -g -O2 -MT c99_functions.lo -MD 
-MP -MF .deps/c99_functions.Tpo -c
../../../gcc/libgfortran/intrinsics/c99_funct
ions.c -o c99_functions.o >/dev/null 2>&1

[SPARC] Enable wide-int support

[Eric Botcazou]

On the heels of s390, this enables wide-int support in the SPARC back-end and 
removes all the obsolete code conditionalized on HOST_BITS_PER_WIDE_INT == 32.

Boostrapped/regtested on SPARC/Solaris, applied on the mainline.


2015-12-12  Eric Botcazou  

* config/sparc/sparc.h (TARGET_SUPPORTS_WIDE_INT): Define to 1.
* config/sparc/sparc.c (sparc_emit_set_const64): Remove code
conditionalized on HOST_BITS_PER_WIDE_INT == 32.
(sparc_cannot_force_const_mem) : New case.
: Remove VOIDmode test.
(epilogue_renumber) : New case.
(sparc_print_operand): Remove support for CONST_DOUBLE with VOIDmode.
(sparc_assemble_integer): Likewise.
(set_extends): Likewise.
(sparc_rtx_costs) : Use SMALL_INT.
: New case.
: Remove support for VOIDmode.
: Remove support for CONST_DOUBLE with VOIDmode.
* config/sparc/predicates.md (const_zero_operand): Add const_wide_int.
(const_all_ones_operand): Likewise.
(uns_small_int_operand): Remove const_double and code conditionalized
on HOST_BITS_PER_WIDE_INT == 32.
(arith_double_operand): Likewise.
(arith_double_add_operand): Likewise.
(input_operand): Remove support for CONST_DOUBLE with DImode.
* config/sparc/sparc.md (DImode CONST_INT splitter): Remove code
conditionalized on HOST_BITS_PER_WIDE_INT == 32.
(DFmode CONST_DOUBLE splitter): Likewise.
(*adddi3_insn_sp32): Likewise.
(*subdi3_insn_sp32): Likewise.
(DImode logical splitter): Likewise.
(DImode CONST_DOUBLE splitter): Delete.

-- 
Eric BotcazouIndex: config/sparc/predicates.md
===
--- config/sparc/predicates.md	(revision 231562)
+++ config/sparc/predicates.md	(working copy)
@@ -21,13 +21,12 @@
 
 ;; Return true if OP is the zero constant for MODE.
 (define_predicate "const_zero_operand"
-  (and (match_code "const_int,const_double,const_vector")
+  (and (match_code "const_int,const_wide_int,const_double,const_vector")
(match_test "op == CONST0_RTX (mode)")))
 
-;; Return true if the integer representation of OP is
-;; all-ones.
+;; Return true if the integer representation of OP is all ones.
 (define_predicate "const_all_ones_operand"
-  (and (match_code "const_int,const_double,const_vector")
+  (and (match_code "const_int,const_wide_int,const_double,const_vector")
(match_test "INTEGRAL_MODE_P (GET_MODE (op))")
(match_test "op == CONSTM1_RTX (GET_MODE (op))")))
 
@@ -47,20 +46,10 @@ (define_predicate "small_int_operand"
 ;; instruction sign-extends immediate values just like all other SPARC
 ;; instructions, but interprets the extended result as an unsigned number.
 (define_predicate "uns_small_int_operand"
-  (match_code "const_int,const_double")
-{
-#if HOST_BITS_PER_WIDE_INT == 32
-  return ((GET_CODE (op) == CONST_INT && (unsigned) INTVAL (op) < 0x1000)
-	  || (GET_CODE (op) == CONST_DOUBLE
-	  && CONST_DOUBLE_HIGH (op) == 0
-	  && (unsigned) CONST_DOUBLE_LOW (op) - 0xF000 < 0x1000));
-#else
-  return (GET_CODE (op) == CONST_INT
-	  && ((INTVAL (op) >= 0 && INTVAL (op) < 0x1000)
-	  || (INTVAL (op) >= 0xF000
-  && INTVAL (op) <= 0x)));
-#endif
-})
+  (and (match_code "const_int")
+   (match_test "((INTVAL (op) >= 0 && INTVAL (op) < 0x1000)
+		|| (INTVAL (op) >= 0xF000
+			&& INTVAL (op) <= 0x))")))
 
 ;; Return true if OP is a constant that can be loaded by the sethi instruction.
 ;; The first test avoids emitting sethi to load zero for example.
@@ -308,7 +297,7 @@ (define_predicate "arith_operand"
 ;; representable by a couple of 13-bit signed fields.  This is an
 ;; acceptable operand for most 3-address splitters.
 (define_predicate "arith_double_operand"
-  (match_code "const_int,const_double,reg,subreg")
+  (match_code "const_int,reg,subreg")
 {
   bool arith_simple_operand = arith_operand (op, mode);
   HOST_WIDE_INT m1, m2;
@@ -316,17 +305,11 @@ (define_predicate "arith_double_operand"
   if (TARGET_ARCH64 || arith_simple_operand)
 return arith_simple_operand;
 
-#if HOST_BITS_PER_WIDE_INT == 32
-  if (GET_CODE (op) != CONST_DOUBLE)
-return false;
-  m1 = CONST_DOUBLE_LOW (op);
-  m2 = CONST_DOUBLE_HIGH (op);
-#else
   if (GET_CODE (op) != CONST_INT)
 return false;
+
   m1 = trunc_int_for_mode (INTVAL (op), SImode);
   m2 = trunc_int_for_mode (INTVAL (op) >> 32, SImode);
-#endif
 
   return SPARC_SIMM13_P (m1) && SPARC_SIMM13_P (m2);
 })
@@ -338,11 +321,9 @@ (define_predicate "arith_add_operand"
 
 ;; Return true if OP is suitable as second double operand for add/sub.
 (define_predicate "arith_double_add_operand"
-  (match_code "const_int,const_double,reg,subreg")
+  (match_code "const_int,reg,subreg")
 {
-  bool _arith_double_operand = arith_double_operand (op, mode);
-
-  if (_arith_double_operand)
+  if 

[Bug fortran/68743] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #4 from dave.anglin at bell dot net ---
On 2015-12-12, at 3:50 PM, dominiq at lps dot ens.fr wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68743
> 
> --- Comment #3 from Dominique d'Humieres  ---
>> Program received signal SIGSEGV, Segmentation fault.
>> floorf (x=42.708, 
>>x@entry=> (257).>)
>> at ../../../gcc/libgfortran/intrinsics/c99_functions.c:293
> 
> AFAIU
> 
> #ifndef HAVE_FLOORF
> #define HAVE_FLOORF 1
> float floorf (float x);
> 
> float
> floorf (float x)
> {
>  return (float) floor (x);
> }
> #endif
> 
> it means that HAVE_FLOORF is not defined. Do you see that in your
> libgfortran/config.log?


Yes.  The puzzle is why "return (float) floor (x);" calls floorf.

--
John David Anglin   dave.ang...@bell.net

[Bug tree-optimization/67781] [5/6 Regression] wrong code generated on big-endian with -O1 -fexpensive-optimizations

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|mips-linux; powerpc-linux   |m68k-*-* mips-*-*
   ||powerpc-*-* sparc-*-*
 CC||ebotcazou at gcc dot gnu.org
Summary|[5/6 Regression] Wrong code |[5/6 Regression] wrong code
   |generated on mips32 with|generated on big-endian
   |-O1 |with -O1
   |-fexpensive-optimizations   |-fexpensive-optimizations
   Severity|critical|major

[Bug tree-optimization/68743] [6 Regression] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

  Component|fortran |tree-optimization
Summary|FAIL:   |[6 Regression] FAIL:
   |gfortran.dg/aint_anint_1.f9 |gfortran.dg/aint_anint_1.f9
   |0   -O0  execution test |0   -O0  execution test

--- Comment #7 from John David Anglin  ---
The floorf function in c99_runtime.c is incorrectly compiled.

[Bug fortran/68747] FAIL: gfortran.dg/specifics_1.f90 -O0 execution test

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> Duplicate of pr68743?

Ping!

[Bug fortran/68748] FAIL: gfortran.dg/g77/20010430.f -O0 execution test

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> Duplicate of pr68743?

Ping!

[Bug fortran/68744] FAIL: gfortran.dg/backtrace_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  ---
(gdb) r
Starting program: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/backtrace_1.exe 
warning: Private mapping of shared library text was not specified
by the executable; setting a breakpoint in a shared library which
is not privately mapped will not work.  See the HP-UX 11i v3 chatr
manpage for methods to privately map shared library text.

Could not print backtrace: backtrace library does not support threads

Program received signal SIGSEGV, Segmentation fault.
backtrace_alloc (state=state@entry=0x0, size=size@entry=4096, 
error_callback=error_callback@entry=0x0, data=data@entry=0x0)
at ../../../gcc/libbacktrace/mmap.c:102
102   if (!state->threaded)
(gdb) p state
$1 = (struct backtrace_state *) 0x0
(gdb) bt
#0  backtrace_alloc (state=state@entry=0x0, size=size@entry=4096, 
error_callback=error_callback@entry=0x0, data=data@entry=0x0)
at ../../../gcc/libbacktrace/mmap.c:102
#1  0xc03438b0 in backtrace_full (state=state@entry=0x0, 
skip=skip@entry=0, 
callback=callback@entry=0xc0347380 , 
error_callback=error_callback@entry=0x83fffdfdce70, 
data=data@entry=0x83fffdff0ba8)
at ../../../gcc/libbacktrace/backtrace.c:118
#2  0xc03477e8 in _gfortrani_show_backtrace (
in_signal_handler=in_signal_handler@entry=false)
at ../../../gcc/libgfortran/runtime/backtrace.c:156
#3  0xc0347864 in _gfortran_backtrace ()
at ../../../gcc/libgfortran/runtime/backtrace.c:172
#4  0x40002bc0 in test ()
at /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/backtrace_1.f90:8
#5  0x40002c58 in main (argc=-2147482625, 
argv=0xc0347380 )
at /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/backtrace_1.f90:10

[Bug fortran/68746] FAIL: gfortran.dg/read_dir.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
Looks like but this one is hard to debug with gdb.

[PATCH] Fix PR c++/21802 (two-stage name lookup fails for operators)

[Patrick Palka]

On Fri, 11 Dec 2015, Jason Merrill wrote:

> On 12/11/2015 02:43 PM, Patrick Palka wrote:
>> +  if (processing_template_decl
>> +  && result != NULL_TREE
>> +  && result != error_mark_node
>> +  && DECL_HIDDEN_FRIEND_P (cand->fn))
>> +{
>> +  tree call = result;
>> +  if (REFERENCE_REF_P (call))
>> +call = TREE_OPERAND (call, 0);
>> +  KOENIG_LOOKUP_P (call) = 1;
>> +}
>
> This should have a comment explaining that this prevents
> build_new_function_call from discarding the function.

Consider it done.

>
>> +  if (op == PREINCREMENT_EXPR
>> +  || op == PREDECREMENT_EXPR)
>> +gcc_assert (nargs == 1);
>> +  else if (op == MODOP_EXPR)
>> +gcc_assert (nargs == 2);
>> +  else
>> +gcc_assert (nargs == TREE_CODE_LENGTH (op));
>
> This should use cp_tree_operand_length.

Hmm, I don't immediately see how I can use this function here.  It
expects a tree but I dont have an appropriate tree to give to it, only a
tree_code.  And I can't overload it easily because it calls
TREE_OPERAND_LENGTH which expects a tree as well.

Your pointing out of this function fortunately made me uncover a bug in
my patch: that the function build_min_non_dep_op_overload expects the
wrong number of arguments to an operator[] overload.  It is expecting 4
(i.e. TREE_CODE_LENGTH (ARRAY_REF)) instead of 2.

This should have caused an ICE but it turns out that the test case was
not using the code I added in build_x_array_ref at all, because during
template processing, ARRAY_REFS seem to get processed via
grok_array_decl -- a caller of build_new_op that I had forgotten to
change.

This patch v3 fixes this issue by adjusting the functions
build_min_non_dep_op_overload and grok_array_decl accordingly.  It also
improves the pr53223.C test case to use static_assert and std::is_same<>
to explicitly confirm that the auto types in the test case are correctly
deduced.

gcc/cp/ChangeLog:

PR c++/21802
PR c++/53223
* cp-tree.h (build_min_non_dep_op_overload): Declare.
* tree.c (build_min_non_dep_op_overload): Define.
(build_win_non_dep_call_vec): Copy KOENIG_LOOKUP_P flag.
* typeck.c (build_x_indirect_ref): Use
build_min_non_dep_op_overload when the given expression
has been resolved to an operator overload.
(build_x_binary_op): Likewise.
(build_x_array_ref): Likewise.
(build_x_unary_op): Likewise.
(build_x_compound_expr): Likewise.
(build_x_modify_expr): Likewise.
* decl2.c (grok_array_decl): Likewise.
* call.c (build_new_op_1): If during template processing we
chose an operator overload that is a hidden friend function, set
the call's KOENIG_LOOKUP_P flag to 1.

gcc/testsuite/ChangeLog:

PR c++/21802
PR c++/53223
* g++.dg/cpp0x/pr53223.C: New test.
* g++.dg/lookup/pr21802.C: New test.
* g++.dg/lookup/two-stage4.C: Remove XFAIL.
---
 gcc/cp/call.c|  13 ++
 gcc/cp/cp-tree.h |   1 +
 gcc/cp/decl2.c   |  13 +-
 gcc/cp/tree.c|  67 
 gcc/cp/typeck.c  | 100 ---
 gcc/testsuite/g++.dg/cpp0x/pr53223.C |  45 +
 gcc/testsuite/g++.dg/lookup/pr21802.C| 276 +++
 gcc/testsuite/g++.dg/lookup/two-stage4.C |   2 +-
 8 files changed, 494 insertions(+), 23 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr53223.C
 create mode 100644 gcc/testsuite/g++.dg/lookup/pr21802.C

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 117dd79..cdfa01a 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -5630,6 +5630,19 @@ build_new_op_1 (location_t loc, enum tree_code code, int 
flags, tree arg1,
result = error_mark_node;
  else
result = build_over_call (cand, LOOKUP_NORMAL, complain);
+
+ if (processing_template_decl
+ && result != NULL_TREE
+ && result != error_mark_node
+ && DECL_HIDDEN_FRIEND_P (cand->fn))
+   {
+ tree call = result;
+ if (REFERENCE_REF_P (call))
+   call = TREE_OPERAND (call, 0);
+ /* This prevents build_new_function_call from discarding this
+function during instantiation of the enclosing template.  */
+ KOENIG_LOOKUP_P (call) = 1;
+   }
}
   else
{
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 6190f4e..3487d77 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6513,6 +6513,7 @@ extern tree build_min (enum 
tree_code, tree, ...);
 extern tree build_min_nt_loc   (location_t, enum tree_code,
 ...);
 extern tree build_min_non_dep  (enum tree_code, tree, ...);
+extern tree build_min_non_dep_op_overload  

Re: [PATCH v2] Do not sanitize left shifts for -fwrapv (PR68418)

[Eric Botcazou]

> gcc:
>   PR sanitizer/68418
>   * c-family/c-ubsan.c (ubsan_instrument_shift): Disable
>   sanitization of left shifts for wrapping signed types as well.

That's incorrect, it should be put into c-family/ChangeLog without prefix.

-- 
Eric Botcazou

Re: basic asm and memory clobbers - Proposed solution

[Paul_Koning]

> On Dec 12, 2015, at 4:51 AM, Andrew Haley  wrote:
> 
> ...
> You've missed the most practical solution, which meets most common
> usage: clobber memory, but not registers.  That allows most of the
> effects that people intuitively want and expect, but avoids the
> breakage of register clobbers.  It allows basic asm to be used in a
> sensible way by pushing and popping all used registers.

Yes, that is the solution I would like to see.

paul

[Bug fortran/68743] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #6 from dave.anglin at bell dot net ---
On 2015-12-12, at 4:21 PM, dave.anglin at bell dot net wrote:

>> Yes.  The puzzle is why "return (float) floor (x);" calls floorf.

It comets from the forwprop1 pass:

;; Function floorf (floorf, funcdef_no=15, decl_uid=167, cgraph_uid=107,
symbol_
order=107)

__attribute__((nothrow, leaf, const))
floorf (float x)
{
  double _2;
  double _3;
  float _4;
  float _6;

  :
  _2 = (double) x_1(D);
  _6 = __builtin_floorf (x_1(D));
  _3 = (double) _6;
  _4 = _6;
  return _4;

}

Before that, we have a call to floor.\:

  _2 = (double) x_1(D);

--
John David Anglin   dave.ang...@bell.net

[Bug fortran/68745] FAIL: gfortran.dg/intrinsic_modulo_1.f90 -O0 execution test

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> Duplicate of pr68743?

Ping!

[Bug fortran/68747] FAIL: gfortran.dg/specifics_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from John David Anglin  ---


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

[Bug tree-optimization/68743] [6 Regression] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #10 from John David Anglin  ---
*** Bug 68747 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/68743] [6 Regression] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #11 from John David Anglin  ---
*** Bug 68748 has been marked as a duplicate of this bug. ***

[Bug fortran/68748] FAIL: gfortran.dg/g77/20010430.f -O0 execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from John David Anglin  ---


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

[Bug fortran/68743] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[dave.anglin at bell dot net]

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

--- Comment #5 from dave.anglin at bell dot net ---
On 2015-12-12, at 4:10 PM, dave.anglin at bell dot net wrote:

> Yes.  The puzzle is why "return (float) floor (x);" calls floorf.

floorf:
.PROC
.CALLINFO FRAME=128,CALLS,SAVE_RP,ENTRY_GR=3
.ENTRY
L$VL0024:
std %r2,-16(%r30)
std,ma %r4,128(%r30)
L$CFI0012:
.loc 1 294 0
ldo -48(%r30),%r29
b,l floorf,%r2
nop
L$VL0025:
.loc 1 295 0
ldd -144(%r30),%r2
bve (%r2)
ldd,mb -128(%r30),%r4
.EXIT
.PROCEND
L$FE0015:
.size   floorf, .-floorf

The .i file is okay.

--
John David Anglin   dave.ang...@bell.net

Re: Prune TYPE_FIELDS lists more in free_lang_data

[Jan Hubicka]

> On Fri, 11 Dec 2015, Jan Hubicka wrote:
> 
> > > 
> > > We explicitely do not use debug-info-level tests in free-lang-data
> > > to allow mixing -g and -g0 objects.  Are you sure doing the above
> > > doesn't mess up tree merging enough to effectively enlarge WPA
> > > memory use and the merged decl sections?
> > > 
> > > [I'm quite sure firefox build system manages to mess up -g vs. -g0
> > > in some places ;)]
> > 
> > Hmm, I will try the debug build with firefox on this.  -fdump-ipa-devirt
> > now dumps all main variants that are duplicates of one ODR type.
> > We definitely have types with hundreds of duplicates, so there are
> > quite common cases where tree merging does not fire.
> > > 
> > > > +  return (!DECL_IGNORED_P (decl) && !is_redundant_typedef (decl));
> > > > +}
> > > > +
> > > 
> > > The patch would be ok if you simply export is_redundant_typedef
> > > and inline the DECL_IGNORED_P check into free-lang-data.
> > 
> > OK, I had that originally, will return that back.
> > is_redundant_typedef is declared inline.  Putting it to tree.h drags
> > bit too many dwarf2out internals, but I suppose it is OK to just
> > turn it non-inline.  It is a type of function where inliner should be
> > able to decide.
> 
> Yeah.
Hi,
this is a variant of patch I re-tested (x86_64-linux) and comitted.  I also
double checked that it results in smaller meomry footprint on the -g/-no-g
mixed build of firefox (I built Javascript without debug and rest with).
THe tree merging is affected but not in very significant way.  Hopefully
this will all go early next stage1 with early debug :)

I also noticed that TYPE_DECLs are common in BLOCK_VARs. I will check how
many of them can be shaved off and if that furhter increases partitionability.

The size of largest ltransp partition with this patch and debug shrinks
from 862k trees to 710k trees and for a first time I am aware of we get
both debug and non-debug builds under 3GB of WPA on my firefox tree (that
is from the time GCC 5 was released - I will update it once I get past issues
on this one)

Thanks,
Honza

* tree.c (free_lang_data_in_type, find_decls_types_r): Also free
unnecesary type decls.
* tree.h (is_redundant_typedef): Declare.
* dwarf2out.c (is_redundant_typedef): Export; booleanize
Index: tree.c
===
--- tree.c  (revision 231581)
+++ tree.c  (working copy)
@@ -5191,7 +5191,10 @@ free_lang_data_in_type (tree type)
   while (member)
{
  if (TREE_CODE (member) == FIELD_DECL
- || TREE_CODE (member) == TYPE_DECL)
+ || (TREE_CODE (member) == TYPE_DECL
+ && !DECL_IGNORED_P (member)
+ && debug_info_level > DINFO_LEVEL_TERSE
+ && !is_redundant_typedef (member)))
{
  if (prev)
TREE_CHAIN (prev) = member;
@@ -5216,7 +5219,7 @@ free_lang_data_in_type (tree type)
   /* Remove TYPE_METHODS list.  While it would be nice to keep it
 to enable ODR warnings about different method lists, doing so
 seems to impractically increase size of LTO data streamed.
-Keep the infrmation if TYPE_METHODS was non-NULL. This is used
+Keep the information if TYPE_METHODS was non-NULL. This is used
 by function.c and pretty printers.  */
   if (TYPE_METHODS (type))
 TYPE_METHODS (type) = error_mark_node;
@@ -5666,7 +5669,10 @@ find_decls_types_r (tree *tp, int *ws, v
  while (tem)
{
  if (TREE_CODE (tem) == FIELD_DECL
- || TREE_CODE (tem) == TYPE_DECL)
+ || (TREE_CODE (tem) == TYPE_DECL
+ && !DECL_IGNORED_P (tem)
+ && debug_info_level > DINFO_LEVEL_TERSE
+ && !is_redundant_typedef (tem)))
fld_worklist_push (tem, fld);
  tem = TREE_CHAIN (tem);
}
Index: tree.h
===
--- tree.h  (revision 231581)
+++ tree.h  (working copy)
@@ -5386,6 +5386,7 @@ extern void gt_pch_nx (tree &);
 extern void gt_pch_nx (tree &, gt_pointer_operator, void *);
 
 extern bool nonnull_arg_p (const_tree);
+extern bool is_redundant_typedef (const_tree);
 
 extern location_t
 set_source_range (tree expr, location_t start, location_t finish);
Index: dwarf2out.c
===
--- dwarf2out.c (revision 231581)
+++ dwarf2out.c (working copy)
@@ -3319,7 +3319,6 @@ static void gen_typedef_die (tree, dw_di
 static void gen_type_die (tree, dw_die_ref);
 static void gen_block_die (tree, dw_die_ref);
 static void decls_for_scope (tree, dw_die_ref);
-static inline int is_redundant_typedef (const_tree);
 static bool is_naming_typedef_decl (const_tree);
 static inline dw_die_ref get_context_die (tree);
 static void gen_namespace_die (tree, dw_die_ref);
@@ -21117,11 

[Bug tree-optimization/68743] [6 Regression] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #8 from John David Anglin  ---
Created attachment 37011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37011=edit
Preprocessed source

[Bug tree-optimization/68743] [6 Regression] FAIL: gfortran.dg/aint_anint_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #9 from John David Anglin  ---
*** Bug 68745 has been marked as a duplicate of this bug. ***

[Bug fortran/68745] FAIL: gfortran.dg/intrinsic_modulo_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from John David Anglin  ---


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

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres  ---
For the record with darwin15 I had to add

/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSEnumerator.h
/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h
/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h

from the 10.9 SDK to

/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h
/System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h
/usr/include/objc/NSObject.h

[Bug fortran/68742] FAIL: gfortran.dg/coarray/event_2.f90 -fcoarray=lib -O2 -lcaf_single -latomic execution test

[danglin at gcc dot gnu.org]

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

--- Comment #2 from John David Anglin  ---
(gdb) r
Starting program: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/event_2.exe 
warning: Private mapping of shared library text was not specified
by the executable; setting a breakpoint in a shared library which
is not privately mapped will not work.  See the HP-UX 11i v3 chatr
manpage for methods to privately map shared library text.

Program aborted. Backtrace:

Could not print backtrace: backtrace library does not support threads

Program received signal SIGSEGV, Segmentation fault.
backtrace_alloc (state=state@entry=0x0, size=size@entry=4096, 
error_callback=error_callback@entry=0x0, data=data@entry=0x0)
at ../../../gcc/libbacktrace/mmap.c:102
102   if (!state->threaded)
(gdb) bt
#0  backtrace_alloc (state=state@entry=0x0, size=size@entry=4096, 
error_callback=error_callback@entry=0x0, data=data@entry=0x0)
at ../../../gcc/libbacktrace/mmap.c:102
#1  0xc03438b0 in backtrace_full (state=state@entry=0x0, 
skip=skip@entry=0, 
callback=callback@entry=0xc0347380 , 
error_callback=error_callback@entry=0x83fffdfd8e70, 
data=data@entry=0x83fffdff0bd8)
at ../../../gcc/libbacktrace/backtrace.c:118
#2  0xc03477e8 in _gfortrani_show_backtrace (
in_signal_handler=in_signal_handler@entry=false)
at ../../../gcc/libgfortran/runtime/backtrace.c:156
#3  0xc0348c10 in _gfortrani_sys_abort ()
at ../../../gcc/libgfortran/runtime/error.c:178
#4  0xc041e4a4 in _gfortran_abort ()
at ../../../gcc/libgfortran/intrinsics/abort.c:33
#5  0x40004ad0 in MAIN__ ()
at /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarray/event_2.f90:15
#6  main (argc=, argv=)
at /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarray/event_2.f90:89
(gdb) p state
$1 = (struct backtrace_state *) 0x0

[Bug fortran/68742] FAIL: gfortran.dg/coarray/event_2.f90 -fcoarray=lib -O2 -lcaf_single -latomic execution test

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from John David Anglin  ---


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

[Bug fortran/68744] FAIL: gfortran.dg/backtrace_1.f90 -O0 execution test

[danglin at gcc dot gnu.org]

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

--- Comment #6 from John David Anglin  ---
*** Bug 68742 has been marked as a duplicate of this bug. ***