[Bug tree-optimization/71040] New: [7 Regression] ICE: verify_gimple failed (error: invalid operand in unary operation; error: incorrect sharing of tree nodes) w/ -O3

[asolokha at gmx dot com]

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

Bug ID: 71040
   Summary: [7 Regression] ICE: verify_gimple failed (error:
invalid operand in unary operation; error: incorrect
sharing of tree nodes) w/ -O3
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20160508 ICEs when compiling the following reduced snippet w/
-O3:

struct
{
  int b8 : 24;
} ud, ce;
int et;

void
fo (void);

void
p4 (int pn)
{
  while (et != 0)
{
  short int *uc = (short int *)
  if (pn != 0)
fo ();
  *uc = ce.b8;
  ++et;
}
}


% gcc-7.0.0-alpha20160508 -c -O3 apdexura.c
apdexura.c: In function 'p4':
apdexura.c:11:1: error: invalid operand in unary operation
 p4 (int pn)
 ^~
# VUSE <.MEM_8(D)>
ce_b8_lsm0.5_6 = () MEM[(struct  *)];
apdexura.c:11:1: error: invalid operand in unary operation
apdexura.c:11:1: error: incorrect sharing of tree nodes
MEM[(struct  *)]
# VUSE <.MEM_8(D)>
_23 = (short int) MEM[(struct  *)];
apdexura.c:11:1: internal compiler error: verify_gimple failed

[Bug tree-optimization/71039] New: [7 Regression] ICE: verify_ssa failed (error: definition in block 4 does not dominate use in block 5) w/ -O1 and above

[asolokha at gmx dot com]

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

Bug ID: 71039
   Summary: [7 Regression] ICE: verify_ssa failed (error:
definition in block 4 does not dominate use in block
5) w/ -O1 and above
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20160508 snapshot ICEs when compiling the following reduced
snippet at -O1 and above:

struct wv
{
  int qi;
} qp, *ft;
void *pb;

void
wz (void)
{
  struct wv *vf = pb ? (struct wv *) : 
  *ft = *vf;
}

% x86_64-pc-linux-gnu-gcc-7.0.0-alpha20160508 -c -O1 fo7dullr.c 
fo7dullr.c: In function 'wz':
fo7dullr.c:8:1: error: definition in block 4 does not dominate use in block 5
 wz (void)
 ^~
for SSA_NAME: ft.2_2 in statement:
# .MEM_7 = VDEF <.MEM_4(D)>
*ft.2_2 = MEM[(struct wv *)];
fo7dullr.c:8:1: internal compiler error: verify_ssa failed

[Bug libstdc++/71038] New: copy_file(...) returns false on successful copy.

[eric at efcs dot ca]

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

Bug ID: 71038
   Summary: copy_file(...) returns false on successful copy.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

The title says it all. copy_file always seems to return false.

Example:

#include 
#include 
#include 

using namespace std::experimental::filesystem;

int main() {
std::ofstream out("/tmp/foo.txt");
out << "hello world!\n";
out.close();
const path p = "/tmp/foo.txt";
const path to = "/tmp/bar.txt";
bool ret = copy_file(p, to);
assert(ret == true);
}

[Bug libstdc++/71037] New: Exceptions thrown from "filesystem::canonical(...)" should contain both paths.

[eric at efcs dot ca]

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

Bug ID: 71037
   Summary: Exceptions thrown from "filesystem::canonical(...)"
should contain both paths.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

The filesystem error thrown from canonical only contains the first path, not
the base. Since the base path can be user specified the exception should
contain this as well.

#include 
#include 

using namespace std::experimental::filesystem;

int main() {
  const path p = "DNE"
  const path base = "BASE";
  try {
canonical(p, base);
assert(false);
  } catch (filesystem_error const& err) {
assert(err.path1() == p);
assert(err.path2() == base); // FIRES
  }
}

[Bug libstdc++/71036] New: create_directory(p, ...) reports a failure when 'p' is an existing directory

[eric at efcs dot ca]

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

Bug ID: 71036
   Summary: create_directory(p, ...) reports a failure when 'p' is
an existing directory
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric at efcs dot ca
  Target Milestone: ---

The create_directory functions should not report an error when the directory
they are trying to create already exists. The create_directory(...) functions
seem to report this error.

#include 
#include 

using namespace std::experimental::filesystem;

int main() {
  path p = "/tmp/foo";
  assert(!exists(p));
  create_directory(p); // create the directory once
  create_directory(p); // THROWS!
}

[Bug c++/71035] GNU does not give error on declaration of non literal type in template function

[Judy.Ward at intel dot com]

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

--- Comment #2 from Judy Ward  ---
Yes I have a beta copy of EDG 
4.11 which has relaxed constexpr and they give an error. Unfortunately some
Boost code (I think inadvertently) relies on not giving a diagnostic.

Yes I see your point that this is really a QOI issue but GNU does seem
inconsistent and EDG will have to emulate that inconsistency.

Thanks
Judy

> On May 9, 2016, at 7:38 PM, msebor at gcc dot gnu.org 
>  wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71035
> 
> Martin Sebor  changed:
> 
>   What|Removed |Added
> 
>   Keywords||accepts-invalid
> Status|UNCONFIRMED |NEW
>   Last reconfirmed||2016-05-09
> CC||msebor at gcc dot gnu.org
> Ever confirmed|0   |1
>  Known to fail||4.9.3, 5.3.0, 6.1.0
>   Severity|normal  |enhancement
> 
> --- Comment #1 from Martin Sebor  ---
> Hi Judy!
> 
> I'll take a stab at this -- let me know if I missed something.  I agree that
> similarly to the non-template case, (in the absence of a valid explicit
> specialization) diagnosing the constexpr function template below would be
> useful, even though in p5 and p6 of [dcl.constexpr], the standard leaves both
> cases as a matter of QoI:
> 
> -6-  If the instantiated template specialization of a constexpr function
> template o member function of a class template would fail to satisfy the
> requirements for a constexpr function or constexpr constructor, that
> specialization is still a constexpr function or constexpr constructor, even
> though a call to such a function cannot appear in a constant expression.  If 
> no
> specialization of the template would satisfy the requirements for a constexpr
> function or constexpr constructor when considered as a non-template function 
> or
> constructor, the template is ill-formed; no diagnostic required.
> 
> (I read the last sentence as referring to implicit specializations of the
> template definition, not explicit ones with valid definitions.)
> 
> Thus, I'm inclined to view this bug not as a defect but an enhancement 
> request.
> Let me know if you disagree.
> 
> Clang is more strict than GCC here by issuing the optional diagnostic.
> 
> My copy of EDG (version 4.10) rejects the program because it doesn't fully
> implement the C++ 14 rules: a) it doesn't recognize void as a literal type, 
> and
> b) it doesn't allow statements in constexpr functions.
> 
> -- 
> You are receiving this mail because:
> You reported the bug.

[Bug c/71013] [7 Regression] c-common.c:12810:37: error: 'LLONG_MAX' was not declared in this scope

[danglin at gcc dot gnu.org]

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

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

This fixes build failure on hppa64-hpux.  Not sure its the right place
or even right fix.

[Bug c++/71035] GNU does not give error on declaration of non literal type in template function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-09
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.3.0, 6.1.0
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
Hi Judy!

I'll take a stab at this -- let me know if I missed something.  I agree that
similarly to the non-template case, (in the absence of a valid explicit
specialization) diagnosing the constexpr function template below would be
useful, even though in p5 and p6 of [dcl.constexpr], the standard leaves both
cases as a matter of QoI:

-6-  If the instantiated template specialization of a constexpr function
template o member function of a class template would fail to satisfy the
requirements for a constexpr function or constexpr constructor, that
specialization is still a constexpr function or constexpr constructor, even
though a call to such a function cannot appear in a constant expression.  If no
specialization of the template would satisfy the requirements for a constexpr
function or constexpr constructor when considered as a non-template function or
constructor, the template is ill-formed; no diagnostic required.

(I read the last sentence as referring to implicit specializations of the
template definition, not explicit ones with valid definitions.)

Thus, I'm inclined to view this bug not as a defect but an enhancement request.
 Let me know if you disagree.

Clang is more strict than GCC here by issuing the optional diagnostic.

My copy of EDG (version 4.10) rejects the program because it doesn't fully
implement the C++ 14 rules: a) it doesn't recognize void as a literal type, and
b) it doesn't allow statements in constexpr functions.

[Bug target/68945] enable libcilkrts on SPARC

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
> * In runtime/config/sparc/os-unix-sysdep.c (__cilkrts_getticks) I needed
> different
>   32- and 64-bit versions.  I tested the result in standalone program which
> just
>   printed the result.

This looks good to me.

> * One thing I wonder about is runtime/config/sparc/os-fence.h: when using
>   __sync_synchronize, gcc emits membar #StoreLoad, while Stefan's patch had
>   membar#LoadLoad | #LoadStore | #StoreStore | #StoreLoad.  It seems that
>   all but #StoreLoad are no-ops for TSO SPARC CPUs, but I'd better get this
> right.

__sync_synchronize emits the minimum memory barrier for the memory model, which
is TSO on Solaris so only #StoreLoad is needed.  The 4 flags are needed for RMO
theoretically, but I'm not sure RMO ever existed in real life.

[Bug target/70947] regrename Go breakage on powerpc64

[amodra at gcc dot gnu.org]

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

--- Comment #1 from Alan Modra  ---
Author: amodra
Date: Mon May  9 23:12:20 2016
New Revision: 236052

URL: https://gcc.gnu.org/viewcvs?rev=236052=gcc=rev
Log:
[RS6000] Stop regrename twiddling with split-stack prologue

PR target/70947
* config/rs6000/rs6000.c (rs6000_expand_split_stack_prologue): Stop
regrename modifying insns saving lr before __morestack call.
* config/rs6000/rs6000.md (split_stack_return): Similarly for
insns restoring lr after __morestack call.

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

