[Bug c++/86187] Subscript operator applied to an temporary array results in an lvalue

2018-06-16 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86187

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #1 from Marc Glisse  ---
It has the same exact title, code, SO link, clang link...

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

[Bug c++/85867] Subscript operator applied to an temporary array results in an lvalue

2018-06-16 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85867

Marc Glisse  changed:

   What|Removed |Added

 CC||zhonghao at pku dot org.cn

--- Comment #3 from Marc Glisse  ---
*** Bug 86187 has been marked as a duplicate of this bug. ***

[Bug c/84887] missing semicolon: further improvements

2018-06-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84887

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-17
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> (In reply to Eric Gallager from comment #2)
> > link to thread on reddit?
> > 
> 
> Never mind, I found it:
> https://www.reddit.com/r/programming/comments/84oizv/
> usability_improvements_in_gcc_8/dvr93d4/
> I'll confirm this bug after finding the Hacker News one, too.

Actually never mind again; that link isn't necessary to confirm this bug.
ASSIGNED since there's an assignee.

[Bug other/84904] Implement an option to attempt to auto-apply fix-it hints

2018-06-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84904

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-06-17
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Eric Gallager  ---
Confirmed as an enhancement and ASSIGNED since you already assigned yourself

[Bug c++/56084] poor error recovery for missing ";"

2018-06-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56084

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #9 from Eric Gallager  ---
ASSIGNED because it already has an assignee.

[Bug c++/68615] Unhelpful location when missing a semi-colon on a function declaration at the end of a header

2018-06-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68615

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #4 from Eric Gallager  ---
Since David put himself as the assignee for this, I'm changing the status to
ASSIGNED.

[Bug driver/29931] following argv[0] symlink in process_command breaks symlinked-together toolchain

2018-06-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931

Eric Gallager  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #7 from Eric Gallager  ---
(In reply to Eric Gallager from comment #6)
> (In reply to Jorn Wolfgang Rennecke from comment #4)
> > The bug is not fixed; the gcc.c patch has not been reviewed.
> 
> What about now, after r169891? As mentioned in the comment after you:
> 
> (In reply to simonb from comment #5)
> > Author: simonb
> > Date: Mon Feb  7 18:10:15 2011
> > New Revision: 169891
> > 
> > URL: http://gcc.gnu.org/viewcvs?root=gcc=rev=169891
> > Log:
> > Auto-detect suitable default behaviour for prefix canonicalization.
> > 
> > Current gcc offers -no-canonical-prefixes to turn off realpath() for 
> > prefixes
> > generated from the path used to address the gcc driver.  This allows gcc to
> > work in "symlink farm" installations, where every file in gcc is actually a
> > symlink to its real contents.  However, the flag has to be given explicitly.
> > If not, the default is to use realpath() to create prefixes and the result
> > is usually failure to find cc1[plus], f951, etc.
> > 
> > This patch adds a check for a file as a way to auto-detect whether prefix
> > canonicalization is appropriate or not.  Detection can be overridden by
> > using the -[no-]canonical-prefixes flags.
> > 
> > The patch also completes the fix for PR/29931, adding code that covers the
> > unadopted portion of this PR's attached patch.
> > 
> > gcc/ChangeLog.google:
> > 2011-02-07  Simon Baldwin  
> > 
> > PR driver/29931
> > * doc/invoke.texi: Adjust -[no-]canonical-prefixes documentation.
> > * gcc.c (display_help): Help text for -[no-]canonical-prefixes.
> > (driver_handle_option): Ignore OPT_canonical_prefixes.
> > (process_command): Handle OPT_[no_]canonical_prefixes, auto-detect
> > suitable default prefix canonicalization mode.
> > * common.opt (canonical-prefixes): New flag.
> > 
> > Google ref: 40029, 38719
> > 
> > 
> > Modified:
> > branches/google/integration/gcc/ChangeLog.google-integration
> > branches/google/integration/gcc/common.opt
> > branches/google/integration/gcc/doc/invoke.texi
> > branches/google/integration/gcc/gcc.c

WAITING on a reply

[Bug driver/40960] POSIX requires that option -D have a lower precedence than -U

2018-06-16 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40960

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80535

--- Comment #6 from Eric Gallager  ---
(In reply to Eric Gallager from comment #5)
> 
> Confirmed, I think a configure option would be a good way to go about it.

Other options as mentioned in bug 80535 comment 1 include respecting the
POSIXLY_CORRECT environment variable, and/or adding a -posix-std= flag to
mirror the existing -std= flag for the language standard

[Bug libstdc++/86188] New: Enhancement to std::merge, constexpr check of iterator types

2018-06-16 Thread joshua.r.marshall.1991 at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86188

Bug ID: 86188
   Summary: Enhancement to std::merge, constexpr check of iterator
types
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joshua.r.marshall.1991 at gmail dot com
  Target Milestone: ---

Before I go in an submitting patches all willy-nilly, I've been poking at
std::merge and I think I see that it could catch some programming bugs better
with constexpr std::iterator_traits::iterator_category == <>.  This looks simple, but there may also be a reason it hasn't been
done.

[Bug c++/86187] New: Subscript operator applied to an temporary array results in an lvalue

2018-06-16 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86187

Bug ID: 86187
   Summary: Subscript operator applied to an temporary array
results in an lvalue
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The code is as follow:

using Y = int[10];

int main() {
(Y { })[0] = 1;
}

The code comes from a discussion on Stackoverflow: 
http://stackoverflow.com/questions/33161003/using-a-temporary-array-as-an-lvalue
 

The problem was reported to clang and it was fixed:
https://bugs.llvm.org/show_bug.cgi?id=25357

Although now clang provides diagnostic, gcc++ still does not provide any error
messages. Please fix the problem.

[Bug c++/86186] New: Unqualified calls of std::get lead to ADL issues

2018-06-16 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86186

Bug ID: 86186
   Summary: Unqualified calls of std::get lead to ADL issues
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The sample code is as follow:

 #include 
 #include 

 namespace foo {
 struct bar { bool operator==(bar) const { return true; } };

 template 
 struct hard_error { static_assert(I > 0, ""); using type = void; };

 template 
 typename hard_error::type get(T) {}
 }

 int main()
 {
 std::tuple t1, t2;
 t1 == t2; // error: static_assert failed ""
 // note: in instantiation of template class 'foo::hard_error<0>'
 // note: while substituting explicitly-specified template arguments into
function template 'get' 
 }

A previous version of clang++ does not produce any error messages for the above
code, but it was fixed in https://bugs.llvm.org/show_bug.cgi?id=20092

[Bug c++/86185] New: gcc does not reject the ill-formed code

2018-06-16 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86185

Bug ID: 86185
   Summary: gcc does not reject the ill-formed code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

gcc++ does not produce any errors when it compiles the following code:

template
void f() {
  auto i = T(), j = 0;
}

int main() {
  f();
  f();
}

The code comes from a bug report of clang:
https://bugs.llvm.org/show_bug.cgi?id=9276

Johannes Schaub analyzed why clang shall reject the code. 
Shall gcc also reject the code?

[Bug c++/86184] New: Shall gcc support this feature?

2018-06-16 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86184

Bug ID: 86184
   Summary: Shall gcc support this feature?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

gcc++ produces errors when compiling the following code:

#include 

int main(int argc, char **argv) {
printf("%p\n", (void *)0xdeadbeef ? : (void *)0xaa);
return 0;
}


This code comes from a bug report of clang:
https://bugs.llvm.org/show_bug.cgi?id=7726

The programmers of clang discuss the code in details. They mentioned that gcc
does not accept the above code, but after all, they decide to implement the
feature to compile the code. 

Shall gcc also support this feature?

[Bug c++/86183] New: Scoped enumeration instantiated even if not required

2018-06-16 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86183

Bug ID: 86183
   Summary: Scoped enumeration instantiated even if not required
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

gcc produces errors when compiling the following code:

template
struct A {
 enum class B {
 X = T::value
 };
};

int main() {
 A a;
}

A previous version of clang++ also produces errors when compiling the above
code, but it was fixed in https://bugs.llvm.org/show_bug.cgi?id=10044

Shall gcc also fix the problem?

[Bug c++/86182] New: gcc crashes when compiling the code

2018-06-16 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86182

Bug ID: 86182
   Summary: gcc crashes when compiling the code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The code is as follow:

#include 

template static char const * f(T *t) {
 T u(*t);
 u.x = "hello world";
 printf("%s\n", u.x);
 return "initialized";
}

int main() {
 union { char const *x = f(this); };
 printf("%s\n", x);
}

gcc++ produces errors messages:

/home/haozhong/project/approach/otherreport/llvm/tmp/llvm_10531/code0.c.cpp: In
function ‘const char* f(T*) [with T = main()::]’:
   
/home/haozhong/project/approach/otherreport/llvm/tmp/llvm_10531/code0.c.cpp:3:42:
error:Local declaration from a different function
 template static char const * f(T *t) {
  ^
D.2918
   
/home/haozhong/project/approach/otherreport/llvm/tmp/llvm_10531/code0.c.cpp:4:4:
 
  T u(*t);
^
_1 = 
   
/home/haozhong/project/approach/otherreport/llvm/tmp/llvm_10531/code0.c.cpp:3:42:
error:Local declaration from a different function
 template static char const * f(T *t) {
  ^
   
/home/haozhong/project/approach/otherreport/llvm/tmp/llvm_10531/code0.c.cpp:3:42:
error:Local declaration from a different function
during GIMPLE pass: cfg
   
/home/haozhong/project/approach/otherreport/llvm/tmp/llvm_10531/code0.c.cpp:3:42:
internal error:verify_gimple 失败
0xf11023 verify_gimple_in_cfg(function*, bool)
../../code/gcc/tree-cfg.c:5585
0xdf808f execute_function_todo
../../code/gcc/passes.c:1994
0xdf8fde execute_todo
../../code/gcc/passes.c:2048

Please include the complete backtrace with any bug report.


The code comes from a bug report of clang++
https://bugs.llvm.org/show_bug.cgi?id=10531

The clang report can provide hints to understand the problem.

[Bug c++/86181] New: static object mangling conflicts

2018-06-16 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86181

Bug ID: 86181
   Summary: static object mangling conflicts
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

I found that gcc+ produces errors when it compiles the following code:
extern "C" void abort();
static int i;
int *p = 
int main()
{ 
 int i;
 { 
 extern int i;
 i = 1;
 *p = 2;
 if (i == 2)
 abort ();
 }
 return 0;
}

When compiling the above code, clang++ does not produce any errors. The code
comes from https://bugs.llvm.org/show_bug.cgi?id=5966

Indeed, the situation is more complicated. The above bug report of clang says
that the code comes from a bug report of gcc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31775

The gcc report has a long discussion on this issue. Perhaps, the bug is not
fully fixed?

[Bug c++/86180] New: Friend function definition not instantiated in certain circumstances

2018-06-16 Thread zhonghao at pku dot org.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86180

Bug ID: 86180
   Summary: Friend function definition not instantiated in certain
circumstances
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhonghao at pku dot org.cn
  Target Milestone: ---

The following code compiles fine on clang++:

template 
struct provide {
  friend T f() { return T(); }
};

void g() {
  void f();
  provide p;
  f();
}

int main() {
  g();
}

However, gcc++ reports that it cannot find the definition of f. 

Indeed, a previous version of clang++ cannot compile the above code either. It
was fixed in https://bugs.llvm.org/show_bug.cgi?id=9518

I believe that gcc++ shall also fix the bug, right?

[Bug c++/86177] Wnull-dereference warning for object file compile missing

2018-06-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177

--- Comment #5 from Jonathan Wakely  ---
Why add it there and not to every other warning option that depends on
interprocedural analysis and inlining?

If the dereference and the null pointer are in separate files, then of course
the compiler can't warn. That's just how C++ works.

[Bug c++/86177] Wnull-dereference warning for object file compile missing

2018-06-16 Thread jg at jguk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177

--- Comment #4 from Jonny Grant  ---
Thank you for your replies!

Could the -flto tip be added to the -Wnull-dereference documentation?

https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

[Bug middle-end/82479] missing popcount builtin detection

2018-06-16 Thread kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479

--- Comment #13 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sat Jun 16 21:39:31 2018
New Revision: 261682

URL: https://gcc.gnu.org/viewcvs?rev=261682=gcc=rev
Log:
gcc/ChangeLog:

2018-06-16  Kugan Vivekanandarajah  

PR middle-end/82479
* ipa-fnsummary.c (will_be_nonconstant_expr_predicate): Handle
CALL_EXPR.
* tree-scalar-evolution.c (interpret_expr): Likewise.
(expression_expensive_p): Likewise.
* tree-ssa-loop-ivopts.c (contains_abnormal_ssa_name_p): Likewise.
* tree-ssa-loop-niter.c (number_of_iterations_popcount): New.
(number_of_iterations_exit_assumptions): Use
number_of_iterations_popcount.
(ssa_defined_by_minus_one_stmt_p): New.

gcc/testsuite/ChangeLog:

2018-06-16  Kugan Vivekanandarajah  

PR middle-end/82479
* gcc.dg/tree-ssa/popcount.c: New test.
* gcc.dg/tree-ssa/popcount2.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/popcount.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/popcount2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-fnsummary.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-scalar-evolution.c
trunk/gcc/tree-ssa-loop-ivopts.c
trunk/gcc/tree-ssa-loop-niter.c

[Bug tree-optimization/64946] [AArch64] gcc.target/aarch64/vect-abs-compile.c - "abs" vectorization fails for char/short types

2018-06-16 Thread kugan at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946

--- Comment #24 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Sat Jun 16 21:34:29 2018
New Revision: 261681

URL: https://gcc.gnu.org/viewcvs?rev=261681=gcc=rev
Log:
gcc/ChangeLog:

2018-06-16  Kugan Vivekanandarajah  

PR middle-end/64946
* cfgexpand.c (expand_debug_expr): Hande ABSU_EXPR.
* config/i386/i386.c (ix86_add_stmt_cost): Likewise.
* dojump.c (do_jump): Likewise.
* expr.c (expand_expr_real_2): Check operand type's sign.
* fold-const.c (const_unop): Handle ABSU_EXPR.
(fold_abs_const): Likewise.
* gimple-pretty-print.c (dump_unary_rhs): Likewise.
* gimple-ssa-backprop.c (backprop::process_assign_use): Likesie.
(strip_sign_op_1): Likesise.
* match.pd: Add new pattern to generate ABSU_EXPR.
* optabs-tree.c (optab_for_tree_code): Handle ABSU_EXPR.
* tree-cfg.c (verify_gimple_assign_unary): Likewise.
* tree-eh.c (operation_could_trap_helper_p): Likewise.
* tree-inline.c (estimate_operator_cost): Likewise.
* tree-pretty-print.c (dump_generic_node): Likewise.
* tree-vect-patterns.c (vect_recog_sad_pattern): Likewise.
* tree.def (ABSU_EXPR): New.

gcc/c-family/ChangeLog:

2018-06-16  Kugan Vivekanandarajah  

* c-common.c (c_common_truthvalue_conversion): Handle ABSU_EXPR.

gcc/c/ChangeLog:

2018-06-16  Kugan Vivekanandarajah  

* c-typeck.c (build_unary_op): Handle ABSU_EXPR;
* gimple-parser.c (c_parser_gimple_statement): Likewise.
(c_parser_gimple_unary_expression): Likewise.

gcc/cp/ChangeLog:

2018-06-16  Kugan Vivekanandarajah  

* constexpr.c (potential_constant_expression_1): Handle ABSU_EXPR.
* cp-gimplify.c (cp_fold): Likewise.

gcc/testsuite/ChangeLog:

2018-06-16  Kugan Vivekanandarajah  

PR middle-end/64946
* gcc.dg/absu.c: New test.
* gcc.dg/gimplefe-29.c: New test.
* gcc.target/aarch64/pr64946.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/absu.c
trunk/gcc/testsuite/gcc.dg/gimplefe-29.c
trunk/gcc/testsuite/gcc.target/aarch64/pr64946.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/c/gimple-parser.c
trunk/gcc/cfgexpand.c
trunk/gcc/config/i386/i386.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-gimplify.c
trunk/gcc/dojump.c
trunk/gcc/expr.c
trunk/gcc/fold-const.c
trunk/gcc/gimple-pretty-print.c
trunk/gcc/gimple-ssa-backprop.c
trunk/gcc/match.pd
trunk/gcc/optabs-tree.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c
trunk/gcc/tree-eh.c
trunk/gcc/tree-inline.c
trunk/gcc/tree-pretty-print.c
trunk/gcc/tree-vect-patterns.c
trunk/gcc/tree.def

[Bug c/86179] ice in get_later_stmt, at tree-vectorizer.h:1108

2018-06-16 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86179

--- Comment #1 from David Binderman  ---
For this C code

c(int *d, char *g) {
  char *a, *b, *e;
  int f;
  for (; f; f -= 8) {
*d++ = *e++ | (unsigned)*g++ << 8 | (unsigned)*b++ << 16 |
   (unsigned)*a++ << 24;
*d++ = *e++ | (unsigned)*g++ << 8 | (unsigned)*b++ << 16 |
   (unsigned)*a++ << 24;
  }
}

compiled by recent gcc trunk and flag -O3, I get:

$ ~/gcc/results/bin/gcc -c -w -O3 bug446.c
during GIMPLE pass: vect
bug446.c: In function ‘c’:
bug446.c:1:1: internal compiler error: in get_later_stmt, at
tree-vectorizer.h:1108
 c(int *d, char *g) {
 ^
0x7df578 get_later_stmt
../../trunk/gcc/tree-vectorizer.h:1105
0x7df578 vect_find_last_scalar_stmt_in_slp(_slp_tree*)
../../trunk/gcc/tree-vect-slp.c:1819
0x316 vect_find_last_scalar_stmt_in_slp(_slp_tree*)
../../trunk/gcc/tree-vect-slp.c:1815
0x316 vect_schedule_slp_instance

$ ~/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.261680.ubsan/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.261680.ubsan
--with-build-config=bootstrap-ubsan --disable-multilib --disable-werror
--enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran
Thread model: posix
gcc version 9.0.0 20180616 (experimental) (GCC) 
$

[Bug c/86179] New: ice in get_later_stmt, at tree-vectorizer.h:1108

2018-06-16 Thread dcb314 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86179

Bug ID: 86179
   Summary: ice in get_later_stmt, at tree-vectorizer.h:1108
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

[Bug c++/85471] closing a "thread" in "C++" using "pthread_exit(NULL)" creates a "SIGABRT"

2018-06-16 Thread aotto1...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85471

--- Comment #4 from Andreas Otto  ---
change my C++ wrapper from "embedded data" (large amount of data) to just an
embedded pointer (only 8byte pointer in the C++ class)

→ the error is still there…

==57730== Process terminating with default action of signal 6 (SIGABRT)
==57730==at 0x6BA2F67: raise (raise.c:55)
==57730==by 0x6BA4339: abort (abort.c:78)
==57730==by 0x4178DD: _Unwind_SetGR (unwind-dw2.c:273)
==57730==by 0x409B8C: __gxx_personality_v0 (eh_personality.cc:712)
==57730==by 0x72AC4A4: _Unwind_ForcedUnwind_Phase2 (unwind.inc:175)
==57730==by 0x72ACA64: _Unwind_ForcedUnwind (unwind.inc:207)
==57730==by 0x696098F: __pthread_unwind (unwind.c:126)
==57730==by 0x695A8B4: __do_cancel (pthreadP.h:283)
==57730==by 0x695A8B4: pthread_exit (pthread_exit.c:28)
==57730==by 0x506554E: libmsgque::SysExit(int, int) (sys.cc:1000)
==57730==by 0x5059987: libmsgque::MqSysExit(int, int) (msgque.h:2038)
==57730==by 0x505B4F8: libmsgque::MqExitP(libmsgque::MqS*, char const*,
char const*) (msgque.cc:440)
==57730==by 0x50B2FAA: ccmsgque::MqC::ExitP(char const*, char const*)
(MqC.cc:380)
==57730==by 0x405EF7: Filter6::EXIT() (Filter6.cc:80)
==57730==by 0x5099A15: ccmsgque::MqC::ProcCall(libmsgque::MqS*, void*)
(ccmisc.cc:50)
==57730==by 0x5043DA3: libmsgque::MqCallbackCall(libmsgque::MqS*,
libmsgque::MqCallbackS) (msgque_private.h:326)
==57730==by 0x5045368: libmsgque::pTokenInvoke(libmsgque::pTokenS const*)
(token.cc:342)
==57730==by 0x507836C: libmsgque::pServiceStart(libmsgque::MqS*,
libmsgque::MqErrorE (*)(void*, libmsgque::MqS**, libmsgque::MqEnvS*), void*)
(service.cc:244)
==57730==by 0x502D33B: libmsgque::pEventStart(libmsgque::MqS*,
libmsgque::MqEventS*, timeval const*) (event.cc:287)
==57730==by 0x5055AD3: libmsgque::pIoSelectStart(libmsgque::MqIoS*, timeval
const*) (io.cc:267)
==57730==by 0x5078B3E: libmsgque::MqProcessEvent(libmsgque::MqS*, long,
libmsgque::MqWaitOnEventE) (service.cc:377)
==57730==by 0x5063F70:
libmsgque::MqSysServerThreadMain(libmsgque::MqSysServerThreadMainS*)
(sys.cc:488)
==57730==by 0x5063FB7: libmsgque::sSysServerThreadInit(void*) (sys.cc:502)
==57730==by 0x6959723: start_thread (pthread_create.c:457)
==57730==by 0x6C5AE8C: clone (clone.S:109)
==57730== 
==57730== HEAP SUMMARY:
==57730== in use at exit: 160,370 bytes in 184 blocks
==57730==   total heap usage: 940 allocs, 756 frees, 677,695 bytes allocated
==57730== 
==57922== 
==57922== HEAP SUMMARY:
==57922== in use at exit: 72,944 bytes in 4 blocks
==57922==   total heap usage: 487 allocs, 483 frees, 273,097 bytes allocated
==57922== 
==57922== LEAK SUMMARY:
==57922==definitely lost: 0 bytes in 0 blocks
==57922==indirectly lost: 0 bytes in 0 blocks
==57922==  possibly lost: 0 bytes in 0 blocks
==57922==still reachable: 72,944 bytes in 4 blocks
==57922== suppressed: 0 bytes in 0 blocks
==57922== Rerun with --leak-check=full to see details of leaked memory
==57922== 
==57922== For counts of detected and suppressed errors, rerun with: -v
==57922== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==57730== LEAK SUMMARY:


but I have additional "leakcheck" data…


 trans2-3-TE2-init-(3|binary|uds|cc.uds.thread) start
==67406== 672 bytes in 2 blocks are possibly lost in loss record 131 of 151
==67406==at 0x4C2C240: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==67406==by 0x40119E1: allocate_dtv (dl-tls.c:322)
==67406==by 0x401223D: _dl_allocate_tls (dl-tls.c:539)
==67406==by 0x695A180: allocate_stack (allocatestack.c:580)
==67406==by 0x695A180: pthread_create@@GLIBC_2.2.5 (pthread_create.c:654)
==67406==by 0x5064231: libmsgque::SysServerThread(libmsgque::MqS*,
libmsgque::MqFactoryS*, libmsgque::MqBufferLS**, libmsgque::MqBufferLS**, char
const*, int, libmsgque::MqIdS*) (sys.cc:562)
==67406==by 0x5057E6F: libmsgque::pIoStartServer(libmsgque::MqIoS*,
libmsgque::IoStartServerE, libmsgque::MqSockS*, libmsgque::MqIdS*) (io.cc:692)
==67406==by 0x5053294: libmsgque::GenericServer(libmsgque::GenericS*,
sockaddr*, unsigned int) (generic_io.cc:155)
==67406==by 0x5048FE9: libmsgque::UdsServer(libmsgque::UdsS*)
(uds_io.cc:129)
==67406==by 0x505421E: libmsgque::pIoCreate(libmsgque::MqS*,
libmsgque::MqIoS**) (io.cc:95)
==67406==by 0x5083507: libmsgque::MqLinkCreate(libmsgque::MqS*,
libmsgque::MqBufferLS*) (link.cc:1104)
==67406==by 0x5084730: libmsgque::MqLinkDefault(libmsgque::MqS*,
libmsgque::MqBufferLS*) (link.cc:1256)
==67406==by 0x5082279: libmsgque::MqLinkCreate(libmsgque::MqS*,
libmsgque::MqBufferLS*) (link.cc:971)
==67406==by 0x50B3ACD: ccmsgque::MqC::LinkCreate(ccmsgque::MqBufferLC*)
(MqC.cc:414)
==67406==by 0x5095DE2: ccmsgque::MqC::LinkCreate(ccmsgque::MqBufferLC)
(ccmsgque.cc:151)
==67406==by 0x40498B: main (Filter6.cc:176)
==67406==

[Bug c++/86177] Wnull-dereference warning for object file compile missing

2018-06-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
If you compile with -flto then the link-time optimizations can see across
translation units and give a warning. Otherwise it's impossible.

Another alternative would be to decorate the function with
__attribute__((nonnull)) which says it requires a non-null pointer:

extern __attribute__((nonnull)) void f(int* i);

Now you'll get a warning when compiling main2.cpp because the compiler can see
you're passing a null pointer to a function that says it requires non-null
pointers:

b.cc: In function ‘int main()’:
b.cc:5:14: warning: null argument where non-null required (argument 1)
[-Wnonnull]
 f(nullptr);
  ^

[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference

2018-06-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172
Bug 86172 depends on bug 86177, which changed state.

Bug 86177 Summary: Wnull-dereference warning for object file compile missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177

   What|Removed |Added

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

[Bug c/86178] No warning when missing return from function main()

2018-06-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86178

--- Comment #2 from Jonathan Wakely  ---
See 4) at http://en.cppreference.com/w/cpp/language/main_function#Explanation

There's also an implicit "return 0;" for C, but only since C99 and only when
the return type of main is compatible with int. See 3) at 
http://en.cppreference.com/w/c/language/main_function

[Bug c++/86177] Wnull-dereference warning for object file compile missing

2018-06-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177

--- Comment #2 from Jonathan Wakely  ---
That's how C++ works. Each translation unit is compiled separately. It's your
job to prevent such errors.

[Bug c/86178] No warning when missing return from function main()

2018-06-16 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86178

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
You've set component=c but you're using g++ which means you're compiling C++
and so there's an implicit "return 0;" from main.

[Bug c/86178] New: No warning when missing return from function main()

2018-06-16 Thread jg at jguk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86178

Bug ID: 86178
   Summary: No warning when missing return from function main()
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Hello, should GCC show an error when "return" is missing from function main()
below ? Maybe I am missing something...

jonny@asus:~/code$ g++ -O2 -Wreturn-type -Wall -Wextra -Wnull-dereference
-Wpedantic -o main main3.cpp
jonny@asus:~/code$ 

I expected:
In function ‘main’:
warning: control reaches end of non-void function [-Wreturn-type]



//g++-8 -O2 -Wreturn-type  -Wall -Wextra -Wnull-dereference -Wpedantic -o main
main3.cpp

#include 

int main(void)
{
   printf("hello\n");
   // return
}

[Bug c++/86177] Wnull-dereference warning for object file compile missing

2018-06-16 Thread jg at jguk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177

--- Comment #1 from Jonny Grant  ---
If g++ compiles both main.cpp and main2.cpp at the same time (ie no separate
obj file stage) it also doesn't give the expected warning.

jonny@asus:~/code$ g++-8 -O2 -Wall -Wextra -Wnull-dereference -Wpedantic -o
main main2.cpp main.cpp
jonny@asus:~/code$

[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool

2018-06-16 Thread TonyELewis at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80485

--- Comment #7 from Tony E Lewis  ---
Ah yes - I'm seeing it compiling cleanly now on Godbolt's trunk (9.0.0
20180615).

Must have been a temporary glitch in the build (and couldn't possibly have been
due to my error :P ).

[Bug c/86174] Poor vectorization/register allocation with omp simd, FMA

2018-06-16 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86174

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #1 from Alexander Monakov  ---
It might be useful to note that what the testcase "wants" to happen is for the
compiler to notice that the temporary array 'double C[Si][Sk]' does not need to
live in memory - ideally it would correspond to 8 256-bit (or 4 512-bit)
registers.

[Bug c++/86177] New: Wnull-dereference warning for object file compile missing

2018-06-16 Thread jg at jguk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86177

Bug ID: 86177
   Summary: Wnull-dereference warning for object file compile
missing
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Hello

This doesn't give any warning that the pointer is not checked when being
compiled. If linked with second program example below, there is no issue
visible. Then crashes when runs:

jonny@asus:~/code$ ./main
Segmentation fault (core dumped)

//g++-8 -O2 -Wall -Wextra -Wnull-dereference -Wpedantic -o main -c main.cpp

void f(int *i)
{
*i = 1;
}





//g++-8 -O2 -Wall -Wextra -Wnull-dereference -Wpedantic main1.o -o main
main2.cpp

extern void f(int* i);

int main()
{
f(nullptr);

   // return
}

[Bug c++/86176] New: Wnull-dereference warning disappears with a call to std::cout on the line after

2018-06-16 Thread jg at jguk dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86176

Bug ID: 86176
   Summary: Wnull-dereference warning disappears with a call to
std::cout on the line after
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jg at jguk dot org
  Target Milestone: ---

Hello

Some possible issues. Could you give your opinion please.

1. printf Wnull-dereference warning is only visible with -O2 (not -O0)
2. printf Wnull-dereference warning disappears if I uncomment the std::cout on
line after.

There is bug 86172 but I have not linked it.

note, I also tried g++8.1 x86-64, same results.


g++-8 --version
g++-8 (Ubuntu 8-20180414-1ubuntu2) 8.0.1 20180414 (experimental) [trunk
revision 259383]

jonny@asus:~/code$ g++-8 -O0 -Wall -Wextra -Wnull-dereference -Wpedantic -o
main.o -c main.cpp
jonny@asus:~/code$ g++-8 -O2 -Wall -Wextra -Wnull-dereference -Wpedantic -o
main.o -c main.cpp
main.cpp: In function ‘int main()’:
main.cpp:8:11: warning: null pointer dereference [-Wnull-dereference]
 printf("%d\n", *i);
 ~~^~~~
jonny@asus:~/code$ 



#include 
#include 

void f(const int *i)
{
printf("%d\n", *i);
//std::cout << *i;
}

int main () {
  f(nullptr);
  return 0;
}

[Bug lto/86175] New: LTO code generator does not respect ld -u option to force symbol inclusion in the link product

2018-06-16 Thread zenith432 at users dot sourceforge.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86175

Bug ID: 86175
   Summary: LTO code generator does not respect ld -u option to
force symbol inclusion in the link product
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zenith432 at users dot sourceforge.net
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 44288
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44288=edit
Test case to demonstrate bug

Please see test case in attached file that contains
Makefile
test.c

GCC is 8.1.1
ld is from binutils 2.29.1

Compiling with -flto and attempting to force inclusion of a symbol with hidden
visibility.  The symbol is discarded.

make
gcc -o test1   -fvisibility=default -ffunction-sections
-Wl,--gc-sections,-u,KeepMe test.c
strings test1 | grep This
This string should appear in the executable.
gcc -o test2 -flto -fvisibility=default -ffunction-sections
-Wl,--gc-sections,-u,KeepMe test.c
strings test2 | grep This
This string should appear in the executable.
gcc -o test3   -fvisibility=hidden  -ffunction-sections
-Wl,--gc-sections,-u,KeepMe test.c
strings test3 | grep This
This string should appear in the executable.
gcc -o test4 -flto -fvisibility=hidden  -ffunction-sections
-Wl,--gc-sections,-u,KeepMe test.c
strings test4 | grep This
make: [Makefile:18: test4] Error 1 (ignored)

[Bug c/86174] New: Poor vectorization/register allocation with omp simd, FMA

2018-06-16 Thread jed at 59A2 dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86174

Bug ID: 86174
   Summary: Poor vectorization/register allocation with omp simd,
FMA
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jed at 59A2 dot org
  Target Milestone: ---

Created attachment 44287
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44287=edit
Source demonstrating poor optimization

The attached code produces lots of needless spills with gcc-8.1 on Linux.

$ gcc -O3 -Wall -march=skylake -ffast-math -fopenmp -c mm-gcc.c

0080  vbroadcastsd ymm2,QWORD PTR [rdx]
0085  vmovupd ymm1,YMMWORD PTR [rcx]
0089  vmovapd ymm0,ymm1
008d  vfmadd213pd ymm0,ymm2,YMMWORD PTR [rsp]
0093  vmovapd YMMWORD PTR [rsp],ymm0
0098  vmovupd ymm0,YMMWORD PTR [rcx+0x20]
009d  vfmadd213pd ymm2,ymm0,YMMWORD PTR [rsp+0x20]
00a4  vmovapd YMMWORD PTR [rsp+0x20],ymm2
00aa  vbroadcastsd ymm2,QWORD PTR [rdx+0x400]
00b3  vmovapd ymm3,ymm1
00b7  vfmadd213pd ymm3,ymm2,YMMWORD PTR [rsp+0x40]
00be  vmovapd YMMWORD PTR [rsp+0x40],ymm3
00c4  vfmadd213pd ymm2,ymm0,YMMWORD PTR [rsp+0x60]
00cb  vmovapd YMMWORD PTR [rsp+0x60],ymm2
00d1  vbroadcastsd ymm2,QWORD PTR [rdx+0x800]
00da  vmovapd ymm3,ymm1
00de  vfmadd213pd ymm3,ymm2,YMMWORD PTR [rsp+0x80]
00e8  vmovapd YMMWORD PTR [rsp+0x80],ymm3
00f1  vfmadd213pd ymm2,ymm0,YMMWORD PTR [rsp+0xa0]
00fb  vmovapd YMMWORD PTR [rsp+0xa0],ymm2
0104  vbroadcastsd ymm2,QWORD PTR [rdx+0xc00]
010d  vfmadd213pd ymm1,ymm2,YMMWORD PTR [rsp+0xc0]
0117  vmovapd YMMWORD PTR [rsp+0xc0],ymm1
0120  vfmadd213pd ymm0,ymm2,YMMWORD PTR [rsp+0xe0]
012a  vmovapd YMMWORD PTR [rsp+0xe0],ymm0
0133  addrdx,0x8
0137  addrcx,0x400
013e  cmprsi,rcx
0141  jne0080 

GCC does not issue vector instructions if omp simd is removed.  In contrast,
clang-6 vectorizes well with or without omp simd:

$ clang -O3 -Wall -march=haswell -ffast-math -c mm-gcc.c

00e0  vmovapd ymm9,ymm6
00e4  vbroadcastsd ymm10,QWORD PTR [rdi+rbx*8-0x800]
00ee  vmovupd ymm6,YMMWORD PTR [rax-0x20]
00f3  vmovupd ymm11,YMMWORD PTR [rax]
00f7  vfmadd231pd ymm1,ymm6,ymm10
00fc  vfmadd231pd ymm7,ymm11,ymm10
0101  vbroadcastsd ymm10,QWORD PTR [rdi+rbx*8-0x400]
010b  vfmadd231pd ymm8,ymm6,ymm10
0110  vfmadd231pd ymm5,ymm11,ymm10
0115  vbroadcastsd ymm10,QWORD PTR [rdi+rbx*8]
011b  vfmadd231pd ymm2,ymm6,ymm10
0120  vfmadd231pd ymm3,ymm11,ymm10
0125  vbroadcastsd ymm10,QWORD PTR [rdi+rbx*8+0x400]
012f  vfmadd213pd ymm6,ymm10,ymm9
0134  vfmadd231pd ymm4,ymm11,ymm10
0139  addrax,0x400
013f  addrbx,0x1
0143  jne00e0 

(I used -march=haswell instead of -march=skylake due to
https://bugs.llvm.org/show_bug.cgi?id=37819.)

[Bug libstdc++/80335] perf of copying std::optional

2018-06-16 Thread sgunderson at bigfoot dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80335

--- Comment #3 from sgunderson at bigfoot dot com ---
Appears to have been fixed in GCC 8, indeed.

#include 

std::optional func()
{
return 3;
}

GCC 7 (-O2) compiles to:

   0:   48 89 f8mov%rdi,%rax
   3:   c7 07 03 00 00 00   movl   $0x3,(%rdi)
   9:   c6 47 04 01 movb   $0x1,0x4(%rdi)
   d:   c3  retq   

GCC 8 (-O2):

   0:   48 b8 03 00 00 00 01movabs $0x10003,%rax
   7:   00 00 00 
   a:   c3  retq   

This is an ABI break, but I'll happily take it. :-)

[Bug c++/86171] [6/7/8/9 Regression] g++ ICE on valid code: tree check: expected var_decl or function_decl, have type_decl in duplicate_decls, at cp/decl.c:2291

2018-06-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86171

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Version|unknown |9.0
   Keywords||ice-checking
   Last reconfirmed||2018-06-16
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|g++  ICE on valid code: |[6/7/8/9 Regression] g++
   |tree check: expected|ICE on valid code: tree
   |var_decl or function_decl,  |check: expected var_decl or
   |have type_decl in   |function_decl, have
   |duplicate_decls, at |type_decl in
   |cp/decl.c:2291  |duplicate_decls, at
   ||cp/decl.c:2291
   Target Milestone|--- |6.5

--- Comment #1 from Jakub Jelinek  ---
Started with r181118.

[Bug c++/86173] Default construction of a union (in std::optional)

2018-06-16 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86173

--- Comment #1 from Marc Glisse  ---
Note that constructing optional from std::nullopt does avoid the memset.

[Bug libstdc++/80335] perf of copying std::optional

2018-06-16 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80335

Marc Glisse  changed:

   What|Removed |Added

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

--- Comment #2 from Marc Glisse  ---
Looks like this is fixed. Although the limitations discussed are present:
optional> copies the whole array even if it is never
engaged.

[Bug c++/86173] New: Default construction of a union (in std::optional)

2018-06-16 Thread glisse at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86173

Bug ID: 86173
   Summary: Default construction of a union (in std::optional)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

Default construction of std::optional always starts with a memset of the
whole optional to 0, while it doesn't with clang using the same libstdc++.

#include 
struct AA {
  double a[1024];
#ifndef TRIVIAL
  AA(); AA(AA const&); AA& operator=(AA const&); ~AA();
#endif
};
typedef std::optional O;
// O fff(){ return {}; }
O fff(){ O o; return o; }

The .original dump has

* = {.D.34926={._M_payload={.D.34026={._M_empty={}}, ._M_engaged=0}}}

which looks good, it says it is initializing the small _M_empty part of the
union, but the gimple dump has

* = {};

which eagerly zeroes everything.

[Bug middle-end/86095] [8/9 Regression] documentation for -Wunsafe-loop-optimizations references options which have no effect any more

2018-06-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86095

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed for 8.2+.

[Bug middle-end/86095] [8/9 Regression] documentation for -Wunsafe-loop-optimizations references options which have no effect any more

2018-06-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86095

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Sat Jun 16 06:51:32 2018
New Revision: 261679

URL: https://gcc.gnu.org/viewcvs?rev=261679=gcc=rev
Log:
PR middle-end/86095
* common.opt (Wunsafe-loop-optimizations): Add Ignore, remove Var,
documented as preserved for backward compatibility only.
* doc/invoke.texi: Remove -Wunsafe-loop-optimizations documentation.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/doc/invoke.texi

[Bug middle-end/86095] [8/9 Regression] documentation for -Wunsafe-loop-optimizations references options which have no effect any more

2018-06-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86095

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Sat Jun 16 06:52:17 2018
New Revision: 261680

URL: https://gcc.gnu.org/viewcvs?rev=261680=gcc=rev
Log:
PR middle-end/86095
* common.opt (Wunsafe-loop-optimizations): Add Ignore, remove Var,
documented as preserved for backward compatibility only.
* doc/invoke.texi: Remove -Wunsafe-loop-optimizations documentation.

Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/common.opt
branches/gcc-8-branch/gcc/doc/invoke.texi

[Bug rtl-optimization/86108] [8/9 Regression] crash during unwinding with -O2

2018-06-16 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86108

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Sat Jun 16 06:50:31 2018
New Revision: 261678

URL: https://gcc.gnu.org/viewcvs?rev=261678=gcc=rev
Log:
PR rtl-optimization/86108
* bb-reorder.c (create_forwarder_block): Renamed to ...
(create_eh_forwarder_block): ... this.  Split OLD_BB after labels and
jump from new landing pad to the second part.
(sjlj_fix_up_crossing_landing_pad, dw2_fix_up_crossing_landing_pad):
Adjust callers.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/bb-reorder.c

[Bug c++/86147] [8/9 Regression] Lambda is capturing a non-ODR-used constexpr

2018-06-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86147

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Sat Jun 16 06:35:53 2018
New Revision: 261676

URL: https://gcc.gnu.org/viewcvs?rev=261676=gcc=rev
Log:
PR c++/86147 - wrong capture for template argument.

* expr.c (mark_use): Look through NOP_EXPR.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/expr.c

[Bug c++/86147] [8/9 Regression] Lambda is capturing a non-ODR-used constexpr

2018-06-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86147

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Sat Jun 16 06:35:53 2018
New Revision: 261676

URL: https://gcc.gnu.org/viewcvs?rev=261676=gcc=rev
Log:
PR c++/86147 - wrong capture for template argument.

* expr.c (mark_use): Look through NOP_EXPR.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/expr.c

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Sat Jun 16 06:36:19 2018
New Revision: 261677

URL: https://gcc.gnu.org/viewcvs?rev=261677=gcc=rev
Log:
PR c++/86147 - wrong capture for template argument.

* expr.c (mark_use): Look through NOP_EXPR.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const9.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/expr.c

[Bug c++/86147] [8/9 Regression] Lambda is capturing a non-ODR-used constexpr

2018-06-16 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86147

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Sat Jun 16 06:36:19 2018
New Revision: 261677

URL: https://gcc.gnu.org/viewcvs?rev=261677=gcc=rev
Log:
PR c++/86147 - wrong capture for template argument.

* expr.c (mark_use): Look through NOP_EXPR.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const9.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/expr.c