[Bug c/45780] Warning for arithmetic operations involving C99 _Bool variable

[egallager at gcc dot gnu.org]

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

--- Comment #7 from Eric Gallager  ---
(In reply to Uroš Bizjak from comment #0)
> > >> It can be done ultimately, but as a prerequisite, we should have
> > >> warnings in -Wextra for all of
> > >>
> > >> ? boolvar++; ++boolvar;
> > >> ? boolvar--; --boolvar;
> > >> ? boolvar = nonbool;
> > >> ? boolvar & nonbool; boolvar &= nonbool;
> > >> ? boolvar | nonbool; boolvar |= nonbool;
> > >> ? boolvar ^ nonbool; boolvar ^= nonbool;
> > >
> > > Fair enough. I have CCed Manuel, perhaps he is interested in this warning.
> > 
> > I am not sure it fits in -Wconversion. -Wbool-arith perhaps?
> 

I made a testcase that includes all of those:

$ cat 45780.c
#include 
#include 

static bool f1(int i)
{
  return i;
}

static bool f2(int i)
{
  i = !!i;
  return i;
}

int main(int argc, char **argv)
{
  bool a = true;
  bool b = a++;
  bool c = ++b;
  bool d = argc;
  bool e = a & argc;
  bool f = b | argc;
  bool g = c ^ argc;
  f &= argc;
  g |= argc;
  e ^= argc;
  if (f1(argc))
e--;
  else
--e;
  if (!!argc)
return ((argv != NULL) ? d : ((f > g) ? e : (f << g)));
  else
return f2(argc);
}
$

gcc's -Wbool-operation currently catches the increments and decrements, but
none of the rest of the operations:

$ /usr/local/bin/gcc -c -Wall -Wextra -Wbool-compare -Wint-in-bool-context
-Wparentheses -pedantic -Wconversion 45780.c
45780.c: In function 'main':
45780.c:18:13: warning: increment of a boolean expression [-Wbool-operation]
   18 |   bool b = a++;
  | ^~
45780.c:19:12: warning: increment of a boolean expression [-Wbool-operation]
   19 |   bool c = ++b;
  |^~
45780.c:28:6: warning: decrement of a boolean expression [-Wbool-operation]
   28 | e--;
  |  ^~
45780.c:30:5: warning: decrement of a boolean expression [-Wbool-operation]
   30 | --e;
  | ^~
$

[Bug fortran/88139] ICE in get_c_type_name, at fortran/dump-parse-tree.c:3047

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from kargl at gcc dot gnu.org ---
It seems that my patch for PR fortran/85780
and committed as 

r268277 | kargl | 2019-01-25 09:55:25 -0800 (Fri, 25 Jan 2019) | 11 lines

2019-01-25  Steven G. Kargl  

PR fortran/85780
* decl.c (gfc_match_subroutine): Check for conflict between BIND(C)
and alternative return.

2019-01-25  Steven G. Kargl  

PR fortran/85780
* gfortran.dg/pr85780.f90: Update testcase for error message.

Fixes this PR.  Closing.

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

[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504

[kargl at gcc dot gnu.org]

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

--- Comment #12 from kargl at gcc dot gnu.org ---
*** Bug 88139 has been marked as a duplicate of this bug. ***

[Bug target/34484] libgcc should check if feclearexcept (and others) available for BID support on uclibc

[egallager at gcc dot gnu.org]

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

--- Comment #15 from Eric Gallager  ---
(In reply to Bernhard Reutner-Fischer from comment #8)
> From FSFChangelog.10:
> Mon Feb 12 20:42:11 1996  Randy Smith  
>

Does Randy have a Bugzilla account that could be cc-ed here?

[Bug c/86157] Wmisleading-indentation disabled after a #line directive

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
cc-ing author of -Wmisleading-indentation

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[zackw at panix dot com]

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

--- Comment #13 from Zack Weinberg  ---
Since examples of this error were observed with base 10, I think the warning
should cover 10^i for decimal literal i, too.

Relatedly, “note: ^ performs exclusive or, not exponentiation” might be a nice
addition to the existing error for ^ with a float for either operand.

[Bug ada/90889] New: ada: snapshot 20190614 fails to build with LTO

[jason.duerstock at gmail dot com]

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

Bug ID: 90889
   Summary: ada: snapshot 20190614 fails to build with LTO
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason.duerstock at gmail dot com
  Target Milestone: ---

From debian gcc-snapshot-20190614:

https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot=amd64=1%3A20190614-1=1560510118=0

/<>/build/./prev-gcc/gcc-ar -B/<>/build/./prev-gcc/
rcT libbackend.a gimple-match.o generic-match.o insn-attrtab.o insn-automata.o
insn-dfatab.o insn-emit.o insn-extract.o insn-latencytab.o insn-modes.o
insn-opinit.o insn-output.o insn-peep.o insn-preds.o insn-recog.o insn-enums.o
ggc-page.o alias.o alloc-pool.o auto-inc-dec.o auto-profile.o bb-reorder.o
bitmap.o bt-load.o builtins.o caller-save.o calls.o ccmp.o cfg.o cfganal.o
cfgbuild.o cfgcleanup.o cfgexpand.o cfghooks.o cfgloop.o cfgloopanal.o
cfgloopmanip.o cfgrtl.o symtab.o cgraph.o cgraphbuild.o cgraphunit.o
cgraphclones.o combine.o combine-stack-adj.o compare-elim.o context.o convert.o
coverage.o cppbuiltin.o cppdefault.o cprop.o cse.o cselib.o data-streamer.o
data-streamer-in.o data-streamer-out.o dbxout.o dbgcnt.o dce.o ddg.o debug.o
df-core.o df-problems.o df-scan.o dfp.o dojump.o dominance.o domwalk.o
double-int.o dse.o dumpfile.o dwarf2asm.o dwarf2cfi.o dwarf2out.o early-remat.o
emit-rtl.o et-forest.o except.o explow.o expmed.o expr.o fibonacci_heap.o
file-prefix-map.o final.o fixed-value.o fold-const.o fold-const-call.o
function.o function-tests.o fwprop.o gcc-rich-location.o gcse.o gcse-common.o
ggc-common.o ggc-tests.o gimple.o gimple-builder.o gimple-expr.o
gimple-iterator.o gimple-fold.o gimple-laddress.o gimple-loop-interchange.o
gimple-loop-jam.o gimple-loop-versioning.o gimple-low.o gimple-pretty-print.o
gimple-ssa-backprop.o gimple-ssa-evrp.o gimple-ssa-evrp-analyze.o
gimple-ssa-isolate-paths.o gimple-ssa-nonnull-compare.o
gimple-ssa-split-paths.o gimple-ssa-store-merging.o
gimple-ssa-strength-reduction.o gimple-ssa-sprintf.o gimple-ssa-warn-alloca.o
gimple-ssa-warn-restrict.o gimple-streamer-in.o gimple-streamer-out.o
gimple-walk.o gimplify.o gimplify-me.o godump.o graph.o graphds.o graphite.o
graphite-isl-ast-to-gimple.o graphite-dependences.o graphite-optimize-isl.o
graphite-poly.o graphite-scop-detection.o graphite-sese-to-poly.o gtype-desc.o
haifa-sched.o hash-map-tests.o hash-set-tests.o hsa-common.o hsa-gen.o
hsa-regalloc.o hsa-brig.o hsa-dump.o hw-doloop.o hwint.o ifcvt.o ree.o
inchash.o incpath.o init-regs.o internal-fn.o ipa-cp.o ipa-devirt.o
ipa-fnsummary.o ipa-polymorphic-call.o ipa-split.o ipa-inline.o ipa-comdats.o
ipa-visibility.o ipa-inline-analysis.o ipa-inline-transform.o ipa-predicate.o
ipa-profile.o ipa-prop.o ipa-param-manipulation.o ipa-pure-const.o ipa-icf.o
ipa-icf-gimple.o ipa-reference.o ipa-hsa.o ipa-ref.o ipa-utils.o ipa.o ira.o
ira-build.o ira-costs.o ira-conflicts.o ira-color.o ira-emit.o ira-lives.o
jump.o langhooks.o lcm.o lists.o loop-doloop.o loop-init.o loop-invariant.o
loop-iv.o loop-unroll.o lower-subreg.o lra.o lra-assigns.o lra-coalesce.o
lra-constraints.o lra-eliminations.o lra-lives.o lra-remat.o lra-spills.o
lto-cgraph.o lto-streamer.o lto-streamer-in.o lto-streamer-out.o
lto-section-in.o lto-section-out.o lto-opts.o lto-compress.o mcf.o
mode-switching.o modulo-sched.o multiple_target.o omp-offload.o omp-expand.o
omp-general.o omp-grid.o omp-low.o omp-simd-clone.o opt-problem.o optabs.o
optabs-libfuncs.o optabs-query.o optabs-tree.o optinfo.o optinfo-emit-json.o
options-save.o opts-global.o passes.o plugin.o postreload-gcse.o postreload.o
predict.o print-rtl.o print-rtl-function.o print-tree.o profile.o
profile-count.o read-md.o read-rtl.o read-rtl-function.o real.o realmpfr.o
recog.o reg-stack.o regcprop.o reginfo.o regrename.o regstat.o reload.o
reload1.o reorg.o resource.o rtl-error.o rtl-tests.o rtl.o rtlhash.o rtlanal.o
rtlhooks.o rtx-vector-builder.o run-rtl-passes.o sched-deps.o sched-ebb.o
sched-rgn.o sel-sched-ir.o sel-sched-dump.o sel-sched.o selftest-rtl.o
selftest-run-tests.o sese.o shrink-wrap.o simplify-rtx.o sparseset.o
spellcheck.o spellcheck-tree.o sreal.o stack-ptr-mod.o statistics.o stmt.o
stor-layout.o store-motion.o streamer-hooks.o stringpool.o
substring-locations.o target-globals.o targhooks.o timevar.o toplev.o tracer.o
trans-mem.o tree-affine.o asan.o tsan.o ubsan.o sanopt.o sancov.o
tree-call-cdce.o tree-cfg.o tree-cfgcleanup.o tree-chrec.o tree-complex.o
tree-data-ref.o tree-dfa.o tree-diagnostic.o tree-dump.o tree-eh.o
tree-emutls.o tree-if-conv.o tree-inline.o tree-into-ssa.o tree-iterator.o
tree-loop-distribution.o tree-nested.o tree-nrv.o tree-object-size.o
tree-outof-ssa.o tree-parloops.o tree-phinodes.o tree-predcom.o
tree-pretty-print.o tree-profile.o tree-scalar-evolution.o tree-sra.o

[Bug middle-end/90888] std::swap bad code gen -- alias analysis insufficient to remove dead store

[david at doublewise dot net]

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

David Stone  changed:

   What|Removed |Added

 CC||david at doublewise dot net

--- Comment #1 from David Stone  ---
Forgot to mention, this occurs at -O1, -O2, -Os, -O3

[Bug fortran/65819] overzealous checking in gfc_check_dependency for identical=true

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Is this PR still a problem?  I get no warnings with 
>
> % gfcx -o z -Wall -Wsurprising -Wextra a.f90

You need -Warray-temporaries and it is still present at revision r272311.

[Bug c/88000] Warn when different local vars regs order may produce different and so unsupported code [-Wasm-register-var]

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Keywords||diagnostic
   Last reconfirmed||2019-06-15
 CC||egallager at gcc dot gnu.org
 Resolution|INVALID |---
 Blocks||87403
 Ever confirmed|0   |1
Summary|Different local vars regs   |Warn when different local
   |order may produce different |vars regs order may produce
   |and so wrong code   |different and so
   ||unsupported code
   ||[-Wasm-register-var]

--- Comment #5 from Eric Gallager  ---
(In reply to Martin Sebor from comment #4)
> GCC could help by issuing a warning for unsupported uses, like in the
> prototype patch below:
> 
> Index: gcc/c/c-typeck.c
> ===
> --- gcc/c/c-typeck.c  (revision 266033)
> +++ gcc/c/c-typeck.c  (working copy)
> @@ -6505,6 +6505,14 @@ convert_for_assignment (location_t location, locat
>objc_ok = objc_compare_types (type, rhstype, parmno, rname);
>  }
>  
> +  if (VAR_P (rhs) && DECL_HARD_REGISTER (rhs)
> +  && warning_at (expr_loc, OPT_Wasm_register_var,
> +  "unsupported use of a hard register %qD as "
> +  "argument %d of %qE",
> +  rhs, parmnum, rname))
> +inform (DECL_SOURCE_LOCATION (rhs),
> + "%qD declared here", rhs);
> +
>if (warn_cxx_compat)
>  {
>tree checktype = origtype != NULL_TREE ? origtype : rhstype;
> Index: gcc/c-family/c.opt
> ===
> --- gcc/c-family/c.opt(revision 266033)
> +++ gcc/c-family/c.opt(working copy)
> @@ -338,6 +338,10 @@ Warray-bounds=
>  LangEnabledBy(C ObjC C++ LTO ObjC++,Wall,1,0)
>  ; in common.opt
>  
> +Wasm-register-var
> +ObjC ObjC++ Var(warn_asm_register_var) Warning LangEnabledBy(C ObjC C++
> ObjC++, Wall)
> +Warn for unsupported uses of variables declared asm register.
> +
>  Wassign-intercept
>  ObjC ObjC++ Var(warn_assign_intercept) Warning
>  Warn whenever an Objective-C assignment is being intercepted by the garbage
> collector.

Reopening to confirm the part about this warning request at least


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug c++/87403] [Meta-bug] Issues that suggest a new warning

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 88000, which changed state.

Bug 88000 Summary: Warn when different local vars regs order may produce 
different and so unsupported code [-Wasm-register-var]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88000

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

[Bug c++/86501] shadow template parameter

[richard-gccbugzilla at metafoo dot co.uk]

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

Richard Smith  changed:

   What|Removed |Added

 CC||richard-gccbugzilla@metafoo
   ||.co.uk

--- Comment #2 from Richard Smith  ---
I think EDG and Clang are wrong here and GCC is right. The template friend
declaration introduces V into the global namespace, so it is not "redeclared
within its scope" (per [temp.local]p6).

[Bug c++/60223] [c++11] ICE with C++11-style default template parameter

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Still ICEs:

$ ./cc1plus -quiet 60223.C
60223.C: In substitution of ‘template void foo(A) [with T =
]’:
60223.C:7:16:   required from here
60223.C:7:16: internal compiler error: in unify, at cp/pt.c:22789
7 |   foo(A());
  |^
0xaef167 unify
/home/mpolacek/src/gcc/gcc/cp/pt.c:22789
0xaed61d unify
/home/mpolacek/src/gcc/gcc/cp/pt.c:22553
0xae91d1 try_class_unification
/home/mpolacek/src/gcc/gcc/cp/pt.c:21548
0xaeda43 unify
/home/mpolacek/src/gcc/gcc/cp/pt.c:22590
0xae68b1 unify_one_argument
/home/mpolacek/src/gcc/gcc/cp/pt.c:20781
0xae6d48 type_unification_real
/home/mpolacek/src/gcc/gcc/cp/pt.c:20900
0xae503f fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/home/mpolacek/src/gcc/gcc/cp/pt.c:20280
0x85a35a add_template_candidate_real
/home/mpolacek/src/gcc/gcc/cp/call.c:3315
0x85a8ec add_template_candidate
/home/mpolacek/src/gcc/gcc/cp/call.c:3400
0x862c22 add_candidates
/home/mpolacek/src/gcc/gcc/cp/call.c:5724
0x85da1f perform_overload_resolution
/home/mpolacek/src/gcc/gcc/cp/call.c:4396
0x85dc90 build_new_function_call(tree_node*, vec**, int)
/home/mpolacek/src/gcc/gcc/cp/call.c:4470
0xb31529 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/mpolacek/src/gcc/gcc/cp/semantics.c:2584
0xa28a9c cp_parser_postfix_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:7375
0xa2b334 cp_parser_unary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:8461
0xa2c78e cp_parser_cast_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9346
0xa2c87b cp_parser_binary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9449
0xa2d639 cp_parser_assignment_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9747
0xa2d9c4 cp_parser_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9914
0xa313ff cp_parser_expression_statement
/home/mpolacek/src/gcc/gcc/cp/parser.c:11515
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/65819] overzealous checking in gfc_check_dependency for identical=true

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #2)
> The LHS and the arrays on the RHS cannot possibly overlap,
> because of the difference in the first index.
> 
> ig25@linux-fd1f:~/Krempel/Dep-f> cat foo.f90
> program main
>   implicit none
>   real, dimension(3,3,3) :: f
>   integer :: three
>   call random_number(f)
>   three = 3
>   f(1, 1:three, :) = matmul(f(2,1:3,2:3), f(3,2:3,:))
>   print *,f
> end program main
> ig25@linux-fd1f:~/Krempel/Dep-f> gfortran -O -Warray-temporaries foo.f90
> foo.f90:7:21:
> 
>f(1, 1:three, :) = matmul(f(2,1:3,2:3), f(3,2:3,:))
>  1
> Warning: Creating array temporary at (1) [-Warray-temporaries]

Is this PR still a problem?  I get no warnings with 

% gfcx -o z -Wall -Wsurprising -Wextra a.f90

[Bug middle-end/90888] New: std::swap bad code gen -- alias analysis insufficient to remove dead store

[david at doublewise dot net]

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

Bug ID: 90888
   Summary: std::swap bad code gen -- alias analysis insufficient
to remove dead store
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at doublewise dot net
  Target Milestone: ---

The following code optimizes well for `custom_swap` and `restrict_std_swap`,
but has an additional `mov` instruction for `std_swap`:


void custom_swap(int * lhs, int * rhs) {
int temp = *lhs;
*lhs = *rhs;
*rhs = temp;
}

void restrict_std_swap(int * __restrict lhs, int * __restrict rhs) {
int temp = *lhs;
*lhs = 0;
*lhs = *rhs;
*rhs = temp;
}

void std_swap(int * lhs, int * rhs) {
int temp = *lhs;
*lhs = 0;
*lhs = *rhs;
*rhs = temp;
}



Compiles into this for x86-64:

custom_swap(int*, int*):
mov eax, DWORD PTR [rdi]
mov edx, DWORD PTR [rsi]
mov DWORD PTR [rdi], edx
mov DWORD PTR [rsi], eax
ret
restrict_std_swap(int*, int*):
mov eax, DWORD PTR [rdi]
mov edx, DWORD PTR [rsi]
mov DWORD PTR [rsi], eax
mov DWORD PTR [rdi], edx
ret
std_swap(int*, int*):
mov eax, DWORD PTR [rdi]
mov DWORD PTR [rdi], 0
mov edx, DWORD PTR [rsi]
mov DWORD PTR [rdi], edx
mov DWORD PTR [rsi], eax
ret


And this for ARM64:

custom_swap(int*, int*):
ldr w3, [x1]
ldr w2, [x0]
str w3, [x0]
str w2, [x1]
ret
restrict_std_swap(int*, int*):
ldr w2, [x0]
ldr w3, [x1]
str w3, [x0]
str w2, [x1]
ret
std_swap(int*, int*):
ldr w2, [x0]
str wzr, [x0]
ldr w3, [x1]
str w3, [x0]
str w2, [x1]
ret


As we see from the example that annotates the parameters with __restrict, the
problem appears to be that the risk of *lhs aliasing *rhs disables the
optimizer's ability to remove the dead store in the second line of std_swap. It
is able to see that if they don't alias, the store in line 2 is dead. It is not
able to see that if they do alias, the store in line 3 is dead and the store in
line 2 is dead.

See it live: https://godbolt.org/z/D3Ey9i . 




The real life problem here is that types that manage a resource but do not
implement a custom std::swap, as well as all types that recursively contain a
type that manages a resource, suffer from reduced performance for using
std::swap. The larger, slightly more meaningful test case showing how I arrived
at this reduction and its relationship to std::swap:

struct unique_ptr {
unique_ptr():
ptr(nullptr)
{
}
unique_ptr(unique_ptr && other) noexcept:
ptr(other.ptr)
{
other.ptr = nullptr;
}
unique_ptr & operator=(unique_ptr && other) noexcept {
delete ptr;
ptr = nullptr;
ptr = other.ptr;
other.ptr = nullptr;
return *this;
}
~unique_ptr() noexcept {
delete ptr;
}

int * ptr;
};


void custom_swap(unique_ptr & lhs, unique_ptr & rhs) noexcept {
int * temp = lhs.ptr;
lhs.ptr = rhs.ptr;
rhs.ptr = temp;
}

void inlined_std_swap(unique_ptr & lhs, unique_ptr & rhs) noexcept {
int * temp_ptr = lhs.ptr;
lhs.ptr = nullptr;

delete lhs.ptr;
lhs.ptr = nullptr;
lhs.ptr = rhs.ptr;
rhs.ptr = nullptr;

delete rhs.ptr;
rhs.ptr = nullptr;

rhs.ptr = temp_ptr;
temp_ptr = nullptr;

delete temp_ptr;
}

void std_swap(unique_ptr & lhs, unique_ptr & rhs) noexcept {
auto temp = static_cast(lhs);
lhs = static_cast(rhs);
rhs = static_cast(temp);
}

See it live: https://godbolt.org/z/yBFa4H

[Bug target/31798] lib1funcs.asm:1000: undefined reference to `raise'

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2019-06-14
 CC||egallager at gcc dot gnu.org
 Resolution|WORKSFORME  |---
 Ever confirmed|0   |1

--- Comment #5 from Eric Gallager  ---
(In reply to Rich Felker from comment #2)
> This does seem to be real, so please reopen it. 

(In reply to Dima Krasner from comment #3)
> Please re-open this bug. 

OK.

[Bug target/89557] [7/8/9/10 regression] 4*movq to 2*movaps IPC performance regression on znver1 with -Og

[0xe2.0x9a.0x9b at gmail dot com]

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

--- Comment #9 from Jan Ziak (http://atom-symbol.net) <0xe2.0x9a.0x9b at gmail 
dot com> ---
(In reply to Richard Biener from comment #5)
> Please provide a compilable testcase.

Done some time ago. Please change the status of this bug from WAITING to some
other status.

[Bug libgomp/57298] GOMP_CPU_AFFINITY will not work when system has >1024 cores

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Jakub Jelinek from comment #2)
> Author: jakub
> Date: Tue Oct  1 14:49:36 2013
> New Revision: 203064
> 
> URL: http://gcc.gnu.org/viewcvs?rev=203064=gcc=rev
> Log:
>   PR libgomp/57298
>   * config/linux/proc.c (gomp_cpuset_size, gomp_cpusetp): New variables.
>   (gomp_cpuset_popcount): Use CPU_COUNT_S if available, or CPU_COUNT if
>   gomp_cpuset_size is sizeof (cpu_set_t).  Use gomp_cpuset_size instead
>   of sizeof (cpu_set_t) to determine number of iterations.
>   (gomp_init_num_threads): Initialize gomp_cpuset_size and gomp_cpusetp
>   here, use gomp_cpusetp instead of  and pass gomp_cpuset_size
>   instead of sizeof (cpu_set_t) to pthread_getaffinity_np.
>   (get_num_procs): Don't call pthread_getaffinity_np if gomp_cpusetp
>   is NULL.  Use gomp_cpusetp instead of  and pass gomp_cpuset_size
>   instead of sizeof (cpu_set_t) to pthread_getaffinity_np.
>   * config/linux/proc.h (gomp_cpuset_popcount): Add attribute_hidden.
>   (gomp_cpuset_size, gomp_cpusetp): Declare.
>   * config/linux/affinity.c (CPU_ISSET_S, CPU_ZERO_S, CPU_SET_S): Define
>   if CPU_ALLOC_SIZE isn't defined.
>   (gomp_init_affinity): Don't call pthread_getaffinity_np here, instead
>   use gomp_cpusetp computed by gomp_init_num_threads.  Use CPU_*_S
>   variants of macros with gomp_cpuset_size as set size, for cpusetnew
>   use alloca for it if CPU_ALLOC_SIZE is defined, otherwise local
>   fixed size variable.
>   (gomp_init_thread_affinity): Use CPU_*_S variants of macros with
>   gomp_cpuset_size as set size, for cpuset use alloca for it if
>   CPU_ALLOC_SIZE is defined, otherwise local fixed size variable.
> 
> Modified:
> branches/gomp-4_0-branch/libgomp/ChangeLog.gomp
> branches/gomp-4_0-branch/libgomp/config/linux/affinity.c
> branches/gomp-4_0-branch/libgomp/config/linux/proc.c
> branches/gomp-4_0-branch/libgomp/config/linux/proc.h

Did this fix it?

(also I'm kind of jealous of anyone with a computer with that many cores...)

[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed on trunk for the invalid testcase.  Can someone please check/confirm
that it solves the LTO issues?

Leaving open for possible backport to 9-branch, unless some fallout shows up.

[Bug fortran/90578] Wrong code with LSHIFT and optimization

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Testcase fixed to no longer invoke undefined behavior.

Documentation fixed, as well as arithmetic shifts which SHIFT=BIT_SIZE(arg1).

No runtime test for invalid SHIFT values.  Please open a separate PR if you
think this is important.

[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Fri Jun 14 18:41:20 2019
New Revision: 272309

URL: https://gcc.gnu.org/viewcvs?rev=272309=gcc=rev
Log:
2019-06-14  Harald Anlauf  

PR fortran/90577
PR fortran/90578
* trans-intrinsic.c (gfc_conv_intrinsic_shift): Properly
distinguish logical/arithmetic shifts.
* intrinsic.texi: Update documentation for SHIFTR/SHIFTL/SHIFTA
(Fortran 2008) and LSHIFT/RSHIFT (GNU extensions).

PR fortran/90577
PR fortran/90578
* gfortran.dg/lrshift_1.f90: Adjust testcase.
* gfortran.dg/shiftalr_3.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/shiftalr_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/lrshift_1.f90

[Bug fortran/90578] Wrong code with LSHIFT and optimization

[anlauf at gcc dot gnu.org]

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Fri Jun 14 18:41:20 2019
New Revision: 272309

URL: https://gcc.gnu.org/viewcvs?rev=272309=gcc=rev
Log:
2019-06-14  Harald Anlauf  

PR fortran/90577
PR fortran/90578
* trans-intrinsic.c (gfc_conv_intrinsic_shift): Properly
distinguish logical/arithmetic shifts.
* intrinsic.texi: Update documentation for SHIFTR/SHIFTL/SHIFTA
(Fortran 2008) and LSHIFT/RSHIFT (GNU extensions).

PR fortran/90577
PR fortran/90578
* gfortran.dg/lrshift_1.f90: Adjust testcase.
* gfortran.dg/shiftalr_3.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/shiftalr_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/lrshift_1.f90

[Bug fortran/89646] [7/8/9/10 Regression] Spurious actual argument might interfere warning

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|7.5 |10.0

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

[Bug other/90887] New: [10 Regression] r272186 causes -fcompare-debug failure

[burnus at gcc dot gnu.org]

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

Bug ID: 90887
   Summary: [10 Regression] r272186 causes -fcompare-debug failure
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---

The commit r272186 causes that our program fails with -fcompare-debug 

That's somewhat odd as it is a libstdc++ change, which shouldn't cause this.

Admittedly, I did only incrementation builds for the bisecting, but it is
robust: going to this revision causes the fail and going to the version before
works.


Triggering the bugs is not that simple - in my case, it only fails for
  g++ ... /full/path.cc
even using ../rel/path.cc made it pass; likewise compiling with "-E" will
produce a file which does compile.

The options required also don't make much sense; the reduced options were
(besides includes/defines):

g++ -std=c++2a -fcompare-debug -Woverloaded-virtual -Wlogical-op -g3 -Wall
-fsanitize=float-cast-overflow -fsanitize=float-divide-by-zero
-fsanitize=undefined -fno-sanitize=vptr,null


The commit which triggers the issue is r272186 

Author: redi 
Date:   Wed Jun 12 14:52:02 2019 +

Replace std::to_string for integers with optimized version


I will try to drill a bit deeper to understand what goes on.

[Bug fortran/89646] [7/8/9/10 Regression] Spurious actual argument might interfere warning

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Jun 14 18:17:00 2019
New Revision: 272307

URL: https://gcc.gnu.org/viewcvs?rev=272307=gcc=rev
Log:
2019-06-14  Steven G. Kargl  

PR fortran/89646
* dependency.c (gfc_check_argument_var_dependency): Suppress spurious
warnings by comparing variable names.

2019-06-14  Steven G. Kargl  

PR fortran/89646
* gfortran.dg/pr89646.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr89646.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/dependency.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #39 from Eric Gallager  ---
(In reply to Richard Biener from comment #35)
> Let's try "fixing" this finally for GCC 6.

Uh... for GCC 10 now?

[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|9.0 |tree-ssa

--- Comment #11 from Jonathan Wakely  ---
std::filesystem::symlink_status (and functions that use it) also fixed for 9.2

[Bug libstdc++/90252] PSTL test failures

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed for 9.2 as well.

[Bug libstdc++/88881] std::filesystem::status gives bad results on mingw32

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Fri Jun 14 18:11:22 2019
New Revision: 272304

URL: https://gcc.gnu.org/viewcvs?rev=272304=gcc=rev
Log:
PR libstdc++/1 fix filesystem::symlink_status for Windows

The fix for PR 1 only added a workaround to filesystem::status, but
filesystem::symlink_status is also affected by the _wstat bug and needs
the same workaround.

The recent change to optimize path::parent_path() means that the
workaround can be simplified to just use parent_path().

Backport from mainline
2019-05-29  Jonathan Wakely  

PR libstdc++/1
* src/c++17/fs_ops.cc [_GLIBCXX_FILESYSTEM_IS_WINDOWS]
(status(const path&, error_code&)): Use parent_path() to remove
trailing slash.
(symlink_status(const path&, error_code&)): Duplicate workaround for
bug in _wstat for paths with trailing slash.
* testsuite/27_io/filesystem/operations/remove_all.cc: Check path
with trailing slash.
* testsuite/27_io/filesystem/operations/status.cc: Likewise.
* testsuite/27_io/filesystem/operations/symlink_status.cc: Likewise.

Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/src/c++17/fs_ops.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/operations/remove_all.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/operations/status.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/operations/symlink_status.cc

[Bug libstdc++/90770] Building with --enable-libstdcxx-debug and make profiledbootstrap fails with mv: cannot stat 'Makefile': No such file or directory

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Fri Jun 14 18:10:57 2019
New Revision: 272299

URL: https://gcc.gnu.org/viewcvs?rev=272299=gcc=rev
Log:
PR libstdc++/90770 fix missing src/debug/Makefile

Backport from mainline
2019-06-07  Jonathan Wakely  

PR libstdc++/90770
* src/Makefile.am (stamp-debug): Also test for missing makefile.
* src/Makefile.in: Regenerate.

Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/src/Makefile.am
branches/gcc-9-branch/libstdc++-v3/src/Makefile.in

[Bug libstdc++/90252] PSTL test failures

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Fri Jun 14 18:10:52 2019
New Revision: 272298

URL: https://gcc.gnu.org/viewcvs?rev=272298=gcc=rev
Log:
PR libstdc++/90252 Check TBB version and ability to link with -ltbb

Backport from mainline
2019-05-21  Jonathan Wakely  

PR libstdc++/90252
* testsuite/lib/libstdc++.exp (check_effective_target_tbb-backend):
Use "additional_flags" to pass -ltbb to v3_target_compile command.
Use check_v3_target_prop_cached to cache the result of the test.

Backport from mainline
2019-05-20  Thomas Rodgers  

PR libstdc++/90252
* testsuite/lib/libstdc++.exp (check_effective_target_tbb-backend):
Changed v3_target_compile check from preprocess to executable.
Added "-ltbb" to v3_target_compile flags.

Backport from mainline
2019-05-20  Thomas Rodgers  

* testsuite/lib/libstdc++.exp (check_effective_target_tbb-backend):
Add check for Thread Building Blocks 2018 or later.

Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/testsuite/lib/libstdc++.exp

[Bug rtl-optimization/25609] too agressive printf optimization

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=15574,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=15685,
   ||http://sourceware.org/bugzi
   ||lla/show_bug.cgi?id=5618

--- Comment #23 from Eric Gallager  ---
(In reply to Ulrich Drepper from comment #6)
> This is NOT a dup of 15574.

ok, but related enough to go under "See Also" though

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to David Malcolm from comment #11)
> Warning for "2 ^ INT" seems reasonable, maybe just for that (I think I agree
> with comment #6).
> 
> Not sure what to call it: "-Wexclusive-or"???

I suppose -Wxor is a bit cryptic-lookin'

What about -Wxor-used-as-pow ?

> I think we'd want to *not* warn if either of the operands are from a macro
> expansion.
> 
> I think both operands ought to be decimal integers to trigger the warning.

And not warn if the C++ 'xor' keyword is used, as nobody's going to think that
"2 xor 8" means raising to the 8th power.

> I like the wording from comment #2: "2 ^ 30 is 28, not 1073741824.", to make
> it clear what's going on (I hope).

Yes, that's also how I phrased the various pull requests and bug reports I've
submitted today.

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[dmalcolm at gcc dot gnu.org]

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

--- Comment #11 from David Malcolm  ---
Warning for "2 ^ INT" seems reasonable, maybe just for that (I think I agree
with comment #6).

Not sure what to call it: "-Wexclusive-or"???

I think we'd want to *not* warn if either of the operands are from a macro
expansion.

I think both operands ought to be decimal integers to trigger the warning.

I like the wording from comment #2: "2 ^ 30 is 28, not 1073741824.", to make it
clear what's going on (I hope).

Other idea: fix-it hints.

So maybe something like:

t.c:10:5: warning: '2^30' is 28; did you mean '1<<30' (1073741824)
[-Wexclusive-or]

  log.Infof("Setting total memory to %.2f GB", float64(args.TotalMem)/(2^30))
   ~^~~
   1<<30

or somesuch.

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Eric Gallager from comment #9)
> * the "not from the expansion of ’s xor macro" criterion I can see
> possibly being a difficulty, due to how many other bugs there are about
> gcc's handling of macros from system headers...

That's not relevant to C++ because xor is a keyword not a macro.

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-14
 CC||egallager at gcc dot gnu.org
 Blocks||87403
 Ever confirmed|0   |1

--- Comment #9 from Eric Gallager  ---
Confirmed. More discussion from that thread about possible heuristics for the
warning: https://twitter.com/elwoz/status/1139522678396784642
* restricting it to just decimal literals probably makes sense, if someone is
using the 0x or 0b prefix, they probably are in fact intending to do
bit-twiddling with xor
* the "not from the expansion of ’s xor macro" criterion I can see
possibly being a difficulty, due to how many other bugs there are about gcc's
handling of macros from system headers...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug rtl-optimization/90765] preferred_stack_boundary is updated for callee

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 10.

[Bug target/90877] Dead codes in ix86_register_move_cost

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 10.

[Bug rtl-optimization/90765] preferred_stack_boundary is updated for callee

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Jun 14 16:24:56 2019
New Revision: 272296

URL: https://gcc.gnu.org/viewcvs?rev=272296=gcc=rev
Log:
Update preferred_stack_boundary only when expanding function call

locate_and_pad_parm is called when expanding function call from
initialize_argument_information and when generating function body
from assign_parm_find_entry_rtl:

  /* Remember if the outgoing parameter requires extra alignment on the
 calling function side.  */
  if (crtl->stack_alignment_needed < boundary)
crtl->stack_alignment_needed = boundary;
  if (crtl->preferred_stack_boundary < boundary)
crtl->preferred_stack_boundary = boundary;

stack_alignment_needed and preferred_stack_boundary should be updated
only when expanding function call, not when generating function body.

Add update_stack_alignment_for_call to update stack alignment when
outgoing parameter is passed in the stack.

gcc/

PR rtl-optimization/90765
* calls.c (update_stack_alignment_for_call): New function.
(expand_call): Call update_stack_alignment_for_call when
outgoing parameter is passed in the stack.
(emit_library_call_value_1): Likewise.
* function.c (locate_and_pad_parm): Don't update
stack_alignment_needed and preferred_stack_boundary.

gcc/testsuite/

PR rtl-optimization/90765
* gcc.target/i386/pr90765-1.c: New test.
* gcc.target/i386/pr90765-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr90765-1.c
trunk/gcc/testsuite/gcc.target/i386/pr90765-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/function.c
trunk/gcc/testsuite/ChangeLog

[Bug target/90878] [8/9/10 Regression] integer -> SSE register move isn't generated

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
We have

-- Target Hook: bool TARGET_RTX_COSTS (rtx X, machine_mode MODE, int
  OUTER_CODE, int OPNO, int *TOTAL, bool SPEED)
 This target hook describes the relative costs of RTL expressions.

 The cost may depend on the precise form of the expression, which is
 available for examination in X, and the fact that X appears as
 operand OPNO of an expression with rtx code OUTER_CODE.  That is,
 the ho-- Target Hook: bool TARGET_RTX_COSTS (rtx X, machine_mode MODE, int
  OUTER_CODE, int OPNO, int *TOTAL, bool SPEED)
 This target hook describes the relative costs of RTL expressions.

 The cost may depend on the precise form of the expression, which is
 available for examination in X, and the fact that X appears as
 operand OPNO of an expression with rtx code OUTER_CODE.  That is,
 the hook can assume that there is some rtx Y such that 'GET_CODE
 (Y) == OUTER_CODE' and such that either (a) 'XEXP (Y, OPNO) == X'
 or (b) 'XVEC (Y, OPNO)' contains X.

 MODE is X's machine mode, or for cases like 'const_int' that do not
 have a mode, the mode in which X is used.

 In implementing this hook, you can use the construct 'COSTS_N_INSNS
 (N)' to specify a cost equal to N fast instructions.

 On entry to the hook, '*TOTAL' contains a default estimate for the
 cost of the expression.  The hook should modify this value as
 necessary.  Traditionally, the default costs are 'COSTS_N_INSNS
 (5)' for multiplications, 'COSTS_N_INSNS (7)' for division and
 modulus operations, and 'COSTS_N_INSNS (1)' for all other
 operations.

 When optimizing for code size, i.e. when 'speed' is false, this
 target hook should be used to estimate the relative size cost of an
 expression, again relative to 'COSTS_N_INSNS'.

 The hook returns true when all subexpressions of X have been
 processed, and false when 'rtx_cost' should recurse.
ok can assume that there is some rtx Y such that 'GET_CODE
 (Y) == OUTER_CODE' and such that either (a) 'XEXP (Y, OPNO) == X'
 or (b) 'XVEC (Y, OPNO)' contains X.

 MODE -- Target Hook: bool TARGET_RTX_COSTS (rtx X, machine_mode MODE, int
  OUTER_CODE, int OPNO, int *TOTAL, bool SPEED)
 This target hook describes the relative costs of RTL expressions.

 The cost may depend on the precise form of the expression, which is
 available for examination in X, and the fact that X appears as
 operand OPNO of an expression with rtx code OUTER_CODE.  That is,
 the hook can assume that there is some rtx Y such that 'GET_CODE
 (Y) == OUTER_CODE' and such that either (a) 'XEXP (Y, OPNO) == X'
 or (b) 'XVEC (Y, OPNO)' contains X.

 MODE is X's machine mode, or for cases like 'const_int' that do not
 have a mode, the mode in which X is used.

 In implementing this hook, you can use the construct 'COSTS_N_INSNS
 (N)' to specify a cost equal to N fast instructions.

 On entry to the hook, '*TOTAL' contains a default estimate for the
 cost of the expression.  The hook should modify this value as
 necessary.  Traditionally, the default costs are 'COSTS_N_INSNS
 (5)' for multiplications, 'COSTS_N_INSNS (7)' for division and
 modulus operations, and 'COSTS_N_INSNS (1)' for all other
 operations.

 When optimizing for code size, i.e. when 'speed' is false, this
 target hook should be used to estimate the relative size cost of an
 expression, again relative to 'COSTS_N_INSNS'.

 The hook returns true when all subexpressions of X have been
 processed, and false when 'rtx_cost' should recurse.
is X's machine mode, or for cases like 'const_int' that do not
 have a mode, the mode in which X is used.

 In implementing this hook, you can use the construct 'COSTS_N_INSNS
 (N)' to specify a cost equal to N fast instructions.

 On entry to the hook, '*TOTAL' contains a default estimate for the
 cost of the expression.  The hook should modify this value as
 necessary.  Traditionally, the default costs are 'COSTS_N_INSNS
 (5)' for multiplications, 'COSTS_N_INSNS (7)' for division and
 modulus operations, and 'COSTS_N_INSNS (1)' for all other
 operations.

 When optimizing for code size, i.e. when 'speed' is false, this
 target hook should be used to estimate the relative size cost of an
 expression, again relative to 'COSTS_N_INSNS'.

 The hook returns true when all subexpressions of X have been
 processed, and false when 'rtx_cost' should recurse.

-- Target Hook: int TARGET_REGISTER_MOVE_COST (machine_mode MODE,
  reg_class_t FROM, reg_class_t TO)
 This target hook should return the cost of moving data of mode MODE
 from a register in class FROM to one in class TO.  The classes are
 expressed using the enumeration values such as 'GENERAL_REGS'.  A
 value of 

[Bug middle-end/90779] Fortran array initialization in offload regions

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Ok, will retest the updated version and commit, defer the rest to you or
somebody else familiar with what is done there.

[Bug middle-end/90779] Fortran array initialization in offload regions

[ams at gcc dot gnu.org]

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

--- Comment #8 from Andrew Stubbs  ---
On GCN I get the lto_priv names, but not the globalization. I think that shows
what the expected behaviour is, thanks ... I just need to find that magic.

That being so, I think I can confirm that your original patch fixes the problem
reported.

[Bug target/90877] Dead codes in ix86_register_move_cost

[hjl at gcc dot gnu.org]

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

--- Comment #1 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Fri Jun 14 15:41:43 2019
New Revision: 272294

URL: https://gcc.gnu.org/viewcvs?rev=272294=gcc=rev
Log:
i386: Update SSE <-> integer move costs

Since inline_secondary_memory_needed has

  /* ??? This is a lie.  We do have moves between mmx/general, and for
 mmx/sse2.  But by saying we need secondary memory we discourage the
 register allocator from using the mmx registers unless needed.  */
  if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2))
return true;

moves between MMX and non-MMX units require secondary memory.   There
is no need to check moves between MMX and integer units.

struct processor_costs has:

  const int mmxsse_to_integer;  /* cost of moving mmxsse register to
   integer.  */
  const int ssemmx_to_integer;  /* cost of moving integer to mmxsse register.
*/

This patch also renames mmxsse_to_integer to sse_to_integer and
ssemmx_to_integer to integer_to_sse.

Tested on Linux/x86-64.

PR target/90877
* config/i386/i386-features.c
(dimode_scalar_chain::compute_convert_gain): Replace
mmxsse_to_integer with sse_to_integer.
* config/i386/i386.c (ix86_register_move_cost): Verify that
moves between MMX and non-MMX units require secondary memory.
Correct costs of moves between SSE and integer units.
* config/i386/i386.h (processor_costs): Rename cost of moving
SSE register to integer to sse_to_integer.  Rename cost of
moving integer register to SSE to integer_to_sse.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386-features.c
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.h

[Bug middle-end/90779] Fortran array initialization in offload regions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Something like:
extern int foo (void);
static int var = 5;
#pragma omp declare target to (var)

int
main ()
{
  int r = 19;
  #pragma omp target map(tofrom: r)
  {
r += ++var;
  }
  #pragma omp target map(tofrom: r)
  {
r += ++var;
  }
  if (r != 19 + 6 + 7)
__builtin_abort ();
  foo ();
  return 0;
}
in one source and:
static int var = 5;
#pragma omp declare target to (var)

int
foo ()
{
  int r = 19;
  #pragma omp target map(tofrom: r)
  {
r += ++var;
  }
  #pragma omp target map(tofrom: r)
  {
r += ++var;
  }
  if (r != 19 + 6 + 7)
__builtin_abort ();
  return 0;
}
needs to work.  Looking at the PTX assembly for this, I see
// BEGIN VAR DEF: var
.global .align 4 .u32 var[1] = { 5 };
//:FUNC_MAP "main$_omp_fn$1"
//:FUNC_MAP "main$_omp_fn$0"
//:VAR_MAP "var"
if I compile just the first TU without the foo () call in there, and 
.global .align 4 .u32 var$lto_priv$1[1] = { 5 };
.global .align 4 .u32 var$lto_priv$0[1] = { 5 };
if I compile both, so there is some magic that makes these global and uglified
so that there can be multiple such vars.
No idea where that happens, whether it is NVPTX specific etc.

[Bug target/90886] loop/while/for problem

[joe at freakyacres dot com]

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

--- Comment #10 from Joe  ---
probably noticed but code is always "i <" not "i =" as I stated in the previous
comments.

[Bug target/90878] [8/9/10 Regression] integer -> SSE register move isn't generated

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to H.J. Lu from comment #1)
> If we make integer register store more expensive, this testcase will
> regress:
> 
> [hjl@gnu-cfl-1 unroll]$ cat x.i
> void
> foo (long p2, long *diag, long d, long i)
> {
>   long k;
>   k = p2 < 3 ? p2 + p2 : p2 + 3;
>   while (i < k)
> diag[i++] = d;
> }
> [hjl@gnu-cfl-1 unroll]$ make
> /export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
> -B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -O3
> -march=skylake  -S x.i
...
> since higher integer register store cost will reduce loop unroll count.

ix86_builtin_vectorization_cost has

 case scalar_load:
/* load/store costs are relative to register move which is 2. Recompute
   it to COSTS_N_INSNS so everything have same base.  */
return COSTS_N_INSNS (fp ? ix86_cost->sse_load[0]
  : ix86_cost->int_load [2]) / 2;

  case scalar_store:
return COSTS_N_INSNS (fp ? ix86_cost->sse_store[0]
  : ix86_cost->int_store [2]) / 2;

sse_load[0], int_load [2], sse_store[0], int_store [2] impact

1. Loop runtime profitability threshold.
2. Selection of memory vs register operands.

Should we add a separate set of costs to processor_costs for vectorizer?

[Bug target/90886] loop/while/for problem

[joe at freakyacres dot com]

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

--- Comment #9 from Joe  ---
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.4.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --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 --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1)

[Bug target/90886] loop/while/for problem

[joe at freakyacres dot com]

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

Joe  changed:

   What|Removed |Added

Version|7.3.0   |7.4.0

--- Comment #8 from Joe  ---
Here is assembler under 7.4.0...  Segmentation fault with i=128.  Any other
value within the bounds of unsigned char is ok.

i=128
04f0 :
 4f0:   c6 05 1a 0b 20 00 00movb   $0x0,0x200b1a(%rip)# 201011 
 4f7:   66 0f 1f 84 00 00 00nopw   0x0(%rax,%rax,1)
 4fe:   00 00 


i=129
04f0 :
 4f0:   31 c0   xor%eax,%eax
 4f2:   88 05 19 0b 20 00   mov%al,0x200b19(%rip)# 201011 
 4f8:   ff c0   inc%eax
 4fa:   3c 81   cmp$0x81,%al
 4fc:   75 f4   jne4f2 
 4fe:   eb f0   jmp4f0 

[Bug middle-end/90779] Fortran array initialization in offload regions

[ams at gcc dot gnu.org]

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

--- Comment #6 from Andrew Stubbs  ---
There's not observable difference. I don't quite follow what the patch is
trying to achieve, but seems like adding the variable to the offload variables
does not address the issue here.

I've added a hack to mkoffload to force the variables listed in the
offload_var_table to be declared "global". This is sufficient to run the small
testcase correctly. (My larger testcase now has a memory fault, but that could
easily be unrelated.)

If the symbol is declared local then there's no (straight-forward) way to
locate the loaded symbol at runtime, hence the libgomp plugin fail.

Setting the symbol global seems like there could be other issues. Given that
libgomp does not actually need access to this variable at runtime, perhaps the
plugin should just ignore the failure and move on, trusting that unfound
variables are not needed?

[Bug tree-optimization/90579] [8/9/10 Regression] Huge store forward stall due to vectorizer

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
After this bug is fixed, we should revisit the workaround for

https://sourceware.org/bugzilla/show_bug.cgi?id=24603

to check if it is still necessary.

[Bug c++/68996] Decltype-specifier in declarator-id should not be accepted

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-14
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed, I supposed.  There's CWG 743:

   auto vec = get_vec();
   decltype(vec)::value_type v = vec.first();

but that includes decltype in a decl-specifier, which is fine.

So

struct S {
   using T = int;
} s;

decltype(s)::T a;

should work but not the testcase in Description.

[Bug c++/90884] Option `-Wctor-dtor-privacy' enables warning even for system headers

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/90884] Option `-Wctor-dtor-privacy' enables warning even for system headers

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Jun 14 14:49:57 2019
New Revision: 272291

URL: https://gcc.gnu.org/viewcvs?rev=272291=gcc=rev
Log:
PR c++/90884 - stray note with -Wctor-dtor-privacy.
* class.c (maybe_warn_about_overly_private_class): Guard the call to
inform.

* g++.dg/warn/ctor-dtor-privacy-4.C: New.
* g++.dg/warn/ctor-dtor-privacy-4.h: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.C
trunk/gcc/testsuite/g++.dg/warn/ctor-dtor-privacy-4.h
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/testsuite/ChangeLog

[Bug target/90886] loop/while/for problem

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #7 from Jonathan Wakely  ---
No, but 7.4.0 is.

[Bug target/83531] Build broken on macOS 10.13.2

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe  ---
(In reply to MCCCS from comment #6)
> After reading your comment, I noticed that
> there were two things I forgot to mention:

> But yes, there's no need to hurry
> to fix it. It's existed since
> October 2017; no one has noticed.

However, I do want to fix it - and I need a name and email address to put onto
the patch credits (or you can post your patch independently - either works).

[Bug target/90886] loop/while/for problem

[joe at freakyacres dot com]

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

--- Comment #6 from Joe  ---
Hmmm... Maybe 7.3.0 isn't supported either.

[Bug middle-end/90779] Fortran array initialization in offload regions

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Andrew Stubbs from comment #4)
> The problem is that the variables are added to the offload_var_table but not
> exported so that libgomp cannot find the symbol at load time. This causes a
> fatal error in a mutex-locked section, which causes libgomp's atexit handler
> to hang trying to take the same lock.

They should be in offload_var_table and should not be exported, it is like any
static filescope variable marked for offload.

Completely wild guess, does incremental:

@@ -65,6 +65,8 @@
 #include "attribs.h"
 #include "asan.h"
 #include "dbgcnt.h"
+#include "omp-offload.h"
+#include "context.h"

 /* Hash set of poisoned variables in a bind expr.  */
 static hash_set *asan_poisoned_variables = NULL;
@@ -1350,7 +1352,15 @@
= tree_cons (id, NULL_TREE, DECL_ATTRIBUTES (t));
  varpool_node *node = varpool_node::get (t);
  if (node)
-   node->offloadable = 1;
+   {
+ node->offloadable = 1;
+ if (ENABLE_OFFLOADING && !DECL_EXTERNAL (t))
+   {
+ g->have_offload = true;
+ if (!in_lto_p)
+   vec_safe_push (offload_vars, t);
+   }
+   }
}
  break;
}

patch help?

[Bug target/90886] loop/while/for problem

[joe at freakyacres dot com]

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

Joe  changed:

   What|Removed |Added

Version|5.4.0   |7.3.0

--- Comment #5 from Joe  ---
Tested with 7.3.0 with same results.

Using built-in specs.
Reading specs from
/home/xxx/avr-tools-test/avr/bin/../lib/gcc/avr/7.3.0/device-specs/specs-avr2
COLLECT_GCC=./avr-g++
COLLECT_LTO_WRAPPER=/home/xxx/avr-tools-test/avr/bin/../libexec/gcc/avr/7.3.0/lto-wrapper
Target: avr
Configured with: ../gcc/configure --enable-fixed-point --enable-languages=c,c++
--prefix=/home/jenkins/workspace/avr-gcc-staging/label/debian7-x86_64/objdir
--disable-nls --disable-libssp --disable-libada --disable-shared
--with-avrlibc=yes --with-dwarf2 --disable-doc --target=avr
Thread model: single
gcc version 7.3.0 (GCC)

[Bug target/90886] loop/while/for problem

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
GCC 5.4 is no longer maintained or supported by the GCC project.

[Bug target/87281] qsort checking ICE in ia64_reorg building libgo

[jason.duerstock at gmail dot com]

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

--- Comment #8 from Jason Duerstock  ---
(In reply to Joseph S. Myers from comment #0)
> Building an all-languages cross compiler for ia64-linux-gnu, trunk r264193,
> I see the following ICE building libgo
> bytes.go:211:1: internal compiler error: qsort checking failed

I could certainly be misunderstanding this, but as libgo is part of the
compiler, I believe this would show up while building the cross compiler
without any additional settings, configuration, or testing:

(edited for (hopeful) clarity)

libtool: compile:  build/build/compilers/ia64-linux-gnu/gcc/./gcc/gccgo
-Bbuild/build/compilers/ia64-linux-gnu/gcc/./gcc/
-Bbuild/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/bin/
-Bbuild/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/lib/ -isystem
build/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/include -isystem
build/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/sys-include -O2 -g
-I . -c -fgo-pkgpath=bytes build/src/gcc/libgo/go/bytes/buffer.go
build/src/gcc/libgo/go/bytes/bytes.go build/src/gcc/libgo/go/bytes/reader.go -o
bytes.o >/dev/null 2>&1

libtool: link: build/build/compilers/ia64-linux-gnu/gcc/./gcc/xgcc
-Bbuild/build/compilers/ia64-linux-gnu/gcc/./gcc/
-Bbuild/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/bin/
-Bbuild/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/lib/ -isystem
build/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/include -isystem
build/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/sys-include   
-shared  [...] .libs/bytes.o [...] -Wl,--whole-archive
../libbacktrace/.libs/libbacktrace.a ../libatomic/.libs/libatomic_convenience.a
../libffi/.libs/libffi_convenience.a -Wl,--no-whole-archive 
-Lbuild/build/compilers/ia64-linux-gnu/gcc/ia64-glibc-linux-gnu/libatomic/.libs
-lpthread -lm  -pthread   -pthread -Wl,-soname -Wl,libgo.so.14 -o
.libs/libgo.so.14.0.0

lrwxrwxrwx 1 jason jason   15 Jun 14 09:48
build/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/lib/libgo.so.14 ->
libgo.so.14.0.0
-rwxr-xr-x 1 jason jason 61070664 Jun 14 09:48
build/install/compilers/ia64-linux-gnu/ia64-glibc-linux-gnu/lib/libgo.so.14.0.0

[Bug target/90886] loop/while/for problem

[joe at freakyacres dot com]

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

--- Comment #3 from Joe  ---
Changing i to 127 produces following assembly...

volatile unsigned char x;

int main() {
  while (1) {
for (unsigned char i = 0 ; i < 127 ; i++) {
  x = i;
}
  }
}

0090 :
  90:   80 e0   ldi r24, 0x00   ; 0
  92:   80 93 00 01 sts 0x0100, r24 ; 0x800100 <_edata>
  96:   8f 5f   subir24, 0xFF   ; 255
  98:   8f 37   cpi r24, 0x7F   ; 127
  9a:   d1 f3   breq.-12; 0x90 
  9c:   fa cf   rjmp.-12; 0x92 

009e <_exit>:
  9e:   f8 94   cli

00a0 <__stop_program>:
  a0:   ff cf   rjmp.-2 ; 0xa0 <__stop_program>

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On June 14, 2019 2:27:22 PM GMT+02:00, "jamborm at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883
>
>--- Comment #4 from Martin Jambor  ---
>(In reply to Richard Biener from comment #3)
>> ...I also wonder why SRA does not elide the aggregate copy.
>
>SRA has a special condition not to attempt to totally scalarize array
>of chars, so that it does not interfere with bigger types
>placement-new placed in those.
>
>It is true that artificially removing this condition would avoid the
>problem though.  However, the IL after esra would look like the
>following:
>   :
>  SR.1_3 = 0;
>  SR.2_8 = 0;
>  SR.3_9 = 0;
>  SR.4_10 = 0;
>  SR.5_11 = 0;
>  SR.6_12 = 0;
>  SR.7_13 = 0;
>  SR.8_14 = 0;
>  SR.1_15 = 0;
>  SR.2_16 = 0;
>  SR.3_17 = 0;
>  SR.4_18 = 0;
>  SR.5_19 = 0;
>  SR.6_20 = 0;
>  SR.7_21 = 0;
>  SR.8_22 = 0;
>  D.10899.a._M_elems[0] = SR.1_15;
>  D.10899.a._M_elems[1] = SR.2_16;
>  D.10899.a._M_elems[2] = SR.3_17;
>  D.10899.a._M_elems[3] = SR.4_18;
>  D.10899.a._M_elems[4] = SR.5_19;
>  D.10899.a._M_elems[5] = SR.6_20;
>  D.10899.a._M_elems[6] = SR.7_21;

Ick. OK, so the important fact would be the zero initialization which we'd only
see in a flow sensitive analysis? Then the above could just be

D. 10899.a._M_elems = {};

>  D.10899.b = SR.8_22;
>  return D.10899;

[Bug target/90886] loop/while/for problem

[joe at freakyacres dot com]

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

--- Comment #2 from Joe  ---
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/5.4.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/5.4.0/lto-wrapper
Target: avr
Configured with: ../gcc/configure -v --enable-languages=c,c++ --prefix=/usr/lib
--infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin
--libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib
--enable-long-long --enable-nls --without-included-gettext --disable-libssp
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr CFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=.
-fstack-protector-strong -Wformat ' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2'
CXXFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=.
-fstack-protector-strong -Wformat ' FCFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=.
-fstack-protector-strong' FFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=.
-fstack-protector-strong' GCJFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=.
-fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro'
OBJCFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=.
-fstack-protector-strong -Wformat ' OBJCXXFLAGS='-g -O2
-fdebug-prefix-map=/build/gcc-avr-n0nSsH/gcc-avr-5.4.0+Atmel3.6.0=.
-fstack-protector-strong -Wformat '
Thread model: single
gcc version 5.4.0 (GCC)

[Bug middle-end/64242] Longjmp expansion incorrect

[wilco at gcc dot gnu.org]

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

--- Comment #27 from Wilco  ---
(In reply to dave.anglin from comment #26)
> On 2019-06-10 9:51 a.m., wilco at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242
> >
> > --- Comment #25 from Wilco  ---
> > I believe this is now fixed for generic code - however targets which 
> > implement
> > the nonlocal_goto expander (eg. pa, sparc, vax) need similar fixes in their
> > backends.
> >
> The test no longer fails on pa.  We need a test that demonstrates the
> problem in the current
> pa expander.

It allocates the buf variables at exactly the same offset in both frames, so
the code below accidentally reads the right values from the wrong address:

broken_longjmp:
.PROC
.CALLINFO FRAME=192,CALLS,SAVE_RP,SAVE_SP,ENTRY_GR=3
.ENTRY
copy %r3,%r1
stw %r2,-20(%r30)
copy %r30,%r3
stwm %r1,192(%r30)
copy %r26,%r25
ldi 20,%r24
bl memcpy,%r2
ldo 8(%r3),%r26
ldw 8(%r3),%r28  -> load frame pointer of parent function
ldo -8(%r28),%r3 -> set hard_frame_pointer
ldw 16(%r3),%r30 -> use wrong frame pointer to read stack pointer
ldw 12(%r3),%r1  -> use wrong frame pointer to read return address
be,n 0(%sr4,%r1)

Given there are many possible stack layouts, the easiest option would be to
clear the input buffer so it will jump to a null pointer. Eg.

__attribute ((noinline)) void
broken_longjmp (void *p)
{
  void *buf[32];
  __builtin_memcpy (buf, p, 5 * sizeof (void*));
  __builtin_memset (p, 0, 5 * sizeof (void*));
  /* Corrupts stack pointer...  */
  __builtin_longjmp (buf, 1);
}

[Bug target/90886] loop/while/for problem

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Target||avr-*-*
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-06-14
  Component|c++ |target
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Please provide the rest of the information requested by
https://gcc.gnu.org/bugs (gcc version and 'gcc -v' output).

[Bug middle-end/90779] Fortran array initialization in offload regions

[ams at gcc dot gnu.org]

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

--- Comment #4 from Andrew Stubbs  ---
The problem is that the variables are added to the offload_var_table but not
exported so that libgomp cannot find the symbol at load time. This causes a
fatal error in a mutex-locked section, which causes libgomp's atexit handler to
hang trying to take the same lock.

The question is then, are the variables supposed to be in the
offload_var_table? 

If so, why? Aren't these just preinitialized constants?

[Bug c++/90886] New: loop/while/for problem

[joe at freakyacres dot com]

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

Bug ID: 90886
   Summary: loop/while/for problem
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joe at freakyacres dot com
  Target Milestone: ---

I apologize because this all got a little bit above my head.  But the following
code only runs the "for" loop once.  

volatile unsigned char x;

int main() {
  while (1) {
for (unsigned char i = 0 ; i < 128 ; i++) {
  x = i;
}
  }
}


Apparently compiles to...

$ avr-g++ -Os -mmcu=atmega328p main.cpp -o main.elf
$ avr-objdump --demangle -d main.elf
(other code omitted)
0090 :
  90:   10 92 00 01 sts 0x0100, r1  ; 0x800100 <_edata>

0094 <_exit>:
  94:   f8 94   cli

0096 <__stop_program>:
  96:   ff cf   rjmp.-2 ; 0x96 <__stop_program>
$ avr-g++ --version


Replacing the for loop 128 with any other value fixes the problem.


Much work was done at the github link below where minds much more advanced than
my own researched and confirmed what was happening.



https://github.com/arduino/Arduino/issues/8973

https://forum.arduino.cc/index.php?topic=621017.0

[Bug c++/85552] Adding curly braces to the declaration of a std::unique_ptr to a forward declared class breaks compilation

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Fri Jun 14 13:22:33 2019
New Revision: 272287

URL: https://gcc.gnu.org/viewcvs?rev=272287=gcc=rev
Log:
PR c++/85552 - wrong instantiation of dtor for DMI.

The problem here is that when processing direct-initialization of a data
member, we don't need to worry about destruction semantics; that will be
handled in the [cd]tor.  Conveniently, we already have tf_no_cleanup from a
similar fix to new-expressions.

* typeck2.c (digest_nsdmi_init): Set tf_no_cleanup for direct-init.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-list5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck2.c

[Bug c++/90875] warnings about switch values outside range don't have associated option

[mbelivea at gcc dot gnu.org]

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

Matthew Beliveau  changed:

   What|Removed |Added

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

[Bug c++/89325] [7/8/9/10 Regression] False warnings about "optimization attribute" on operators when -fno-ipa-cp-clone

[chtz at informatik dot uni-bremen.de]

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

Christoph Hertzberg  changed:

   What|Removed |Added

 CC||chtz at informatik dot 
uni-bremen.
   ||de

--- Comment #6 from Christoph Hertzberg  
---
Related:
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1724
We just mask the warning for g++-7 at the moment.

[Bug c++/90881] -Wunused-value false positive in SFINAE context

[federico.kircheis at gmail dot com]

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

--- Comment #6 from Federico Kircheis  ---
> With my patch, we wouldn't warn on this second testcase.  But clang++
> doesn't warn, either.

Yes, I just wanted to point out that giving warning in unevaluated contexts has
some benefits too.
I believe gcc is doing a better job than clang or msvc.

I actually thought about this bug, and would like to rephrase it.
It's not a false positive, it's an usability bug.



It's not problematic that gcc gives a warning, the text is
problematic/misleading.

It says "left operand of comma operator has no effect", and as I showed this is
wrong.

It should say "left operand of comma operator is not used" or something in that
direction, since the warning should be about unused variables
(`-Wunused-value`), and it would be correct.


As a programmer I can see more easily what gcc is trying to say, and I would be
less tempted to remove the unused variable because gcc did not told me it was
useless.


Now you might think, that this does not help me as programmer at all, since I
would like to write warning-free code, and I might be tempted to remove the
unused variable also in this situation.


Therefore, just add the hint (as actually documented), to cast the variable to
void!
Exactly as on would normally do for other unused variables.
I did not think about it, because I payed too much attention at the error text,
and not the cause of the warning.

This sample does compile, works as expected, and does not generate any warning.


#include 

template  struct status : std::false_type{};

template  struct status :
std::true_type {};

struct s1{int member;};
struct s2{int _member;};

int main(){
static_assert(status::value, "has member");
static_assert(!status::value, "has no member");
}


What do you think?

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
(In reply to Richard Biener from comment #3)
> ...I also wonder why SRA does not elide the aggregate copy.

SRA has a special condition not to attempt to totally scalarize array
of chars, so that it does not interfere with bigger types
placement-new placed in those.

It is true that artificially removing this condition would avoid the
problem though.  However, the IL after esra would look like the
following:

   :
  SR.1_3 = 0;
  SR.2_8 = 0;
  SR.3_9 = 0;
  SR.4_10 = 0;
  SR.5_11 = 0;
  SR.6_12 = 0;
  SR.7_13 = 0;
  SR.8_14 = 0;
  SR.1_15 = 0;
  SR.2_16 = 0;
  SR.3_17 = 0;
  SR.4_18 = 0;
  SR.5_19 = 0;
  SR.6_20 = 0;
  SR.7_21 = 0;
  SR.8_22 = 0;
  D.10899.a._M_elems[0] = SR.1_15;
  D.10899.a._M_elems[1] = SR.2_16;
  D.10899.a._M_elems[2] = SR.3_17;
  D.10899.a._M_elems[3] = SR.4_18;
  D.10899.a._M_elems[4] = SR.5_19;
  D.10899.a._M_elems[5] = SR.6_20;
  D.10899.a._M_elems[6] = SR.7_21;
  D.10899.b = SR.8_22;
  return D.10899;

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
(In reply to John Marshall from comment #6)
> > let's not speculate ... could you (and/or Rainer) try this (untested) patch 
> > and
> > see how far it gets you?
> 
> Fails in approximately the same place as without:
> 
> ../../gcc/configure --disable-nls --disable-multilib
> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> --enable-languages=c,c++
> Make

> ^~~~
> 
> I.e. it got no definition of __AVAILABILITY_INTERNAL__MAC_10_10.

OK. So we're stuck with either (hopefully) a fix in the released version or
another fix includes.

Let's hope for the former - there's no point in committing fixincludes patches
for something unreleased, but I suppose someone could cook up/propose the
minimum needed.

(It seems that the one for 10.13/14 SDKs needs applying anyway.)

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[John.W.Marshall at glasgow dot ac.uk]

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

--- Comment #6 from John Marshall  ---
> let's not speculate ... could you (and/or Rainer) try this (untested) patch 
> and
> see how far it gets you?

Fails in approximately the same place as without:

../../gcc/configure --disable-nls --disable-multilib
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
--enable-languages=c,c++
Make
[...]
/Users/johnm/thirdparty/build/gcc-perbrew-iains/./gcc/xgcc
-B/Users/johnm/thirdparty/build/gcc-perbrew-iains/./gcc/
-B/usr/local/x86_64-apple-darwin18.6.0/bin/
-B/usr/local/x86_64-apple-darwin18.6.0/lib/ -isystem
/usr/local/x86_64-apple-darwin18.6.0/include -isystem
/usr/local/x86_64-apple-darwin18.6.0/sys-include   -fno-checking -g -O2 -O2  -g
-O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  
-mmacosx-version-min=10.5 -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -mmacosx-version-min=10.5 -pipe -fno-common -I. -I.
-I../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include 
-DHAVE_CC_TLS -DUSE_EMUTLS -o _muldi3_s.o -MT _muldi3_s.o -MD -MP -MF
_muldi3_s.dep -DSHARED -DL_muldi3 -c ../../../../gcc/libgcc/libgcc2.c
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:69,
from
/Users/johnm/thirdparty/build/gcc-perbrew-iains/gcc/include-fixed/stdio.h:78,
from ../../../../gcc/libgcc/../gcc/tsystem.h:87,
from ../../../../gcc/libgcc/libgcc2.c:27:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/stdio.h: In
function 'renameat':
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/stdio.h:39:56:
error: expected declaration specifiers before
'__AVAILABILITY_INTERNAL__MAC_10_10'
39 | int renameat(int, const char *, int, const char *)
__OSX_AVAILABLE_STARTING(__MAC_10_10, __IPHONE_8_0);
|   
^~~~

I.e. it got no definition of __AVAILABILITY_INTERNAL__MAC_10_10.

[Bug target/90834] Header and startup objects not found on macOS 10.15

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #10)
> (In reply to John Marshall from comment #9)

> > This has an unfortunate side-effect that the compiler looks in the
> > non-existent /Library/.../MacOSX.sdk/usr/local/include instead of
> > /usr/local/include [2].
> 
> That's an irritation, indeed.

> It's possible we could work around the /usr/include/local thing relatively
> easily, one can add un-sysrooted paths (and also compiler-relative paths).

Having said this, what does clang do?
We probably want to avoid doing things too much differently, or people's build
systems will behave in unexpected ways with GCC c.f. clang.

on a regular Xcode installation what do you get for

clang -xc /dev/null -fsyntax-only -v

?

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
The right heuristic for the warning isn't entirely obvious though.

I think it should only warn when both operands are integer literals. Should all
kinds of integer literals be treated equally? Is 0x11 ^ 0b0011 wrong? Maybe not
as obviously as 2^8 and 2^32.

Do these mistakes only happen for powers of 2 and powers of 10? Is it worth
warning about 3^4?

After some more searches I'm not even sure 10^ is common enough to worry about.
Maybe it should only warn for 2 ^ integer-literal.

Warning X^X where the same literal is given twice probably makes sense, that
would catch the 10^10 case in comment 1 (but not the -10^10 one).

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[yann at droneaud dot fr]

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

--- Comment #7 from Yann Droneaud  ---
The issue was noted on twitter by John Regehr, in
https://twitter.com/johnregehr/status/1139295920997068800 and following
messages.

The warning was suggest again by John Regehr in
https://twitter.com/johnregehr/status/1139302389612077056

[Bug target/87281] qsort checking ICE in ia64_reorg building libgo

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> I don't understand how that applies in the context of Joseph's
> build-many-glibcs.py script.

This PR is about a compiler issue so I presume that build-many-glibcs.py tests
the compiler at some point?  If so, then you either need to make sure that it
tests the trunk compiler and not the compiler from the 9 branch, or else you
need to configure the compiler from the 9 branch with
--enable-checking=release,misc.

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
There's nothing wrong about implicit fallthrough, misleading indentation,
ambiguous else, or missing parentheses in nested logic expressions either. But
people get it wrong all the time.

I can't see a good reason to write 2^16 when you mean 18, or 10^9 when you mean
3, so it's probably a bug. And there's an easy workaround to avoid the warning:
just write the exact constant as a literal, not an XOR expression.

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Maybe we should accept 2**32 as extension ;)

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #4 from Richard Biener  ---
But there's nothing invalid about these constant expressions?  But yeah

[Bug c++/90884] Option `-Wctor-dtor-privacy' enables warning even for system headers

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
The problem here is the naked note; the warning itself only triggers with
-Wsystem-headers.

[Bug c++/90881] -Wunused-value false positive in SFINAE context

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
(In reply to Federico Kircheis from comment #4)
> (In reply to Jonathan Wakely from comment #1)
> > Confirmed. We shouldn't give that warning in unevaluated contexts (decltype,
> > sizeof, etc.) because unevaluated operands have no effects at all, with or
> > without the comma operator.
> 
> The compiler flag is about unused variables, not statements without effects.
> 
> I guess it would be nice for
> 
> 
> int main(){
> decltype(short(), int()) a = 1;
> return a;
> }
> 
> 
> to have a warning that the left operand is unused (as of today), since here 
> SFINAE does not kick in:
> 
> --
> : In function 'int main()':
> :2:21: warning: left operand of comma operator has no effect
> [-Wunused-value]
> 2 | decltype(short(), int()) a = 1;
>   | ^
> --
> 
> But maybe there are not enough use-cases to be worth to diagnostic it.

With my patch, we wouldn't warn on this second testcase.  But clang++ doesn't
warn, either.

[Bug target/87281] qsort checking ICE in ia64_reorg building libgo

[jason.duerstock at gmail dot com]

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

--- Comment #6 from Jason Duerstock  ---
(In reply to Eric Botcazou from comment #5)

> Note that you need to test the trunk in order to get the diagnostics, or
> else to configure the 9.x compiler with --enable-checking=release,misc at
> least.

I don't understand how that applies in the context of Joseph's
build-many-glibcs.py script.

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
read_bytes(, (char *) &(val),
   ( (n < (2 ^ 8))  ? 1 :
 ( (n < (2 ^ 16)) ? 2 :
   ( (n < (2 ^ 24)) ? 3 :
 4 ) ) ) );

[Bug target/90834] Header and startup objects not found on macOS 10.15

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe  ---
(In reply to John Marshall from comment #9)
> The Homebrew folks have been configuring with a sysroot to work around this
> on Mojave since it came out last year:
> 
> --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> 
> and it bootstraps fine (in the context of their recipe [1]). Nobody seems to
> complain that frameworks etc in / are now missing, but it's entirely likely
> that none of their users are exercising it hard enough to notice.

Likewise, I configure this way pretty much all the time.

The frameworks themselves (executable binaries) are not missing from /

What's "missing" are the Header directories that used to be installed into /
(pre Sierra command line tools).  So now the Header directors, and a set of
"tbd" files (representing the linkable objects) are presented in the SDK. -
this is fine, as noted the paths they specify are correct for the runtimes.

> This has an unfortunate side-effect that the compiler looks in the
> non-existent /Library/.../MacOSX.sdk/usr/local/include instead of
> /usr/local/include [2].

That's an irritation, indeed.

> Longterm it seems like the GCC driver would need some basic xcrun
> capabilities, but as an immediate fix for that it seems like a configure
> option (--with-local-prefix-outside-sysroot?
> --without-local-prefix-sysroot?) to make LOCAL_INCLUDE_DIR ignore sysroots
> would be appropriate. (I've been composing such a proposal for gcc@...)

Configuring without a sysroot isn't going to work - there are no headers in /
to be found.
What is possible is to configure with a "build-time" sysroot, and then to
discover the actual one at runtime - the penalty there being potential 10ms+
time in looking something up (a bunch of syscalls at least).  As I've noted
before - it doesn't seem much until you multiply it by 400k for the GCC test
suite...

It's possible we could work around the /usr/include/local thing relatively
easily, one can add un-sysrooted paths (and also compiler-relative paths).

Making our own sysroot (which would allow us to control where it's installed)
is next to impossible, since many of the Frameworks are closed source.

> (I'm just a brewed-GCC user who'd like the compiler to basically work; not a
> Homebrew maintainer.)

We want it to work "out of the tin" - without external deps on a distro - so
"fixing" it is in the plan.

However configuring "--with-sysoot=" isn't actually broken, but a perfectly
valid approach, and we can probably make some auto-discovery in the configure
script that will work behind the scenes for most people.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to John Marshall from comment #4)
> (In reply to comment #3)
> > > --- Comment #2 from Iain Sandoe  ---
> > > * for the other things, if it's a beta, then perhaps there's some chance 
> > > it
> > > will be fixed before issue.
> > 
> > Right: I believe I got at least one such bug fixed during 10.14 Beta.
> 
> FWIW I've reported the AvailabilityInternal.h part to Apple (as FB6125120),
> though I'm just some rando on the internet so they probably haven't even
> read it yet. With a few dozen more duplicate reports they might look into
> it... :-)  (See https://twitter.com/jomarnz/status/1136275996515155969 and
> thread.)

thanks, AFAIU they are somewhat driven by radars for fixing things - so it's
worth doing.

> 
> > > * we 
> > >   - unconditionally define __has_xx(x) 0 in Darwin's builtin defines
> > 
> > That's most likely the easiest way out.
> 
> I don't think that'll help the AvailabityInternal.h problem as presumably
> these things are already decaying to 0, leading to a path through
> AvailabityInternal.h that never defines __AVAILABILITY_INTERNAL__MAC_10_14
> et al. So predefining them to 0 will lead to the same path, no?

let's not speculate ... could you (and/or Rainer) try this (untested) patch and
see how far it gets you?

(I don't expect it to solve all problems, but maybe some - it also might create
some by introducing the false assumption that the reports about
builtins/extensions are valid).

diff --git a/gcc/config/darwin-c.c b/gcc/config/darwin-c.c
index aa5d2f2..9440b30 100644
--- a/gcc/config/darwin-c.c
+++ b/gcc/config/darwin-c.c
@@ -731,6 +731,13 @@ darwin_cpp_builtins (cpp_reader *pfile)
   builtin_define_with_value ("__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__",
 macosx_version_as_macro(), false);

+  /* Until we implement __has-builtin, __has_feature, __has_extension it's
+ better to jam them to 0 than to fight the cases where system headers
+ have not been tested with GCC.  */
+  builtin_define_with_value ("__has_builtin(X)", "0", false);
+  builtin_define_with_value ("__has_feature(X)", "0", false);
+  builtin_define_with_value ("__has_extension(X)", "0", false);
+
   /* Since we do not (at 4.6) support ObjC gc for the NeXT runtime, the
  following will cause a syntax error if one tries to compile gc attributed
  items.  However, without this, NeXT system headers cannot be parsed 

> >>   - implement __has_x() .. which would be nicer, but not sure who has 
> >> time
> >> to do it .. 
> 
> I've been feeling some temptation to implement
> __attribute__(availability(...)) as a no-op that just ignores its arguments.
> It would be preferable for Apple to put the fallback definitions back into
> their header, but failing that capitulating to __availability__ seems
> least-worst.

I'm not in favour of defining that to "do nothing" (actually a "do nothing"
attribute patch is only a few lines) - I suspect defining it to "do nothing"
would open a different can of worms - at least the absence of something is a
known state to Apple - and reasonably can be made to operate conservatively.

I have an implementation for __attribute__(__unavailable__) on my gcc-5 branch,
it needs bringing forward (and get accepted onto trunk) - at that point, it's
probably not too hard to implement the availability attribute.

[Bug target/90834] Header and startup objects not found on macOS 10.15

[John.W.Marshall at glasgow dot ac.uk]

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

John Marshall  changed:

   What|Removed |Added

 CC||John.W.Marshall at glasgow dot 
ac.
   ||uk

--- Comment #9 from John Marshall  ---
The Homebrew folks have been configuring with a sysroot to work around this on
Mojave since it came out last year:

--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

and it bootstraps fine (in the context of their recipe [1]). Nobody seems to
complain that frameworks etc in / are now missing, but it's entirely likely
that none of their users are exercising it hard enough to notice.

This has an unfortunate side-effect that the compiler looks in the non-existent
/Library/.../MacOSX.sdk/usr/local/include instead of /usr/local/include [2].

Longterm it seems like the GCC driver would need some basic xcrun capabilities,
but as an immediate fix for that it seems like a configure option
(--with-local-prefix-outside-sysroot? --without-local-prefix-sysroot?) to make
LOCAL_INCLUDE_DIR ignore sysroots would be appropriate. (I've been composing
such a proposal for gcc@...)

(I'm just a brewed-GCC user who'd like the compiler to basically work; not a
Homebrew maintainer.)

[1] https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb
[2] https://github.com/Homebrew/homebrew-core/issues/35181

[Bug c++/90881] -Wunused-value false positive in SFINAE context

[federico.kircheis at gmail dot com]

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

--- Comment #4 from Federico Kircheis  ---
(In reply to Jonathan Wakely from comment #1)
> Confirmed. We shouldn't give that warning in unevaluated contexts (decltype,
> sizeof, etc.) because unevaluated operands have no effects at all, with or
> without the comma operator.

The compiler flag is about unused variables, not statements without effects.

I guess it would be nice for


int main(){
decltype(short(), int()) a = 1;
return a;
}


to have a warning that the left operand is unused (as of today), since here 
SFINAE does not kick in:

--
: In function 'int main()':
:2:21: warning: left operand of comma operator has no effect
[-Wunused-value]
2 | decltype(short(), int()) a = 1;
  | ^
--

But maybe there are not enough use-cases to be worth to diagnostic it.

[Bug target/90835] Incompatibilities with macOS 10.15 headers

[John.W.Marshall at glasgow dot ac.uk]

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

John Marshall  changed:

   What|Removed |Added

 CC||John.W.Marshall at glasgow dot 
ac.
   ||uk

--- Comment #4 from John Marshall  ---
(In reply to comment #3)
> > --- Comment #2 from Iain Sandoe  ---
> > * for the other things, if it's a beta, then perhaps there's some chance it
> > will be fixed before issue.
> 
> Right: I believe I got at least one such bug fixed during 10.14 Beta.

FWIW I've reported the AvailabilityInternal.h part to Apple (as FB6125120),
though I'm just some rando on the internet so they probably haven't even read
it yet. With a few dozen more duplicate reports they might look into it... :-) 
(See https://twitter.com/jomarnz/status/1136275996515155969 and thread.)

> > * we 
> >   - unconditionally define __has_xx(x) 0 in Darwin's builtin defines
> 
> That's most likely the easiest way out.

I don't think that'll help the AvailabityInternal.h problem as presumably these
things are already decaying to 0, leading to a path through
AvailabityInternal.h that never defines __AVAILABILITY_INTERNAL__MAC_10_14 et
al. So predefining them to 0 will lead to the same path, no?

>>   - implement __has_x() .. which would be nicer, but not sure who has 
>> time
>> to do it .. 

I've been feeling some temptation to implement __attribute__(availability(...))
as a no-op that just ignores its arguments. It would be preferable for Apple to
put the fallback definitions back into their header, but failing that
capitulating to __availability__ seems least-worst.

(That'd probably be big enough that I'd have to finally get myself
copyright-assigned first.)

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|GCC should warning about|GCC should warn about 2^16
   |2^16 and 2^32 and 2^64  |and 2^32 and 2^64

--- Comment #2 from Jonathan Wakely  ---
https://github.com/google/gvisor/pull/375

[Bug target/87281] qsort checking ICE in ia64_reorg building libgo

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-14
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Eric Botcazou  ---
> As of r272229 I can't replicate this:
> 
> $ ~/glibc/scripts/build-many-glibcs.py bmg --full-gcc compilers
> ia64-linux-gnu
> PASS: compilers-ia64-linux-gnu check-host-libraries
> ...
> PASS: compilers-ia64-linux-gnu done

Note that you need to test the trunk in order to get the diagnostics, or else
to configure the 9.x compiler with --enable-checking=release,misc at least.

[Bug c++/90885] GCC should warning about 2^16 and 2^32 and 2^64

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
And maybe also 10^X where X is a literal.
https://codesearch.isocpp.org/cgi-bin/cgi_ppsearch?q=10+%5E=Search

A sample:

tp->tv_sec  = attributes[0] / 10^9;
tp->tv_nsec = attributes[0] % 10^9;

 range->pmin[TREND_FCT] = -10^10;
 range->pmax[TREND_MEAN] = 10^10;


#define IRQ_CHINT5_LEVEL(12 ^ 7)
#define IRQ_CHINT4_LEVEL(11 ^ 7)
#define IRQ_CHINT3_LEVEL(10 ^ 7)
#define IRQ_CHINT2_LEVEL(9 ^ 7)
#define IRQ_CHINT1_LEVEL(8 ^ 7)

[Bug c++/90885] New: GCC should warning about 2^16 and 2^32 and 2^64

[redi at gcc dot gnu.org]

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

Bug ID: 90885
   Summary: GCC should warning about 2^16 and 2^32 and 2^64
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

GCC doesn't warn for:

short maxshort = 2^16;
int maxint = 2^32;
long maxlong = 2^64;

Sadly people actually do this:
https://twitter.com/jfbastien/status/1139298419988549632
https://twitter.com/mikemx7f/status/1139335901790625793

We probably want it for both C and C++.

[Bug c/90882] Possible security breach through undefined behavior when treating boolean as int

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Kevin Dewald from comment #1)
> From what I've read, modifying a boolean variable with an int pointer is
> undefined.

Yes.

> Nevertheless, this feels unexpected from a programmers point of
> view,

Yes, that's the nature of undefined behaviour. So don't do it.

[Bug c++/90881] -Wunused-value false positive in SFINAE context

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
That was quick!

[Bug c++/90880] compile error instead of SFINAE with non-public member variables

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Federico Kircheis from comment #3)
> Sorry if linking to external bug trackers in comments is bad practice, but I
> did not saw any rule about it.

There's no rule against it, it's useful.

> Since it could be interesting for those having this issue, here is the bug
> report for MSVC: 
> 
> https://developercommunity.visualstudio.com/content/problem/607019/incorrect-
> decltype-on-non-public-member-variables.html

Thanks.

[Bug c++/90884] Option `-Wctor-dtor-privacy' enables warning even for system headers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed, but I'll also use a #pragma to disable the warning for __nonesuch
because it *has* to be that way, by design.

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org,
   ||law at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
  Component|c++ |tree-optimization

--- Comment #3 from Richard Biener  ---
So before SRA we have

slow ()
{
  struct C D.26322;
  struct C D.29886;

   :
  D.26322 = {};
  D.26322.a = {};
  D.26322.b = 0;
  D.29886 = D.26322;
  D.26322 ={v} {CLOBBER};
  return D.29886;

fast ()
{
  struct C c;
  struct C D.29889;

   :
  c = {};
  D.29889 = c;
  c ={v} {CLOBBER};
  return D.29889;

and then SRA does nothing to fast but half-way optimizes slow() to

   :
  D.26322 = {};
  D.26322.a = {};
  D.29886 = D.26322;
  D.26322 ={v} {CLOBBER};
  return D.29886;

where then probably DSE wrecks things by trimming the earlier store:

   :
  MEM[(struct C *) + 7B] = {};
  D.26322.a = {};
  D.29886 = D.26322;
  D.26322 ={v} {CLOBBER};
  return D.29886;

which we later do not recover from (store-merging?).  I also wonder
why SRA does not elide the aggregate copy.

-O2 -fno-tree-dse generates

_Z4slowv:
.LFB1099:
.cfi_startproc
movq$0, -32(%rsp)
xorl%eax, %eax
xorl%edx, %edx
ret

[Bug tree-optimization/90879] fold zero-equality of strcmp between a longer string and a smaller array

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-06-14
 Ever confirmed|0   |1

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