[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 

[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

[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.

[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.

[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.

[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

[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.

[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.

[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. ***

[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.

[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?

[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 

[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

[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?

[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 :-)

[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

[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.

[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

[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. ***