[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices

[klindsay at ucar dot edu]

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

--- Comment #9 from Keith Lindsay  ---
Harald,

Thanks for your tips on validation/sanitizing tools.

I am not sufficiently fluent in standard-ese to know what 'associated
do-loops(s)" means. It doesn't help that BLOCK and ASSOCIATE appear in other
contexts in the OpenMP standard, making it challenging to locate information
about them in the standard.

If I replace ASSOCIATE with BLOCK/END BLOCK, I do see the same problems.

I added -fdump-tree-original to the gfortran invocation and compiled code with
and without the BLOCK construct. The generated intermediate files have the
difference

@@ -6,7 +6,7 @@
   static integer(kind=4) s_true = 5050;

   s = {};
-  #pragma omp parallel private(i)
+  #pragma omp parallel
 {
   {
 #pragma omp for private(j) nowait

(There are other differences that appear to simply be renaming of labels, I'm
ignoring those.) So it does seem that the presence of the BLOCK construct is
changing how the compiler assigns attributes to the inner loop index. I didn't
think this was correct, but perhaps I'm misunderstanding how the OpenMP and
Fortran standards interact.

At this point, I would like to know if the compiler is in the right in doing
this. If it is, then I would change my coding practice. If it isn't, then I
assume that gfortran developers would want to know about this.

Keith

[Bug fortran/71032] explicit interface and must not have attributes generates gfortran: internal compiler error: Abort trap: 6 (program f951)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-05-09
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
There is no ICE (only normal errors) when compiling the tests with gfortran
6.1.0 and trunk (7.0).

The ICE has been fixed between revisions r223447 (2015-05-20, ICE) and r223694
(2015-05-26, errors), likely r223614 (last patch for pr44054). AFAICT there is
no plan to back port the fix to the gcc-5 branch. Unless someone objects, I'll
close this PR as fixed in the coming days.

[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
OK, there is an obvious bug in the define_expand for vsx_xvcvdpsxds_scale.  If
the scale factor is 0, wrong code is always generated.  I'll get a patch going.

[Bug c++/71035] New: GNU does not give error on declaration of non literal type in template function

[Judy.Ward at intel dot com]

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

Bug ID: 71035
   Summary: GNU does not give error on declaration of non literal
type in template function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Judy.Ward at intel dot com
  Target Milestone: ---

Both EDG and Clang give an error on the code below.

GNU only gives an error if call() is not a template function (see -DERROR
below) or if call() is used in a way that requires it to be constexpr (i.e. in
a static_assert).

I think this should be an error.

struct C
{
   C(); // constructor is not declared constexpr
};

#ifdef ERROR
#else
template 
#endif
constexpr void call()
{
   C c;
}

int main() {
#ifdef ERROR
   call();
#else
   call();
#endif
   return 0;
}

[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
Note also that your asm constraints are wrong.  You need VSX registers, not
Altivec registers, so you should be using the "wa" constraint instead of the
"v" constraint.  This is why you get some apparently wrong register numbers
with your asm results.

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

[seurer at linux dot vnet.ibm.com]

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

--- Comment #9 from Bill Seurer  ---
Systems where I see it fail:
granola
yavin3

Systems where I do not:
bns

All are power7 BE systems.  I didn't do anything special on any of the systems.
 I ran configure like this on all of them:

/home/seurer/gcc/gcc-test/configure --prefix=/home/seurer/gcc/install/gcc-test 
 --enable-languages=c,fortran,c++ --disable-multilib --disable-libsanitizer
--disable-bootstrap

Different compiler versions were used to build on all of the systems.

seurer@bns:~/gcc/build/gcc-test$ $CC --version
gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]

On bns I also tried a bootstrapped gcc 7.0 and the test case still worked
there.

seurer@yavin3:~/gcc/build/gcc-test$ $CC --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)


seurer@granola:~/gcc/build/gcc-test$ $CC --version
gcc (GCC) 5.3.0

[Bug target/70963] vec_cts/vec_ctf intrinsics produce wrong results for 64-bit floating point

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
The xxswapd's are a bit of a red herring.  These are part of the little-endian
normalization code that are required with the funky lxvd2x and stxvd2x
instructions.  The problem appears to be the register assignment on the
instructions generated for vec_cts and vec_ctf.  The use of vs12 on vec_cts is
an obvious problem, since vs12 doesn't contain any value assigned in the
function.  The code for vec_ctf looks fine.  So we need to figure out what
happened with the register number on xvcvdpsxds.

The problem still exists on trunk.

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #30 from Steve Kargl  ---
On Mon, May 09, 2016 at 02:55:01PM +, fritzoreese at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226
> 
> --- Comment #29 from Fritz Reese  ---
> (In reply to Andreas Schwab from comment #25)
> > FAIL: gfortran.dg/dec_union_4.f90   -O0  execution test
> > FAIL: gfortran.dg/dec_union_4.f90   -O1  execution test
> > FAIL: gfortran.dg/dec_union_4.f90   -O2  execution test
> > FAIL: gfortran.dg/dec_union_4.f90   -O3 -fomit-frame-pointer -funroll-loops
> > -fpeel-loops -ftracer -finline-functions  execution test
> > FAIL: gfortran.dg/dec_union_4.f90   -O3 -g  execution test
> > FAIL: gfortran.dg/dec_union_4.f90   -Os  execution test
> 
> It was silly of me to disregard endian-ness in this test case. Fixed:
> 
> https://gcc.gnu.org/ml/fortran/2016-05/msg00018.html
> 

Thanks for the patch.  I'll take care of this on Saturday,
if no one else commits before then.

[Bug tree-optimization/71034] abs(f) u>= 0. is always true

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
(In reply to Andrew Pinski from comment #1)
> I think this is the optimizations that should be done:
> abs(x) < 0 -> x != x

for x=NaN, abs(x) is NaN, and NaN<0 is false. So the current simplification to
false seems correct.

> abs(x) >= 0 -> x u== x

x == x. I'd like to canonicalize it to x ord x, but that's a different issue.

> abs(x) == 0 -> x == 0
> abs(x) <= 0 -> x == 0 (since this is an ordered comparison)

ok

> abs(x) u< 0 -> false
> abs(x) u>= 0 -> false

u<, u>= are true if an argument is NaN... u< can simplify to x unord x, and u>=
is always true.

> abs(x) u== 0 -> x == 0

x u== 0

[Bug tree-optimization/71034] abs(f) u>= 0. is always true

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think this is the optimizations that should be done:
abs(x) < 0 -> x != x
abs(x) >= 0 -> x u== x
abs(x) == 0 -> x == 0
abs(x) <= 0 -> x == 0 (since this is an ordered comparison)
abs(x) u< 0 -> false
abs(x) u>= 0 -> false
abs(x) u== 0 -> x == 0

 I Hope I did not mess this up and got the unordered comparisons correct.

[Bug tree-optimization/71034] New: abs(f) u>= 0. is always true

[glisse at gcc dot gnu.org]

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

Bug ID: 71034
   Summary: abs(f) u>= 0. is always true
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

A very simple missed optimization, we optimize abs(x)<0 to false (in forwprop,
haven't found the exact place yet) but not abs(x) u>= 0 to true. I noticed it
because cdce now produces this comparison for sqrt, which causes a small
regression on a dead sqrt(abs(x)).

int f(double x){
  x=__builtin_fabs(x);
  // return x<0;
  return !__builtin_isless(x,0);
}

[Bug middle-end/70988] missing buffer overflow detection in chained strcat calls

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|missing buffer overflow |missing buffer overflow
   |warning on chained strcat   |detection in chained strcat
   |calls   |calls
  Known to fail||4.5.3, 4.8.3, 4.9.3, 5.3.0,
   ||6.1.0

--- Comment #1 from Martin Sebor  ---
Furthermore, in cases where GCC does optimize multiple chained strcat calls
into calls to __builtin_memcpy (which are then expanded into inline assembly)
as in the test case below, it fails to add the instrumentation necessary to
detect the buffer overflow.

$ cat xxx.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -D_FORTIFY_SOURCE=2 -O2 -S -Wall -Wextra
-Wpedantic -fdump-tree-optimized=/dev/stdout xxx.c && ./a.out 
#include 

void  __attribute__ ((noclone, noinline))
f (const char *s)
{
  __builtin_printf ("\"%s\"\n", s);
}

void  __attribute__ ((noclone, noinline))
g (void)
{
  char a [4] = "";
  strcat (a, "abc");
  strcat (a, "def");
  strcat (a, "ghi");
  strcat (a, "jkl");
  f (a);
}

int main ()
{
  g ();
}

;; Function f (f, funcdef_no=24, decl_uid=2214, cgraph_uid=24, symbol_order=24)

__attribute__((noinline, noclone))
f (const char * s)
{
  :
  __builtin_printf ("\"%s\"\n", s_2(D)); [tail call]
  return;

}



;; Function g (g, funcdef_no=25, decl_uid=2217, cgraph_uid=25, symbol_order=25)

__attribute__((noinline, noclone))
g ()
{
  char a[4];

  :
  MEM[(char * {ref-all})] = "abc";
  __builtin_memcpy ([(void *) + 3B], "def", 4);
  __builtin_memcpy ([(void *) + 6B], "ghi", 4);
  __builtin_memcpy ([(void *) + 9B], "jkl", 4);
  f ();
  a ={v} {CLOBBER};
  return;

}



;; Function main (main, funcdef_no=26, decl_uid=2220, cgraph_uid=26,
symbol_order=26) (executed once)

main ()
{
  :
  g ();
  return 0;

}


"�@abcdef"

[Bug middle-end/70626] bogus results in 'acc parallel loop' reductions

[cesar at gcc dot gnu.org]

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

--- Comment #6 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Mon May  9 20:42:47 2016
New Revision: 236049

URL: https://gcc.gnu.org/viewcvs?rev=236049=gcc=rev
Log:
Backport trunk r235651:
2016-04-29  Cesar Philippidis  

gcc/c-family/
PR middle-end/70626
* c-common.h (c_oacc_split_loop_clauses): Add boolean argument.
* c-omp.c (c_oacc_split_loop_clauses): Use it to duplicate
reduction clauses in acc parallel loops.

gcc/c/
PR middle-end/70626
* c-parser.c (c_parser_oacc_loop): Don't augment mask with
OACC_LOOP_CLAUSE_MASK.
(c_parser_oacc_kernels_parallel): Update call to
c_oacc_split_loop_clauses.

gcc/cp/
PR middle-end/70626
* parser.c (cp_parser_oacc_loop): Don't augment mask with
OACC_LOOP_CLAUSE_MASK.
(cp_parser_oacc_kernels_parallel): Update call to
c_oacc_split_loop_clauses.

gcc/fortran/
PR middle-end/70626
* trans-openmp.c (gfc_trans_oacc_combined_directive): Duplicate
the reduction clause in both parallel and loop directives.

gcc/testsuite/
PR middle-end/70626
* c-c++-common/goacc/combined-reduction.c: New test.
* gfortran.dg/goacc/reduction-2.f95: Add check for kernels reductions.

libgomp/
PR middle-end/70626
* testsuite/libgomp.oacc-c++/template-reduction.C: Adjust test.
* testsuite/libgomp.oacc-c-c++-common/combined-reduction.c: New test.
* testsuite/libgomp.oacc-fortran/combined-reduction.f90: New test.


Added:
   
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/combined-reduction.c
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/goacc/pr70688.c
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/combined-reduction.c
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-fortran/combined-reduction.f90
Modified:
branches/gomp-4_0-branch/gcc/c-family/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/c-family/c-common.h
branches/gomp-4_0-branch/gcc/c-family/c-omp.c
branches/gomp-4_0-branch/gcc/c/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/c/c-parser.c
branches/gomp-4_0-branch/gcc/cp/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/cp/parser.c
branches/gomp-4_0-branch/gcc/cp/semantics.c
branches/gomp-4_0-branch/gcc/fortran/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/fortran/gfortran.h
branches/gomp-4_0-branch/gcc/fortran/match.c
branches/gomp-4_0-branch/gcc/fortran/trans-openmp.c
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp
   
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/combined-directives.f90
branches/gomp-4_0-branch/gcc/testsuite/gfortran.dg/goacc/reduction-2.f95
   
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.oacc-c++/template-reduction.C

[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices

[anlauf at gmx dot de]

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

--- Comment #8 from Harald Anlauf  ---
(In reply to Keith Lindsay from comment #6)
> Harald,
> 
> The problem does go away if I add a PRIVATE(i) clause to the OMP directive.
> 
> However, my understanding of OpenMP in fortran is that all loop iteration
> variables, even inner nested loops, in an OpenMP PARALLEL DO construct (and
> some others) are private by default. I.e., they do not need to be declared
> private in the OMP directive. (I think this specification is different than
> the specification for inner loops in C.)

The OpenMP 4.5 standard says (2.15.1.1, for Fortran):

- The loop iteration variable(s) in the associated do-loop(s) of a do,
  parallel do, taskloop, or distribute construct is (are) private.
[...]
- A loop iteration variable for a sequential loop in a parallel or task
  generating construct is private in the innermost such construct that
  encloses the loop.
[...]

Now the question is: what are the "associated do-loop(s)"?  And
what exactly does the second item above mean?

I'm not too versed in reading the standard, and I tend to be on the
conservative side here and interpret the ASSOCIATE construct to
generate something like a BLOCK that makes things interesting, so
that the i loop is to be dealt with separately.  (I usually declare
all loop variables explicitly.)

What do you get when replacing ASSOCIATE by BLOCK/END BLOCK?
I'd expect you experience the same problem.

> Indeed, if I comment out the associate construct, the problem goes away. So
> I'm inferring that the associate construct is interfering with the inner
> loop index being assigned the private attribute.
> 
> Keith

I would recommend to always validate OpenMP parallelized code under
some suitable tool, like valgrind/helgrind, gcc/thread-sanitizer, or
Intel Inspector.  Don't rely on just running your code.

(I get a possible data race when running your original code under
valgrind with gfortran and ifort, and a cross-thread stack access
with ifort/Intel Inspector for the line doing the accumulation.
However, I also get this for the fixed code.)

If you need more insight on what gfortran is doing, add the option
"-fdump-tree-original" and compare the resulting intermediate files
*.003t.original.

[Bug c++/69363] ICE when doing a pragma simd reduction with max

[cesar at gcc dot gnu.org]

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

--- Comment #8 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Mon May  9 20:23:31 2016
New Revision: 236047

URL: https://gcc.gnu.org/viewcvs?rev=236047=gcc=rev
Log:
Backport trunk r235290:
2016-04-20  Ilya Verbin  

gcc/c-family/
PR c++/69363
* c-cilkplus.c (c_finish_cilk_clauses): Remove function.
* c-common.h (c_finish_cilk_clauses): Remove declaration.

gcc/c/
PR c++/69363
* c-parser.c (c_parser_cilk_all_clauses): Use c_finish_omp_clauses
instead of c_finish_cilk_clauses.
* c-tree.h (c_finish_omp_clauses): Add new default argument.
* c-typeck.c (c_finish_omp_clauses): Add new argument.  Allow
floating-point variables in the linear clause for Cilk Plus.

gcc/cp/
PR c++/69363
* cp-tree.h (finish_omp_clauses): Add new default argument.
* parser.c (cp_parser_cilk_simd_all_clauses): Use finish_omp_clauses
instead of c_finish_cilk_clauses.
* semantics.c (finish_omp_clauses): Add new argument.  Allow
floating-point variables in the linear clause for Cilk Plus.

gcc/testsuite/
PR c++/69363
* c-c++-common/cilk-plus/PS/clauses3.c: Adjust dg-error string.
* c-c++-common/cilk-plus/PS/clauses4.c: New test.
* c-c++-common/cilk-plus/PS/pr69363.c: New test.


Added:
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/cilk-plus/PS/clauses4.c
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/cilk-plus/PS/pr69363.c
Modified:
branches/gomp-4_0-branch/gcc/c-family/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/c-family/c-cilkplus.c
branches/gomp-4_0-branch/gcc/c-family/c-common.h
branches/gomp-4_0-branch/gcc/c/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/c/c-parser.c
branches/gomp-4_0-branch/gcc/c/c-tree.h
branches/gomp-4_0-branch/gcc/c/c-typeck.c
branches/gomp-4_0-branch/gcc/cp/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/cp/cp-tree.h
branches/gomp-4_0-branch/gcc/cp/parser.c
branches/gomp-4_0-branch/gcc/cp/semantics.c
branches/gomp-4_0-branch/gcc/testsuite/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/testsuite/c-c++-common/cilk-plus/PS/clauses3.c

[Bug c/71033] Segmentation fault c + intel assembly, unable to use EBX

[formateu at gmail dot com]

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

Mateusz Forc  changed:

   What|Removed |Added

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

--- Comment #2 from Mateusz Forc  ---
(In reply to Uroš Bizjak from comment #1)
> x86 ABI requires that %ebx is preserved across function call. So, you need
> to save it to stack in f.s and restore it before function returs. Or, you
> can use %edx instead, which can be clobbered in function.

[Bug fortran/71027] -fsanitize=address catches out of bounds access on assumed size array only with -O0

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
Yes, you are right, and probably in real programs the subroutine would
not be optimized away.
Thank you for the explanation.

[Bug c/71033] Segmentation fault c + intel assembly, unable to use EBX

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
x86 ABI requires that %ebx is preserved across function call. So, you need to
save it to stack in f.s and restore it before function returs. Or, you can use
%edx instead, which can be clobbered in function.

[Bug c/71033] New: Segmentation fault c + intel assembly, unable to use EBX

[formateu at gmail dot com]

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

Bug ID: 71033
   Summary: Segmentation fault c + intel assembly, unable to use
EBX
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: formateu at gmail dot com
  Target Milestone: ---

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

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 6.1.1 20160501 (GCC) 


Program runs intel x86 assembly function in main. Use of the EBX register
inside that function causes segmentation fault (after return from function).
It seems like gcc is using EBX instead of EBP before function call.
Program compiled using clang works properly.
Bug was noticed firstly on gcc 5.3.0 version, but is still present on latest
repository version.

Used makefile:

CC=gcc
CFLAGS= -Wall -m32 -O0 -save-temps

all: main.o f.o
 $(CC) $(CFLAGS) main.o f.o -o fun

main.o: main.c
  $(CC) $(CFLAGS) -c main.c -o main.o


command : make && ./fun 2


f.o: f.s
  nasm -f elf -g f.s -o f.o

main.c :
#include "f.h" //only void f(char*)

int main(int argc, char *argv[])
{
  if(argc < 2) {
return 1;
  }

  f(argv[1]);

  return 0;
}

f.s :
;f.i is not generated

  section .text
  global f
f:
  push ebp
  mov ebp, esp
  mov eax, [ebp+8]
  mov ebx, 9
begin:
  mov cl, [eax]
  cmp cl, 0 
  jz end
  add cl, 1
  mov [eax], cl
  inc eax
  jmp begin
end:
  mov esp, ebp
  pop ebp
  ret

[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices

[klindsay at ucar dot edu]

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

--- Comment #7 from Keith Lindsay  ---
The Linux system that I'm working on has multiple versions of gcc/gfortran
installed. I've compiled and run my example program with different versions and
have found the following:

Versions 4.9.0, 4.9.1, 4.9.2, 4.9.3, 5.0.1, 5.1.0
Program, as is, works (i.e. no reported mismatches over 10 runs)

Versions 5.2.0, 5.3.0, 6.0.1, 6.1.0
Program, as is, reports mismatches (and sometimes hangs)

So it seems like the behavior I'm seeing originated in 5.2.0.

[Bug fortran/71032] New: explicit interface and must not have attributes generates gfortran: internal compiler error: Abort trap: 6 (program f951)

[kendrick.killian at colostate dot edu]

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

Bug ID: 71032
   Summary: explicit interface and must not have attributes
generates gfortran: internal compiler error: Abort
trap: 6 (program f951)
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kendrick.killian at colostate dot edu
  Target Milestone: ---

Created attachment 38458
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38458=edit
source file that generates f951 Segmentation fault

I had a routine that typed a function and declared it as external. I added the
function as an "contains" routine. An obvious over specification. The compiler
issued the
error message, Procedure ... has an explicit interface and must not have
attributes declared
 the following error messages:
---
---

GCC VERSION:
gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/gfortran/libexec/gcc/x86_64-apple-darwin14/5.2.0/lto-wrapper
Target: x86_64-apple-darwin14
Configured with: ../gcc-5.2.0/configure --prefix=/usr/local/gfortran
--with-gmp=/Users/fx/devel/gcc/deps-static/x86_64
--enable-languages=c,c++,fortran,objc,obj-c++ --build=x86_64-apple-darwin14
Thread model: posix
gcc version 5.2.0 (GCC) 

system type:
  Model Name:   MacBook Pro
  Model Identifier: MacBookPro8,2
  Processor Name:   Intel Core i7
  System Version:   OS X 10.11.4 (15E65)
  Kernel Version:   Darwin 15.4.0
  Developer Tools:
Version:7.3.1 (7D1014)
Location:   /Applications/Xcode.app

Compile Command:
gfortran -O3  -fno-underscoring -Wunused -Waliasing -Wampersand -Wsurprising
-Wno-tabs  -c internalerr.f90


compiler output:
catanf.f:5.28:
Included at internalerr.f90:40:

  real function carctanf(x,a,b,c,d)
1
internalerr.f90:25.39:

  real agdrat, bgdrat, carctanf
   2
Error: Procedure 'carctanf' at (1) has an explicit interface and must not have
attributes declared at (2)
f951: internal compiler error: Segmentation fault: 11

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


Files:
Sorry I don't know where preprocessed file (*.i*) is
The short attached source file generate the error.

[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices

[klindsay at ucar dot edu]

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

--- Comment #6 from Keith Lindsay  ---
Harald,

The problem does go away if I add a PRIVATE(i) clause to the OMP directive.

However, my understanding of OpenMP in fortran is that all loop iteration
variables, even inner nested loops, in an OpenMP PARALLEL DO construct (and
some others) are private by default. I.e., they do not need to be declared
private in the OMP directive. (I think this specification is different than the
specification for inner loops in C.)

Indeed, if I comment out the associate construct, the problem goes away. So I'm
inferring that the associate construct is interfering with the inner loop index
being assigned the private attribute.

Keith

[Bug c/71030] Strange segmentation fault

[formateu at gmail dot com]

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

Mateusz Forc  changed:

   What|Removed |Added

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

[Bug tree-optimization/71031] New: [7 Regression] ICE in extract_range_from_binary_expr_1, at tree-vrp.c:2535 w/ -Os

[asolokha at gmx dot com]

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

Bug ID: 71031
   Summary: [7 Regression] ICE in
extract_range_from_binary_expr_1, at tree-vrp.c:2535
w/ -Os
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20160508 snapshot ICEs when compiling the following reduced
testcase w/ -Os:

int zj;
int **yr;

void
nn (void)
{
  unsigned int od = 4;

  for (;;)
{
  int lk;

  for (lk = 0; lk < 2; ++lk)
{
  static int cm;

  zj = 0;
  if (od == 0)
return;
  ++od;
  for (cm = 0; cm < 2; ++cm)
{
  --od;
  **yr = 0;
}
}
}
}

% gcc-7.0.0-alpha20160508 -c -Os z5y81wfl.c
z5y81wfl.c: In function 'nn':
z5y81wfl.c:5:1: internal compiler error: in extract_range_from_binary_expr_1,
at tree-vrp.c:2535
 nn (void)
 ^~

[Bug c/71030] Strange segmentation fault

[formateu at gmail dot com]

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

--- Comment #2 from Mateusz Forc  ---
(In reply to H.J. Lu from comment #1)
> Please provide f.i.

f.i is not generated using -save-temps, how am I supposed to get this file?

[Bug c/71013] [7 Regression] c-common.c:12810:37: error: 'LLONG_MAX' was not declared in this scope

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net ---
On 2016-05-09 7:29 AM, John David Anglin wrote
> LLONG_MAX is not defined in hpux11.11.  It comes from fixed limits.h:
> ./lib/gcc/hppa64-hp-hpux11.11/5.3.1/include-fixed/limits.h:# undef LLONG_MIN
> ./lib/gcc/hppa64-hp-hpux11.11/5.3.1/include-fixed/limits.h:# define LLONG_MIN 
> (-LLONG_MAX - 1LL)
>
Should have provided more details:

#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
/* Minimum and maximum values a `signed long long int' can hold. */
# undef LLONG_MIN
# define LLONG_MIN (-LLONG_MAX - 1LL)
# undef LLONG_MAX
# define LLONG_MAX __LONG_LONG_MAX__

/* Maximum value an `unsigned long long int' can hold.  (Minimum is 0).  */
# undef ULLONG_MAX
# define ULLONG_MAX (LLONG_MAX * 2ULL + 1ULL)
#endif

  __STDC_VERSION__ is not defined when c-family/c-common.c is

compiled with g++ driver.  It is defined when gcc driver is used:

   else if (CPP_OPTION (pfile, lang) == CLK_STDC94)
 _cpp_define_builtin (pfile, "__STDC_VERSION__ 199409L");
   else if (CPP_OPTION (pfile, lang) == CLK_STDC11
|| CPP_OPTION (pfile, lang) == CLK_GNUC11)
 _cpp_define_builtin (pfile, "__STDC_VERSION__ 201112L");
   else if (CPP_OPTION (pfile, c99))
 _cpp_define_builtin (pfile, "__STDC_VERSION__ 199901L");

glimits.h has same issue.

[Bug c++/71029] large fold expressions compile slowly with -Wall

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-09
 Ever confirmed|0   |1

--- Comment #1 from Marc Glisse  ---
Could be my profiling going wrong, but we seem to spend a lot of time in
mark_used, with a running time at least quadratic in 2048, so maybe we mark as
used all the previous elements of the comma chain, for each element?

Clang does not emit the thousands of get<1234> functions. I am not sure we want
to follow them there, as it would make debugging harder.

[Bug c/71030] Strange segmentation fault

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-05-09
 CC||hjl.tools at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
Please provide f.i.

[Bug c++/70796] [DR 1030] Initialization order with braced-init-lists still broken

[rs2740 at gmail dot com]

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

--- Comment #2 from TC  ---
It occurred to me that one issue here is whether initialization of the
parameter object (of the constructor) is considered a "value computation [or]
side effect associated with" an initializer-clause. If not, then the current
behavior is correct - the increments are sequenced relative to each other but
not to the initialization of the parameter objects (which reads from 'i').

[Bug c/71030] New: Strange segmentation fault

[formateu at gmail dot com]

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

Bug ID: 71030
   Summary: Strange segmentation fault
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: formateu at gmail dot com
  Target Milestone: ---

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

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release
Thread model: posix
gcc version 6.1.1 20160501 (GCC) 

Used makefile 
CC=gcc
CFLAGS= -Wall -m32 

all: main.o f.o
  $(CC) $(CFLAGS) main.o f.o -o fun

main.o: main.c 
  $(CC) $(CFLAGS) -c main.c -o main.o
f.o: f.s   
  nasm -f elf -g f.s -o f.o

make && ./fun 2 2

Program runs intel x86 assembly function in main. Use of the EBX register
inside that function causes segmentation fault (after return from function).
It seems like gcc is using EBX instead of EBP before function call.
Program compiled using clang works properly.
Bug was noticed firstly on gcc 5.3.0 version, but is still present on latest
repository version.

main.c file : 

#include "f.h" // only void f(int); + guardian

int main()
{
  int var = 4;
  f(var);
  return 0;
}

f.s file :

  section .text
  global f
f:
  push ebp
  mov ebp, esp
  mov eax, [ebp+8]
  mov ebx, 0
begin:
  mov cl, [eax]
  mov ebx, 0
  add cl, 1
  mov [eax], cl
  mov esp, ebp
  pop ebp
  ret

[Bug middle-end/71028] [7 regression] ICE in redirect_jump, at jump.c:1560

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-09
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
Confirmed (with arm-linux-gnueabi, -O2 to reproduce).  Mine.

[Bug fortran/71027] -fsanitize=address catches out of bounds access on assumed size array only with -O0

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-05-09
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
IMO your expectation is invalid:

[Book15] f90/bug% gfc pr71027.f90 -Og -fdump-tree-optimized
[Book15] f90/bug% cat pr71027.f90.211t.optimized 

;; Function main (main, funcdef_no=2, decl_uid=3429, cgraph_uid=2,
symbol_order=2) (executed once)

__attribute__((externally_visible))
main (integer(kind=4) argc, character(kind=1) * * argv)
{
  static integer(kind=4) options.0[9] = {68, 1023, 0, 0, 1, 1, 0, 0, 31};

  :
  _gfortran_set_args (argc_2(D), argv_3(D));
  _gfortran_set_options (9, [0]);
  return 0;

}

i.e., the subroutine sub is optimized away. If you do something such as

  subroutine sub(vv)
  dimension vv(*)
  x=vv(20) ! out of bounds access
  vv(1)=x
  end subroutine

then -fsanitize=address catches the invalid address.

[Bug c++/71029] New: large fold expressions compile slowly with -Wall

[alisdairm at me dot com]

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

Bug ID: 71029
   Summary: large fold expressions compile slowly with -Wall
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alisdairm at me dot com
  Target Milestone: ---

Created attachment 38456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38456=edit
file is very slow compiled with Wall

The attached file uses a simple fold expression over a comma operator to
consume 'get' on each element of a std::array, so essentially
2047 comma operators separating empty 'sink' function calls.

On my current machine, with just with just g++ -std=c++1z file.cpp, this takes
around 2.5 seconds to compile.  With g++ -std=c++1z -Wall file.cpp it takes 25
seconds, and still reports no warnings.

The generated code is also quite large, regardless of warning setting,
generating an executable of around 650k.  This is less than 5k when compiled
-O3.

Running the same scenario through Clang, the unoptimized code produced s 90k
executable, and consistently gives a 1.5 second compile time, regardless of
warning level.

I suspect that Clang is getting in an early optimization around the do-nothing
function to eliminate a lot of code prior to running warning passes, but that
is entirely speculation as I have no idea how either compiler is implemented ;)


For the curious, compiling with the latest gcc 7 branch available through
MacPorts, this takes around 60% longer again although I am not sure if that
compiler is built with the same optimization settings as the released gcc 6.1
compiler.

[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  ---
*** Bug 71025 has been marked as a duplicate of this bug. ***

[Bug libstdc++/71025] std::call_once aborts instead of propagating an exception (AIX 6.1)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Yes this is PR 66146

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

[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #5 from Harald Anlauf  ---
(In reply to Keith Lindsay from comment #4)
> Thanks for taking a look. I've attached the output from the command
> gfortran -v -fopenmp openmp_nested_loops.f90 -o openmp_nested_loops
> on two different systems where I'm seeing the problem.

Do you still see the problem when you replace the line

!$OMP PARALLEL DO

by

!$OMP PARALLEL DO private(i,j) shared(s) default(none)

?

What you see might be a race condition, since you did not declare the
inner loop variable i as private.

[Bug middle-end/71028] New: [7 regression] ICE in redirect_jump, at jump.c:1560

[vp at gcc dot gnu.org]

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

Bug ID: 71028
   Summary: [7 regression] ICE in redirect_jump, at jump.c:1560
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vp at gcc dot gnu.org
  Target Milestone: ---

gcc.c-torture/compile/pr37483.c and
gcc.dg/20010822-1.c

FAILs on arm-none-eabi with:

...: internal compiler error: in redirect_jump, at jump.c:1560
 }
 ^
0x98314d redirect_jump(rtx_jump_insn*, rtx_def*, int)
../../gcc/gcc/jump.c:1560
0x10b8276 try_optimize_cfg
../../gcc/gcc/cfgcleanup.c:2900
0x10b8276 cleanup_cfg(int)
../../gcc/gcc/cfgcleanup.c:3150
0x10b9646 execute
../../gcc/gcc/cfgcleanup.c:3279


The following commit seem to cause it:
https://gcc.gnu.org/viewcvs?rev=235904=gcc=rev

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[ssbssa at yahoo dot de]

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

--- Comment #11 from Domani Hannes  ---
I can confirm that this patch works for windows as well.

[Bug fortran/71027] New: -fsanitize=address catches out of bounds access on assumed size array only with -O0

[zeccav at gmail dot com]

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

Bug ID: 71027
   Summary: -fsanitize=address catches out of bounds access on
assumed size array only with -O0
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

! -fsanitize=address -O0 catches out of bounds access on assumed size array
! any other optimization level, even -Og, inhibits catching
  dimension v(10)
  call sub(v)
  contains
  subroutine sub(vv)
  dimension vv(*)
  x=vv(20) ! out of bounds access
  end subroutine
  end

[Bug c++/71010] error: 'begin' was not declared in this scope

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Jonathan Wakely from comment #1)
 Furthermore, your code has undefined behaviour, it is forbidden to add your
> own functions to namespace std. The correct way to do it is to write the
> begin/end overloads in the same namespace as your type (in this case that's
> the global namespace).

I actually did not know that. Would it be possible to warn about this? I guess
libstdc++ files are system-headers and can avoid the warning.

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[zenith432 at users dot sourceforge.net]

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

--- Comment #10 from zenith432 at users dot sourceforge.net ---
(In reply to vries from comment #8)
> Created attachment 38453 [details]
> tentative patch

vries, thank you very much.  I verified and looks good.

Built GCC 6.1.0 with patch from released sources on ftp.gnu.org.
[moved the patch to the right place of course]

Built a fairly large UEFI-based project with a good number of ms_va_list. 
Checked the disassembly manually for 1 instance.  Code is right + tested it to
run ok in various scenarios I know to use __builtin_va_arg.

Bug can be changed to resolved as far as I'm concerned.  Not sure whether it
has to wait for commit, so leaving it to TPTB.

[Bug target/70904] ICE: Max. number of generated reload insns per insn is achieved (90) with -fno-split-wide-types @ aarch64

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #2 from Jiong Wang  ---
(In reply to Zdenek Sojka from comment #0)
> Created attachment 38393 [details]
> reduced testcase
> 
> Compiler output:
> $ aarch64-unknown-linux-gnu-gcc -O -fno-split-wide-types testcase.c 
> testcase.c: In function 'foo':
> testcase.c:8:1: internal compiler error: Max. number of generated reload
> insns per insn is achieved (90)
> 
>  }
>  ^
> 0x9dafa9 lra_constraints(bool)
> /repo/gcc-trunk/gcc/lra-constraints.c:4440
> 0x9c63dc lra(_IO_FILE*)
> /repo/gcc-trunk/gcc/lra.c:2290
> 0x96de19 do_reload
> /repo/gcc-trunk/gcc/ira.c:5425
> 0x96de19 execute
> /repo/gcc-trunk/gcc/ira.c:5609

From rtl dump, reload is trying to insert the following reload insn

  r93:OI = r80:OI

r93 is with general register class and r80 is with vector register
class. r93 was created to meet the constraint inside insn 17, and was to
replace the vector register r80 inside the subreg, as vector register
can't be used as index register.

(insn 17 11 20 2 (set (mem:SI (plus:DI (sign_extract:DI (mult:DI (subreg:DI
(reg:OI 80 [ D.2754 ]) 0)
(const_int 4 [0x4]))  
(const_int 34 [0x22])
(const_int 0 [0]))
(reg/f:DI 83)) [1 *_9+0 S4 A32])
(const_int 0 [0])) bug-1.c:7 49 {*movsi_aarch64}

reload here is trying to reload the inner register r80 instead of the whole
subreg,
thus creating a new "OImode (vector register)" to "OImode (general register"
move
which can't be supported in hardware and caused further endless reload.

For mode with size bigger than word_mode, there won't be "mov" between
two registers with different classes, but there normally will be "mov"
which transfers element of vector register into the general register, and
this normally will be a subreg.

So I think we should teach reload about this to reload the whole subreg
if above conditions met.

Comments?

(CCed RA maintainer Vlad)

diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 14d5f1d..0ca7a7d 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -1307,7 +1307,15 @@ process_addr_reg (rtx *loc, bool check_only_p, rtx_insn
**before, rtx_insn **aft

   subreg_p = GET_CODE (*loc) == SUBREG;
   if (subreg_p)
-loc = _REG (*loc);
+{
+  reg = SUBREG_REG (*loc);
+  mode = GET_MODE (reg);
+
+  if (in_class_p (reg, cl, _class)
+ || GET_MODE_SIZE (mode) <= GET_MODE_SIZE (word_mode))
+   loc = _REG (*loc);
+}
+
   reg = *loc;
   mode = GET_MODE (reg);
   if (! REG_P (reg))

[Bug tree-optimization/71026] New: Missing division optimizations

[wdijkstr at arm dot com]

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

Bug ID: 71026
   Summary: Missing division optimizations
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wdijkstr at arm dot com
  Target Milestone: ---

With -Ofast GCC doesn't reassociate constant multiplies or negates away from
divisors to allow for more reciprocal division optimizations. It is also
possible to avoid divisions (or multiplies) involving immediates in comparisons
that check for a positive/negative result.

float f1(float x, float y) { return x / (y * y); }// -> x * (1/y) * (1/y)
float f2(float x, float y) { return x / (y * 3.0f); } // -> (x/3) / y
float f3(float x, float y) { return x / -y; } // -> (-x) / y
int f4(float x) { return (1.0f / x) < 0.0f; } // -> x < 0.0f
int f5(float x) { return (x / 2.0f) <= 0.0f; }// -> x <= 0.0f

A quick experiment shows the first transformation could remove almost 100
divisions from SPEC2006, the 2nd 50. The first transformation is only useful if
there is at least one other division by y, so likely best done in the division
reciprocal optimization phase.

[Bug target/70894] ICE when using neon intrinsic with mabi=apcs-gnu

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-09
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #1 from Richard Earnshaw  ---
Confirmed on trunk.  Note that I don't expect that we ever intended to make
ACLE extensions work with the old ABI (-mabi=apcs-gnu).  Nevertheless, we
shouldn't ICE.

[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices

[klindsay at ucar dot edu]

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

--- Comment #4 from Keith Lindsay  ---
Thanks for taking a look. I've attached the output from the command
gfortran -v -fopenmp openmp_nested_loops.f90 -o openmp_nested_loops
on two different systems where I'm seeing the problem.

[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices

[klindsay at ucar dot edu]

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

--- Comment #3 from Keith Lindsay  ---
Created attachment 38455
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38455=edit
output from gfortran -v

[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices

[klindsay at ucar dot edu]

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

--- Comment #2 from Keith Lindsay  ---
Created attachment 38454
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38454=edit
output from gfortran -v

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[ssbssa at yahoo dot de]

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

Domani Hannes  changed:

   What|Removed |Added

 CC||ssbssa at yahoo dot de

--- Comment #9 from Domani Hannes  ---
I've the same behavior on windows as well, even if I remove the ms_abi
attribute (probably because it's always ms_abi anyway?).

[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-05-09
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
WORKSFORME on x86_64-apple-darwin15 from 4.9.3 up to trunk (7.0). With 4.8.5 I
get

pr71014.f90:19:0: internal compiler error: in omp_add_variable, at
gimplify.c:5896
   associate (jassoc => j)

Could you please post the result of 'gfortran -v'?

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
There is no such macro.

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[fritzoreese at gmail dot com]

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

--- Comment #29 from Fritz Reese  ---
(In reply to Andreas Schwab from comment #25)
> FAIL: gfortran.dg/dec_union_4.f90   -O0  execution test
> FAIL: gfortran.dg/dec_union_4.f90   -O1  execution test
> FAIL: gfortran.dg/dec_union_4.f90   -O2  execution test
> FAIL: gfortran.dg/dec_union_4.f90   -O3 -fomit-frame-pointer -funroll-loops
> -fpeel-loops -ftracer -finline-functions  execution test
> FAIL: gfortran.dg/dec_union_4.f90   -O3 -g  execution test
> FAIL: gfortran.dg/dec_union_4.f90   -Os  execution test

It was silly of me to disregard endian-ness in this test case. Fixed:

https://gcc.gnu.org/ml/fortran/2016-05/msg00018.html

[Bug libstdc++/71025] std::call_once aborts instead of propagating an exception (AIX 6.1)

[vfried at opentext dot com]

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

--- Comment #1 from Vojtech Fried  ---
I am sorry, probably duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146

[Bug fortran/52162] Bogus -fcheck=bounds with realloc on assignment to unallocated LHS

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||mrestelli at gmail dot com

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

[Bug fortran/70953] Reallocation on assignment does not work with debug flags

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
> It looks like a duplicate of pr52162 (see comment 2).

Not challenged, marked as duplicate of pr52162.

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

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
Looks like it also did not fail in the latest gcc-testresults Power7 BE run. 
Going to stop looking at this unless/until it shows up again.

[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Note that ultimatively the error is still that is_short () accesses the wrong
union member.

I'll still see whether there is a bug in optimize_bit_field_compare.

[Bug fortran/60483] [4.9/5/6/7 Regression] No IMPLICIT type error with: ASSOCIATE( X => derived_type() ) [i.e. w/ structure constructor]

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||mrestelli at gmail dot com

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

[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
So PRE sees:

  :
  # .MEM_3 = VDEF <.MEM_1(D)>
  MEM[(struct  &)this_2(D)] ={v} {CLOBBER};
  # .MEM_14 = VDEF <.MEM_3>
  MEM[(struct  &)this_2(D)] ={v} {CLOBBER};
  # .MEM_15 = VDEF <.MEM_14>
  MEM[(struct short_t &)this_2(D)].h.is_short = 1;
  # .MEM_16 = VDEF <.MEM_15>
  MEM[(struct short_t &)this_2(D)].h.length = 0;
  # .MEM_17 = VDEF <.MEM_16>
  MEM[(struct short_t &)this_2(D)].data[0] = 0;
  # VUSE <.MEM_17>
  _19 = BIT_FIELD_REF ;
  _20 = _19 & 1;
  if (_20 != 0)
goto ;
  else
goto ;

  :
  # VUSE <.MEM_17>
  _21 = BIT_FIELD_REF ;
  _22 = _21 & 1;
  if (_22 != 0)
goto ;
  else
goto ;

  :
  # .MEM_34 = VDEF <.MEM_17>
  short_backup = MEM[(const struct short_t &)this_2(D)];
  # .MEM_35 = VDEF <.MEM_34>
  MEM[(struct long_t *)this_2(D)] = MEM[(const struct long_t *)str_5(D)];
  # .MEM_36 = VDEF <.MEM_35>
  MEM[(struct short_t *)str_5(D)] = short_backup;
  # .MEM_37 = VDEF <.MEM_36>
  short_backup ={v} {CLOBBER};
  goto ;

  :
  # .MEM_29 = PHI <.MEM_33(13), .MEM_37(5)>
  # VUSE <.MEM_29>
  _9 = MEM[(const struct short_t &)this_2(D)].h.length;
  _10 = (long unsigned int) _9;
  goto ;

and it concludes that on the path bb2 -> bb5 -> bb10 nothing can clobber
MEM[(const struct short_t &)this_2(D)].h.length and thus it is safe to
replace it with zero (from the init in bb2).  The "obvious" clobbering
candidate is

  # .MEM_35 = VDEF <.MEM_34>
  MEM[(struct long_t *)this_2(D)] = MEM[(const struct long_t *)str_5(D)];

but that is storing using a different type.  So the error must happen earlier.
It might be as early as the BIT_FIELD_REF folding of the is_short read which
does

  _19 = BIT_FIELD_REF ;

It is DOM who threads further reads from the above again not considering
the above store clobbering a read via 'struct string' (which does not
include long_t in its alias subsets).

Thus mine (to fix optimize_bit_field_compare).

[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #7 from Bill Schmidt  ---
I can no longer reproduce this with a bootstrap compiler, even on the revision
where it failed for me before.  I'm perplexed.  Do you still see it failing?

[Bug fortran/71023] Problem with associate and function returning derived type

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
I think it is a duplicate of pr60483.

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

[Bug libstdc++/71025] New: std::call_once aborts instead of propagating an exception (AIX 6.1)

[vfried at opentext dot com]

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

Bug ID: 71025
   Summary: std::call_once aborts instead of propagating an
exception (AIX 6.1)
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vfried at opentext dot com
  Target Milestone: ---

When an exception is thrown inside a function called from std::call_once, the
process is aborted. The exception should be propagated outside std::call_once.

#include 
#include 
#include 

int main()
{
static std::once_flag flag;

printf( "start\n" );
try
{
std::call_once(
flag,
[&]()
{
throw std::runtime_error("thrown from once");
} );
}
catch ( std::runtime_error const& exc )
{
printf( "%s\n", exc.what() );
}
printf( "end\n" );
return 0;
}

bea@stbldap02:~/samples$ g++ -std=c++14 -pthread std_call_once_exception.cxx
bea@stbldap02:~/samples$ ./a.out
start
terminate called after throwing an instance of 'std::runtime_error'
  what():  thrown from once
IOT/Abort trap (core dumped)

BTW: the system on which I tested it should be the same as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67478

[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor

[eric at efcs dot ca]

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

--- Comment #6 from Eric Fiselier  ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Eric Fiselier from comment #1)
> > recursive_directory_iterator it;
> > assert(it.recursion_pending() == false);
> > assert(it.recursion_pending() == true);
> 
> N.B. This test is undefined, those observer functions have preconditions
> that they are not called on the end iterator.

That's true, my mistake.

[Bug c++/71024] New: Missing warning for contradictory attributes

[mpolacek at gcc dot gnu.org]

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

Bug ID: 71024
   Summary: Missing warning for contradictory attributes
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Observe that on 

void __attribute ((always_inline)) foo (void);
void __attribute ((noinline)) foo (void);

$ ./cc1 -quiet q.cc 
q.cc:2:31: warning: declaration of ‘foo’ with attribute ‘noinline’ follows
declaration with attribute ‘always_inline’ [-Wattributes]
 void __attribute ((noinline)) foo (void);
   ^~~
q.cc:1:36: note: previous declaration of ‘foo’ was here
 void __attribute ((always_inline)) foo (void);
^~~
but cc1plus is silent.  I think we need to factor out some code out of
diagnose_mismatched_decls.

[Bug fortran/71023] New: Problem with associate and function returning derived type

[mrestelli at gmail dot com]

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

Bug ID: 71023
   Summary: Problem with associate and function returning derived
type
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrestelli at gmail dot com
  Target Milestone: ---

gfortran does not compile the following valid code:


module m
 implicit none

 type :: t
  integer :: i
 end type t

contains

 pure function make_a_t(i) result(at)
  integer, intent(in) :: i
  type(t) :: at
   at%i = i
 end function make_a_t

 subroutine s()

  associate( my_t => make_a_t(5) )

  write(*,*) my_t%i

  end associate

 end subroutine s

end module m



$ gfortran -c asb.f90 -o asb.o
asb.f90:20:18:

   write(*,*) my_t%i
  1
Error: Symbol »my_t« at (1) has no IMPLICIT type

$ gfortran --version
GNU Fortran (GCC) 7.0.0 20160422 (experimental)

[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Mon, 9 May 2016, tavianator at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
> 
> --- Comment #5 from Tavian Barnes  ---
> > But if it is not POD then assuming it gets copied correctly when
> > init-constructing a POD union where they placed such object is
> > an interesting assumption...
> 
> Hrm?  They seem to always copy it manually with long_t's copy constructor:
> 
> ::new(_repr.long_repr()) long_t(other.m_repr.long_repr());

I stand corrected.  At least they always read from short_t when
computing is_short() even if that is not the active union member.

Some missed optimizations:

foo::foo(string) (struct foo * const this, struct string & restrict str)
{
...
  :
  MEM[(struct short_t &)this_2(D)].h.is_short = 1;
  MEM[(struct short_t &)this_2(D)].h.length = 0;
  MEM[(struct short_t &)this_2(D)].data[0] = 0;
  _19 = BIT_FIELD_REF ;
  _20 = _19 & 1;
  if (_20 != 0)

this is fold-const.c at work replacing the load from h.is_short
with the BIT_FIELD_REF.

But then we go to

short_t short_backup(m_repr.short_repr());
m_repr.short_repr().~short_t();
::new(_repr.long_repr()) long_t(other.m_repr.long_repr());
other.m_repr.long_repr().~long_t();
::new(_repr.short_repr()) short_t(short_backup);

  :
  short_backup = MEM[(const struct short_t &)this_2(D)];
  MEM[(struct long_t *)this_2(D)] = MEM[(const struct long_t *)str_5(D)];
  MEM[(struct short_t *)str_5(D)] = short_backup;
  short_backup ={v} {CLOBBER};
  goto ;

which looks good.  But

  :
  # prephitmp_52 = PHI <_51(10), 0(5)>
  goto ;

  :
  # iftmp.7_13 = PHI 
  *this_2(D).m_len = iftmp.7_13;

stores zero into the length field.  Somehow PRE does this transform.

I'll investigate some more.

[Bug rtl-optimization/71022] New: GCC prefers register moves over move immediate

[wdijkstr at arm dot com]

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

Bug ID: 71022
   Summary: GCC prefers register moves over move immediate
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wdijkstr at arm dot com
  Target Milestone: ---

When assigning the same immediate value to different registers, GCC will always
CSE the immediate and emit a register move for subsequent uses. This creates
unnecessary register dependencies and increases latency. When the cost of an
immediate move is the same as a register move (which should be true for most
targets), it should prefer the former. A register move is better only when the
immediate requires multiple instructions or is larger with -Os.

It's not obvious where this is best done. The various cprop phases before IRA
do the right thing, but cse2 (which runs later) then undoes it. And
cprop_hardreg doesn't appear to be able to deal with immediates.

int f1(int x)
{
  int y = 1, z = 1;
  while (x--)
{
  y += z;
  z += x;
}
  return y + z;
}

void g(float, float);
void f2(void) { g(1.0, 1.0); g(3.3, 3.3); }

On AArch64 I get:

f1:
sub w1, w0, #1
cbz w0, .L12
mov w0, 1
mov w2, w0 *** mov w2, 1
.p2align 2
.L11:
add w2, w2, w0
add w0, w0, w1
sub w1, w1, #1
cmn w1, #1
bne .L11
add w0, w2, w0
ret
.L12:
mov w0, 2
ret

f2:
fmovs1, 1.0e+0
str x30, [sp, -16]!
fmovs0, s1*** fmov s0, 1.0
bl  g
adrpx0, .LC1
ldr x30, [sp], 16
ldr s1, [x0, #:lo12:.LC1]
fmovs0, s1*** ldr s0, [x0, #:lo12:.LC1] 
b   g

[Bug testsuite/71021] [libatomic testsuite] Test program compilation fail (missing -pthread flag)

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #1 from nsz at gcc dot gnu.org ---
i think target lib tests are broken in gcc (other than libstdc++ and
libgfortran).

if the build-sysroot paths were used then the right libc would be linked.

but CC (with all the necessary flags) is not passed from make to the test
system, instead dejagnu find_gcc is used and some heuristics to reconstruct the
-B etc flags, and thus the build sysroot is missing. (e.g. getenv CC instead of
find_gcc would be a correct fix in libatomic.exp.. +export CC in the makefile).

others seem to have run into this too, but apparently it was not fixed:
https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01181.html

(the libstdc++ solution is also less than elegant: it generates a shell script
that knows the paths/flags and call that repeatedly from the dejagnu tcl code..
instead of just passing the envvars from make to runtest)

all target libs with tests need this fix when --with-build-sysroot is used.

[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

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

[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation

[tavianator at gmail dot com]

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

--- Comment #5 from Tavian Barnes  ---
> But if it is not POD then assuming it gets copied correctly when
> init-constructing a POD union where they placed such object is
> an interesting assumption...

Hrm?  They seem to always copy it manually with long_t's copy constructor:

::new(_repr.long_repr()) long_t(other.m_repr.long_repr());

[Bug testsuite/71021] New: [libatomic testsuite] Test program compilation fail (missing -pthread flag)

[romain.geissler at amadeus dot com]

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

Bug ID: 71021
   Summary: [libatomic testsuite] Test program compilation fail
(missing -pthread flag)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Created attachment 38452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38452=edit
Add "-pthread" flag when compiling libatomic test programs

Hi,

I am currently building up the Amadeus toolchain and I have trouble running the
testsuite with libatomic. All test fails because the compilation of the test
program fails. This happens in the specific case of our own toolchain because
we build and install glibc/binutils/gcc in a custom prefix
"/opt/1A/toolchain/x86_64-2.6.32-v2-6/". It also fails since the default system
glibc (found in /lib) is different from the Amadeus toolchain glibc against
which we link both binutils and glibc. The toolchain glibc is glibc 2.23 while
the system glibc is glibc

This happens on Linux x86_64, using gcc 4.9.4. I haven't checked yet if it also
happens with gcc 6 but I will check soon.

When I run:
make check-target-libatomic RUNTESTFLAGS="c.exp=atomic-compare-exchange-1.c -v
-v"

I can see:

Executing on host: /workdir/build/final-system/gcc-build/gcc/xgcc
-B/workdir/build/final-system/gcc-build/gcc/
/workdir/src/gcc-4.9.4/libatomic/testsuite/libatomic.c/atomic-compare-exchange-1.c
 -B/workdir/build/final-system/gcc-build/x86_64-1a-linux-gnu/./libatomic/
-I/workdir/build/final-system/gcc-build/x86_64-1a-linux-gnu/./libatomic
-I/workdir/src/gcc-4.9.4/libatomic/testsuite/.. -fmessage-length=0
-fno-inline-atomics  -g  
-L/workdir/build/final-system/gcc-build/x86_64-1a-linux-gnu/./libatomic/.libs
-latomic -lm   -o ./atomic-compare-exchange-1.exe(timeout = 300)
pid is 23832 -23832
waitres is 23832 exp8 0 1
close result is 23832 exp8 0 1
output is /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to
`h_errno@GLIBC_PRIVATE'
collect2: error: ld returned 1 exit status

If I manually run the link phase with "-Wl,-v,-t" I have this:
/workdir/build/final-system/gcc-build/gcc/collect-ld -plugin
/workdir/build/final-system/gcc-build/gcc/liblto_plugin.so
-plugin-opt=/workdir/build/final-system/gcc-build/gcc/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccSu6fuN.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib64/ld-linux-x86-64.so.2 -o
./atomic-compare-exchange-1.exe
/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64/crt1.o
/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64/crti.o
/workdir/build/final-system/gcc-build/gcc/crtbegin.o
-L/workdir/build/final-system/gcc-build/x86_64-1a-linux-gnu/./libatomic/.libs
-L/workdir/build/final-system/gcc-build/gcc
-L/workdir/build/final-system/gcc-build/x86_64-1a-linux-gnu/./libatomic
-L/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64
-L/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib /tmp/cccwFSDA.o -latomic -lm -v -t
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /workdir/build/final-system/gcc-build/gcc/crtend.o
/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64/crtn.o
GNU ld (GNU Binutils) 2.26.0.20160501
/opt/1A/toolchain/x86_64-2.6.32-v2-6/x86_64-1a-linux-gnu/bin/ld: mode
elf_x86_64
/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64/crt1.o
/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64/crti.o
/workdir/build/final-system/gcc-build/gcc/crtbegin.o
/tmp/cccwFSDA.o
-latomic
(/workdir/build/final-system/gcc-build/x86_64-1a-linux-gnu/./libatomic/.libs/libatomic.so)
/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/libm.so.6/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/libmvec.so.1
/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/libmvec.so.1
-lgcc_s (/workdir/build/final-system/gcc-build/gcc/libgcc_s.so)  
/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/libc.so.6  
(/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/libc_nonshared.a)elf-init.oS
/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/ld-linux-x86-64.so.2
/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/ld-linux-x86-64.so.2  
-lgcc_s (/workdir/build/final-system/gcc-build/gcc/libgcc_s.so)  
/workdir/build/final-system/gcc-build/gcc/crtend.o  
/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64/crtn.o  
/lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to
`h_errno@GLIBC_PRIVATE'  
/opt/1A/toolchain/x86_64-2.6.32-v2-6/x86_64-1a-linux-gnu/bin/ld: link errors
found, deleting executable `./atomic-compare-exchange-1.exe'
collect2: error: ld returned 1 exit status

So it clearly shows there is a conflict between the glibc in
/opt/1A/toolchain/x86_64-2.6.32-v2-6/ and the one in /lib. The linker uses 

[Bug testsuite/70826] [7 regression] many test cases fail starting with r235442

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC|amodra at gcc dot gnu.org, |
   |amodra at gmail dot com|
 Resolution|--- |FIXED

--- Comment #11 from Alan Modra  ---
Fixed, until it breaks next time.

[Bug testsuite/70826] [7 regression] many test cases fail starting with r235442

[amodra at gcc dot gnu.org]

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

--- Comment #10 from Alan Modra  ---
Author: amodra
Date: Mon May  9 12:35:25 2016
New Revision: 236033

URL: https://gcc.gnu.org/viewcvs?rev=236033=gcc=rev
Log:
[RS6000] Fragile testcase breaks with -frename-registers

PR testsuite/70826
* gcc.target/powerpc/savres.c: Compile with -fno-rename-registers.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/savres.c

[Bug ipa/70785] LTO bootstrap with IPA PTA is broken

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||riad93 at mail dot ru

--- Comment #6 from Richard Biener  ---
*** Bug 71018 has been marked as a duplicate of this bug. ***

[Bug lto/71018] lto + ipa-pta causes exception with trivial boost::ptime code.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
The patch for PR70785 fixed this, thus fixed for GCC 6.2.

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

[Bug tree-optimization/70985] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/70985] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon May  9 12:23:11 2016
New Revision: 236032

URL: https://gcc.gnu.org/viewcvs?rev=236032=gcc=rev
Log:
2016-05-09  Richard Biener  

PR tree-optimization/70985
* match.pd (BIT_FIELD_REF -> (type)): Disable on GIMPLE when
op0 isn't a gimple register.

* gcc.dg/torture/pr70985.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr70985.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Mon, 9 May 2016, tavianator at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
> 
> --- Comment #3 from Tavian Barnes  ---
> Because their long_t is not POD.  I don't know why that is though.  It could 
> be
> POD if they removed the default/copy constructors and assignment operator.
> 
> Actually they're probably worried about custom allocators where the pointer
> type is not POD.  So it couldn't be POD in general, and thus can't appear in a
> union directly (in C++03).

But if it is not POD then assuming it gets copied correctly when
init-constructing a POD union where they placed such object is
an interesting assumption...

[Bug target/68945] enable libcilkrts on SPARC

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

  Attachment #38221|0   |1
is obsolete||
  Attachment #38413|0   |1
is obsolete||

--- Comment #10 from Rainer Orth  ---
Created attachment 38451
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38451=edit
Revised patch

Here's a version of the patch that is, I believe, ready for upstream
submission.

It's based on the upstream version as has just been merged into the gcc repo.

Compared to the previous sparcv9 support, the assertions are gone to allow for
an easier read.

I've also replaced the times(3C) based implementation of __cilkrts_getticks by
one reading %tick directly, which should work on all UltraSPARC CPUs,
independent
of O/S.

I've replaced the _GNU_SOURCE guard around runtime/sysdep-unix.c
(get_runtime_path) around the use dladdr
by the result of a configure check.  The previous version had been wrong (just
defining _GNU_SOURCE) doesn't suddently materialize dladdr), and the function 
is present in Solaris libc.

Perhaps Eric could have a look at the SPARC assembler code to double-check that
I got it right:

* In runtime/config/sparc/os-unix-sysdep.c (__cilkrts_getticks) I needed
different
  32- and 64-bit versions.  I tested the result in standalone program which
just
  printed the result.

* One thing I wonder about is runtime/config/sparc/os-fence.h: when using
  __sync_synchronize, gcc emits membar #StoreLoad, while Stefan's patch had
  membar#LoadLoad | #LoadStore | #StoreStore | #StoreLoad.  It seems that
  all but #StoreLoad are no-ops for TSO SPARC CPUs, but I'd better get this
right.

I also believe that only so little of Stefan's code is left
(__cilkrts_short_pause mostly) to not require a separate assignement for
upstream submission.  If I'm mistaken, we'd better get that ball rolling.

  Rainer

[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation

[tavianator at gmail dot com]

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

--- Comment #3 from Tavian Barnes  ---
Because their long_t is not POD.  I don't know why that is though.  It could be
POD if they removed the default/copy constructors and assignment operator.

Actually they're probably worried about custom allocators where the pointer
type is not POD.  So it couldn't be POD in general, and thus can't appear in a
union directly (in C++03).

[Bug tree-optimization/71020] [6/7 Regression] SSA corruption: Unable to coalesce ssa_names 2 and 13 which are marked as MUST COALESCE.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||rsandifo at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
  b_13(ab) = SQRT (b_1(ab));
  DCE_COND_LB.2_15 = b_1(ab);
  if (DCE_COND_LB.2_15 u>= 0.0)

introduced by cdce.  Likely triggered by Richards changes.  We have

  :
  # b_1(ab) = PHI 
  _setjmp ();
  b_13(ab) = sqrt (b_1(ab));
  err_logo ();
  goto ;

where one way to fix this is push b_1(ab) to a non-abnormal temporary
before the call and re-use that.  Or simply give up for example
via checking for abnormal SSA call arguments in an appropriate place.

[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Mon May  9 11:50:01 2016
New Revision: 236028

URL: https://gcc.gnu.org/viewcvs?rev=236028=gcc=rev
Log:
libstdc++/71004 fix recent additions to testcase

PR libstdc++/71004
* testsuite/experimental/filesystem/iterators/
recursive_directory_iterator.cc: Fix test02 to not call member
functions on invalid iterator, and use VERIFY not assert.

Modified:
trunk/libstdc++-v3/ChangeLog
   
trunk/libstdc++-v3/testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc

[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Eric Fiselier from comment #1)
> recursive_directory_iterator it;
> assert(it.recursion_pending() == false);
> assert(it.recursion_pending() == true);

N.B. This test is undefined, those observer functions have preconditions that
they are not called on the end iterator.

[Bug tree-optimization/71020] [6/7 Regression] SSA corruption: Unable to coalesce ssa_names 2 and 13 which are marked as MUST COALESCE.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-09
  Known to work||5.3.0
   Target Milestone|--- |6.2
Summary|SSA corruption: Unable to   |[6/7 Regression] SSA
   |coalesce ssa_names 2 and 13 |corruption: Unable to
   |which are marked as MUST|coalesce ssa_names 2 and 13
   |COALESCE.   |which are marked as MUST
   ||COALESCE.
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c/71013] [7 Regression] c-common.c:12810:37: error: 'LLONG_MAX' was not declared in this scope

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2016-05-09, at 4:26 AM, rguenth at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71013
> 
> Richard Biener  changed:
> 
>   What|Removed |Added
> 
>   Target Milestone|--- |7.0
> 
> --- Comment #1 from Richard Biener  ---
> How do you get LLONG_MAX on hpux?  There is HAVE_LONG_LONG[_INT] in
> auto-host.h,
> maybe that needs to be used here.


LLONG_MAX is not defined in hpux11.11.  It comes from fixed limits.h:
./lib/gcc/hppa64-hp-hpux11.11/5.3.1/include-fixed/limits.h:# undef LLONG_MIN
./lib/gcc/hppa64-hp-hpux11.11/5.3.1/include-fixed/limits.h:# define LLONG_MIN
(-LLONG_MAX - 1LL)

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

[Bug tree-optimization/71020] New: SSA corruption: Unable to coalesce ssa_names 2 and 13 which are marked as MUST COALESCE.

[pdewacht at gmail dot com]

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

Bug ID: 71020
   Summary: SSA corruption: Unable to coalesce ssa_names 2 and 13
which are marked as MUST COALESCE.
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdewacht at gmail dot com
  Target Milestone: ---

This function triggers an internal compiler error. Reduced using C-Reduce from
a source file from FMSLogo.

$ cat ssa2.c
binary() {
  double b = get();
  _setjmp();
  b = sqrt(b);
  err_logo();
}

$ gcc-6 -O -w -c ssa2.c

Unable to coalesce ssa_names 2 and 13 which are marked as MUST COALESCE.
b_2(ab) and  b_13(ab)
ssa2.c: In function ‘binary’:
ssa2.c:1:1: internal compiler error: SSA corruption
 binary() {
 ^~
0xa90f9c fail_abnormal_edge_coalesce
../../src/gcc/tree-ssa-coalesce.c:1010
0xa90f9c coalesce_partitions
../../src/gcc/tree-ssa-coalesce.c:1411
0xa90f9c coalesce_ssa_name()
../../src/gcc/tree-ssa-coalesce.c:1895
0xa4798f remove_ssa_form
../../src/gcc/tree-outof-ssa.c:978
0xa4798f rewrite_out_of_ssa(ssaexpand*)
../../src/gcc/tree-outof-ssa.c:1202
0x69b2e0 execute
../../src/gcc/cfgexpand.c:6136
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ gcc-6 -v
Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.1.1-1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.1.1 20160430 (Debian 6.1.1-1)

[Bug lto/71018] lto + ipa-pta causes exception with trivial boost::ptime code.

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Possibly related to PR70760 or PR70785.  Can't reproduce with GCC 6 branch head
(so I'd say 70785), building GCC 6.1.0 right now.

[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

--- Comment #3 from Jonathan Wakely  ---
Only fixed on trunk so far.

[Bug tree-optimization/71016] [6/7 Regression] Redundant sign extension with conditional __builtin_clzl

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/71016] [6/7 Regression] Redundant sign extension with conditional __builtin_clzl

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||kuganv at linaro dot org

--- Comment #2 from Richard Biener  ---
PHI prephitmp_8 changed to factor conversion out from COND_EXPR.
New stmt with CAST that defines prephitmp_8.

Added with

2015-07-12  Kugan Vivekanandarajah  

PR middle-end/66726
* tree-ssa-phiopt.c(factor_out_conditional_conversion): New function.
tree_ssa_phiopt_worker): Call it.

[Bug tree-optimization/71016] [6/7 Regression] Redundant sign extension with conditional __builtin_clzl

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-09
   Target Milestone|--- |6.2
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So PRE still does the desired tranform:

  :
  if (i_4(D) != 0)
goto ;
  else
goto ;

  :
  i.1_1 = (long unsigned int) i_4(D);
  _2 = __builtin_clzl (i.1_1);
  _5 = (long int) _2;

  :
  # _7 = PHI <_2(3), 17(2)>
  # prephitmp_8 = PHI <_5(3), 17(2)>
  return prephitmp_8;

but then later phiopt comes along and un-does it:

--- t.c.172t.forwprop4  2016-05-09 13:15:20.830707963 +0200
+++ t.c.173t.phiopt32016-05-09 13:15:20.830707963 +0200
@@ -6,7 +6,7 @@
 {
   long unsigned int i.1_1;
   int _2;
-  long int _5;
+  int _7;
   long int prephitmp_8;

   :
@@ -18,10 +18,10 @@
   :
   i.1_1 = (long unsigned int) i_4(D);
   _2 = __builtin_clzl (i.1_1);
-  _5 = (long int) _2;

   :
-  # prephitmp_8 = PHI <_5(3), 17(2)>
+  # _7 = PHI <_2(3), 17(2)>
+  prephitmp_8 = (long int) _7;
   return prephitmp_8;

 }

I think this was intended to be an enablement transform of some sort -
obviously
here it mis-fires.