[Bug middle-end/97898] ICE in outermost_invariant_loop, at tree-ssa-loop-im.c:431

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |middle-end
 CC||jakub at gcc dot gnu.org
   Keywords||openmp

--- Comment #1 from Richard Biener  ---
note you can use -fchecking even with not checking enabled builds to get IL
verification.

So this is a OMP expansion issue.

[Bug tree-optimization/97897] ICE tree check: expected ssa_name, have integer_cst in compute_optimized_partition_bases, at tree-ssa-coalesce.c:1638

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Component|c   |tree-optimization
   Last reconfirmed||2020-11-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
Mine.  We may not have constants in abnormal edge PHI arguments.

[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/97895] [11 Regression] ICE in do_auto_deduction, at cp/pt.c:29255

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #7)
> Actually still ICEs.

Yes, it was just a fix for the ISEL logic which was broken, not yet a fix for
the actual testcase.

[Bug tree-optimization/97901] New: ICE at -Os: verify_gimple failed

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 97901
   Summary: ICE at -Os: verify_gimple failed
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[539] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201119 (experimental) [master revision
25bb75f841c:9f334878639:700337494e1b0d5ff608e1a3c77852381e264653] (GCC)
[540] %
[540] % gcctk -Os small.c
small.c: In function ‘main’:
small.c:3:5: error: invalid address operand in ‘mem_ref’
3 | int main() {
  | ^~~~
a[0];

# VUSE <.MEM_22>
_5 = a[0];
during GIMPLE pass: loopdone
small.c:3:5: internal compiler error: verify_gimple failed
0xd62975 verify_gimple_in_cfg(function*, bool)
../../gcc-trunk/gcc/tree-cfg.c:5461
0xc118ee execute_function_todo
../../gcc-trunk/gcc/passes.c:2039
0xc127d2 execute_todo
../../gcc-trunk/gcc/passes.c:2093
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
[541] %
[541] % cat small.c
int a[1], b, *c, *d;

int main() {
L:
  d = c;
  for (b = 0; b < 2; b++)
d = &a[0];
  if (c)
goto L;
  if (*d)
__builtin_abort ();
  return 0;
}

[Bug target/93176] PPC: inefficient 64-bit constant consecutive ones

[amodra at gmail dot com via Gcc-bugs]

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

Alan Modra  changed:

   What|Removed |Added

URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
   |il/gcc-patches/2020-Septemb |il/gcc-patches/2020-October
   |er/553661.html  |/555760.html

--- Comment #6 from Alan Modra  ---
No, the patch hasn't yet been reviewed.

[Bug target/97891] [x86] Consider using registers on large initializations

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
This problem is very similar to the one pass_rpad deals with.

[Bug c++/97900] [9/10/11 Regression] g++ crashes when instantiating a templated function with a template-type vector parameter

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-11-19
 Ever confirmed|0   |1

[Bug c++/97900] [9/10/11 Regression] g++ crashes when instantiating a templated function with a template-type vector parameter

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
Summary|g++ crashes when|[9/10/11 Regression] g++
   |instantiating a templated   |crashes when instantiating
   |function with a |a templated function with a
   |template-type vector|template-type vector
   |parameter   |parameter
   Keywords||ice-on-valid-code
   Target Milestone|--- |9.4

[Bug c++/97900] g++ crashes when instantiating a templated function with a template-type vector parameter

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Marek Polacek  ---
Confirmed.  Started with r266055.

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Marek Polacek  ---
Reduced even more:

// PR c++/97899

template 
int fn()
{
  return 1;
}

template 
void bar() {
  const int i = int{fn()};
}

[Bug tree-optimization/91029] missed optimization regarding value of modulo operation

[bruno at clisp dot org via Gcc-bugs]

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

--- Comment #8 from Bruno Haible  ---
> what is the reason to require that b >= 0 in all of this?

In the 1990ies there were portability problems with a%b, b < 0. ANSI C said
that the result was machine-dependent if a < 0 or b < 0. Fortunately the result
is formally specified now, since ISO C 99.

You're right: Since GCC emits the instructions for the % operation, and
supposedly in compliance with ISO C and ISO C++, it can assume that negative
operands behave as specified.

> So, shouldn't the rules be

Yes, these 4 rules look correct.

[Bug c++/89197] Templated Functions const auto assignment causes internal compiler error

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Reduced, but it ICEs with -std=c++03 same like bug 97899:

// PR c++/89197

template  void foo(int i) { const int c = int{i}; }

[Bug c++/97900] g++ crashes when instantiating a templated function with a template-type vector parameter

[Jonathan.Strobl at gmx dot de via Gcc-bugs]

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

--- Comment #1 from Jonathan Strobl  ---
Created attachment 49593
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49593&action=edit
gcc -v and crash output

Attaching the output seems to have failed last time. Here it is.

[Bug c++/97900] New: g++ crashes when instantiating a templated function with a template-type vector parameter

[Jonathan.Strobl at gmx dot de via Gcc-bugs]

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

Bug ID: 97900
   Summary: g++ crashes when instantiating a templated function
with a template-type vector parameter
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Jonathan.Strobl at gmx dot de
  Target Milestone: ---

Dear GCC maintainers, I have managed to crash the compiler with the following
template instantiation. This happens on version 10.2.0 (on Debian Testing), as
well as on 11.0.0 20201114 (experimental) on compiler explorer:
https://godbolt.org/z/57xYb7

g++ -x c++ - <
T test(T __attribute__((vector_size(2 * sizeof(T vec) {
return vec[0] + vec[1];
}
typedef int v2si __attribute__((vector_size(2 * sizeof(int;
int run(v2si vec) {
return test(vec);
}
EOF


I have attached the output of "gcc -v" as well as the full backtrace. Thank you
very much for your support.

Yours sincerely,
Jonathan Strobl

[Bug c++/89197] Templated Functions const auto assignment causes internal compiler error

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Will reduce && add the test.

[Bug c++/89197] Templated Functions const auto assignment causes internal compiler error

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Somehow got fixed by my r268321.

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

[florin.iucha at amd dot com via Gcc-bugs]

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

--- Comment #7 from Florin Iucha  ---
Cool, thank you!

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Marek Polacek  ---
Reduced:

// PR c++/97899

template 
T fn(T a)
{
  return a;
}

template 
struct C {
  void bar() {
int d = 42;
const int i = int{fn(d)};
  }
};

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

[florin.iucha at amd dot com via Gcc-bugs]

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

--- Comment #5 from Florin Iucha  ---
Curious, were you able to reduce it further, or just bisected it?

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Marek Polacek  ---
Started with r11-4959.

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

[florin.iucha at amd dot com via Gcc-bugs]

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

--- Comment #3 from Florin Iucha  ---
gcc version 11.0.0 20201108 (previous snapshot) is compiling fine.

[Bug c++/97899] [11 Regression] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-19
   Keywords||ice-on-valid-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |11.0
Summary|internal compiler error: in |[11 Regression] internal
   |split_nonconstant_init_1,   |compiler error: in
   |at cp/typeck2.c:626 |split_nonconstant_init_1,
   ||at cp/typeck2.c:626
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Confirmed, thanks for reporting this.

Reducing...

[Bug c++/97899] internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

[florin.iucha at amd dot com via Gcc-bugs]

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

--- Comment #1 from Florin Iucha  ---
Created attachment 49590
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49590&action=edit
pre-processed source file

[Bug c++/97899] New: internal compiler error: in split_nonconstant_init_1, at cp/typeck2.c:626

[florin.iucha at amd dot com via Gcc-bugs]

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

Bug ID: 97899
   Summary: internal compiler error: in split_nonconstant_init_1,
at cp/typeck2.c:626
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: florin.iucha at amd dot com
  Target Milestone: ---

Created attachment 49589
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49589&action=edit
c++ source code

gcc version 11.0.0 20201115 (experimental) (GCC) built from
c746fc40f4ec8cfc1092efd49d567751858d2099 (equivalent to
https://gcc.gnu.org/pub/gcc/snapshots/LATEST-11/gcc-11-20201115.tar.xz)

Backtrace:

$ /opt/gcc11-for-tng/bin/g++-11 -std=c++17 -O3 -c pack-fail.cpp
pack-fail.cpp: In member function 'int Baz::otherTest()':
pack-fail.cpp:37:58: internal compiler error: in split_nonconstant_init_1, at
cp/typeck2.c:626
   37 | const auto address = uint64_t{packUint(low, high)};
  |  ^
0x7224d6 split_nonconstant_init_1
../../gcc/gcc/cp/typeck2.c:626
0xb3238f split_nonconstant_init(tree_node*, tree_node*)
../../gcc/gcc/cp/typeck2.c:657
0x99ac66 check_initializer
../../gcc/gcc/cp/decl.c:6909
0x9bebcd cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:7699
0xa69587 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:21362
0xa475a3 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13943
0xa63dfd cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:13342
0xa4935f cp_parser_statement
../../gcc/gcc/cp/parser.c:11588
0xa4a46d cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11954
0xa4a548 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11904
0xa63f65 cp_parser_function_body
../../gcc/gcc/cp/parser.c:23551
0xa63f65 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:23602
0xa68800 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:29492
0xa68c4c cp_parser_late_parsing_for_member
../../gcc/gcc/cp/parser.c:30394
0xa4482b cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:24664
0xa45723 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:24688
0xa45723 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:17943
0xa466b9 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:14565
0xa70215 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:29888
0xa70596 cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:29552
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Source code for pack-fail.cpp is attached.

[Bug c/97817] -Wformat-truncation=2 elicits invalid warning

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Martin Sebor  ---
I agree that the text of the warning could be improved.  I'm hoping to make
changes along the lines you suggest for GCC 12 (it's too late for GCC 11),

[Bug target/97847] [11 Regression] ICE in insert_insn_on_edge, at cfgrtl.c:1976

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Segher Boessenkool  ---
This was caused (or exposed) by e3b3b59683c1:

commit e3b3b59683c1e7d31a9d313dd97394abebf644be
Author: Vladimir N. Makarov 
Date:   Fri Nov 13 12:45:59 2020 -0500

[PATCH] Implementation of asm goto outputs

[Bug c/97861] [11 Regression] ICE in warn_parm_array_mismatch, at c-family/c-warn.c:3378

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug c/97879] [11 Regression] ICE in from_mode_char, at attribs.h:298 since r11-3303-g6450f07388f9fe57

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559550.html

[Bug tree-optimization/91029] missed optimization regarding value of modulo operation

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Actually, if (a % b) > 0 && b >= 0, can't we infer that a > 0?  For a == 0 the
(a % b) expression would be 0.
Similarly, if say (a % b) > 2 && b >= 0, can't we infer that a > 2, generally
(a % b) > x && x >= 0 && b >= 0 implies a > x
(a % b) < x && x <= 0 && b >= 0 implies a < x

Also, what is the reason to require that b >= 0 in all of this?
Isn't a % -b == a % b (except for b equal to INT_MIN, in that case
a % INT_MIN is a == INT_MIN ? 0 : a, but that also satisfies a % INT_MIN > 0
implies a > 0, a % INT_MIN < 0 implies a < 0, or say a % INT_MIN > 30 implies a
> 30 or a % INT_MIN < -42 implies a < -42.

So, shouldn't the rules be
(a % b) > x && x >= 0 implies a > x
(a % b) < x && x <= 0 implies a < x
(a % b) > x && x >= 0 implies b > x || b < -x
(a % b) < x && x <= 0 implies b > -x || b < x
?

[Bug middle-end/85811] Invalid optimization with fmax, fabs and nan

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:1be4878116a2be82552bd59c3c1c9adcac3d106b

commit r11-5152-g1be4878116a2be82552bd59c3c1c9adcac3d106b
Author: Roger Sayle 
Date:   Wed Nov 18 15:09:46 2020 -0700

Fix middle-end/85811: Introduce tree_expr_maybe_non_p et al.

The motivation for this patch is PR middle-end/85811, a wrong-code
regression entitled "Invalid optimization with fmax, fabs and nan".
The optimization involves assuming max(x,y) is non-negative if (say)
y is non-negative, i.e. max(x,2.0).  Unfortunately, this is an invalid
assumption in the presence of NaNs.  Hence max(x,+qNaN), with IEEE fmax
semantics will always return x even though the qNaN is non-negative.
Worse, max(x,2.0) may return a negative value if x is -sNaN.

I'll quote Joseph Myers (many thanks) who describes things clearly as:
> (a) When both arguments are NaNs, the return value should be a qNaN,
> but sometimes it is an sNaN if at least one argument is an sNaN.
> (b) Under TS 18661-1 semantics, if either argument is an sNaN then the
> result should be a qNaN (whereas if one argument is a qNaN and the
> other is not a NaN, the result should be the non-NaN argument).
> Various implementations treat sNaNs like qNaNs here.

Under this logic, the tree_expr_nonnegative_p for IEEE fmax should be:

CASE_CFN_FMAX:
CASE_CFN_FMAX_FN:
  /* Usually RECURSE (arg0) || RECURSE (arg1) but NaNs complicate
 things.  In the presence of sNaNs, we're only guaranteed to be
 non-negative if both operands are non-negative.  In the presence
 of qNaNs, we're non-negative if either operand is non-negative
 and can't be a qNaN, or if both operands are non-negative.  */
  if (tree_expr_maybe_signaling_nan_p (arg0) ||
  tree_expr_maybe_signaling_nan_p (arg1))
return RECURSE (arg0) && RECURSE (arg1);
  return RECURSE (arg0) ? (!tree_expr_maybe_nan_p (arg0)
  || RECURSE (arg1))
: (RECURSE (arg1)
  && !tree_expr_maybe_nan_p (arg1));

Which indeed resolves the wrong code in the PR.  The infrastructure that
makes this possible are the two new functions tree_expr_maybe_nan_p and
tree_expr_maybe_signaling_nan_p which test whether a value may potentially
be a NaN or a signaling NaN respectively.  In fact, this patch adds seven
new predicates to the middle-end:

bool tree_expr_finite_p (const_tree);
bool tree_expr_infinite_p (const_tree);
bool tree_expr_maybe_infinite_p (const_tree);
bool tree_expr_signaling_nan_p (const_tree);
bool tree_expr_maybe_signaling_nan_p (const_tree);
bool tree_expr_nan_p (const_tree);
bool tree_expr_maybe_nan_p (const_tree);

These functions correspond to the "must" and "may" operators in modal
logic,
and allow us to triage expressions in the middle-end; definitely a NaN,
definitely not a NaN, and unknown at compile-time, etc.  A prime example of
the utility of these functions is that a IEEE floating point value promoted
from an integer type can't be a NaN or infinite.  Hence (double)i+0.0 where
i is an integer can be simplified to (double)i even with -fsignaling-nans.
Currently in GCC optimizations are enabled/disabled based on whether the
expression's type supports NaNs or sNaNs; with these new predicates they
can be controlled by whether the actual operands may or may not be NaNs.

Having added these extremely useful helper functions to the middle-end,
I couldn't help by use then in a few places in fold-const.c, builtins.c
and match.pd.  In the near term, these can/should be used in places
where the tree optimizers test for HONOR_NANS, HONOR_INFINITIES or
HONOR_SNANS, or explicitly test whether a REAL_CST is a NaN or Inf.
In the longer term (I'm not volunteering) these predicates could perhaps
be hooked into the middle-end's SSA chaining and/or VRP machinery,
allowing finiteness to propagated around the CFG, much like we
currently propagate value ranges.

This patch has been tested on x86_64-pc-linux-gnu with a "make bootstrap"
and "make -k check".
Ok for mainline?

2020-08-15  Roger Sayle  

gcc/ChangeLog
PR middle-end/85811
* fold-const.c (tree_expr_finite_p): New function to test whether
a tree expression must be finite, i.e. not a FP NaN or infinity.
(tree_expr_infinite_p):  New function to test whether a tree
expression must be infinite, i.e. a FP infinity.
(tree_expr_maybe_infinite_p): New function to test whether a tree
expression may be infinite, i.e. a FP infinity.
(tree_expr_signaling_nan_p): New function to test

[Bug tree-optimization/97888] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Reverting the following snippet from my fix attempt for pr91651:

diff --git a/gcc/fortran/iresolve.c b/gcc/fortran/iresolve.c
index c2a4865f28f..994a9af4eb8 100644
--- a/gcc/fortran/iresolve.c
+++ b/gcc/fortran/iresolve.c
@@ -1296,11 +1296,7 @@ gfc_resolve_index_func (gfc_expr *f, gfc_actual_arglist
*a)

   f->ts.type = BT_INTEGER;
   if (kind)
-{
-  f->ts.kind = mpz_get_si ((kind)->value.integer);
-  a_back->next = NULL;
-  gfc_free_actual_arglist (a_kind);
-}
+f->ts.kind = mpz_get_si ((kind)->value.integer);
   else
 f->ts.kind = gfc_default_integer_kind;

fixes the current PR, but breaks testcase index_4.f90

[Bug tree-optimization/91029] missed optimization regarding value of modulo operation

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:71c9d2b088c9d409a1bd3b50523ac4623a5bf1b4

commit r11-5150-g71c9d2b088c9d409a1bd3b50523ac4623a5bf1b4
Author: Jakub Jelinek 
Date:   Wed Nov 18 22:13:06 2020 +0100

vrp: Fix operator_trunc_mod::op1_range [PR97888]

As mentioned in the PR, in (x % y) >= 0 && y >= 0, we can't deduce
x's range to be x >= 0, as e.g. -7 % 7 is 0.  But we can deduce it
from (x % y) > 0.  The patch also fixes up the comments.

2020-11-18  Jakub Jelinek  

PR tree-optimization/91029
PR tree-optimization/97888
* range-op.cc (operator_trunc_mod::op1_range): Only set op1
range to >= 0 if lhs is > 0, rather than >= 0.  Fix up comments.

* gcc.dg/pr91029.c: Add comment with PR number.
(f2): Use > 0 rather than >= 0.
* gcc.c-torture/execute/pr97888-1.c: New test.
* gcc.c-torture/execute/pr97888-2.c: New test.

[Bug tree-optimization/97888] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:71c9d2b088c9d409a1bd3b50523ac4623a5bf1b4

commit r11-5150-g71c9d2b088c9d409a1bd3b50523ac4623a5bf1b4
Author: Jakub Jelinek 
Date:   Wed Nov 18 22:13:06 2020 +0100

vrp: Fix operator_trunc_mod::op1_range [PR97888]

As mentioned in the PR, in (x % y) >= 0 && y >= 0, we can't deduce
x's range to be x >= 0, as e.g. -7 % 7 is 0.  But we can deduce it
from (x % y) > 0.  The patch also fixes up the comments.

2020-11-18  Jakub Jelinek  

PR tree-optimization/91029
PR tree-optimization/97888
* range-op.cc (operator_trunc_mod::op1_range): Only set op1
range to >= 0 if lhs is > 0, rather than >= 0.  Fix up comments.

* gcc.dg/pr91029.c: Add comment with PR number.
(f2): Use > 0 rather than >= 0.
* gcc.c-torture/execute/pr97888-1.c: New test.
* gcc.c-torture/execute/pr97888-2.c: New test.

[Bug target/97847] [11 Regression] ICE in insert_insn_on_edge, at cfgrtl.c:1976

[segher at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Segher Boessenkool  ---
I can now reproduce it, with a compiler built yesterday (previous was a
few days older), and -O0.

Confirmed.

[Bug analyzer/97893] Analyzer should only use CWE 690 when null ptr is from unchecked function return value

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from David Malcolm  ---
Should be fixed by the above commit.

[Bug analyzer/97893] Analyzer should only use CWE 690 when null ptr is from unchecked function return value

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r11-5148-gf3f312b535f57b5773953746f6ad0d890ce09b88
Author: David Malcolm 
Date:   Wed Nov 18 15:53:36 2020 -0500

analyzer: only use CWE-690 for unchecked return value [PR97893]

CWE-690 is only for dereferencing an unchecked return value; for
other kinds of NULL dereference, use the parent classification, CWE-476.

gcc/analyzer/ChangeLog:
PR analyzer/97893
* sm-malloc.cc (null_deref::emit): Use CWE-476 rather than
CWE-690, as this isn't due to an unchecked return value.
(null_arg::emit): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/97893
* gcc.dg/analyzer/malloc-1.c: Add CWE-690 and CWE-476 codes to
expected output.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

[abebeos at lazaridis dot com via Gcc-bugs]

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

--- Comment #16 from abebeos at lazaridis dot com ---
I've updated the bounty, and you can follow the work here:

https://github.com/abebeos/avr-gnu

Whenever something relevant happens, I'll report it here.

[Bug target/97873] Failure to optimize abs optimally (at least one completely useless instruction on x86)

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #4)
> So then either we should expand the SWI48x mode abs for !TARGET_EXPAND_ABS
> into
> a pre-reload define_insn_and_split with abs that we'd split almost like
> smax, except for using the result of neg for the condition codes (and we'd
> need to see how it plays with STV), or add a define_insn_and_split that
> would match what the combiner is trying:
> (set (reg:SI 84)
> (smax:SI (neg:SI (reg/v:SI 83 [ x ]))
> (reg/v:SI 83 [ x ])))
> (clobber (reg:CC 17 flags))
> and again split that cmov consumer of neg as flag setter (and again see what
> STV does with that).

This should be done after combine pass, so STV has a chance to convert min/max
to SSE instructions.  Effectively that means that only a peephole2 is feasible.

[Bug tree-optimization/96671] Failure to optimize a 3 xor+and pattern to xor+andnot

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r11-5146-gf44e6091627372bd8fc4e72874a003643b021dca
Author: Eugene Rozenfeld 
Date:   Wed Nov 18 14:29:49 2020 -0500

Optimize two patterns with three xors

gcc/
PR tree-optimization/96671
* match.pd (three xor patterns): New patterns.

[Bug target/97865] libtool needs to be updated for Darwin20.

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from Iain Sandoe  ---
(In reply to Jürgen Reuter from comment #14)
> If there is a git branch or so, I could also test it on my system with our
> code whether this works as expected.

Here you go - this is config.{sub, guess}, libtool and a small patch to enable
libsanitizer for darwin20 (which I'll likely push soon).

https://github.com/iains/gcc-git/tree/master-wip-config-darwin20

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #15 from rguenther at suse dot de  ---
On November 18, 2020 3:55:44 PM GMT+01:00, amacleod at redhat dot com
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
>
>--- Comment #12 from Andrew Macleod  ---
>Maybe I'm a little dense.
>
>if we are presuming that  
>  &x + (a + b) 
>implies a + b == 0, then we also should assume that
>
>  &x + a  implies a == 0
>
>and if we can make those assumptions, then
>&x + 1 is garbage because we can assume 1 == 0.
>
>And if a and b are both unsigned, then I guess we can also assume a ==
>b ==
>MAX_UINT / 2 ?
>
>
>Now, if we decided to actually do this...  I see IL:
>
> :
>  x.0_1 = x;
>  y = x.0_1;
>  a.1_2 = a;
>  b.2_3 = b;
>  _4 = a.1_2 + b.2_3;
>  _5 = (long unsigned int) _4;
>  _6 = _5 * 4;
>  _7 = &y + _6;
>
>The clear implications is that _6 == 0 in this expression?
>
>If we implemented that in the operator_pointer_plus::op1_range routine,
>and
>then were to back substitute, we'd get
>(_6)[0,0] = _5 * 4   -> _5 = [0,0]
>(_5)[0,0] = (long unsigned int) _4;  -> _4 == [0,0]
>(_4)[0,0] = a.1_2 + b.2_3   which gives us nothing additional...  Other
>than a
>potential relationship to track I suppose  a.1_2 == -B.2_3 for signed,
>but it
>would record that _4 is [0,0] when we calculate an outgoing range.
>
>but regardless, its seems that another straightforward place to do this
>would
>be in statement folding?  Isn't the basic assumption:
>
>_7 = &y + _6;
>implies _6 is always 0, which would enable us to fold this to
>_7 = &y
>then _6 is unused and the other statements would ultimately just go
>away.
>
>So why not make folding simply throw away the "+ _6" part because it is
>now
>being forced to be 0?  We can't really assume that it is [0,0], but
>then not
>use that information to optimize?

Well, clearly the zero case is degenerate but it extends to sth like int a[2] ;
and &a + n. I guess you're already handling ARRAY_REF indices.

[Bug target/97873] Failure to optimize abs optimally (at least one completely useless instruction on x86)

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Uroš Bizjak  ---
The attached patch generates:

movl%edi, %eax
negl%eax
cmovs   %edi, %eax
ret

The patch changes CC mode of NEG instruction to CCGOCmode, which is the same
mode as the mode of SUB instruction. IOW, sign bit becomes usable.

We have r1 = neg (r0). The NEG insn sets sign flag (SF) based on the *result*,
so when the SF is set, we are sure that r1 holds the negative and consequently
r0 holds the positive value. Now, when SF is set, CMOVE should select r0 (the
positive mirror image), otherwise it should select r1. This is just how CMOVS
works.

The patch also changes the mode iterator of  patterns to
SWI48 instead of SWI248. The purpose of maxmin expander is to prepare max/min
RTX for STV to eventually convert them to SSE MAX/MIN instructions, in order to
*avoid* CMOV insns with general registers. HImode will not be converted, so it
can be expanded by middle-end to a generic shift/xor/sub sequence as well.

[Bug target/97417] RISC-V Unnecessary andi instruction when loading volatile bool

[wilson at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #40 from Jim Wilson  ---
If you look at riscv.opt you will see that the -mshorten-memrefs option sets
the variable riscv_mshorten_memrefs.  If you grep for that, you will see that
it is used in riscv_address_cost in riscv.c.  I believe it is this change to
the address cost that is supposed to prevent the recombination back into
addresses that don't fit in compressed instructions.  So you need to look at
why this works in the current code, but not with your zero/sign extend load
patch.  Maybe there is something about the rtx costs for a regular load versus
a zero/sign extend load that causes the problem.  In the combine dump where it
says "original costs" and "replacement costs" that is where it is using
rtx_cost and riscv_address_cost.  The replacement cost should be more than the
original cost to prevent the recombination.  You should see that if you look at
the combine dump for the unpatched compiler.

[Bug target/97873] Failure to optimize abs optimally (at least one completely useless instruction on x86)

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Uroš Bizjak  ---
Created attachment 49588
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49588&action=edit
Proposed patch

Attached patch introduces relevant peephole2 pattern (and fixes some other
issues).

[Bug target/93176] PPC: inefficient 64-bit constant consecutive ones

[bergner at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Peter Bergner  ---
Alan, didn't one of your recent patches fix this particular bug?  So can we
mark this as fixed?

[Bug c/97884] INT_MIN falsely expanded to 64 bit

[schwab--- via Gcc-bugs]

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

--- Comment #11 from Andreas Schwab  ---
2147483648 does not fit in 32 bits.

[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-18
 Status|UNCONFIRMED |WAITING
   Priority|P3  |P4
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
I see the ICE from GCC7 up to GCC11, including GCC 10.2.1, but not for GCC
10.2.0.

[Bug c/97879] [11 Regression] ICE in from_mode_char, at attribs.h:298 since r11-3303-g6450f07388f9fe57

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
The attribute validation needs to be tightened up.

[Bug c/97884] INT_MIN falsely expanded to 64 bit

[s.bauroth--- via Gcc-bugs]

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

--- Comment #10 from s.baur...@tu-berlin.de ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to s.bauroth from comment #7)
> > > The type of an integer constant is the first of the corresponding list
> > > in which its value can be represented.
> > These kind of sentences make me think gcc's behaviour is wrong. The number
> > can be represented in 32 bits.

> So the - sign is not part of the constant. The constant is 2147483648 and
> that doesn't fit in 32 bits. So it's a 64-bit type, and then that gets
> negated.
If the constant is not allowed to have a sign why try to press it into a signed
type? I know it's the standard that does it - but does it make any sense?

> That has been explained several times now.
And I said multiple times that I understand the reasoning.

> "I don't understand C and I won't read the spec" is not a GCC bug.
Not going to comment.

I'm not questioning your reading of the standard, I'm not saying gcc breaks the
standard. From a programmers perspective it's not intuitive that 'INT_MIN',
'-2147483647 - 1' and all the other forms (like int a = -2147483648;
printf("%i", a);' work, but '-2147483648' does not. And from a technical
perspective it is absolutely unnecessary. Despite what the standard says about
how to tokenize the number , it fits in 32 bits. It just does.

[Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Martin Sebor  ---
What I mean is that unless error_mark_node necessarily implies (and guarantees)
the bound is a constant zero (as opposed to a similarly "broken" VLA bound),
simply bailing is safer than skipping it.  I have no idea if the front end
guarantees it but I don't see it mentioned in array_type_nelts().  If it is
guaranteed then continuing is fine but it should also be documented in the
comment above array_type_nelts(), and I would suggest to also mention it in the
change to get_parm_array_spec.

[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jonathan Wakely  ---
Github's poor life choices should not be our problem ;-)

If clang-8 doesn't ship  and doesn't work with GCC's ,
I would interpret that as you can't test  with clang-8.

[Bug c/97880] [8/9/10/11 Regression] ICE in emit_library_call_value_1, at calls.c:5298

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
With trunk, I get for 
  for (int i = 0; i < 8; i++)
for (long j = 0; j < 8; j++);

foocc.c: In function ‘f._omp_fn.0’:
foocc.c:6:1: error: type mismatch in binary expression
6 | }
  | ^
signed long

long int

int

D.2125 = .tile.5 * .tile.7;
during IPA pass: *free_lang_data


Draft patch:

--- a/gcc/omp-expand.c
+++ b/gcc/omp-expand.c
@@ -7561 +7561,2 @@ expand_oacc_for (struct omp_region *region, struct
omp_for_data *fd)
-   expr = fold_build2 (MULT_EXPR, diff_type, counts[ix].tile, expr);
+   expr = fold_build2 (MULT_EXPR, diff_type,
+   fold_convert (diff_type, counts[ix].tile), expr);

[Bug c/97884] INT_MIN falsely expanded to 64 bit

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to s.bauroth from comment #7)
> > The type of an integer constant is the first of the corresponding list
> > in which its value can be represented.
> These kind of sentences make me think gcc's behaviour is wrong. The number
> can be represented in 32 bits.

No it can't.

A few paragraphs above the text I quoted last time it says:L

"An integer constant begins with a digit, but has no period or exponent part.
It may have a prefix that specifies its base and a suffix that specifies its
type."

So the - sign is not part of the constant. The constant is 2147483648 and that
doesn't fit in 32 bits. So it's a 64-bit type, and then that gets negated.

That has been explained several times now.

"I don't understand C and I won't read the spec" is not a GCC bug.

[Bug c/97884] INT_MIN falsely expanded to 64 bit

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Jakub Jelinek  ---
If you design your own programming language, you can define it whatever way you
want, but for C and C++ it is well defined how the compiler must behave in
these cases, that -2147483648 are two separate tokens, unary minus and an
integral constant.

[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore

[rsandifo at gcc dot gnu.org via Gcc-bugs]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #15 from rsandifo at gcc dot gnu.org  
---
The original problem is fixed for GCC 10 and the kernel
manifestation is fixed for trunk.  We still need to deal
with the testcase in comment 8, which is another manifestation
that affects trunk only.

[Bug c/97884] INT_MIN falsely expanded to 64 bit

[s.bauroth--- via Gcc-bugs]

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

--- Comment #7 from s.baur...@tu-berlin.de ---
I do understand that +2147483648 is not an int. I am aware of how the 2s
complement works. It seems to me the reason for INT_MIN being '(-2147483647 -
1)' instead of the mathematically equivalent '-2147483648' is the parser
tokenizing the absolute value of the literal split from the sign of the
literal. I'm also able to imagine why that eases parsing. But if splitting
absolute value and sign - why not treat the absolute value as unsigned? Or
maybe do a check 'in the end' (I have no knowledge of the codebase here...)
whether one can reduce the size of the literal again?
The fact is INT_MIN and '-2147483648' are both integers perfectly representable
in 32 bits. I understand why gcc treats the second one differently (and clang
does too) - I just think it's not right (or expectable for that matter). And if
it's right, gcc should maybe warn about a 32bit literal being expanded to a
larger type - not only in format strings.

> The type of an integer constant is the first of the corresponding list in 
> which its value can be represented.
These kind of sentences make me think gcc's behaviour is wrong. The number can
be represented in 32 bits.

[Bug target/97506] [11 Regression] ICE: in extract_insn, at recog.c:2294 (unrecognizable insn) with -mavx512vbmi -mavx512vl

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Fixed.

[Bug c++/97523] [11 Regression] bogus "would use explicit constructor" error for new[]()

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Marek Polacek  ---
Better test:

// PR c++/97523
// { dg-do compile }

struct T {
  explicit T();
  T(int);
};

void
fn (int n)
{
  new T[1]();
  new T[2]();
  new T[3]();
  new T[n]();
#if __cpp_aggregate_paren_init
  new T[]();
  new T[2](1, 2);
  new T[3](1, 2);
#endif
}

[Bug c++/97895] [11 Regression] ICE in do_auto_deduction, at cp/pt.c:29255

[mpolacek at gcc dot gnu.org via Gcc-bugs]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-11-18
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Marek Polacek  ---
Mine, started with r11-4547.

[Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Jakub Jelinek  ---
As I said, [0] is not a VLA bound.
And we don't record anything for constant bounds (even if they are in the
middle).
So perhaps:
  /* array_type_nelts assumes the middle-end TYPE_DOMAINs, while
 GNU [0] array in the FE don't have TYPE_MAX_VALUE of the
 domain set, yet they are complete types with no elements.  */
  if (nelts == error_mark_node
  && TYPE_DOMAIN (type)
  && !TYPE_MAX_VALUE (TYPE_DOMAIN (type))
  && COMPLETE_P (type)
  && integer_zerop (TYPE_SIZE (type)))
continue;
  if (error_mark_operand (nelts))
return attrs;
which would bail for errors, but would handle [0] complete arrays as
non-errors.
After all, even for those it might be meaningful to complain about out of
bounds accesses.
Sure, for [0] arrays all dereferences are invalid, but taking address of
element [0] is ok.

[Bug c/97898] New: ICE in outermost_invariant_loop, at tree-ssa-loop-im.c:431

[gscfq--- via Gcc-bugs]

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

Bug ID: 97898
   Summary: ICE in outermost_invariant_loop, at
tree-ssa-loop-im.c:431
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least version r5 :


$ cat z1.c
void f (int n)
{
  int *i;
#pragma omp for schedule(static, 2)
  for (i = 0; i < 8; i += n);
}


$ gcc-11-20201115 -c z1.c -fopenmp -O2
z1.c: In function 'f':
z1.c:5:17: warning: comparison between pointer and integer
5 |   for (i = 0; i < 8; i += n);
  | ^
during GIMPLE pass: lim
z1.c:1:6: internal compiler error: in outermost_invariant_loop, at
tree-ssa-loop-im.c:431
1 | void f (int n)
  |  ^
0xc43b12 outermost_invariant_loop
../../gcc/tree-ssa-loop-im.c:431
0xc48551 compute_invariantness
../../gcc/tree-ssa-loop-im.c:1063
0xc48551 loop_invariant_motion_in_fun(function*, bool)
../../gcc/tree-ssa-loop-im.c:3114
0xc49e2a execute
../../gcc/tree-ssa-loop-im.c:3180

---

$ gcc-11-20201115 -c z1.c -fopenmp   # configured with --enable-checking=yes
z1.c: In function 'f':
z1.c:5:17: warning: comparison between pointer and integer
5 |   for (i = 0; i < 8; i += n);
  | ^
z1.c:5:24: error: invalid operands in binary operation
5 |   for (i = 0; i < 8; i += n);
  |^~
i = i + (sizetype) D.2082;
during GIMPLE pass: ompexp
z1.c:5:24: internal compiler error: verify_gimple failed
0xd61194 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5461
0xc1742e execute_function_todo
../../gcc/passes.c:2039
0xc182d2 execute_todo
../../gcc/passes.c:2093

[Bug c/97884] INT_MIN falsely expanded to 64 bit

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Jonathan Wakely  ---
The C standard says "The type of an integer constant is the first of the
corresponding list in which its value can be represented." The corresponding
list for decimal constants with no suffix is int, long int, long long int.

Since 2147483647 doesn't fit in int, it will have a larger type (long long int
for your target). The unary - operator changes the value, but it still has type
long long int.

If you use INT_MIN from  it will work, because that's defined as
(-INT_MAX - 1) as Richard and Jakub said. It's defined like that for a good
reason.

[Bug c/97897] New: ICE tree check: expected ssa_name, have integer_cst in compute_optimized_partition_bases, at tree-ssa-coalesce.c:1638

[gscfq--- via Gcc-bugs]

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

Bug ID: 97897
   Summary: ICE tree check: expected ssa_name, have integer_cst in
compute_optimized_partition_bases, at
tree-ssa-coalesce.c:1638
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :
(compiles with "(_Complex a)" instead)


$ cat z1.c
void h ();
void f () __attribute__ ((returns_twice));
void g (_Complex int a)
{
  f ();
  if (a != 0)
  {
a = 0;
h ();
  }
}


$ gcc-11-20201115 -c z1.c
during RTL pass: expand
z1.c: In function 'g':
z1.c:3:6: internal compiler error: tree check: expected ssa_name, have
integer_cst in compute_optimized_partition_bases, at tree-ssa-coalesce.c:1638
3 | void g (_Complex int a)
  |  ^
0x626df8 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9779
0xe4bb1f tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3314
0xe4bb1f compute_optimized_partition_bases
../../gcc/tree-ssa-coalesce.c:1638
0xe4bb1f coalesce_ssa_name(_var_map*)
../../gcc/tree-ssa-coalesce.c:1718
0xdde89b remove_ssa_form
../../gcc/tree-outof-ssa.c:1065
0xdde89b rewrite_out_of_ssa(ssaexpand*)
../../gcc/tree-outof-ssa.c:1323
0x80fa70 execute
../../gcc/cfgexpand.c:6407

[Bug fortran/97896] New: [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156

[gscfq--- via Gcc-bugs]

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

Bug ID: 97896
   Summary: [11 Regression] ICE in gfc_trans_assignment_1, at
fortran/trans-expr.c:11156
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Follow-up of pr91651, changed between 20201004 and 20201018 :


$ cat z1.f90
program p
   logical :: a(2)
   integer :: b(2)
   b = index('xyxy', 'yx', a, 4)
   print *, b
end


$ gfortran-11-20201004 -c z1.f90
$
$ gfortran-11-20201115 -c z1.f90
z1.f90:4:32:

4 |b = index('xyxy', 'yx', a, 4)
  |1
internal compiler error: in gfc_trans_assignment_1, at
fortran/trans-expr.c:11156
0x764094 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:11155
0x725aa7 trans_code
../../gcc/fortran/trans.c:1888
0x74bbe4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6878
0x6d2e86 translate_all_program_units
../../gcc/fortran/parse.c:6347
0x6d2e86 gfc_parse_file()
../../gcc/fortran/parse.c:6616
0x71ee2f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:212

[Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Martin Sebor  ---
Actually, I missed that your patch just skips over the error node.  That will
leave the attribute spec out of sync with the argument (it contains a '$' for
each VLA bound).  Rather than continuing to the next bound I think we should
bail.  The alternative is to change the rest of the code (the attribute handler
and the whole attribute access machinery) to skip these erroneous bounds.

[Bug c++/97895] New: [11 Regression] ICE in do_auto_deduction, at cp/pt.c:29255

[gscfq--- via Gcc-bugs]

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

Bug ID: 97895
   Summary: [11 Regression] ICE in do_auto_deduction, at
cp/pt.c:29255
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed recently between 20201018 and 20201108 :


$ cat z1.cc
namespace std {
  template struct initializer_list {
const T *ptr;
decltype(sizeof 0) n;
  };
  auto a = {};
}


$ g++-11-20201115 -c z1.cc
z1.cc:6:13: internal compiler error: Segmentation fault
6 |   auto a = {};
  | ^
0xc727ef crash_signal
../../gcc/toplev.c:330
0x7642c1 vec::end()
../../gcc/vec.h:585
0x7642c1 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../gcc/cp/pt.c:29255
0x6c4cf2 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7570
0x74d7f7 cp_parser_init_declarator
../../gcc/cp/parser.c:21362
0x72f42a cp_parser_simple_declaration
../../gcc/cp/parser.c:13943
0x75307a cp_parser_declaration
../../gcc/cp/parser.c:13640
0x753d34 cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:13485
0x753d34 cp_parser_namespace_body
../../gcc/cp/parser.c:19955
0x753d34 cp_parser_namespace_definition
../../gcc/cp/parser.c:19933
0x752eaf cp_parser_declaration
../../gcc/cp/parser.c:13620
0x75390a cp_parser_translation_unit
../../gcc/cp/parser.c:4806
0x75390a c_parse_file()
../../gcc/cp/parser.c:44595
0x81d252 c_common_parse_file()
../../gcc/c-family/c-opts.c:1196

[Bug c/97894] New: gcc/attr-fnspec.h: 8 * function could be const ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 97894
   Summary: gcc/attr-fnspec.h: 8 * function could be const ?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

It would be a minor tidyup to mark some member functions in file 
gcc/attr-fnspec.h as const.

Here is some output from from a recent run of the static analyser cppcheck:

trunk.git/gcc/attr-fnspec.h:109:3: style:inconclusive: Technically the member
function 'attr_fnspec::known_p' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:227:3: style:inconclusive: Technically the member
function 'attr_fnspec::returns_arg' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:241:3: style:inconclusive: Technically the member
function 'attr_fnspec::returns_noalias_p' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:248:3: style:inconclusive: Technically the member
function 'attr_fnspec::global_memory_read_p' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:256:3: style:inconclusive: Technically the member
function 'attr_fnspec::global_memory_written_p' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:262:3: style:inconclusive: Technically the member
function 'attr_fnspec::errno_maybe_written_p' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:272:3: style:inconclusive: Technically the member
function 'attr_fnspec::get_str' can be const. [functionConst]
trunk.git/gcc/attr-fnspec.h:77:16: style:inconclusive: Technically the member
function 'attr_fnspec::arg_idx' can be const. [functionConst]

[Bug c/97884] INT_MIN falsely expanded to 64 bit

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
But INT_MIN in C is (-2147483647 - 1) for 32-bit ints, not -2147483648, as has
been explained, there is a significant difference for those two, because
2147483648 constant is not representable in int and therefore the constant gets
a different type and the negation preserves that type.
If something defines INT_MIN to -2147483648, the bug is in whatever defines it
that way.

[Bug c/97884] INT_MIN falsely expanded to 64 bit

[s.bauroth--- via Gcc-bugs]

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

--- Comment #4 from s.baur...@tu-berlin.de ---
I am aware of the warning, I disagree with it's content. INT_MIN is an int, not
a long long int. I understand why it is processed as a long long int
internally, but that should not be visible from the outside world, at least
imho.

[Bug analyzer/97893] New: Analyzer should only use CWE 690 when null ptr is from a function return

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97893
   Summary: Analyzer should only use CWE 690 when null ptr is from
a function return
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

>From an email from a user:

> -Wanalyzer-possible-null-dereference reports CWE-690. If we
> know that the NULL is the result of a function returning NULL, then 690 is
> correct.  Otherwise, 476 is the parent of 690 which means it's a more
> generalized classification for all NULL ptr dereferences. So, it's probably 
> what we want for less specific kinds of dereferences.

Internally, 690 is used unconditionally by possible_null_deref::emit,
possible_null_arg::emit, null_deref::emit, and null_arg::emit.

[Bug target/97528] [9/10/11 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 49587
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49587&action=edit
gcc11-pr97528.patch

Untested fix.

[Bug target/97528] [9/10/11 Regression] ICE in decompose_automod_address, at rtlanal.c:6298 (arm-linux-gnueabihf)

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
We have:
(insn 7 6 9 2 (set (reg:SI 114 [ _3 ])
(ashift:SI (reg:SI 122 [ d ])
(const_int 1 [0x1]))) "pr97528-2.c":14:9 147 {*arm_shiftsi3}
 (expr_list:REG_DEAD (reg:SI 122 [ d ])
(nil)))
...
(insn 12 25 24 2 (set (mem/c:V4HI (post_modify:SI (reg/v/f:SI 118 [ dst ])
(plus:SI (reg/v/f:SI 118 [ dst ])
(reg:SI 114 [ _3 ]))) [0 MEM[(short int[4] *)&c]+0 S8 A16])
(unspec:V4HI [
(reg:V4HI 117 [ _14 ])
] UNSPEC_VST1)) "pr97528-2.c":13:5 2508 {neon_vst1v4hi}
 (expr_list:REG_INC (reg/v/f:SI 118 [ dst ])
(nil)))
and combine attempts to propagate the shift into the insn:
(insn 12 25 24 2 (set (mem/c:V4HI (post_modify:SI (reg/v/f:SI 118 [ dst ])
(plus:SI (mult:SI (reg:SI 122 [ d ])
(const_int 2 [0x2]))
(reg/v/f:SI 118 [ dst ]))) [0 MEM[(short int[4] *)&c]+0 S8
A16])
(unspec:V4HI [
(reg:V4HI 117 [ _14 ])
] UNSPEC_VST1)) "pr97528-2.c":13:5 2508 {neon_vst1v4hi}
 (expr_list:REG_INC (reg/v/f:SI 118 [ dst ])
(nil)))
That is not valid RTL, as documented:
   Currently, the compiler can only handle second operands of the
   form (plus (reg) (reg)) and (plus (reg) (const_int)), where
   the first operand of the PLUS has to be the same register as
   the first operand of the *_MODIFY.

[Bug c/97884] INT_MIN falsely expanded to 64 bit

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
Compiling with -Wall should issue a warning pointing out the problem:

$ cat pr97884.c && gcc -O2 -S -Wall pr97884.c
void f (void)
{
  __builtin_printf ("%i\n", -2147483648);
  __builtin_printf ("%i\n", (int)-2147483648);
}


pr97884.c: In function 'f':
pr97884.c:3:23: warning: format '%i' expects argument of type 'int', but
argument 2 has type 'long long int' [-Wformat=]
3 |   __builtin_printf ("%i\n", -2147483648);
  |  ~^ ~~~
  |   | |
  |   int   long long int
  |  %lli

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from Martin Sebor  ---
Andrew, we discussed the same idea for built-in functions at Couldron.  For
instance, in:

  void f (const char *s, int n)
  {
char a[8];
memcpy (a, s, n); // n must be in [0, 8]
if (n < 0 || n > 8)   // fold to false
  abort ();
  }

[Bug target/97532] [11 Regression] Error: insn does not satisfy its constraints, internal compiler error: in extract_constrain_insn, at recog.c:2196

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #16 from Jakub Jelinek  ---
.

[Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #3)
> I was going to commit the following but I'll leave it to you.
> 
> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
> index d348e39c27a..95cf9e4cb00 100644
> --- a/gcc/c/c-decl.c
> +++ b/gcc/c/c-decl.c
> @@ -5775,6 +5775,10 @@ get_parm_array_spec (const struct c_parm *parm, tree
> attrs)
>type = TREE_TYPE (type))
> {
>   tree nelts = array_type_nelts (type);
> + if (error_operand_p (nelts))
> +   /* Avoid erroneous expressions.  */
> +   return attrs;
> +
>   if (TREE_CODE (nelts) != INTEGER_CST)
> {
>   /* Each variable VLA bound is represented by the dollar

For errors why not, but typedef int T[0]; really is not an error actually.

[Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Martin Sebor  ---
I was going to commit the following but I'll leave it to you.

diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index d348e39c27a..95cf9e4cb00 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -5775,6 +5775,10 @@ get_parm_array_spec (const struct c_parm *parm, tree
attrs)
   type = TREE_TYPE (type))
{
  tree nelts = array_type_nelts (type);
+ if (error_operand_p (nelts))
+   /* Avoid erroneous expressions.  */
+   return attrs;
+
  if (TREE_CODE (nelts) != INTEGER_CST)
{
  /* Each variable VLA bound is represented by the dollar

[Bug c/97882] [8/9/10/11 Regression] Segmentation Fault on improper redeclaration of function

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r7-760-gaa4b467b680f230ab11922d1e29695e1eaba12af

[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to

[segher at gcc dot gnu.org via Gcc-bugs]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #8 from Segher Boessenkool  ---
The fmadd;frsp sequence is correct for this source code.  It does double
rounding of the result (first to DP float, then to SP float), so using
just fmadds is only correct for -ffast-math or similar.

[Bug target/97870] [11 Regression] ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

https://gcc.gnu.org/g:2f2709e691148160e4f88090eaf48d3e4915b0e4

commit r11-5131-g2f2709e691148160e4f88090eaf48d3e4915b0e4
Author: Vladimir N. Makarov 
Date:   Wed Nov 18 10:07:56 2020 -0500

[PR97870] LRA: don't remove asm goto, just nullify it.

gcc/

2020-11-18  Vladimir Makarov  

PR target/97870
* lra-constraints.c (curr_insn_transform): Do not delete asm goto
with wrong constraints.  Nullify it saving CFG.

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
(In reply to Andrew Macleod from comment #12)
> Maybe I'm a little dense.
> 
> if we are presuming that  
>   &x + (a + b) 
> implies a + b == 0, then we also should assume that

&x + (a + b) for scalar x doesn't imply a + b == 0, it implies a + b <= 1.
Only when it is dereferenced, i.e. (&x)[a + b] is accessed a + b has to be 0.

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #7 from Uroš Bizjak  ---
I'll fix this.

[Bug c++/95192] [11 Regression] ICE: tree check: expected tree_list, have error_mark in handle_assume_aligned_attribute, at c-family/c-attribs.c:2996

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
In cp/parser.c, we have code that avoids building attributes with
error_mark_node values (instead just use error_mark_node as the attributes).

So, I wonder if we shouldn't do that in tsubst_attributes too, like:
--- gcc/cp/pt.c.jj  2020-11-18 09:40:09.618663053 +0100
+++ gcc/cp/pt.c 2020-11-18 15:47:26.584181671 +0100
@@ -11502,6 +11502,8 @@ tsubst_attribute (tree t, tree *decl_p,
   tree chain
= tsubst_expr (TREE_CHAIN (val), args, complain, in_decl,
   /*integral_constant_expression_p=*/false);
+  if (chain == error_mark_node)
+   return error_mark_node;
   if (chain != TREE_CHAIN (val))
val = tree_cons (NULL_TREE, TREE_VALUE (val), chain);
 }
@@ -11524,8 +11526,12 @@ tsubst_attribute (tree t, tree *decl_p,
   return list;
 }
   else
-val = tsubst_expr (val, args, complain, in_decl,
-  /*integral_constant_expression_p=*/false);
+{
+  val = tsubst_expr (val, args, complain, in_decl,
+/*integral_constant_expression_p=*/false);
+  if (val == error_mark_node)
+   return val;
+}

   if (val != TREE_VALUE (t))
 return build_tree_list (TREE_PURPOSE (t), val);

Except that we accept the testcase then rather than reject - the unification is
done with complain == 0...

[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #12 from Andrew Macleod  ---
Maybe I'm a little dense.

if we are presuming that  
  &x + (a + b) 
implies a + b == 0, then we also should assume that

  &x + a  implies a == 0

and if we can make those assumptions, then
&x + 1 is garbage because we can assume 1 == 0.

And if a and b are both unsigned, then I guess we can also assume a == b ==
MAX_UINT / 2 ?


Now, if we decided to actually do this...  I see IL:

 :
  x.0_1 = x;
  y = x.0_1;
  a.1_2 = a;
  b.2_3 = b;
  _4 = a.1_2 + b.2_3;
  _5 = (long unsigned int) _4;
  _6 = _5 * 4;
  _7 = &y + _6;

The clear implications is that _6 == 0 in this expression?

If we implemented that in the operator_pointer_plus::op1_range routine, and
then were to back substitute, we'd get
(_6)[0,0] = _5 * 4   -> _5 = [0,0]
(_5)[0,0] = (long unsigned int) _4;  -> _4 == [0,0]
(_4)[0,0] = a.1_2 + b.2_3   which gives us nothing additional...  Other than a
potential relationship to track I suppose  a.1_2 == -B.2_3 for signed, but it
would record that _4 is [0,0] when we calculate an outgoing range.

but regardless, its seems that another straightforward place to do this would
be in statement folding?  Isn't the basic assumption:

_7 = &y + _6;
implies _6 is always 0, which would enable us to fold this to
_7 = &y
then _6 is unused and the other statements would ultimately just go away.

So why not make folding simply throw away the "+ _6" part because it is now
being forced to be 0?  We can't really assume that it is [0,0], but then not
use that information to optimize?

[Bug target/97891] [x86] Consider using registers on large initializations

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-18
 Status|UNCONFIRMED |NEW
 Target|x86-64  |x86_64-*-* i?86-*-*
 Ever confirmed|0   |1
   Keywords||missed-optimization

--- Comment #2 from Richard Biener  ---
Confirmed.  I think we have (plenty?) duplicates.

[Bug c/97892] [10/11 Regression] ICE in tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:2946

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

Summary|ICE in tree check: expected |[10/11 Regression] ICE in
   |class ‘type’, have  |tree check: expected class
   |‘exceptional’ (error_mark)  |‘type’, have ‘exceptional’
   |in c_expr_sizeof_expr, at   |(error_mark) in
   |c/c-typeck.c:2946   |c_expr_sizeof_expr, at
   ||c/c-typeck.c:2946
   Priority|P3  |P4
  Component|other   |c
   Keywords||error-recovery
   Target Milestone|--- |10.3

[Bug target/96377] [10/11 Regression] GCC 10.2/11 doesn't build Linux kernel anymore

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Jakub Jelinek  ---
Actually still ICEs.

[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
So fixed?  Any reason why the testcase hasn't been added to the testsuite?  I
can test it on skylake-avx512 and add it there.

[Bug ipa/97673] [11 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1922 since r11-4267-g0e590b68fa374365

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
It is not, it still ICEs with r11-5128 and
-O3 -fno-early-inlining --param large-stack-frame=4000 on x86_64-linux.

[Bug c/97860] [11 Regression] ICE in handle_argspec_attribute, at c-family/c-attribs.c:3244 since r11-3303-g6450f07388f9fe57

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The problem is that in the C FE TYPE_MAX_VALUE (TYPE_DOMAIN (type)) isn't set
for the [0] types (yet they are complete), while the middle-end expects for
them to have TYPE_MAX_VALUE of -1 or so, so array_type_nelts returns
error_mark_node.
We could do:
  /* array_type_nelts assumes the middle-end TYPE_DOMAINs, while
 GNU [0] array in the FE don't have TYPE_MAX_VALUE of the
 domain set, yet they are complete types with no elements.  */
  if (nelts == error_mark_node
  && TYPE_DOMAIN (type)
  && !TYPE_MAX_VALUE (TYPE_DOMAIN (type))
  && COMPLETE_P (type)
  && integer_zerop (TYPE_SIZE (type)))
continue;
but then it doesn't make sense to queue up error_mark_nodes in the attributes
when we ICE on them later, so perhaps better:
2020-11-18  Jakub Jelinek  

PR c/97860
* c-decl.c (get_parm_array_spec): Don't chain error_mark_node as
VLA bounds.

* gcc.dg/pr97860.c: New test.

--- gcc/c/c-decl.c.jj   2020-11-11 01:46:03.245697697 +0100
+++ gcc/c/c-decl.c  2020-11-18 15:11:14.613565216 +0100
@@ -5775,7 +5775,7 @@ get_parm_array_spec (const struct c_parm
   type = TREE_TYPE (type))
{
  tree nelts = array_type_nelts (type);
- if (TREE_CODE (nelts) != INTEGER_CST)
+ if (TREE_CODE (nelts) != INTEGER_CST && nelts != error_mark_node)
{
  /* Each variable VLA bound is represented by the dollar
 sign.  */
--- gcc/testsuite/gcc.dg/pr97860.c.jj   2020-11-18 15:15:08.858931877 +0100
+++ gcc/testsuite/gcc.dg/pr97860.c  2020-11-18 15:14:50.751135430 +0100
@@ -0,0 +1,11 @@
+/* PR c/97860 */
+/* { dg-do compile } */
+/* { dg-options "" } */
+
+void
+foo (int n)
+{
+  typedef int T[0];
+  typedef T V[n];
+  void bar (V);
+}

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Richard Biener  ---
So likely caused by g:f359611b363490b48a7ce0fd021f7e47d8816eb0

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Uroš Bizjak  ---
> > This should have the following insn constraint:
> > 
> >   "TARGET_80387 && !(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)"
> > 
> > to hide it from combine in cases where relevant SSE mode is available.
> 
> Hmm, it is
> 
> ;; Changing of sign for FP values is doable using integer unit too.
> (define_insn "*2_i387_1"
>   [(set (match_operand:X87MODEF 0 "register_operand" "=f,!r")
> (absneg:X87MODEF
>   (match_operand:X87MODEF 1 "register_operand" "0,0")))
>(clobber (reg:CC FLAGS_REG))]
>   "TARGET_80387"
>   "#")
> 
> that is not guarded in this way?

Yes, this is the one.

[Bug target/97887] [10/11 Regression] Failure to optimize neg plus div to avoid using x87 floating point stack

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Richard Biener  ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Richard Biener from comment #2)
> > combine first makes recog pick negsf2_i387_1:
> 
> This should have the following insn constraint:
> 
>   "TARGET_80387 && !(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)"
> 
> to hide it from combine in cases where relevant SSE mode is available.

Hmm, it is

;; Changing of sign for FP values is doable using integer unit too.
(define_insn "*2_i387_1"
  [(set (match_operand:X87MODEF 0 "register_operand" "=f,!r")
(absneg:X87MODEF
  (match_operand:X87MODEF 1 "register_operand" "0,0")))
   (clobber (reg:CC FLAGS_REG))]
  "TARGET_80387"
  "#")

that is not guarded in this way?

[Bug middle-end/97862] [11 Regression] ICE in expand_omp_for_init_vars, at omp-expand.c:2524

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug target/97873] Failure to optimize abs optimally (at least one completely useless instruction on x86)

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
So then either we should expand the SWI48x mode abs for !TARGET_EXPAND_ABS into
a pre-reload define_insn_and_split with abs that we'd split almost like smax,
except for using the result of neg for the condition codes (and we'd need to
see how it plays with STV), or add a define_insn_and_split that would match
what the combiner is trying:
(set (reg:SI 84)
(smax:SI (neg:SI (reg/v:SI 83 [ x ]))
(reg/v:SI 83 [ x ])))
(clobber (reg:CC 17 flags))
and again split that cmov consumer of neg as flag setter (and again see what
STV does with that).

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Richard Biener  ---
There's then also a permute optimization left on the plate:

t.c:16:3: note:   node 0x3a19590 (max_nunits=4, refcnt=2)
t.c:16:3: note: stmt 0 _153 = f11_im_76 * x1_im_142;
t.c:16:3: note: stmt 1 _213 = f11_re_72 * x1_re_202;
t.c:16:3: note: stmt 2 _275 = f11_re_72 * x1_re_264;
t.c:16:3: note: stmt 3 _337 = f11_re_72 * x1_re_326;
t.c:16:3: note: stmt 4 _155 = f11_im_76 * x1_re_140;
t.c:16:3: note: stmt 5 _217 = f11_im_76 * x1_re_202;
t.c:16:3: note: stmt 6 _279 = f11_im_76 * x1_re_264;
t.c:16:3: note: stmt 7 _341 = f11_im_76 * x1_re_326;
t.c:16:3: note: children 0x3a19600 0x3a19670
t.c:16:3: note:   node (external) 0x3a19600 (max_nunits=1, refcnt=1)
t.c:16:3: note: { f11_im_76, f11_re_72, f11_re_72, f11_re_72,
f11_im_76, f11_im_76, f11_im_76, f11_im_76 }
t.c:16:3: note:   node 0x3a19670 (max_nunits=4, refcnt=1)
t.c:16:3: note: stmt 0 x1_im_142 = *_141;
t.c:16:3: note: stmt 1 x1_re_202 = *_201;
t.c:16:3: note: stmt 2 x1_re_264 = *_263;
t.c:16:3: note: stmt 3 x1_re_326 = *_325;
t.c:16:3: note: stmt 4 x1_re_140 = *_139;
t.c:16:3: note: stmt 5 x1_re_202 = *_201;
t.c:16:3: note: stmt 6 x1_re_264 = *_263;
t.c:16:3: note: stmt 7 x1_re_326 = *_325;
t.c:16:3: note: load permutation { 4 1 2 3 0 1 2 3 }

which we currently do not handle (there's a FIXME as to permute externals,
currently we only handle splats as transparent for permutes).