[Bug middle-end/93631] internal compiler error: in gimple_ca ll_arg, at gimple.h:3258

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-10
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.  As said elsewhere the real issue lies in the C FE having this kind
of prototypes marked with BUILT-IN.

[Bug c++/93632] Build time regression in 9.2.1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-02-10
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Same as PR92442?  Try without -fdebug-types-section -ggnu-pubnames

[Bug gcov-profile/93626] [GCOV] incorrect coverage when compiled with option '-fsanitize=undefined' for typedef struct

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-10
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I would not recommend combining --coverage and a sanitizer.

[Bug gcov-profile/93623] No need to dump gcdas when forking

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-10
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug middle-end/93644] [10 Regression] spurious -Wreturn-local-addr with PHI of PHI

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug libstdc++/93602] Missing reference to libiconv in 9.x libstdc++

[ilg at livius dot net]

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

--- Comment #13 from Liviu Ionescu  ---
I'm not sure what the best solution might be, but it looks like the configure
script can detect the case when a distinct libiconv is encountered.

In this case the only thing that is needed is an explicit reference in
libstdc++ to libiconv, to instruct the loader.


The other possible case, which is to ignore the separate libiconv is a bit more
tricky, since it involves the order of processing the headers. If iconv.h is
first encountered in the distinct libiconv, I don't know what we can do to
ignore it and go to the next definition in the system headers.

As I said, in my environment it was easy to uninstall libiconv, since none of
the applications really needed the new version, the system one was enough, but
there might be situations when this is not true, and in this case compiling gcc
produces a shared library that requires applications using it to explicitly use
-liconv.

It would be interesting to check what happens when installing libiconv in a
regular system, not a custom build environment like mine, is it picked by
configure or the system one is used and the problem is somehow masked.

[Bug target/92518] [10 regression] ppc rounding tests fail after r278207

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #9 from Martin Liška  ---
I'll take a look.

[Bug lto/92599] [8/9 regression] ICE in speculative_call_info, at cgraph.c:1142

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
I would close it.

[Bug other/93641] Wrong strncmp and strncasecmp size arguments

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I'll handle some of these (i386.c is my fault, have already verified cp/error.c
too, now looking into c-format.c).

[Bug inline-asm/93648] New: Inline assembly and C++ references cause uninitialized read

[rzhikharev...@yandex-team.ru]

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

Bug ID: 93648
   Summary: Inline assembly and C++ references cause uninitialized
read
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rzhikharev...@yandex-team.ru
  Target Milestone: ---

Created attachment 47809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47809&action=edit
Triggering code

Passing a char[16] reference operand to inline assembly causes an uninitialized
memory read. Changing the '+' modifier to '=' turns it into an uninitialized
register read. See the attachment for details.

[Bug c++/93618] [10 Regression] : unknown array size in delete when using C++20 standard

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:59dbb04df76da41f26192c2c219584fc3d6017cc

commit r10-6543-g59dbb04df76da41f26192c2c219584fc3d6017cc
Author: Jason Merrill 
Date:   Mon Feb 10 00:47:34 2020 +0100

c++: Fix flexible array with synthesized constructor.

We were already rejecting initialization of a flexible array member in a
constructor; we similarly shouldn't try to clean it up.

PR c++/93618
* tree.c (array_of_unknown_bound_p): New.
* init.c (perform_member_init): Do nothing for flexible arrays.

[Bug inline-asm/93648] Inline assembly and C++ references cause uninitialized read

[rzhikharev...@yandex-team.ru]

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

--- Comment #1 from Roman Zhikharevich  ---
Reproducible in G++ 9.1 and 9.2, but not 8.3 (did not test 9.0 because
godbolt.org doesn't support it).

[Bug inline-asm/93648] Inline assembly and C++ references cause uninitialized read

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
First off the comma is ignored in inline-asm.

[Bug inline-asm/93648] Inline assembly and C++ references cause uninitialized read

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-02-10
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
The generated inline-asm looks correct for both x86_64 and AARCH64.
There is a warning too for x86_64:
# 4 "t1.cc" 1
t1.cc: In function ‘int main()’:
t1.cc:6:1: warning: unsupported size for integer register
6 | }
  | ^


The generated code is:
movq.LC0(%rip), %rax
movq.LC0+8(%rip), %rdx
#APP
# 4 "t1.cc" 1
//%rax
# 0 "" 2
#NO_APP
movsbl  %al, %eax

here the reference is stabilized.


>Changing the '+' modifier to '=' turns it into an uninitialized register read. 
> See the attachment for details.

Yes because it is saying you are writing the whole field and not reading from
it at all.  Using the wrong modifier and the wrong constraints can do that.

The documentation for '=' is:
Means that this operand is written to by this instruction: the previous value
is discarded and replaced by new data.

What did you think was correct?

[Bug analyzer/93649] New: ICE in get_representative, at analyzer/constraint-manager.cc:297

[asolokha at gmx dot com]

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

Bug ID: 93649
   Summary: ICE in get_representative, at
analyzer/constraint-manager.cc:297
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

Created attachment 47810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47810&action=edit
Testcase

gcc-10.0.1-alpha20200209 snapshot (g:8686c4d84517b54cf3dfe98fca3a814b7d606502)
ICEs when compiling the attached testcase w/ -O2 -fanalyzer:

% gcc-10.0.1 -O2 -fanalyzer -w -c a0avgfhq.c
during IPA pass: analyzer
a0avgfhq.c: In function 'ts':
a0avgfhq.c:59:7: internal compiler error: in get_representative, at
analyzer/constraint-manager.cc:297
   59 |   h5 (cx);
  |   ^~~
0x792f18 ana::equiv_class::get_representative() const
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/constraint-manager.cc:297
0x792f18 ana::equiv_class::get_representative() const
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/constraint-manager.cc:291
0x792f18 ana::constraint_manager::canonicalize(unsigned int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/constraint-manager.cc:1260
0x1104209 ana::region_model::canonicalize(ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/region-model.cc:3787
0x10f86dd ana::program_state::prune_for_point(ana::exploded_graph&,
ana::program_point const&, ana::state_change*) const
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/program-state.cc:915
0x10e531e ana::exploded_graph::get_or_create_node(ana::program_point const&,
ana::program_state const&, ana::state_change*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/engine.cc:1841
0x10e84e9 ana::exploded_graph::process_node(ana::exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/engine.cc:2465
0x10e8c62 ana::exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/engine.cc:2266
0x10e9389 ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/engine.cc:3617
0x10e9e2c ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/engine.cc:3674
0x10df5b8 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/analyzer/analyzer-pass.cc:84

[Bug other/93641] Wrong strncmp and strncasecmp size arguments

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org,
   ||mrs at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
In doc/invoke.texi it is correct as is, and I'll defer the darwin-c.c change to
Darwin maintainers.

[Bug inline-asm/93648] Inline assembly and C++ references cause uninitialized read

[rzhikharev...@yandex-team.ru]

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

--- Comment #4 from Roman Zhikharevich  ---
Sorry, I forgot to mention that this is triggered with -O2, on x86-64.

> First off the comma is ignored in inline-asm.

This doesn't seem to be true because it changes the generated assembly.

[Bug inline-asm/93648] Inline assembly and C++ references cause uninitialized read

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
This inline-asm has issue anyways.

[Bug inline-asm/93648] Inline assembly and C++ references cause uninitialized read

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
What exactly are you trying to do with this inline-asm?

[Bug c++/93650] New: ICE in cxx_eval_constant_expression, at cp/constexpr.c:5626

[asolokha at gmx dot com]

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

Bug ID: 93650
   Summary: ICE in cxx_eval_constant_expression, at
cp/constexpr.c:5626
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.1-alpha20200209 snapshot (g:8686c4d84517b54cf3dfe98fca3a814b7d606502)
ICEs when compiling the following testcase, extracted from
gcc/testsuite/g++.dg/cpp2a/spaceship-scalar1.C, w/ -std=c++2a -Wall:

#include 

void
foo ()
{
  auto v = 1 <=> 2;
}

% g++-10.0.1 -std=c++2a -Wall -c tezg1h8p.C
tezg1h8p.C: In function 'void foo()':
tezg1h8p.C:6:18: internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:5626
6 |   auto v = 1 <=> 2;
  |  ^
0x5ee4e1 cxx_eval_constant_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/constexpr.c:5626
0x8a0c76 cxx_eval_constant_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/constexpr.c:5883
0x8a47a6 cxx_eval_outermost_constant_expr
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/constexpr.c:6404
0x8a8e67 maybe_constant_value(tree_node*, tree_node*, bool, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/constexpr.c:6695
0x93193d fold_for_warn(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/expr.c:401
0xab2ecf check_function_restrict
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/c-family/c-common.c:5410
0xab2ecf check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/c-family/c-common.c:5750
0x8721d3 build_over_call
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/call.c:8818
0x874d4d build_new_method_call_1
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/call.c:10295
0x875ee0 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/call.c:10370
0x875ee0 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/call.c:9771
0x8d43e1 ocp_convert(tree_node*, tree_node*, int, int, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/cvt.c:938
0x9393c5 expand_default_init
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/init.c:1894
0x9393c5 expand_aggr_init_1
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/init.c:2071
0x93b41b build_aggr_init(tree_node*, tree_node*, int, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/init.c:1806
0x8e73dd build_aggr_init_full_exprs
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/decl.c:6584
0x8e73dd check_initializer
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/decl.c:6768
0x90b4fe cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/decl.c:7746
0x9b48fb cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/parser.c:20831
0x995313 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200209/work/gcc-10-20200209/gcc/cp/parser.c:13678

[Bug analyzer/93375] ICE in gimple_call_arg, at gimple.h:3258

[clyon at gcc dot gnu.org]

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

--- Comment #8 from Christophe Lyon  ---
(In reply to David Malcolm from comment #7)
> Does the patch in comment #6 fix the remaining test failures for everyone?

It's OK for me on arm, thanks.

[Bug inline-asm/93648] Inline assembly and C++ references cause uninitialized read

[rzhikharev...@yandex-team.ru]

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

--- Comment #7 from Roman Zhikharevich  ---
I am writing benchmarking code for my project and trying to make the compiler
ignore its knowledge of certain values during optimization. I settled for

  template 
  void black_box(T* value) {
asm volatile ("" :: "g"(value) : "memory");
  }

but I am trying to figure out the reasoning behind Google Benchmark's
implementation of similar functionality:
https://github.com/google/benchmark/blob/7d97a057e16597e8020d0aca110480fe82c9ca67/include/benchmark/benchmark.h#L318

They use

  template 
  inline BENCHMARK_ALWAYS_INLINE void DoNotOptimize(Tp& value) {
  #if defined(__clang__)
asm volatile("" : "+r,m"(value) : : "memory");
  #else
asm volatile("" : "+m,r"(value) : : "memory");
  #endif
  }

[Bug c++/93650] ICE in cxx_eval_constant_expression, at cp/constexpr.c:5626

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
W/o :

namespace std {
  using type = enum _Ord { less };
  class strong_ordering {
type _M_value;
constexpr strong_ordering(_Ord) : _M_value() {}
static const strong_ordering less;
static strong_ordering equal;
static strong_ordering greater;
  } constexpr strong_ordering::less(_Ord::less);
  auto v = 1 <=> 2;
}

[Bug c++/93650] [10 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.c:5626

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-10
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|ICE in  |[10 Regression] ICE in
   |cxx_eval_constant_expressio |cxx_eval_constant_expressio
   |n, at cp/constexpr.c:5626   |n, at cp/constexpr.c:5626
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f

[Bug c++/93650] [10 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.c:5626

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I guess we could do something like punt instead of ICEing if CONSTRUCTOR
appears there with ctx->uid_sensitive, but whether it is the correct thing to
do, no idea.

[Bug middle-end/93636] Incorrect diagnostic of a potential string overflow in strncat

[sebunger44 at gmail dot com]

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

--- Comment #4 from Sebastian Unger  ---
I agree that the API of strncat is confusingly different to many of the other
API such as strncpy etc. However, the use-case I show is a valid one (as far as
one can ever consider any use of a non-terminated string 'valid'). I will
probably eventually go through all these cases and see if I can refactor them,
but I'd rather neither delay the introduction of the new GCC version nor turn
off the entire diagnostic warning this is currently under (it also found some
real bugs).

So, for my purpose having a separate option for this case which may be valid
would be an acceptable solution.

[Bug inline-asm/93648] Inline assembly and C++ references cause uninitialized read

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
See PR 92597.

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

[Bug inline-asm/92597] std::fma gives nan using -march=sandybridge+ with asm volatile

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rzhikharevich@yandex-team.r
   ||u

--- Comment #17 from Andrew Pinski  ---
*** Bug 93648 has been marked as a duplicate of this bug. ***

[Bug c++/93650] [10 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.c:5626

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-10
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r10-6110-g8158a4640819dbb3210326e37786fb874f450272 , before that
the vars have been mangled - _ZZ2f1E1f, _ZZ2f2E1f .
BTW, I get an ICE instead of assembler-failure:
pr93643.C:25:1: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
   25 | }
  | ^
f/2 (void (* f)()) @0x7f7f7a699200
  Type: variable definition analyzed
  Visibility: no_reorder public weak comdat comdat_group:f one_only
  previous sharing asm name: 0
  References: 
  Referring: f2/3 (write)f2/3 (read)
  Availability: not-ready
  Varpool flags:
f/0 (void (* f)()) @0x7f7f7a699180
  Type: variable definition analyzed
  Visibility: no_reorder public weak comdat comdat_group:f one_only
  next sharing asm name: 2
  References: 
  Referring: f1/1 (write)f1/1 (read)
  Availability: not-ready
  Varpool flags:
pr93643.C:25:1: internal compiler error: symtab_node::verify failed
0xe54eff symtab_node::verify_symtab_nodes()
../../gcc/symtab.c:1342
0xe7cf94 symtab_node::checking_verify_symtab_nodes()
../../gcc/cgraph.h:667
0xe7b065 symbol_table::compile()
../../gcc/cgraphunit.c:2720
0xe7b696 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2984
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
assembler-failure only if -fno-checking.

[Bug c/93640] The write_only and read_write attributes can be mistyped due to invalid strncmp size argument

[dominik.b.czarnota+bugzilla at gmail dot com]

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

--- Comment #2 from Dominik Czarnota  ---
Just to clarify, I reported other cases like this in Bug 93641 - Wrong strncmp
and strncasecmp size arguments
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93641).

[Bug target/93637] [9/10 Regression] ICE: Segmentation fault (in force_operand)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The problem is that with -mavx -mno-avx2, we have vcondv4div4df optab, but not
vcondv4div4di.  Before fre4 we have:
  vect_cst__5 = { 0.0, 0.0, 1.0e+0, 0.0 };
...
  _55 = &ev[0] + 32;
  MEM  [(double *)_55] = vect_cst__5;
...
  vect_cst__49 = { 0.0, 0.0, 0.0, 0.0 };
...
  vectp_ev.9_29 = &ev + 32;
...
  vect__1.11_77 = MEM  [(double *)vectp_ev.9_29];
...
  _80 = VEC_COND_EXPR ;
which fre4 optimizes into:
  _80 = VEC_COND_EXPR <{ -1, -1, 0, -1 }, { 5, 6, 7, 8 }, _28>;
but with the comparison in VEC_COND_EXPR simplified into a constant all traces
of the V4DF are gone, and this is after the last veclower pass.

[Bug target/93637] [9/10 Regression] ICE: Segmentation fault (in force_operand)

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #3)
>   _80 = VEC_COND_EXPR <{ -1, -1, 0, -1 }, { 5, 6, 7, 8 }, _28>;

Isn't a constant argument 0 for VEC_COND_EXPR really a VEC_PERM?

[Bug target/93637] [9/10 Regression] ICE: Segmentation fault (in force_operand)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
It is a blend, so yes, it can be represented as VEC_PERM_EXPR, or using
vcond_mask_optab etc.
The trouble is that TARGET_AVX && !TARGET_AVX2 is really weird when 32-byte
integral modes are involved and the question is what the middle-end should try
as a fallback if it sees the vcond{,u} failing when the condition is constant.
Because VEC_PERM_EXPR is said not to be supported:
typedef long long __v4di __attribute__((vector_size (32)));

__v4di
foo (__v4di z, __v4di u)
{
  return __builtin_shuffle (z, u, (__v4di) { 0, 1, 6, 3 });
}
with -mavx this is lowered during veclower.
I'd say we either should enable vcond_mask* even for V4DI/V8SI, or disable
vcond{v4div4df,v8siv8sf} for !TARGET_AVX2 && TARGET_AVX.
Untested patch to do the former fixes the ICE:
--- gcc/config/i386/sse.md.jj   2020-02-10 13:14:02.970131692 +0100
+++ gcc/config/i386/sse.md  2020-02-10 13:14:43.689525366 +0100
@@ -3430,13 +3430,19 @@ (define_expand "vcond_mask_ 3 "register_operand")))]
   "TARGET_AVX512BW")

+;; As vcondv4div4df and vcondv8siv8sf are enabled already with TARGET_AVX,
+;; and their condition can be folded late into a constant, we need to
+;; support vcond_mask_v4div4di and vcond_mask_v8siv8si for TARGET_AVX.
+(define_mode_iterator VI_256_AVX2 [(V32QI "TARGET_AVX2") (V16HI "TARGET_AVX2")
+  V8SI V4DI])
+
 (define_expand "vcond_mask_"
-  [(set (match_operand:VI_256 0 "register_operand")
-   (vec_merge:VI_256
- (match_operand:VI_256 1 "nonimmediate_operand")
- (match_operand:VI_256 2 "nonimm_or_0_operand")
+  [(set (match_operand:VI_256_AVX2 0 "register_operand")
+   (vec_merge:VI_256_AVX2
+ (match_operand:VI_256_AVX2 1 "nonimmediate_operand")
+ (match_operand:VI_256_AVX2 2 "nonimm_or_0_operand")
  (match_operand: 3 "register_operand")))]
-  "TARGET_AVX2"
+  "TARGET_AVX"
 {
   ix86_expand_sse_movcc (operands[0], operands[3],
 operands[1], operands[2]);

[Bug libstdc++/93651] New: std::ranges::iota_view::iterator is not a Cpp17 input iterator

[pilarlatiesa at gmail dot com]

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

Bug ID: 93651
   Summary: std::ranges::iota_view::iterator is not a
Cpp17 input iterator
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pilarlatiesa at gmail dot com
  Target Milestone: ---

In my understanding, std::ranges::iota_view::iterator should model
at least Cpp17InputIterator, but it doesn't. In contrast,
std::ranges::iota_view::iterator is accepted as an input iterator.

I surfaced the issue in -std=c++2a, while it does not happen with -std=gnu++2a,
which makes me think it is possibly related to  __iota_diff_t being defined as
__int128 (PR 93267).

Below there's an example showing the issue.

$ cat test1.cpp

#include 
#include 

int main()
{
  std::ranges::iota_view const i(0, 10u);
  std::vector v(std::begin(i), std::end(i));
}

$ cat test2.cpp

#include 
#include 

int main()
{
  std::ranges::iota_view const i(0, 10u);
  std::vector v(std::begin(i), std::end(i));
}

./g++ -std=gnu++2a -c test2.cpp

no output

./g++ -std=c++2a -c test2.cpp

no output

./g++ -std=gnu++2a -c test1.cpp

no output

./g++ -std=c++2a -c test1.cpp

test1.cpp: In function 'int main()':
test1.cpp:7:56: error: no matching function for call to 'std::vector::vector(std::ranges::iota_view::_Iterator, std::ranges::iota_view::_Iterator)'
7 |   std::vector v(std::begin(i), std::end(i));
  |^
In file included from
/home/pililatiesa/gcc-trunk-20200208/include/c++/10.0.1/vector:67,
 from test1.cpp:1:
/home/pililatiesa/gcc-trunk-20200208/include/c++/10.0.1/bits/stl_vector.h:650:2:
note: candidate: 'template std::vector<_Tp,
_Alloc>::vector(_InputIterator, _InputIterator, const allocator_type&) [with
_InputIterator = _InputIterator;  =
; _Tp = long unsigned int; _Alloc = std::allocator]'
  650 |  vector(_InputIterator __first, _InputIterator __last,
  |  ^~
/home/pililatiesa/gcc-trunk-20200208/include/c++/10.0.1/bits/stl_vector.h:650:2:
note:   template argument deduction/substitution failed:
In file included from
/home/pililatiesa/gcc-trunk-20200208/include/c++/10.0.1/bits/move.h:57,
 from
/home/pililatiesa/gcc-trunk-20200208/include/c++/10.0.1/bits/stl_pair.h:59,
 from
/home/pililatiesa/gcc-trunk-20200208/include/c++/10.0.1/bits/stl_algobase.h:64,
 from
/home/pililatiesa/gcc-trunk-20200208/include/c++/10.0.1/vector:60,
 from test1.cpp:1:
/home/pililatiesa/gcc-trunk-20200208/include/c++/10.0.1/type_traits: In
substitution of 'template using __enable_if_t = typename
std::enable_if::type [with bool _Cond = false; _Tp = void]':
/home/pililatiesa/gcc-trunk-20200208/include/c++/10.0.1/bits/stl_iterator_base_types.h:249:11:
  required by substitution of 'template using _RequireInputIter
= std::__enable_if_t::iterator_category,
std::input_iterator_tag>::value> [with _InIter = std::ranges::iota_view::_Iterator]'
/home/pililatiesa/gcc-trunk-20200208/include/c++/10.0.1/bits/stl_vector.h:649:9:
  required from here
/home/pililatiesa/gcc-trunk-20200208/include/c++/10.0.1/type_traits:2191:11:
error: no type named 'type' in 'struct std::enable_if'
 2191 | using __enable_if_t = typename enable_if<_Cond, _Tp>::type;
  |   ^

[...] (The error message continues listing the other constructors)


g++ -v

Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk-20200208/configure --prefix=/usr
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--disable-bootstrap --with-abi=m64 --enable-clocale=gnu
--enable-languages=c,c++,fortran --enable-ld=yes --enable-checking=release
--enable-lto --enable-threads=posix --enable-libatomic --enable-libcilkrts
--enable-libgomp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200208 (experimental) (GCC)

[Bug other/89863] [meta-bug] Issues that static analyzers (cppcheck, clang-static-analyzer) find that gcc misses

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
For this C++ code:

// reading 8 bytes from a 5 byte field

# include 
# include 

struct S
{
char a[ 5];
short b;
};

void f( const S * ps)
{
uint64_t n;

memcpy( &n, ps->a, sizeof( uint64_t));
}

derived from recent Linux kernel, gcc has nothing to say:

$ /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra feb10a.cc
$ 

Interestingly, clang++ doesn't say much either:

$ clang++ -c -O2 -Wall -Wextra feb10a.cc
$ 

Adding _FORTIFY_SOURCE=2 doesn't help. Here is cppcheck in action:

$ /home/dcb/cppcheck/trunk/cppcheck  feb10a.cc
feb10a.cc:17:16: error: Buffer is accessed out of bounds: ps->a
[bufferAccessOutOfBounds]
 memcpy( &n, ps->a, sizeof( uint64_t));
   ^
$

[Bug c++/93618] [10 Regression] : unknown array size in delete when using C++20 standard

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed.

[Bug c++/92583] [8/9/10 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:15552

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug analyzer/93375] ICE in gimple_call_arg, at gimple.h:3258

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from David Malcolm  ---
Thanks.  I'll mark this as resolved; feel free to reopen if any configurations
are still failing.

[Bug analyzer/93647] ICE in get_lvalue_1, at analyzer/region-model.cc:4613

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-10
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Still affects master; it's get_any_origin on an INTEGER_CST, which calls
get_lvalue on it, and hits a gcc_unreachable.

[Bug other/89863] [meta-bug] Issues that static analyzers (cppcheck, clang-static-analyzer) find that gcc misses

[dcb314 at hotmail dot com]

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

--- Comment #7 from David Binderman  ---
For this C++ code:

// Division by zero.

extern void g();

void f()
{
unsigned int vsync_rate_hz = 0;
unsigned int frame_time_microsec = 100 / vsync_rate_hz;

g();
}

gcc and clang have nothing to say, even with -g -O2 -Wall -Wextra 
but cppcheck finds the problem.

[Bug analyzer/93649] ICE in get_representative, at analyzer/constraint-manager.cc:297

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-10
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed.

[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled

[iucar at fedoraproject dot org]

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

--- Comment #2 from Iñaki Ucar  ---
Created attachment 47811
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47811&action=edit
test.ii

[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled

[iucar at fedoraproject dot org]

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

--- Comment #3 from Iñaki Ucar  ---
I got no backtrace, just the output shown in my first comment, at least with
the gcc version included in Fedora Rawhide. I've just attached the test.ii file
too. With -v:

$ g++ -v -save-temps test.cpp 
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200130 (Red Hat 10.0.1-0.7) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/10/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o test.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/10/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/10/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10

/usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/x86_64-redhat-linux
 /usr/lib/gcc/x86_64-redhat-linux/10/../../../../include/c++/10/backward
 /usr/lib/gcc/x86_64-redhat-linux/10/include
 /usr/local/include
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-redhat-linux/10/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -version -o
test.s
GNU C++14 (GCC) version 10.0.1 20200130 (Red Hat 10.0.1-0.7)
(x86_64-redhat-linux)
compiled by GNU C version 10.0.1 20200130 (Red Hat 10.0.1-0.7), GMP
version 6.1.2, MPFR version 4.0.2-p1, MPC version 1.1.0, isl version
isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 10.0.1 20200130 (Red Hat 10.0.1-0.7)
(x86_64-redhat-linux)
compiled by GNU C version 10.0.1 20200130 (Red Hat 10.0.1-0.7), GMP
version 6.1.2, MPFR version 4.0.2-p1, MPC version 1.1.0, isl version
isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 80355902cebbb142e87c9570dbf4f6a2
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o test.o test.s
GNU assembler version 2.34 (x86_64-redhat-linux) using BFD version version
2.34-1.fc32
test.s: Assembler messages:
test.s:41: Error: symbol `f' is already defined

[Bug libstdc++/93651] std::ranges::iota_view::iterator is not a Cpp17 input iterator

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-10
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I think this is a defect in the C++2a draft. The cpp17-iterator concept
requires the difference_type to be a signed integral type. To work with
iota_view's iterators I think it should permit signed integer-like types as
well (because iota_view's iterators use non-integral types to represent the
difference type when the view uses the largest integer type).

[Bug libstdc++/93502] std::regex_match uses stack space proportional to input string length

[a...@cloudius-systems.com]

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

--- Comment #6 from Avi Kivity  ---
Even if match_results stores a copy of the matching string, it would be stored
on the heap and only pointers would be stored on the stack. So the stack
overflow comes from recursion, not because of the delegation to the overload
that creates the match_results.

[Bug libstdc++/93651] std::ranges::iota_view::iterator is not a Cpp17 input iterator

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Created attachment 47812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47812&action=edit
Make cpp17-input-iterator concept allow non-integral types.

This patch fixes the problem.

[Bug c++/93652] New: -Wconversion gives false warning with bitwise operations on reference types returned from function

[gcc at mailinator dot com]

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

Bug ID: 93652
   Summary: -Wconversion gives false warning with bitwise
operations on reference types returned from function
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at mailinator dot com
  Target Milestone: ---

```
[]$ /bin/g++ -v
Using built-in specs.
COLLECT_GCC=/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC) 
[]$ cat a.cpp
char x,y;
char& f(){ return x; }
char& g(){ return y; }
void h(){ f()^=g(); }
[]$ /bin/g++ -Wconversion -c a.cpp 
a.cpp: In function ‘void h()’:
a.cpp:4:18: warning: conversion from ‘int’ to ‘char’ may change value
[-Wconversion]
4 | void h(){ f()^=g(); }
  |  ^

```

Similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38522, but this only
happens with reference returned from functions. Local reference created in the
function or local variable does not raise the bug.

[Bug other/93641] Wrong strncmp and strncasecmp size arguments

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:36a798fd192ced25eefaeee345507fa1a0c0356e

commit r10-6544-g36a798fd192ced25eefaeee345507fa1a0c0356e
Author: Jakub Jelinek 
Date:   Mon Feb 10 15:02:39 2020 +0100

i386: Fix strncmp last arguments in x86_64_elf_section_type_flags

Clearly I can't count, so we would consider as SECTION_BSS even sections
like .lbssfoo or .gnu.linkonce.lbbar, even when linker only considers as
special .lbss or .lbss.baz or .gnu.linkonce.lb.qux.

2020-02-10  Jakub Jelinek  

PR target/58218
PR other/93641
* config/i386/i386.c (x86_64_elf_section_type_flags): Fix up last
arguments of strncmp.

[Bug target/58218] -mcmodel=medium cause assembler warning "ignoring incorrect section type for .lbss"

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:36a798fd192ced25eefaeee345507fa1a0c0356e

commit r10-6544-g36a798fd192ced25eefaeee345507fa1a0c0356e
Author: Jakub Jelinek 
Date:   Mon Feb 10 15:02:39 2020 +0100

i386: Fix strncmp last arguments in x86_64_elf_section_type_flags

Clearly I can't count, so we would consider as SECTION_BSS even sections
like .lbssfoo or .gnu.linkonce.lbbar, even when linker only considers as
special .lbss or .lbss.baz or .gnu.linkonce.lb.qux.

2020-02-10  Jakub Jelinek  

PR target/58218
PR other/93641
* config/i386/i386.c (x86_64_elf_section_type_flags): Fix up last
arguments of strncmp.

[Bug other/93641] Wrong strncmp and strncasecmp size arguments

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:13686ecef23bcfe9443a0755c73a19d677b786bd

commit r10-6545-g13686ecef23bcfe9443a0755c73a19d677b786bd
Author: Jakub Jelinek 
Date:   Mon Feb 10 15:04:55 2020 +0100

c++: Fux strncmp last argument in dump_decl_name [PR93641]

I'm not aware of symbols starting with _ZG that don't start with _ZGR
prefix, but perhaps in the future there might be some.

2020-02-10  Jakub Jelinek  

PR other/93641
* error.c (dump_decl_name): Fix up last argument to strncmp.

[Bug c++/93632] Build time regression in 9.2.1

[jeanmichael.celerier at gmail dot com]

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

--- Comment #2 from Jean-Michaël Celerier  ---
Without these options it goes down from 2 minutes to 16 seconds which is
already much better, but still a couple times slower than before

[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]

[rguenth at gcc dot gnu.org]

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

--- Comment #17 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #16)
> I'll play with it next week.

What can be handled specially is certainly size2i == maxsizei for the
known_subrange_p case.  Then we can pun the RHS directly without
going through native encode/interpret.  But I always thought we have
too much special-casing there anyways - more generalized bit-precision
and offset aware native encode/interpret handling would be appreciated.

As for the more complex case of handling non-constants mixed with constants
I do have some patches in the queue for stage1 for the partial overlap case
but only for byte offsets/sizes again.

Note there's always the question as to what replacements we want VN to make
since an extra load can be quite cheap sometimes compared to having a live
register that needs to be combined.  VN doesn't know whether the memory
can be elided later to offset such cost :/

For bitfields there's also the ever present bitfield-lowering idea...

And the fact that optimize_bit_field_compare is done way too early.

[Bug target/93615] [10 Regression] unwind.h on arm can't be compiled with -std=c11

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

https://gcc.gnu.org/g:5602b48b2ed84feb1a5792e3d73b00b42138ca6e

commit r10-6546-g5602b48b2ed84feb1a5792e3d73b00b42138ca6e
Author: Christophe Lyon 
Date:   Mon Feb 10 12:54:39 2020 +

arm: Fix up arm installed unwind.h for use in pedantic modes [PR93615]

Commit r10-6500-g811a475ea3fcc55ee4aea7c81171891ef19dfc25 broke the
GCC build for arm-none-uclinuxfdpiceabi, as it forgot to update some
uses of gnu_Unwind_Find_got.

2020-02-10  Christophe Lyon  

libgcc/
PR target/93615
* unwind-arm-common.inc: Replace uses of gnu_Unwind_Find_got with
_Unwind_gnu_Find_got.
* unwind-pe.h: Likewise.

[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #17)
> As for the more complex case of handling non-constants mixed with constants
> I do have some patches in the queue for stage1 for the partial overlap case
> but only for byte offsets/sizes again.
> 
> Note there's always the question as to what replacements we want VN to make
> since an extra load can be quite cheap sometimes compared to having a live
> register that needs to be combined.  VN doesn't know whether the memory
> can be elided later to offset such cost :/

I wanted to try to handle the complex case, and see if e.g. something we use in
store-merging where we have to deal with all the bit but not byte aligned
positions and sizes couldn't be used here too.

> For bitfields there's also the ever present bitfield-lowering idea...

I understood Andrew P. is working on something, but no idea how far it is.

> And the fact that optimize_bit_field_compare is done way too early.

Agreed on that.

[Bug other/93641] Wrong strncmp and strncasecmp size arguments

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:a59aa3026821ac4883198f1858984b6f78612ae6

commit r10-6547-ga59aa3026821ac4883198f1858984b6f78612ae6
Author: Jakub Jelinek 
Date:   Mon Feb 10 15:50:17 2020 +0100

c-format: -Wformat-diag fix [PR93641]

The last argument to strncasecmp is incorrect, so it matched even when
can%' wasn't followed by t.  Also, the !ISALPHA (format_chars[1]) test
looks pointless, format_chars[1] must be ' if strncasecmp succeeded and
so will never be ISALPHA.

2020-02-10  Jakub Jelinek  

PR other/93641
* c-format.c (check_plain): Fix up last argument of strncasecmp.
Remove useless extra test.

* gcc.dg/format/gcc_diag-11.c (test_cdiag_bad_words): Add two further
tests.

[Bug c++/93639] [c++2a] Segfault on non type template parameter and consteval (master)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-10
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
Confirmed.

G++ 7 ICEs too with -std=c++17, so not caused by consteval.

[Bug target/91913] [8/9/10 Regression] ICE in extract_constrain_insn, at recog.c:2211

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw  ---
Main bug fixed with https://gcc.gnu.org/ml/gcc-cvs/2020-02/msg02312.html
Awaiting commit of testcase.

[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function

[seurer at gcc dot gnu.org]

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

--- Comment #8 from seurer at gcc dot gnu.org ---
While trying to figure out what was going on I tried the original test on
several different machines including multiple power 8s and power 9s and it
eventually would fail on any of them.  Sometimes it took 10s of thousands of
tries, though.

[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:bf6465d0461234ccd45ae34d5e2375a0bee0081d

commit r10-6550-gbf6465d0461234ccd45ae34d5e2375a0bee0081d
Author: H.J. Lu 
Date:   Mon Feb 10 07:58:45 2020 -0800

i386: Properly pop restore token in signal frame

Linux CET kernel places a restore token on shadow stack for signal
handler to enhance security.  The restore token is 8 byte and aligned
to 8 bytes.  It is usually transparent to user programs since kernel
will pop the restore token when signal handler returns.  But when an
exception is thrown from a signal handler, now we need to pop the
restore token from shadow stack.  For x86-64, we just need to treat
the signal frame as normal frame.  For i386, we need to search for
the restore token to check if the original shadow stack is 8 byte
aligned.  If the original shadow stack is 8 byte aligned, we just
need to pop 2 slots, one restore token, from shadow stack.  Otherwise,
we need to pop 3 slots, one restore token + 4 byte padding, from
shadow stack.

This patch also includes 2 tests, one has a restore token with 4 byte
padding and one without.

Tested on Linux/x86-64 CET machine with and without -m32.

libgcc/

PR libgcc/85334
* config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment):
New.

gcc/testsuite/

PR libgcc/85334
* g++.target/i386/pr85334-1.C: New test.
* g++.target/i386/pr85334-2.C: Likewise.

[Bug target/91913] [8/9/10 Regression] ICE in extract_constrain_insn, at recog.c:2211

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:86edfcfeccf16a30e541883532d9bdbece5d9f60

commit r10-6551-g86edfcfeccf16a30e541883532d9bdbece5d9f60
Author: Jakub Jelinek 
Date:   Mon Feb 10 17:05:58 2020 +0100

arm: Add testcase for already fixed ICE [PR91913]

2020-02-10  Jakub Jelinek  

PR target/91913
* gfortran.dg/pr91913.f90: New test.

[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:3fde3398341ba900ed2e1eaecf00799fda66686a

commit r9-8208-g3fde3398341ba900ed2e1eaecf00799fda66686a
Author: H.J. Lu 
Date:   Mon Feb 10 07:58:45 2020 -0800

i386: Properly pop restore token in signal frame

Linux CET kernel places a restore token on shadow stack for signal
handler to enhance security.  The restore token is 8 byte and aligned
to 8 bytes.  It is usually transparent to user programs since kernel
will pop the restore token when signal handler returns.  But when an
exception is thrown from a signal handler, now we need to pop the
restore token from shadow stack.  For x86-64, we just need to treat
the signal frame as normal frame.  For i386, we need to search for
the restore token to check if the original shadow stack is 8 byte
aligned.  If the original shadow stack is 8 byte aligned, we just
need to pop 2 slots, one restore token, from shadow stack.  Otherwise,
we need to pop 3 slots, one restore token + 4 byte padding, from
shadow stack.

This patch also includes 2 tests, one has a restore token with 4 byte
padding and one without.

Tested on Linux/x86-64 CET machine with and without -m32.

libgcc/

Backport from mainline
PR libgcc/85334
* config/i386/shadow-stack-unwind.h (_Unwind_Frames_Increment):
New.

gcc/testsuite/

Backport from mainline
PR libgcc/85334
* g++.target/i386/pr85334-1.C: New test.
* g++.target/i386/pr85334-2.C: Likewise.

(cherry picked from commit bf6465d0461234ccd45ae34d5e2375a0bee0081d)

[Bug target/91489] misplaced stack pointer when __ms_hook_prologue__ attribute is used

[gofmanp at gmail dot com]

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

--- Comment #4 from Paul Gofman  ---
I suppose I figured a better way to fix this and sent the patch to the mailing
list: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00554.html

[Bug target/93372] cris performance regressions due to de-cc0 work

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Hans-Peter Nilsson :

https://gcc.gnu.org/g:7573521f46427d36a203f72794af7188ce04de88

commit r10-6557-g7573521f46427d36a203f72794af7188ce04de88
Author: Hans-Peter Nilsson 
Date:   Mon Feb 10 17:39:00 2020 +0100

gcc.target/cris/pr93372-3.c, -4.c...-35.c: New tests.

PR target/93372
* gcc.target/cris/pr93372-3.c, gcc.target/cris/pr93372-4.c,
gcc.target/cris/pr93372-6.c, gcc.target/cris/pr93372-7.c,
gcc.target/cris/pr93372-9.c, gcc.target/cris/pr93372-10.c,
gcc.target/cris/pr93372-11.c, gcc.target/cris/pr93372-12.c,
gcc.target/cris/pr93372-13.c, gcc.target/cris/pr93372-14.c,
gcc.target/cris/pr93372-15.c, gcc.target/cris/pr93372-16.c,
gcc.target/cris/pr93372-17.c, gcc.target/cris/pr93372-18.c,
gcc.target/cris/pr93372-19.c, gcc.target/cris/pr93372-20.c,
gcc.target/cris/pr93372-21.c, gcc.target/cris/pr93372-22.c,
gcc.target/cris/pr93372-23.c, gcc.target/cris/pr93372-24.c,
gcc.target/cris/pr93372-25.c, gcc.target/cris/pr93372-26.c,
gcc.target/cris/pr93372-27.c, gcc.target/cris/pr93372-28.c,
gcc.target/cris/pr93372-29.c, gcc.target/cris/pr93372-30.c,
gcc.target/cris/pr93372-31.c, gcc.target/cris/pr93372-32.c,
gcc.target/cris/pr93372-33.c, gcc.target/cris/pr93372-34.c,
gcc.target/cris/pr93372-35.c: New tests.

Check that somewhat-trivially eliminable compare-instructions
are eliminated, for all instructions.  Note that pr93372-23.c
and pr93372-24.c are xfailed with cc0.

[Bug c/93653] New: diagnose calls to strncmp with bound less than constant string length

[msebor at gcc dot gnu.org]

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

Bug ID: 93653
   Summary: diagnose calls to strncmp with bound less than
constant string length
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

-Wstring-compare diagnoses equality expressions involving calls to strcmp and
strncmp that evaluate to constant s based on the size of one argument and the
length of another.  Such calls are likely mistakes (it makes little sense to
compare a longer string for equality to a smaller array).

Another class of mistakes -Wstring-compare could help detect is those pointed
out in pr93640 and pr93641: calls with constant bounds that are less than the
length of the constant string argument.  These should probably be detected and
diagnosed early, before non-constant expressions have been folded into
constants.  Another question is whether the string arguments should be limited
to literals or whether all constant strings should be considered.

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic x.c
char a[2];

int f (void)
{
  return __builtin_strncmp (a, "123", 3) == 0;   // warning
}

int g (const char *s)
{
  return __builtin_strncmp (s, "123", 2) == 0;   // should warn
}
x.c: In function ‘f’:
x.c:5:10: warning: ‘__builtin_strncmp’ of a string of length 3, an array of
size 2 and bound of 3 evaluates to nonzero [-Wstring-compare]
5 |   return __builtin_strncmp (a, "123", 3) == 0;   // warning
  |  ^~~

[Bug target/93654] New: Inappropriate "- -fcf-protection and -mindirect-branch=thunk are incompatible on x86_64" restriction

[andrew.cooper3 at citrix dot com]

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

Bug ID: 93654
   Summary: Inappropriate "- -fcf-protection and
-mindirect-branch=thunk are incompatible on x86_64"
restriction
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.cooper3 at citrix dot com
  Target Milestone: ---

Bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87412 prohibited the use of
-fcf-protection and -mindirect-branch=thunk in combination.

However, it also breaks kernels which use -mindirect-branch=thunk-extern

When retpoline protections were developed, I specifically requested
thunk-extern to exist for kernels which provide their own, so that it can be
made compatible with CET.

A kernel which provides its own thunks will boot-time modify them to be
appropriate for the system, and may not be a retpoline gadget.  (They may be
lfence; jmp *%reg which is recommended on AMD, or just jmp *%reg with IBRS)

-mindirect-branch=thunk-extern specifically should be permitted with
-fcf-protection, because this *was* the plan to make a single binary capable of
using CET on applicable hardware, yet being safe to Spectre v2 on older
hardware.

[Bug ipa/93203] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5448 since r278893

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #3 from David Binderman  ---
I tried the source code file pr93203.C on ARM raspberry pi hardware
with compiler flag -O3 and it crashed a little later at line 5467.

Maybe the patch isn't quite right at optimisation level -O3 ?

[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #8 from David Binderman  ---
I tried the pr93549.C source code file on ARM based raspberry pi hardware
and the compiler crashed. No optimisation flags required.

[Bug c/93640] The write_only and read_write attributes can be mistyped due to invalid strncmp size argument

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:0cc575e4d8b68b743e07da02a74733f9b5cb585a

commit r10-6559-g0cc575e4d8b68b743e07da02a74733f9b5cb585a
Author: Martin Sebor 
Date:   Mon Feb 10 10:27:00 2020 -0700

PR c/93640 - The write_only and read_write attributes can be mistyped due
to invalid strncmp size argument

gcc/c-family/ChangeLog:

PR c/93640
* c-attribs.c (handle_access_attribute): Correct off-by-one mistakes.

gcc/testsuite/ChangeLog:

PR c/93640
* gcc.dg/attr-access.c: New test.

[Bug c/93640] The write_only and read_write attributes can be mistyped due to invalid strncmp size argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed.

[Bug c/93653] diagnose calls to strncmp with bound less than constant string length

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |enhancement

[Bug middle-end/93655] New: diagnose calls to strncmp with bound greater than constant string length

[msebor at gcc dot gnu.org]

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

Bug ID: 93655
   Summary: diagnose calls to strncmp with bound greater than
constant string length
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In addition to pr93653, the -Wstring-compare warning (new in GCC 10) could also
diagnose strncmp calls where the bound is so large that it could cause the
function to read past the end of one of the string, as is possible in all three
instances below.  The warning should be issued regardless of how the result of
the call is used (i.e., for equality or otherwise).

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic x.c
char a2[2], a3[3];

int f (void)
{
  return __builtin_strncmp (a3, "12", 5);   // missing warning
}

int g (void)
{
  return __builtin_strncmp (a3, a2, 7); // missing warning
}

int h (const char *s)
{
  return __builtin_strncmp (a3, s, 7); // missing warning
}

[Bug c/93653] diagnose calls to strncmp with bound less than constant string length

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think we should warn about this if the second argument is a string literal,
not when optimizers propagate a pointer to a string literal to it, so do it in
the FEs, make sure it handles strncmp inline -D_FORTIFY_SOURCE=2 wrapper and
also handle strncasecmp as well.

[Bug target/81652] [meta-bug] -fcf-protection=full bugs

[hjl.tools at gmail dot com]

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

Bug 85334 Summary: Shadow stack isn't unwound properly through signal handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug libgcc/85334] Shadow stack isn't unwound properly through signal handler

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from H.J. Lu  ---
Fixed for GCC 10, GCC 9.3 and GCC 8.4.

[Bug target/93656] New: FAIL: gcc.target/i386/pr67770.c execution test with -fcf-protection

[hjl.tools at gmail dot com]

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

Bug ID: 93656
   Summary: FAIL: gcc.target/i386/pr67770.c execution test with
-fcf-protection
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
Blocks: 81652
  Target Milestone: ---
Target: i386

On Linux/x86-64,

$ make check-gcc RUNTESTFLAGS="--target_board='unix{-m32\ -fcf-protection}'
i386.exp=pr67770.c"
...
FAIL: gcc.target/i386/pr67770.c execution test
...


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
[Bug 81652] [meta-bug] -fcf-protection=full bugs

[Bug fortran/83113] Bogus "duplicate allocatable attribute" error for submodule character function

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Andrew Benson :

https://gcc.gnu.org/g:7848054c68bad6e2aa40cb59f77cc99bd8448d52

commit r10-6560-g7848054c68bad6e2aa40cb59f77cc99bd8448d52
Author: Andrew Benson 
Date:   Mon Feb 10 17:59:34 2020 +

Fix bogus duplicate attribute errors for submodule functions.

PR fortran/83113
* array.c: Do not attempt to set the array spec for a submodule
function symbol (as it has already been set in the corresponding
module procedure interface).
* symbol.c: Do not reject duplicate POINTER, ALLOCATABLE, or
DIMENSION attributes in declarations of a submodule function.
* gfortran.h: Add a macro that tests for a module procedure in a
submodule.
* gfortran.dg/pr83113.f90: New test.

[Bug fortran/89943] Submodule functions are not allowed to have C binding

[abensonca at gcc dot gnu.org]

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

Bug 83113 Summary: Bogus "duplicate allocatable attribute" error for submodule 
character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113

   What|Removed |Added

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

[Bug fortran/83113] Bogus "duplicate allocatable attribute" error for submodule character function

[abensonca at gcc dot gnu.org]

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

Andrew Benson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||abensonca at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #11 from Andrew Benson  ---
Fixed by https://gcc.gnu.org/g:7848054c68bad6e2aa40cb59f77cc99bd8448d52

[Bug other/93641] Wrong strncmp and strncasecmp size arguments

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:c88ffcc6f4f46223c219014729f33f6cb9649928

commit r10-6561-gc88ffcc6f4f46223c219014729f33f6cb9649928
Author: Iain Sandoe 
Date:   Mon Feb 10 20:29:30 2020 +0100

Darwin: -Wformat-diag fix (PR93641)

The length used for the comparison for 'CFStringRef' was only comparing
for 'CFString', potentially allowing mismatched identifiers.

2020-02-10  Iain Sandoe  

PR other/93641
* config/darwin-c.c (darwin_cfstring_ref_p): Fix up last
argument of strncmp.

[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  ---
On Sun, Feb 09, 2020 at 06:39:31PM +, kargl at gcc dot gnu.org wrote:
>
> Fortuantely, I 
> use neither namelist nor equivalence, so have no skin in the 
> game.  Someone else can complete the fix.
> 

Here's a patch that fixes the issue and cures the ICE in the
old testcase.  Whoever commit patch needs to convert the 
example code here into a testcase.


Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 280157)
+++ gcc/fortran/symbol.c(working copy)
@@ -394,18 +395,35 @@ gfc_check_function_type (gfc_namespace *ns)

 / Symbol attribute stuff */

+/* Older standard produced conflicts for some attributes that are now
+   allowed in newer standards.  Check for the conflict and issue an
+   error depending on the standard in play.  */
+
+static bool
+conflict_std (int standard, const char *a1, const char *a2, const char *name,
+ locus *where)
+{
+  if (name == NULL)
+{
+  return gfc_notify_std (standard, "%s attribute conflicts "
+ "with %s attribute at %L", a1, a2,
+ where);
+}
+  else
+{
+  return gfc_notify_std (standard, "%s attribute conflicts "
+"with %s attribute in %qs at %L",
+ a1, a2, name, where);
+}
+}
+
+
+
 /* This is a generic conflict-checker.  We do this to avoid having a
single conflict in two places.  */

 #define conf(a, b) if (attr->a && attr->b) { a1 = a; a2 = b; goto conflict; }
 #define conf2(a) if (attr->a) { a2 = a; goto conflict; }
-#define conf_std(a, b, std) if (attr->a && attr->b)\
-  {\
-a1 = a;\
-a2 = b;\
-standard = std;\
-goto conflict_std;\
-  }

 bool
 gfc_check_conflict (symbol_attribute *attr, const char *name, locus *where)
@@ -438,7 +456,7 @@ gfc_check_conflict (symbol_attribute *attr, const char
"OACC DECLARE DEVICE_RESIDENT";

   const char *a1, *a2;
-  int standard;
+  bool standard;

   if (attr->artificial)
 return true;
@@ -450,16 +468,18 @@ gfc_check_conflict (symbol_attribute *attr, const char
 {
   a1 = pointer;
   a2 = intent;
-  standard = GFC_STD_F2003;
-  goto conflict_std;
+  standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+  if (!standard)
+ return standard;
 }

   if (attr->in_namelist && (attr->allocatable || attr->pointer))
 {
   a1 = in_namelist;
   a2 = attr->allocatable ? allocatable : pointer;
-  standard = GFC_STD_F2003;
-  goto conflict_std;
+  standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+  if (!standard)
+ return standard;
 }

   /* Check for attributes not allowed in a BLOCK DATA.  */
@@ -566,9 +586,31 @@ gfc_check_conflict (symbol_attribute *attr, const char
 return false;

   conf (allocatable, pointer);
-  conf_std (allocatable, dummy, GFC_STD_F2003);
-  conf_std (allocatable, function, GFC_STD_F2003);
-  conf_std (allocatable, result, GFC_STD_F2003);
+  if (attr->allocatable && attr->dummy)
+{
+  a1 = allocatable;
+  a2 = dummy;
+  standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+  if (!standard)
+ return standard;
+}
+  if (attr->allocatable && attr->function)
+{
+  a1 = allocatable;
+  a2 = function;
+  standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+  if (!standard)
+ return standard;
+}
+  if (attr->allocatable && attr->result)
+{
+  a1 = allocatable;
+  a2 = result;
+  standard = conflict_std (GFC_STD_F2003, a1, a2, name, where);
+  if (!standard)
+ return standard;
+}
+
   conf (elemental, recursive);

   conf (in_common, dummy);
@@ -908,25 +950,10 @@ conflict:
   a1, a2, name, where);

   return false;
-
-conflict_std:
-  if (name == NULL)
-{
-  return gfc_notify_std (standard, "%s attribute conflicts "
- "with %s attribute at %L", a1, a2,
- where);
-}
-  else
-{
-  return gfc_notify_std (standard, "%s attribute conflicts "
-"with %s attribute in %qs at %L",
- a1, a2, name, where);
-}
 }

 #undef conf
 #undef conf2
-#undef conf_std


 /* Mark a symbol as referenced.  */
@@ -4039,6 +4066,31 @@ gfc_free_namespace (gfc_namespace *ns)
   ns->refs--;
   if (ns->refs > 0)
 return;
+
+  /* If an error occurred while parsing a submodule, the namespace is freed.
+ However, gfortran reaches a ref count of -1.  Note, gfc_state_stack does
+ not ind

[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman  ---
False alarm. Sorry. Bad raspberry pi config.

[Bug ipa/93203] [10 Regression] ICE in decide_about_value, at ipa-cp.c:5448 since r278893

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman  ---
Another false result produced by my bad gcc config.
Please ignore my previous comment.

[Bug analyzer/93657] New: Ambiguous wording "is doing to"

[roland.illig at gmx dot de]

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

Bug ID: 93657
   Summary: Ambiguous wording "is doing to"
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From analyzer.opt:
> Dump internal details about what the analyzer is doing to 
> SRCFILE.analyzer.txt.

What is the analyzer doing to the SRCFILE? No harm, I hope.

(I don't know whether the string becomes less ambiguous in its natural context;
when I tried to translate it to German, I picked the wrong AST.)

[Bug analyzer/93657] Ambiguous wording "is doing to"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #1 from Andrew Pinski  ---
Maybe:
Dump to SRCFILE.analyzer.txt, internal details about what the analyzer is
doing.

By the way I don't think it is that ambiguous; just english is full of
ambiguities in general.

[Bug rtl-optimization/93658] New: [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu

[doko at ubuntu dot com]

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

Bug ID: 93658
   Summary: [9/10 Regression] infinite loop building ghostscript
and icu with -O3 on powerpc64le-linux-gnu
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at ubuntu dot com
  Target Milestone: ---

Created attachment 47813
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47813&action=edit
preprocessed source

seen with gcc-9 and trunk 20200204, building ghostscript and icu with -O3 on
powerpc64le-linux-gnu.  Falling back to -O2 lets the build succeed, a -O3 build
on x86_64-linux-gnu succeeds.

Program received signal SIGTSTP, Stopped (user).
push_to_sequence (first=0x7320d580) at ../../src/gcc/emit-rtl.c:5574
5574../../src/gcc/emit-rtl.c: No such file or directory.
(gdb) bt
#0  push_to_sequence (first=0x7320d580) at ../../src/gcc/emit-rtl.c:5574
#1  0x10843000 in process_address_1 (nop=nop@entry=0, 
check_only_p=check_only_p@entry=false, before=before@entry=0x7fffdbf0, 
after=after@entry=0x7fffdbe8) at ../../src/gcc/lra-constraints.c:3434
#2  0x1084527c in process_address (after=,
before=, 
check_only_p=, nop=) at
../../src/gcc/lra-constraints.c:3637
#3  curr_insn_transform (check_only_p=check_only_p@entry=false)
at ../../src/gcc/lra-constraints.c:3952
#4  0x1084ad10 in lra_constraints (first_p=)
at ../../src/gcc/lra-constraints.c:5025
#5  0x10833940 in lra (f=) at ../../src/gcc/lra.c:2437
#6  0x107d893c in do_reload () at ../../src/gcc/ira.c:5518
#7  (anonymous namespace)::pass_reload::execute (this=) at
../../src/gcc/ira.c:5704
#8  0x10928280 in execute_one_pass (pass=pass@entry=0x11d106f0)
at ../../src/gcc/passes.c:2500
#9  0x10929314 in execute_pass_list_1 (pass=0x11d106f0) at
../../src/gcc/passes.c:2588
#10 0x1092932c in execute_pass_list_1 (pass=0x11d0f4f0) at
../../src/gcc/passes.c:2589
#11 0x109293b8 in execute_pass_list (fn=,
pass=)
at ../../src/gcc/passes.c:2599
#12 0x104f4a2c in cgraph_node::expand (this=0x76ee7d28) at
../../src/gcc/context.h:48
#13 0x104f600c in expand_all_functions () at
../../src/gcc/cgraphunit.c:2454
#14 symbol_table::compile (this=this@entry=0x752f) at
../../src/gcc/cgraphunit.c:2804
#15 0x104f8c54 in symbol_table::compile (this=0x752f)
at ../../src/gcc/cgraphunit.c:2984
#16 symbol_table::finalize_compilation_unit (this=0x752f)
at ../../src/gcc/cgraphunit.c:2984
#17 0x10a321bc in compile_file () at ../../src/gcc/toplev.c:483
#18 0x10187c8c in do_compile () at ../../src/gcc/toplev.c:2273
#19 toplev::main (this=0x7fffe6a0, argc=, argv=)
at ../../src/gcc/toplev.c:2412
#20 0x10189e78 in main (argc=, argv=0x7fffeac8)
at ../../src/gcc/main.c:39

GCC defaults to hardening options and is configured using
--enable-languages=c,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=powerpc64le-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin
--enable-default-pie --with-system-zlib --disable-libphobos
--enable-objc-gc=auto --enable-secureplt --with-cpu=power8
--enable-targets=powerpcle-linux --disable-multilib --enable-multiarch
--disable-werror --with-long-double-128 --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-checking=release --build=powerpc64le-linux-gnu
--host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu

[Bug rtl-optimization/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu

[doko at ubuntu dot com]

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

Matthias Klose  changed:

   What|Removed |Added

   Keywords||ra
 Target||powerpc64le-linux-gnu
  Known to work||9.2.0
  Known to fail||10.0, 9.2.1

--- Comment #1 from Matthias Klose  ---
memory usage stays constant at about 2GB, the package build gets cancelled
after 150 minutes.

[Bug analyzer/93659] New: typo in analyzer.opt: call tha would

[roland.illig at gmx dot de]

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

Bug ID: 93659
   Summary: typo in analyzer.opt: call tha would
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from analyzer.opt:
- call tha would
+ call that would

[Bug fortran/93660] New: ICE in ipa_simd_modify_function_body, at omp-simd-clone.c:993

[gs...@t-online.de]

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

Bug ID: 93660
   Summary: ICE in ipa_simd_modify_function_body, at
omp-simd-clone.c:993
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r7 :


$ cat z1.f90
integer function f(x)
   integer :: x[*]
   !$omp declare simd
   f = x[1]
end


$ gfortran-10-20200209 -c z1.f90 -fopenmp -fcoarray=single
$
$ gfortran-10-20200209 -c z1.f90 -fopenmp -fcoarray=lib
during IPA pass: simdclone
z1.f90:5:0:

5 | end
  |
internal compiler error: in ipa_simd_modify_function_body, at
omp-simd-clone.c:993
0x179e6cc ipa_simd_modify_function_body
../../gcc/omp-simd-clone.c:993
0x179f330 simd_clone_adjust
../../gcc/omp-simd-clone.c:1188
0x17a3faf expand_simd_clones(cgraph_node*)
../../gcc/omp-simd-clone.c:1751
0x17a4af7 ipa_omp_simd_clone
../../gcc/omp-simd-clone.c:1772
0x17a4af7 execute
../../gcc/omp-simd-clone.c:1800

[Bug analyzer/93659] typo in analyzer.opt: call tha would

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
And another typo, from the same file:
- Warn about code paths in which an initialized value is used.
+ Warn about code paths in which an uninitialized value is used.

[Bug c/93661] New: [10 Regression] ICE in tree_to_poly_int64, at tree.c:2976

[gs...@t-online.de]

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

Bug ID: 93661
   Summary: [10 Regression] ICE in tree_to_poly_int64, at
tree.c:2976
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190630 and 20190728 :


$ cat z1.c
int f ()
{
  unsigned x = 0x;
  __builtin_memset (1+(char *) &x, 0, -1);
  return (x != 0xf000);
}


$ gcc-10-20200209 -c z1.c -O2
during GIMPLE pass: fre
z1.c: In function 'f':
z1.c:6:1: internal compiler error: in tree_to_poly_int64, at tree.c:2976
6 | }
  | ^
0xfd0a42 tree_to_poly_int64(tree_node const*)
../../gcc/tree.c:2976
0xecb460 vn_reference_lookup_3
../../gcc/tree-ssa-sccvn.c:2507
0xdf6910 walk_non_aliased_vuses(ao_ref*, tree_node*, bool, void* (*)(ao_ref*,
tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
tree_node* (*)(tree_node*), unsigned int&, void*)
../../gcc/tree-ssa-alias.c:3568
0xec235e vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**)
../../gcc/tree-ssa-sccvn.c:3225
0xecd452 visit_reference_op_load
../../gcc/tree-ssa-sccvn.c:4547
0xecd452 visit_stmt
../../gcc/tree-ssa-sccvn.c:4964
0xecea9b process_bb
../../gcc/tree-ssa-sccvn.c:6633
0xed0c80 do_rpo_vn
../../gcc/tree-ssa-sccvn.c:7152
0xed168f execute
../../gcc/tree-ssa-sccvn.c:7420

[Bug fortran/93662] New: [10 Regression] ICE in tree_to_poly_int64, at tree.c:2976

[gs...@t-online.de]

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

Bug ID: 93662
   Summary: [10 Regression] ICE in tree_to_poly_int64, at
tree.c:2976
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20191103 (error) and 20191110 (ICE) at -O1+ :
(for some reason much later than pr93661 ...)


$ cat z1.f90
subroutine s
   type t
  integer, allocatable :: a
  character(huge(1_8)) :: c
   end type
   class(t), allocatable :: x
   allocate(t :: x)
end


$ cat z2.f90
subroutine s
   type t
  integer, allocatable :: a
  character(2_8**60) :: c
   end type
   class(t), allocatable :: x
   allocate(t :: x)
end


$ gfortran-10-20200209 -c z1.f90 -O2
z1.f90:1:12:

1 | subroutine s
  |1
Warning: size of '__def_init_s_T' 9223372036854775816 bytes exceeds maximum
object size 9223372036854775807 [-Wlarger-than=]
z1.f90:7:0:

7 |allocate(t :: x)
  |
Warning: size of 't.6' 9223372036854775816 bytes exceeds maximum object size
9223372036854775807 [-Wlarger-than=]
f951: Warning: size of '' 9223372036854775816 bytes exceeds maximum
object size 9223372036854775807 [-Wlarger-than=]
f951: Warning: size of '' 9223372036854775816 bytes exceeds maximum
object size 9223372036854775807 [-Wlarger-than=]
during GIMPLE pass: esra
z1.f90:8:0:

8 | end
  |
internal compiler error: in tree_to_poly_int64, at tree.c:2976
0x10403e2 tree_to_poly_int64(tree_node const*)
../../gcc/tree.c:2976
0xe45ed1 get_access_for_expr
../../gcc/tree-sra.c:3608
0xe4a7cb sra_modify_assign
../../gcc/tree-sra.c:4002
0xe4a7cb sra_modify_function_body
../../gcc/tree-sra.c:4325
0xe4a7cb perform_intra_sra
../../gcc/tree-sra.c:4435

[Bug c/93663] New: [10 Regression] ICE in is_halfway_below, at real.c:5192

[gs...@t-online.de]

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

Bug ID: 93663
   Summary: [10 Regression] ICE in is_halfway_below, at
real.c:5192
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190825 and 20190901 :


$ cat z1.c
void f() {roundeven(0x0.1p1128);}


$ gcc-10-20200209 -c z1.c -O2
z1.c: In function 'f':
z1.c:1:11: warning: implicit declaration of function 'roundeven'
[-Wimplicit-function-declaration]
1 | void f() {roundeven(0x0.1p1128);}
  |   ^
z1.c:1:11: warning: incompatible implicit declaration of built-in function
'roundeven'
z1.c:1:1: warning: floating constant exceeds range of 'double' [-Woverflow]
1 | void f() {roundeven(0x0.1p1128);}
  | ^~~~
z1.c:1:1: internal compiler error: in is_halfway_below, at real.c:5192
0xc23e0b is_halfway_below(real_value const*)
../../gcc/real.c:5192
0xc23e24 real_roundeven(real_value*, format_helper, real_value const*)
../../gcc/real.c:5226
0x95c8fd fold_const_call_ss
../../gcc/fold-const-call.c:877
0x95ea12 fold_const_call_1
../../gcc/fold-const-call.c:1213
0x78c957 fold_builtin_1
../../gcc/builtins.c:10043
0x78c957 fold_builtin_n
../../gcc/builtins.c:10332
0x959a31 fold(tree_node*)
../../gcc/fold-const.c:12690
0x6d9a5c c_fully_fold_internal
../../gcc/c/c-fold.c:626
0x6dd417 c_fully_fold(tree_node*, bool, bool*, bool)
../../gcc/c/c-fold.c:125
0x670201 c_process_expr_stmt(unsigned int, tree_node*)
../../gcc/c/c-typeck.c:11095
0x6705ed c_finish_expr_stmt(unsigned int, tree_node*)
../../gcc/c/c-typeck.c:11140
0x6ca18a c_parser_statement_after_labels
../../gcc/c/c-parser.c:6294
0x6cc340 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5800
0x6ccaf6 c_parser_compound_statement
../../gcc/c/c-parser.c:5616
0x6ce431 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2504
0x6d8237 c_parser_external_declaration
../../gcc/c/c-parser.c:1746
0x6d8d59 c_parser_translation_unit
../../gcc/c/c-parser.c:1619
0x6d8d59 c_parse_file()
../../gcc/c/c-parser.c:21710
0x73df70 c_common_parse_file()
../../gcc/c-family/c-opts.c:1186

[Bug tree-optimization/93661] [10 Regression] ICE in tree_to_poly_int64, at tree.c:2976

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Target Milestone|--- |10.0

--- Comment #1 from Andrew Pinski  ---
Note that memset is undefined.  -1 is all of the size.

[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]

[pinskia at gcc dot gnu.org]

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

--- Comment #19 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #18)
> > For bitfields there's also the ever present bitfield-lowering idea...
> 
> I understood Andrew P. is working on something, but no idea how far it is.

I am working towards regression free.  I have most of it completed, the store
merging regression is the main thing which is blocking it.

> 
> > And the fact that optimize_bit_field_compare is done way too early.
> 
> Agreed on that.

Agreed there too.

[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Iñaki Ucar from comment #3)
> I got no backtrace, just the output shown in my first comment, at least with
> the gcc version included in Fedora Rawhide. I've just attached the test.ii
> file too. With -v:


Yes that is because the GCC is configured with "--enable-checking=release".

[Bug analyzer/93657] Ambiguous wording "is doing to"

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
common.opt's has:

fdump-
Common Joined RejectNegative Var(common_deferred_options) Defer
-fdump-   Dump various compiler internals to a file.


so how about:

fdump-analyzer
Common RejectNegative Var(flag_dump_analyzer)
Dump various analyzer internals to SRCFILE.analyzer.txt.

fdump-analyzer-stderr
Common RejectNegative Var(flag_dump_analyzer_stderr)
Dump various analyzer internals to stderr.

Request For Partnership

[CLI INVESTMENT GROUP]

Hello,

CLI Investment Group here in New York, an affiliate of CLI Ventures. We are a 
Financial Investment Company looking for Company(s) with profitable projects or 
entrepreneurial teams that require partnership. We are focusing on supporting 
early to late stage Companies. If interested, please contact us for details and 
procedures.

Regards,
Samuel Price.
Loan Administration
CLI Investment Group
14 Wall St, New York,
NY 10005 U.S.A
Email: samuel.pr...@cliinvestmentgroups.com

Samuel Price

14 Wall St , New York , NY 10005

Unsubscribe (  
https://u14851712.ct.sendgrid.net/wf/unsubscribe?upn=PQSYFRt-2Bwqd75usGEgqqWVXdK29tZgmSzJh7GonUuAVbCv-2FKKZ8RusZa4MzJD0lqJM6VNAkZo63mi4GOw3dkC0uyDOiFbNk6oS2xXA0CpZoUaFj9I0xYYRGzTTdgODlWomga8ywHWVbZf1qHAE9VGLjeCnSzVeDiU-2FW4632cYt2P7cEFFfHUhV-2Fqgy33Wq7KfoEhFNtRy-2F-2FHvfQNBxHmOkR9Z7Sl1k2Q3g7WOsgViZGvfA9dPZwLR7-2Fm4BSbB-2FV1xYqWl0YgCDWW24t7Ouv5u7DewHMNe1HOV9UxX7yh3ZFpUZxsqIRSg15EjJws3sciOuBJUkU-2Bvi9jxVCN1nExpeEZvP5HhkB9bnDMwJ88bk9gJV-2Frj0s3Ke0kIjPgiS7hEptsWOK1y4NxKxvQmnussiDKpxxbdgiqmKLiEnz7hPKejj3wOscxS7PsZa9KqP8tIkZtoql-2BW0Dg2ZGK1i0xf-2FCebNw3biA3ERqG857BeeENPLZJRLn0vLrO-2BGTjcbWGSzZRSFklUfLQM-2BifJaYXq83REbKCmk138sQStvr2FYzKuCA42dyZ53cnZaZUgEhzATjiAlZJJVN5ZSkYhGS-2FhvfespaSmbTZxizRGuIjlsEePqv3BpMuliDcLiCXEq7eewHSC4wbJHEu2s5AM-2Bt0Ng-3D-3D
  )

[Bug analyzer/93659] typo in analyzer.opt: call tha would

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-10
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Thanks.  I'm working on a patch.