[Bug fortran/91862] [9/10 Regression] ICE in fold_convert_loc, at fold-const.c:2394

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.3

[Bug fortran/91863] [9/10 Regression] ICE in wide_int_to_tree_1, at tree.c:156

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.3

[Bug fortran/91864] [9/10 Regression] ICE in gfc_check_do_variable, at fortran/parse.c:4405

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.3

[Bug rtl-optimization/91865] Combine misses opportunity to remove (sign_extend (zero_extend)) before searching for insn patterns

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  I guess either simplify-rtx or the combine variant could be
amended.
There may be guards against partial int modes preventing existing
simplifications to apply (for hysterical reasons).

[Bug middle-end/91866] Sign extend of an int is not recognized

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
There are some dups I believe.

[Bug middle-end/91869] Constant bitfield assignment causes unnecessary use of memory and instructions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  One issue is with the use of volatile in the testcase which
on GIMPLE forces an intermediate init of an aggregate that is then
volatile-copied to the destination.

If you remove the volatile qualifications the code generation improves but
we still see

main ()
{
   [local count: 1073741825]:
  MEM[(struct Reg_T *)&Reg_0] = 0;
  MEM[(struct Reg_T *)&Reg_1] = 64;
  MEM[(struct Reg_T *)&Reg_2] = 8;
  Reg_3 = *.LC0;
  MEM[(struct Reg_T *)&Reg_4] = 4;
  Reg_5 = *.LC1;
  Reg_6 = *.LC2;
  Reg_7 = *.LC3;
  Reg_A = 0;
  Reg_B = 72;
  Reg_C = 255;
  return 0;

thus 1-byte constant pool entries being used:

movzbl  .LC0(%rip), %eax
...

on the GIMPLE level this isn't cleaned up because of the aggregate-ness
(plus the constructor involving bitfields and us being lazy and giving up
on native-interpreting those in the constant folding code - still we
have code to deal with this in ctor emit code).

The cases with *.LCN uses come from the gimplifier heuristic when
there's more than one non-zero initializer:

Reg_0.a = 0;
Reg_0.b = 0;
Reg_0.c = 0;
Reg_1.a = 0;
Reg_1.b = 0;
Reg_1.c = 4;
Reg_2.a = 0;
Reg_2.b = 1;
Reg_2.c = 0;
Reg_3 = *.LC0;
Reg_4.a = 4;
Reg_4.b = 0;
Reg_4.c = 0;
Reg_5 = *.LC1;
Reg_6 = *.LC2;
Reg_7 = *.LC3;
Reg_A = 0;
Reg_B = 72;
Reg_C = 255;

the heuristics are a bit odd here given we don't use pre-init and in the
other cases and thus don't save anything?!

Note I'd rather have the gimplifier use *.LCN aggregate assigns always
and leave the optimization to optimizations (which we obviously have to
improve as can be seen here).

The immediate "refactoring" possible is trying to unify the ctor
emission code in varasm.c and the native_encode stuff.  Then it could
be SRAs job to optimally scalarize the aggregate init.

[Bug ipa/91872] [10 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2877, or ICE in expand_expr_real_1, at expr.c:10062

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||9.2.0
Version|unknown |10.0
   Last reconfirmed||2019-09-24
  Component|middle-end  |ipa
 CC||jamborm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |10.0
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r275982.

[Bug target/91875] Performance drop with mt19937 with -O2/-O3/-Ofast compared to -O1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Martin Liška  ---
Well, using a native ISA (-march=native) gives me on znver1 following numbers
for GCC 9.2.0:

marxin@marxinbox:~/Programming/testcases> g++ pr91875.cc -O1 -march=native &&
./a.out 
float_default: 48.716
float_mt: 33.531
float_mt_64: 81.984
marxin@marxinbox:~/Programming/testcases> g++ pr91875.cc -O1 && ./a.out 
float_default: 48.484
float_mt: 32.037
float_mt_64: 82.632
marxin@marxinbox:~/Programming/testcases> g++ pr91875.cc -Ofast -march=native
&& ./a.out 
float_default: 46.845
float_mt: 20.189
float_mt_64: 66.006

[Bug fortran/91863] [9/10 Regression] ICE in wide_int_to_tree_1, at tree.c:156

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
  Known to work||8.3.0
 Ever confirmed|0   |1
  Known to fail||10.0, 9.2.0

--- Comment #1 from Martin Liška  ---
Started with r269156.

[Bug fortran/91862] [9/10 Regression] ICE in fold_convert_loc, at fold-const.c:2394

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
  Known to work||8.3.0
 Ever confirmed|0   |1
  Known to fail||10.0, 9.2.0

--- Comment #2 from Martin Liška  ---
Started with r269962.

[Bug c++/91877] New: [10 Regression] ICE in convert_like_real, at cp/call.c:7385 since r276058

[marxin at gcc dot gnu.org]

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

Bug ID: 91877
   Summary: [10 Regression] ICE in convert_like_real, at
cp/call.c:7385 since r276058
   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: marxin at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Following is causing ICE now:

$ ./xg++ -B. -fpack-struct
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/dfp/44473-1.C
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/dfp/44473-1.C: In
instantiation of ‘std::vector<_Tp, _Alloc>::const_iterator std::vector<_Tp,
_Alloc>::end() const [with _Tp = std::decimal::decimal32; _Alloc =
std::allocator; std::vector<_Tp,
_Alloc>::const_iterator = __gnu_cxx::__normal_iterator >; typename
std::_Vector_base<_Tp, _Alloc>::_Tp_alloc_type::const_pointer = const
std::decimal::decimal32*]’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/dfp/44473-1.C:95:23:  
required from ‘bool std::vector<_Tp, _Alloc>::empty() const [with _Tp =
std::decimal::decimal32; _Alloc = std::allocator]’
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/dfp/44473-1.C:116:22:  
required from here
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/dfp/44473-1.C:91:14: internal
compiler error: in convert_like_real, at cp/call.c:7385
   91 |   return const_iterator (this->_M_impl._M_finish);
  |  ^~~~
0x8d4064 convert_like_real
../../gcc/cp/call.c:7385
0x8d7709 build_over_call
../../gcc/cp/call.c:8356
0x8dd624 build_new_method_call_1
../../gcc/cp/call.c:9838
0x8ddaa5 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.c:9913
0x8db67d build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/cp/call.c:9351
0x8e3032 perform_direct_initialization_if_possible(tree_node*, tree_node*,
bool, int)
../../gcc/cp/call.c:11255
0xc0dcb8 build_static_cast_1
../../gcc/cp/typeck.c:7250
0xc11330 cp_build_c_cast(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:8047
0xc244d0 build_functional_cast(tree_node*, tree_node*, int)
../../gcc/cp/typeck2.c:2314
0xb4d800 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18461
0xb4b4f0 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17934
0xb43f4a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17046
0xb46930 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17338
0xb6a1c8 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:24784
0xb6ab9e instantiate_pending_templates(int)
../../gcc/cp/pt.c:24900
0x9dffdf c_parse_final_cleanups()
../../gcc/cp/decl2.c:4834
0xcaa8af c_common_parse_file()
../../gcc/c-family/c-opts.c:1183

[Bug c++/91877] [10 Regression] ICE in convert_like_real, at cp/call.c:7385 since r276058

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
  Known to fail||10.0

[Bug ipa/91872] [10 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2877, or ICE in expand_expr_real_1, at expr.c:10062

[asolokha at gmx dot com]

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

--- Comment #2 from Arseny Solokha  ---
Dup of PR91831, then?

[Bug c++/91876] Segmentation fault when comparing std::system_error::code() and std::errc::invalid_argument

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The gdb backtrace shows your program is linked to the wrong libstdc++.so that
comes from the gcc-4.4.7 system compiler, not the one from gcc-7.2.1 that you
compiled with.

See
https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
and
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.html#manual.intro.using.linkage.dynamic

[Bug lto/91870] ICE in ltotests_1.o

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
duplicate

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

[Bug lto/91027] [10 regression] SEGV in hash_table::find_slot_with_hash

[rguenth at gcc dot gnu.org]

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

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

[Bug libstdc++/91871] iterator_to_const_iterator() in testsuite_hooks.h causes valid -Wreturn-stack-address warnings with LLVM

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 Ever confirmed|0   |1

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

[Bug ipa/91872] [10 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2877, or ICE in expand_expr_real_1, at expr.c:10062

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
I'll take the PTA issue.

[Bug ipa/91872] [10 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2877, or ICE in expand_expr_real_1, at expr.c:10062

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
For the PTA issue the first of the 'this' PARM_DECLs "duplicates" comes from

_ZThn16_N12_GLOBAL__N_11B3fooEi.artificial_thunk.0/42
(_ZThn16_N12_GLOBAL__N_11B3fooEi.artificial_thunk.0) @0x769a6438
  Type: function definition analyzed
  Visibility: artificial
  References: _ZN12_GLOBAL__N_1L2goE/1 (write)
  Referring: 
  Availability: local
  Function flags: count:118111600 (estimated locally) body local nonfreeing_fn
  Former thunk fixed offset -16 virtual value 0 indirect_offset 0 has virtual
offset 0
  Called by: int main(int, char**)/24 (955630223 (estimated locally),8.09 per
call) void bar()/23 (955630223 (estimated locally),8.09 per call) 
  Calls: 

and the second

_ZThn16_N12_GLOBAL__N_11B3fooEi/19 (virtual void
{anonymous}::B::_ZThn16_N12_GLOBAL__N_11B3fooEi(int)) @0x769a6ca8
  Type: function definition analyzed
  Visibility: prevailing_def_ironly virtual artificial
  Address is taken.
  References: _ZN12_GLOBAL__N_1L2goE/1 (write)
  Referring: _ZTVN12_GLOBAL__N_11BE/25 (addr)
  Availability: available
  Function flags: count:118111600 (estimated locally) body nonfreeing_fn
  Former thunk fixed offset -16 virtual value 0 indirect_offset 0 has virtual
offset 0
  Called by: 
  Calls: 

both FUNCTION_DECLs share the same DECL_ARGUMENTS, that doesn't look correct?

The duplicate is created by duplicate_thunk_for_node in a new IPA SRA path
but I don't see any DECL_ARGUMENTS adjustment / copying of PARM_DECLs?
Note both thunks above are "analyzed" and thus have a GIMPLE body.

Not a IPA PTA issue but wrong GIMPLE IMHO.

You can see it in pr60640-4.C.082i.materialize-all-clones:

{anonymous}::B::_ZThn16_N12_GLOBAL__N_11B3fooEi (struct BD.2510 * const
thisD.2622)
{
  struct BD.2510 * const adjusted_this.16D.2748;

   [local count: 1]:
  this_2 = this_1(D) + 18446744073709551600;
  adjusted_this.16_3 = this_2;
  {anonymous}::B::*.LTHUNK0 (adjusted_this.16_3); [tail call]
  return;

}

and

{anonymous}::B::_ZThn16_N12_GLOBAL__N_11B3fooEi.artificial_thunk.0 (struct
BD.2510 * const thisD.2622)
{
  struct BD.2510 * const adjusted_this.15D.2745;

   [local count: 1]:
  this_2 = this_1(D) + 18446744073709551600;
  adjusted_this.15_3 = this_2;
  {anonymous}::B::foo.constprop (adjusted_this.15_3); [tail call]
  return;

}

note the same UID for the this PARM_DECL.

[Bug ipa/91872] [10 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2877, or ICE in expand_expr_real_1, at expr.c:10062

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
And indeed the RTL expansion ICE points to the very same issue via

context = decl_function_context (exp);
  gcc_assert (!exp
...
  || context == current_function_decl

[Bug c++/91874] ICE compiling constexpr function using another struct's member as array size in template

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||9.2.0
 Resolution|--- |FIXED
  Known to fail||9.1.0

--- Comment #1 from Richard Biener  ---
Fixed in GCC 9.2.

[Bug middle-end/91866] Sign extend of an int is not recognized

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
I meant something like:
--- gcc/match.pd.jj 2019-09-21 23:53:52.108385196 +0200
+++ gcc/match.pd2019-09-24 10:18:58.804114496 +0200
@@ -2265,8 +2265,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  max_ovf = wi::OVF_OVERFLOW;
 tree inner_type = TREE_TYPE (@0);

-wide_int w1 = wide_int::from (wi::to_wide (@1), TYPE_PRECISION
(inner_type),
-   TYPE_SIGN (inner_type));
+wide_int w1
+ = wide_int::from (wi::to_wide (@1), TYPE_PRECISION (inner_type),
+   TYPE_SIGN (inner_type));

 wide_int wmin0, wmax0;
 if (get_range_info (@0, &wmin0, &wmax0) == VR_RANGE)
@@ -2280,6 +2281,20 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  )))
 #endif

+/* ((T)(A + CST1)) + CST2 -> (T)(A) + (T)CST1 + CST2  */
+#if GIMPLE
+  (for op (plus minus)
+   (simplify
+(plus (convert:s (op:s @0 INTEGER_CST@1)) INTEGER_CST@2)
+ (if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
+ && TREE_CODE (type) == INTEGER_TYPE
+ && TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))
+ && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
+ && !TYPE_OVERFLOW_SANITIZED (TREE_TYPE (@0))
+ && TYPE_OVERFLOW_WRAPS (type))
+   (plus (convert @0) (op @2 (convert @1))
+#endif
+
   /* ~A + A -> -1 */
   (simplify
(plus:c (bit_not @0) @0)

i.e. just handle the case where undefined overflow in the inner op rules out
all problematic cases, with :s to make sure the optimization is actually
beneficial,  that we either replace two original additions with one or with
zero, because it has the drawback that we loose information about the undefined
cases.

[Bug middle-end/91866] Sign extend of an int is not recognized

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #3)
> I meant something like:
> --- gcc/match.pd.jj   2019-09-21 23:53:52.108385196 +0200
> +++ gcc/match.pd  2019-09-24 10:18:58.804114496 +0200
> @@ -2265,8 +2265,9 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> max_ovf = wi::OVF_OVERFLOW;
>  tree inner_type = TREE_TYPE (@0);
>  
> -wide_int w1 = wide_int::from (wi::to_wide (@1), TYPE_PRECISION
> (inner_type),
> - TYPE_SIGN (inner_type));
> +wide_int w1
> +   = wide_int::from (wi::to_wide (@1), TYPE_PRECISION (inner_type),
> + TYPE_SIGN (inner_type));
>  
>  wide_int wmin0, wmax0;
>  if (get_range_info (@0, &wmin0, &wmax0) == VR_RANGE)
> @@ -2280,6 +2281,20 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
>   )))
>  #endif
>  
> +/* ((T)(A + CST1)) + CST2 -> (T)(A) + (T)CST1 + CST2  */
> +#if GIMPLE
> +  (for op (plus minus)
> +   (simplify
> +(plus (convert:s (op:s @0 INTEGER_CST@1)) INTEGER_CST@2)
> + (if (TREE_CODE (TREE_TYPE (@0)) == INTEGER_TYPE
> +   && TREE_CODE (type) == INTEGER_TYPE
> +   && TYPE_PRECISION (type) > TYPE_PRECISION (TREE_TYPE (@0))

>= would also work?

> +   && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
> +   && !TYPE_OVERFLOW_SANITIZED (TREE_TYPE (@0))
> +   && TYPE_OVERFLOW_WRAPS (type))

this last check should not be necessary?

> +   (plus (convert @0) (op @2 (convert @1))
> +#endif
> +
>/* ~A + A -> -1 */
>(simplify
> (plus:c (bit_not @0) @0)
> 
> i.e. just handle the case where undefined overflow in the inner op rules out
> all problematic cases, with :s to make sure the optimization is actually
> beneficial,  that we either replace two original additions with one or with
> zero, because it has the drawback that we loose information about the
> undefined cases.

I don't exactly remember the patch I approved of the referenced series
or if it was applied already but IIRC at least I suggested sth along
the above line (also mentioning the loss of information...)

For the information loss we could add sth like

   (plus:r{range} (convert @0) (op @2 (convert @1

with genmatch setting a precomputed range-info 'range' on the plus
operation result if the target IL has that.  Not sure if worth.

[Bug sanitizer/91878] New: No sanitizer report for past-end access of std∷set

[Hi-Angel at yandex dot ru]

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

Bug ID: 91878
   Summary: No sanitizer report for past-end access of std∷set
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Hi-Angel at yandex dot ru
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

# Steps to reproduce (in terms of terminal commands)

$ cat test2.cpp
#include 
#include 

int main() {
std::set s{};
printf("%i\n", *s.begin());
}
$ g++ test2.cpp -o a -g3 -O0 -fsanitize=address,undefined
$ ./a

## Expected

It either crashes on past-end access, or produces a warning (depending on
whether it's handled as a past-end access or UB).

## Actual

It prints:

0

[Bug sanitizer/91878] No sanitizer report for past-end access of std∷set

[Hi-Angel at yandex dot ru]

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

--- Comment #1 from Konstantin Kharlamov  ---
Btw, worth noting that clang 8.0.1 does not handle it either.

[Bug sanitizer/91878] No sanitizer report for past-end access of std∷set

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, we're slowly adding instrumentation for std containers to
sanitizers.

[Bug sanitizer/91878] No sanitizer report for past-end access of std∷set

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
-D_GLIBCXX_DEBUG is the current way to add many checks to libstdc++, and it
detects this.

[Bug sanitizer/91878] No sanitizer report for past-end access of std∷set

[Hi-Angel at yandex dot ru]

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

--- Comment #4 from Konstantin Kharlamov  ---
(In reply to Marc Glisse from comment #3)
> -D_GLIBCXX_DEBUG is the current way to add many checks to libstdc++, and it
> detects this.

Oh, cool, I'll make use of it, thanks for the hint!

[Bug sanitizer/91878] No sanitizer report for past-end access of std∷set

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Jonathan Wakely  ---
(In reply to Konstantin Kharlamov from comment #0)
> It either crashes on past-end access, or produces a warning (depending on
> whether it's handled as a past-end access or UB).

No, that's not how undefined behaviour works. You are wrong to expect a crash,
and not all cases of undefined behaviour can be detected reliably.

I don't think this case can be caught by sanitizers. As Marc said (and as I
suggested on your previous bug report) you should use -D_GLIBCXX_DEBUG to catch
these kind of bugs.

[Bug rtl-optimization/91860] [10 Regression] ICE: in decompose, at rtl.h:2279 with -Og -fipa-cp -g --param=max-combine-insns=3

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #3 from David Binderman  ---
I am seeing something similar for a kernel build on raspberry pi.

[Bug sanitizer/91878] No sanitizer report for past-end access of std∷set

[Hi-Angel at yandex dot ru]

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

--- Comment #6 from Konstantin Kharlamov  ---
(In reply to Jonathan Wakely from comment #5)

> No, that's not how undefined behaviour works. You are wrong to expect a crash

No, in context of the report I'm not. You're correct this is not how UB works,
but this is how address sanitizer does.

> and not all cases of undefined behaviour can be detected reliably.

Well, given -D_GLIBCXX_DEBUG does handle it, probably sanitizer can either.

> As Marc said (and as I suggested on your previous bug report) you should use
> -D_GLIBCXX_DEBUG to catch these kind of bugs.

Right, thanks, FTR: my prev. report was handled by sanitizer correctly, so back
then I wouldn't need to use the additional debugging option.

[Bug sanitizer/91878] No sanitizer report for past-end access of std∷set

[Hi-Angel at yandex dot ru]

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

--- Comment #7 from Konstantin Kharlamov  ---
@Jonathan Wakely I think you accidentally closed the report, would you mind to
reopen it (I'm not seeing why would it be "invalid", people even confirmed that
more support for std containers is being added to sanitizers).

[Bug sanitizer/91878] No sanitizer report for past-end access of std∷set

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Konstantin Kharlamov from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> 
> > No, that's not how undefined behaviour works. You are wrong to expect a 
> > crash
> 
> No, in context of the report I'm not. You're correct this is not how UB
> works, but this is how address sanitizer does.

The past-the-end iterator of a std::set doesn't point to the heap, and points
to a valid object that is always readable. I don't see how asan can help here.

> > and not all cases of undefined behaviour can be detected reliably.
> 
> Well, given -D_GLIBCXX_DEBUG does handle it, probably sanitizer can either.

No, I don't agree. They work very differently.

Closing the bug was not an accident, I don't believe there are any plans to add
asan instrumentation to std::set, and I don't believe it's possible to handle
the past-the-end case.

[Bug sanitizer/91878] No sanitizer report for past-end access of std∷set

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |WONTFIX

--- Comment #9 from Jonathan Wakely  ---
I'll call it WONTFIX rather than INVALID if you prefer, but it's not going to
be handled by asan either way.

[Bug libstdc++/91871] iterator_to_const_iterator() in testsuite_hooks.h causes valid -Wreturn-stack-address warnings with LLVM

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 24 10:09:18 2019
New Revision: 276091

URL: https://gcc.gnu.org/viewcvs?rev=276091&root=gcc&view=rev
Log:
PR libstdc++/91871 fix Clang warnings in testsuite

PR libstdc++/91871
* testsuite/util/testsuite_hooks.h
(conversion::iterator_to_const_iterator()): Do not return an invalid
iterator. Test direct-initialization and direct-list-initialization
as well as implicit conversion.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/util/testsuite_hooks.h

[Bug libstdc++/91871] iterator_to_const_iterator() in testsuite_hooks.h causes valid -Wreturn-stack-address warnings with LLVM

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
I haven't tested with Clang, but it should be fixed now. Please reopen if not.

[Bug other/91879] New: DESTDIR support seems incomplete

[stsp at users dot sourceforge.net]

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

Bug ID: 91879
   Summary: DESTDIR support seems incomplete
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stsp at users dot sourceforge.net
  Target Milestone: ---

Hello.

I tried to build gcc with non-empty DESTDIR.
It fails on libquadmath:

In file included from ../../../gnu/gcc-9.2.0/libquadmath/math/x2y2m1q.c:19:
../../../gnu/gcc-9.2.0/libquadmath/quadmath-imp.h:24:10: fatal error: errno.h:
No such file or directory
   24 | #include 
  |  ^

The problem is that the system headers are searched in a
prefix path that doesn't account for DESTDIR. This is because
of the explicit -isystem in the command line. I looked at a
build system and found that -isystem is built from the "tooldir"
variable of the configure script. So I made the following change
to confirm my findings:

--- configure.ac.old2019-09-24 03:44:28.141779422 +0300
+++ configure.ac2019-09-24 03:30:59.022308759 +0300
@@ -2572,7 +2572,7 @@

 # Some systems (e.g., one of the i386-aix systems the gas testers are
 # using) don't handle "\$" correctly, so don't use it here.
-tooldir='${exec_prefix}'/${target_noncanonical}
+tooldir='${DESTDIR}${exec_prefix}'/${target_noncanonical}
 build_tooldir=${tooldir}

 # Create a .gdbinit file which runs the one in srcdir


And with that change the build worked.
So I suppose this is a build system bug.

[Bug ipa/91832] [10 Regression] ICE in scan_expr_access, at ipa-sra.c:1695 since r275982

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
Author: jamborm
Date: Tue Sep 24 11:16:57 2019
New Revision: 276093

URL: https://gcc.gnu.org/viewcvs?rev=276093&root=gcc&view=rev
Log:
[PR 91832] Do not ICE on negative offsets in ipa-sra

Hi,

IPA-SRA asserts that an offset obtained from get_ref_base_and_extent
is non-negative (after it verifies it is based on a parameter).  That
assumption is invalid as the testcase shows.  One could probably also write a
testcase with defined behavior, but unless I see a reasonable one
where the transformation is really desirable, I'd like to just punt on
those cases.

Bootstrapped and tested on x86_64-linux.  OK for trunk?

Thanks,

Martin

2019-09-24  Martin Jambor  

PR ipa/91832
* ipa-sra.c (scan_expr_access): Check that offset is non-negative.

testsuite/
* gcc.dg/ipa/pr91832.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/ipa/pr91832.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-sra.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68858] Cannot use fold expression in requirements with two parameters packs

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #2 from Jeff Chapman  ---
Created attachment 46921
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46921&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

It does seem likely that this was the same issue as 68812; regardless both now
work on concepts-cxx2a. Patch adds a test for this case.

[Bug ipa/91831] [10 Regression] ICE in expand_expr_real_1, at expr.c:10062 after r275982

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Author: jamborm
Date: Tue Sep 24 11:20:57 2019
New Revision: 276094

URL: https://gcc.gnu.org/viewcvs?rev=276094&root=gcc&view=rev
Log:
[PR 91831] Copy PARM_DECLs of artificial thunks

Hi,

I am quite surprised I did not catch this before but the new
ipa-param-manipulation does not copy PARM_DECLs when creating
artificial thinks (I think it originally did but then I somehow
removed during one cleanups).  Fixed by adding the capability at the
natural place.  It is triggered whenever context of the PARM_DECL that
is just taken from the original function does not match the target
fndecl rather than by some constructor parameter because in such
situation it is always the correct thing to do.

Bootstrapped and tested on x86_64-linux.  OK for trunk?

Thanks,

Martin

2019-09-24  Martin Jambor  

PR ipa/91831
* ipa-param-manipulation.c (carry_over_param): Make a method of
ipa_param_body_adjustments, remove now unnecessary argument.  Also copy
in case of a context mismatch.
(ipa_param_body_adjustments::common_initialization): Adjust call to
carry_over_param.
* ipa-param-manipulation.h (class ipa_param_body_adjustments): Add
private method carry_over_param.

testsuite/
* g++.dg/ipa/pr91831.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/ipa/pr91831.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-param-manipulation.c
trunk/gcc/ipa-param-manipulation.h
trunk/gcc/testsuite/ChangeLog

[Bug ipa/91831] [10 Regression] ICE in expand_expr_real_1, at expr.c:10062 after r275982

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #4 from Martin Jambor  ---
*** Bug 91872 has been marked as a duplicate of this bug. ***

[Bug ipa/91872] [10 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2877, or ICE in expand_expr_real_1, at expr.c:10062

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Martin Jambor  ---
(In reply to Arseny Solokha from comment #2)
> Dup of PR91831, then?

Yes, should be fixed now.

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

[Bug other/91879] DESTDIR support seems incomplete

[harald at gigawatt dot nl]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #1 from Harald van Dijk  ---
DESTDIR is meant to install to a specific directory in such a way that the
contents of that directory can then be moved or copied to the location the
software will be run from, typically by a package manager creating an archive
from the DESTDIR directory and extracting it elsewhere. It is not supposed to
be used at configure time to pick up other software, only at install time to
determine the location to install into.

The ways to handle libc being installed in non-standard locations depend on
your specific use case. GCC provides the --with-sysroot and
--with-native-system-header-dir configure options, documented at
. If you need more info on what
they do, or if they do not handle your use case, the mailing lists are a better
place to ask first than Bugzilla. You can get help in seeing whether GCC
already supports your use case in a different way than you're trying now, and
if not and you want to report that as a bug, what details would need to be
included.

[Bug target/91880] New: ICE: segfault in hwloop_optimize

[jcmvbkbc at gcc dot gnu.org]

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

Bug ID: 91880
   Summary: ICE: segfault in hwloop_optimize
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jcmvbkbc at gcc dot gnu.org
  Target Milestone: ---

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

gcc built for xtensa call0 ABI and invoked with the attached source and the
following command line segfaults in hwloop_optimize:

cc1 -mlongcalls -mauto-litpools -Os -O3 -std=c11 -fomit-frame-pointer -fPIC
-fno-math-errno -fno-signed-zeros -fno-tree-vectorize vp9dsp_8bpp.i

[Bug other/91879] DESTDIR support seems incomplete

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Stas Sergeev from comment #0)
> Hello.
> 
> I tried to build gcc with non-empty DESTDIR.

What exact commands did you run?

I don't see why DESTDIR should matter until the 'make install' step.

[Bug c++/91877] [10 Regression] ICE in convert_like_real, at cp/call.c:7385 since r276058

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/69235] [concepts] Spurious ambiguous template instantiation error on oppositely constrained class template specializations

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #1 from Jeff Chapman  ---
Created attachment 46923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46923&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug other/91879] DESTDIR support seems incomplete

[stsp at users dot sourceforge.net]

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

--- Comment #3 from Stas Sergeev  ---
(In reply to Harald van Dijk from comment #1)
> archive from the DESTDIR directory and extracting it elsewhere. It is not
> supposed to be used at configure time to pick up other software, only at
> install time to determine the location to install into.

Yes, I understand that.
And yet what I see is that when gcc is building its libs,
it looks for the system headers under prefix, not under destdir.
But you are right, I probably should try mail list for
the help with that.

(In reply to Jonathan Wakely from comment #2)
> (In reply to Stas Sergeev from comment #0)
> > Hello.
> > 
> > I tried to build gcc with non-empty DESTDIR.
> 
> What exact commands did you run?

I have the script that runs basically "make all-gcc" and
"make" after setting some env vars. And what fails is the
plain "make" step. I can show you how exactly:
---
libtool: compile: 
/home/stas/src/build-gcc/build/djcross-gcc-9.2.0/djcross/./gcc/xgcc
-B/home/stas/src/build-gcc/build/djcross-gcc-9.2.0/djcross/./gcc/
-B/usr/local/cross/i586-pc-msdosdjgpp/bin/
-B/usr/local/cross/i586-pc-msdosdjgpp/lib/ -isystem
/usr/local/cross/i586-pc-msdosdjgpp/include -isystem
/usr/local/cross/i586-pc-msdosdjgpp/sys-include -DHAVE_CONFIG_H -I.
-I../../../gnu/gcc-9.2.0/libquadmath -I
../../../gnu/gcc-9.2.0/libquadmath/../include -g -O2 -MT math/x2y2m1q.lo -MD
-MP -MF math/.deps/x2y2m1q.Tpo -c
../../../gnu/gcc-9.2.0/libquadmath/math/x2y2m1q.c -o math/x2y2m1q.o
In file included from ../../../gnu/gcc-9.2.0/libquadmath/math/x2y2m1q.c:19:
../../../gnu/gcc-9.2.0/libquadmath/quadmath-imp.h:24:10: fatal error: errno.h:
No such file or directory
   24 | #include 
  |  ^
compilation terminated.
---

> I don't see why DESTDIR should matter until the 'make install' step.

Please note the
-isystem /usr/local/cross/i586-pc-msdosdjgpp/include -isystem
/usr/local/cross/i586-pc-msdosdjgpp/sys-include

above. Clearly it misses the DESTDIR, and feeding the
DESTDIR there makes the problem to go away.

[Bug c++/78752] [concepts] ICE with constrained variadic member function

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #2 from Jeff Chapman  ---
The original ICE is fixed on concepts-cxx2a. However, constraint satisfaction
still fails for the abbreviated function template version. It fails for both
free and member functions and for both regular and variadic concepts.

[Bug middle-end/91866] Sign extend of an int is not recognized

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Sep 24 12:45:13 2019
New Revision: 276096

URL: https://gcc.gnu.org/viewcvs?rev=276096&root=gcc&view=rev
Log:
PR middle-end/91866
* match.pd (((T)(A)) + CST -> (T)(A + CST)): Formatting fix.
(((T)(A + CST1)) + CST2 -> (T)(A) + (T)CST1 + CST2): New optimization.

* gcc.dg/tree-ssa/pr91866.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr91866.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/91866] Sign extend of an int is not recognized

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Should be implemented for GCC 10+.

[Bug c++/90825] [9 Regression] g++: internal compiler error: Segmentation fault signal terminated program cc1plus

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||qux at gmail dot com

--- Comment #8 from Jakub Jelinek  ---
*** Bug 91874 has been marked as a duplicate of this bug. ***

[Bug c++/91874] ICE compiling constexpr function using another struct's member as array size in template

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Resolution|FIXED   |DUPLICATE

--- Comment #2 from Jakub Jelinek  ---
Looks like PR90825.

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

[Bug c++/91877] [10 Regression] ICE in convert_like_real, at cp/call.c:7385 since r276058

[mpolacek at gcc dot gnu.org]

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

--- Comment #1 from Marek Polacek  ---
Candidate fix:

--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -7382,8 +7382,7 @@ convert_like_real (conversion *convs, tree expr, tree fn,
int argnum,
tree type = TREE_TYPE (ref_type);
cp_lvalue_kind lvalue = lvalue_kind (expr);

-   gcc_assert (same_type_ignoring_top_level_qualifiers_p
-   (type, next_conversion (convs)->type));
+   gcc_assert (similar_type_p (type, next_conversion (convs)->type));
if (!CP_TYPE_CONST_NON_VOLATILE_P (type)
&& !TYPE_REF_IS_RVALUE (ref_type))
  {

[Bug c++/79759] [concepts] ICE in tsubst, at cp/pt.c:13509

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #3 from Jeff Chapman  ---
Created attachment 46924
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46924&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This and the related PRs appear to be fixed on concepts-cxx2a. Patch adds a
test for this PR.

[Bug c++/91877] [10 Regression] ICE in convert_like_real, at cp/call.c:7385 since r276058

[mpolacek at gcc dot gnu.org]

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

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

template  class b {
public:
  b(const a &);
};
struct {
  int *c;
} d;
void e() { b(d.c); }

[Bug target/91816] Arm generates out of range conditional branches in Thumb2

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 Ever confirmed|0   |1

[Bug middle-end/91881] New: Value range knowledge of higher bits not used in optimizations

[antoshkka at gmail dot com]

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

Bug ID: 91881
   Summary: Value range knowledge of higher bits not used in
optimizations
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:

unsigned long long sample2(unsigned long long m) {
if (m >= 100) __builtin_unreachable();
m *= 16;
return m >> 3;
}

After the `if` statement we do know that the higher bits are set to 0. So
instead of generating the following assembly:

sample2(unsigned long long):
  mov rax, rdi
  sal rax, 4
  shr rax, 3
  ret

A more optimal assembly could be generated:

sample2(unsigned long long):
  lea rax, [rdi + rdi]
  ret


Godbolt playground: https://godbolt.org/z/1iSpTh

P.S.: that optimization is important for std::to_chars(..., double) like
functions, where a significant of a double is extracted into an unsigned long
long variable, so its upper bits are always zero.

[Bug c++/91222] [10 Regression] 507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571

[marxin at gcc dot gnu.org]

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

--- Comment #18 from Martin Liška  ---
I would like to see this also fixed. But I know Honza has some comments about
the patch. Honza?

[Bug tree-optimization/91882] New: boolean XOR tautology missed optimisation

[SztfG at yandex dot ru]

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

Bug ID: 91882
   Summary: boolean XOR tautology missed optimisation
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SztfG at yandex dot ru
  Target Milestone: ---

This functions is always return true regardless of the value of the arguments:

bool bool_xor_test(bool a, bool b)
{
  return (a != b) == ((a || b) && !(a && b));
}

bool bool_xor_test2(bool a, bool b)
{
  return (a ^ b) == ((a || b) && !(a && b));
}

but compiler does not simplify to "return true;". Expression ((a || b) && !(a
&& b)) poorly optimized


BUT! In this case:
bool xor_test_unsigned_int(unsigned int a, unsigned int b)
{
  return (a ^ b) == ((a | b) & ~(a & b));
}

It actually simlified to "return true;" :

movl$1, %eax
ret

[Bug middle-end/91883] New: Division by a constant could be optimized for known variables value range

[antoshkka at gmail dot com]

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

Bug ID: 91883
   Summary: Division by a constant could be optimized for known
variables value range
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

Consider the example:

unsigned long long kBorder = (1ull<<62);

unsigned long long sample(unsigned long long m) {
if (m >= kBorder) __builtin_unreachable();
return m / 10;
}

It produces the following assembly:

sample(unsigned long long):
  movabs rdx, -3689348814741910323
  mov rax, rdi
  mul rdx
  mov rax, rdx
  shr rax, 3
  ret

However, knowing that the higher bits are always 0, the constant could be
adjusted to avoid the `shr rax, 3`:

sample(unsigned long long):
  movabs rax, 1844674407370955162
  mul rdi
  mov rax, rdx
  ret

Godbolt playground: https://godbolt.org/z/YU2yAC

This issue is probably related to PR 91881

P.S.: that optimization is important for std::to_chars(..., double) like
functions, where a significant of a double is extracted into an unsigned long
long variable, so its upper bits are always zero.

[Bug tree-optimization/91882] boolean XOR tautology missed optimisation

[SztfG at yandex dot ru]

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

--- Comment #1 from SztfG at yandex dot ru ---
Similar problem with other tautology:

unsigned int impl_bit(unsigned int a, unsigned int b) // bitwise implication
{
  return (~a | b);
}

unsigned int eq_bit(unsigned int a, unsigned int b) // bitwise equivalence
{
  return (~a ^ b);
}

// good optimisation - "return 1;"
unsigned int always_true(unsigned int a, unsigned int b)
{
  return eq_bit(impl_bit(a,b), impl_bit(b,a)) == eq_bit(a, b); // ( (a -> b) =
(b -> a) ) = (a = b) tautology
}



bool impl_bool(bool a, bool b
{
return (!a || b);
}

// bad optimisation
bool always_true(bool a, bool b)
{
return (impl(a,b) == impl(b,a)) == (a == b); // ( (a -> b) = (b -> a) ) =
(a = b) tautology
}

[Bug c++/91845] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_m_component_ref, at cp/typeck2.c:2086

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Tue Sep 24 14:38:53 2019
New Revision: 276102

URL: https://gcc.gnu.org/viewcvs?rev=276102&root=gcc&view=rev
Log:
PR c++/91845 - ICE with invalid pointer-to-member.
* expr.c (mark_use): Use error_operand_p.
* typeck2.c (build_m_component_ref): Check error_operand_p after
calling mark_[lr]value_use.

* g++.dg/cpp1y/pr91845.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr91845.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/expr.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/91868] wrong location info with -Wshadow on C++ constructors

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue Sep 24 14:40:24 2019
New Revision: 276103

URL: https://gcc.gnu.org/viewcvs?rev=276103&root=gcc&view=rev
Log:
PR c++/91868 - improve -Wshadow location.
* name-lookup.c (check_local_shadow): Use DECL_SOURCE_LOCATION
instead of input_location.

* g++.dg/warn/Wshadow-16.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wshadow-16.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/80746] [concepts] ICE evaluating constraints for concepts with dependent template parameters

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #4 from Jeff Chapman  ---
Created attachment 46925
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46925&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This and the related PRs appear to be fixed on concepts-cxx2a. Patch adds a
test for this PR.

[Bug c++/91868] wrong location info with -Wshadow on C++ constructors

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/91845] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_m_component_ref, at cp/typeck2.c:2086

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed for GCC 10.

[Bug c++/80773] [Concepts] Internal Compiler error on template parameter pack expansion

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #2 from Jeff Chapman  ---
Created attachment 46926
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46926&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug testsuite/91884] New: libgomp testsuite: (not) using a specific driver for C++, Fortran

[tschwinge at gcc dot gnu.org]

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

Bug ID: 91884
   Summary: libgomp testsuite: (not) using a specific driver for
C++, Fortran
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

This is to keep track of the discussion started in
, where I propose to
change libgomp testsuite to use a specific driver for C++, Fortran testing,
instead of re-inventing what these drivers are doing, using 'gcc' with flags
such as '-lgfortran'.

In the first follow-up message, I had posted a set of patches.  These are still
valid, hopefully, and can be used to complete this task, if we agree that's the
way to go.

(I don't think I ever figured out the reason for the current setup, where
libgomp testing is not using a specific driver for C++, Fortran?)

[Bug testsuite/91884] libgomp testsuite: (not) using a specific driver for C++, Fortran

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
One stopgap patch is
,
to un-break libgomp Fortran testing in a context where '-lquadmath' is not
automatically deduced from '-lgfortran' in a cross-compilation setting.

[Bug c++/82507] [concepts] premature substitution into constraint of non-template member function

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #3 from Jeff Chapman  ---
Created attachment 46927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46927&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug libstdc++/91871] iterator_to_const_iterator() in testsuite_hooks.h causes valid -Wreturn-stack-address warnings with LLVM

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90905

--- Comment #5 from Martin Sebor  ---
If the template is instantiated it should be diagnosed by -Wreturn-local-addr,
but it isn't.  Bug 90905 tracks that limitation.

[Bug c++/49974] missing -Wreturn-local-addr for indirectly returning reference to local/temporary

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90905

--- Comment #15 from Martin Sebor  ---
GCC 10 issues two warnings for the first test case in comment #0:

pr49974.C: In function ‘const X& g()’:
pr49974.C:8:15: warning: function returns address of local variable
[-Wreturn-local-addr]
8 | return f(x);  // !!!
  |   ^
pr49974.C:7:7: note: declared here
7 | X x;
  |   ^
In function ‘const X& h()’:
cc1plus: warning: function returns address of local variable
[-Wreturn-local-addr]
pr49974.C:7:7: note: declared here


The second test case is not diagnosed (due to a similar problem as pr90905). 
The test cases in comment #8  are also not diagnosed.

[Bug libstdc++/91871] iterator_to_const_iterator() in testsuite_hooks.h causes valid -Wreturn-stack-address warnings with LLVM

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Or maybe it's bug 49974, depending on what type the template is instantiated
on.

[Bug tree-optimization/91885] New: ICE when compiling SPEC 2017 blender benchmark with -O3 -fprofile-generate

[sje at gcc dot gnu.org]

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

Bug ID: 91885
   Summary: ICE when compiling SPEC 2017 blender benchmark with
-O3 -fprofile-generate
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sje at gcc dot gnu.org
  Target Milestone: ---

When compiling the SPEC 2017 526.blender_r benchmark for peak, the compilation
that tries to generate profile information aborts with an ICE.  This happens to
me on an Aarch64 machine (ThunderX2) with -O3 -fprofile-generate.  Below is a
small testcase cutdown from blender that shows the ICE.


% /extra/sellcey/gcc-tot/install/bin/gcc -O3 -fprofile-generate x.i
during GIMPLE pass: vect
x.i: In function 'IMB_indexer_open':
x.i:18:20: internal compiler error: in execute_todo, at passes.c:2032
   18 | struct anim_index *IMB_indexer_open(const char *name) {
  |^~~~
0xb87933 execute_todo
../../gcc/gcc/passes.c:2032
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

% cat x.i
typedef signed long int __int64_t;
typedef unsigned long int __uint64_t;
typedef __int64_t int64_t;
typedef __uint64_t uint64_t;
inline void BLI_endian_switch_int64(int64_t *val) {
  uint64_t tval = *val;
  *val = ((tval >> 56)) | ((tval << 40) & 0x00ffll) | ((tval << 24)
& 0xff00ll) | ((tval << 8) & 0x00ffll) | ((tval >> 8) &
0xff00ll) | ((tval >> 24) & 0x00ffll) | ((tval >> 40) &
0xff00ll) | ((tval << 56));
}
typedef struct anim_index_entry {
  unsigned long long seek_pos_dts;
  unsigned long long pts;
} anim_index_entry;
extern struct anim_index_entry *MEM_callocN(int);
struct anim_index {
  int num_entries;
  struct anim_index_entry *entries;
};
struct anim_index *IMB_indexer_open(const char *name) {
  char header[13];
  struct anim_index *idx;
  int i;
  idx->entries = MEM_callocN(8);
  if (((1 == 0) != (header[8] == 'V'))) {
   for (i = 0; i < idx->num_entries; i++) {
BLI_endian_switch_int64((int64_t *)&idx->entries[i].seek_pos_dts);
BLI_endian_switch_int64((int64_t *)&idx->entries[i].pts);
   }
  }
}

[Bug c++/82740] [concepts] requires clause evaluated early

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #1 from Jeff Chapman  ---
Created attachment 46928
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46928&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug c++/82794] ICE: Cannot allocate memory for concept with default argument

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #3 from Jeff Chapman  ---
Created attachment 46929
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46929&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug c++/84140] Inline friends are not constrained by concepts

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #3 from Jeff Chapman  ---
Created attachment 46930
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46930&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug other/91879] DESTDIR support seems incomplete

[stsp at users dot sourceforge.net]

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

--- Comment #4 from Stas Sergeev  ---
(In reply to Harald van Dijk from comment #1)
> The ways to handle libc being installed in non-standard locations depend on
> your specific use case. GCC provides the --with-sysroot and
> --with-native-system-header-dir configure options,

These ones specify the locations permanently.
My problem is that I need a different sysroot/system-header-dir
only for the time of building the gcc libs.
This is when DESTDIR is set. When the package
is installed on the target, then DESTDIR is
unset and the prefix locations should be used.
So I think the options you pointed, do not help
in my case. Somehow I need the build system to
pick up DESTDIR while building its libs.

If I could pass the variable name to --with-native-system-header-dir,
like -with-native-system-header-dir=\$DESTDIR/somedir
(dollar is "escaped" in that example to not expand immediately)
then that would work, but I don't suppose passing
the variable name is possible?

[Bug c++/85241] Requires-expressions, fold expressions, and member function templates with dependent parameters don't play nicely

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #4 from Jeff Chapman  ---
Created attachment 46931
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46931&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This and the related PR appear to be fixed on concepts-cxx2a. Patch adds a test
for this PR.

[Bug c++/85808] [concepts] unqualified name lookup breaks after qualified lookup in nested requirement

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #1 from Jeff Chapman  ---
Created attachment 46932
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46932&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug c++/86000] ICE with requires statement in a non constexpr if

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #3 from Jeff Chapman  ---
Created attachment 46933
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46933&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug c++/86269] [concepts] ICE with intermediate concepts notation

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #2 from Jeff Chapman  ---
Created attachment 46934
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46934&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug c++/87441] [concepts] Found compiler internal error: in tsubst at cp/pt.c:13657

[jeff.chapman.bugs at gmail dot com]

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

Jeff Chapman  changed:

   What|Removed |Added

 CC||jeff.chapman.bugs at gmail dot 
com

--- Comment #4 from Jeff Chapman  ---
Created attachment 46935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46935&action=edit
Patch against concepts-cxx2a to add test (git format-patch format)

This appears to be fixed on concepts-cxx2a. Patch adds a test for the PR.

[Bug target/91886] New: [10 regression] powerpc64 impossible register constraint in asm

[nsz at gcc dot gnu.org]

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

Bug ID: 91886
   Summary: [10 regression] powerpc64 impossible register
constraint in asm
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

this used to work for me:

double fmax(double x, double y)
{
__asm__ ("xsmaxdp %x0, %x1, %x2" : "=ws"(x) : "ws"(x), "ws"(y));
return x;
}

compiled to

fmax:
xsmaxdp 1, 1, 2
    blr

now (gcc version 10.0.0 20190924) i get

fmax.c: In function 'fmax':
fmax.c:3:2: error: impossible constraint in 'asm'
3 |  __asm__ ("xsmaxdp %x0, %x1, %x2" : "=ws"(x) : "ws"(x), "ws"(y));
  |  ^~~

[Bug rtl-optimization/91865] Combine misses opportunity to remove (sign_extend (zero_extend)) before searching for insn patterns

[jozefl.gcc at gmail dot com]

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

--- Comment #2 from Jozef Lawrynowicz  ---
A related issue can be observed if "char i" is made global instead of an
argument to func.

const int table[2] = {1, 2};

int foo;
char i;

void func(void)
{
  foo = table[i];
}

Combine combines the zero_extend and sign_extend insns into a single
(sign_extend(subreg)) insn:

Trying 6 -> 7:
6: r27:HI=zero_extend([`i'])
7: r28:PSI=sign_extend(r27:HI)#0
  REG_DEAD r27:HI
Failed to match this instruction:
(set (reg:PSI 28 [ i ])
(sign_extend:PSI (subreg:HI (mem/c:QI (symbol_ref:PSI ("i")

As far as I'm aware, this is a "discouraged" use of subreg, but also means we
miss out on the best match.

Note that the subreg in the combined instruction is unrelated to the subreg
that is the rvalue of insn 7. The subreg in insn 7 is from the RTL pattern for
extendhipsi2.
To avoid any confusion I've attached a one line patch
(msp430-extendhispsi2.diff) which removes the the subreg from this RTL insn
pattern, yet the the subreg in the insn combine searches for remains. Here is
the output from combine with the patch (note the the lack of subreg in insn 7):

Trying 6 -> 7:  
6: r27:HI=zero_extend([`i'])
7: r28:PSI=sign_extend(r27:HI)  
  REG_DEAD r27:HI   
Successfully matched this instruction:  
(set (reg:PSI 28 [ i ]) 
(sign_extend:PSI (subreg:HI (mem/c:QI (symbol_ref:PSI ("i")
allowing combination of insns 6 and 7   
original costs 16 + 8 = 24  
replacement cost 20 
deferring deletion of insn with uid = 6.
modifying insn i3 7: r28:PSI=sign_extend([`i']#0)   
deferring rescan insn with uid = 7.

Even though we matched, it is undesirable since we matched the costly
"extendhipsi2".
We want to match movqipsi2, which would happen if:
(sign_extend:PSI (zero_extend:HI (mem:QI))) -> (zero_extend:PSI (mem:QI))

P.S. I believe the subreg in some of the msp430 RTL patterns is because of
historical issues with reload and/or optimization tweaks. The attached patch is
just to clarify the behaviour I mentioned and not necessarily beneficial
overall.

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[h2+bugs at fsfe dot org]

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

--- Comment #8 from Hannes Hauswedell  ---
Anything I can do to help resolve this? We have library code that breaks
because of the issue and since 9.2 is deployed everywhere that 9.1 was used,
this is very disruptive...

Thank you!

[Bug rtl-optimization/91865] Combine misses opportunity to remove (sign_extend (zero_extend)) before searching for insn patterns

[jozefl.gcc at gmail dot com]

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

--- Comment #3 from Jozef Lawrynowicz  ---
Created attachment 46936
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46936&action=edit
msp430-extendhipsi2.diff

[Bug other/91879] DESTDIR support seems incomplete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-09-24
 Ever confirmed|0   |1

--- Comment #5 from Jonathan Wakely  ---
(In reply to Stas Sergeev from comment #3)
> And yet what I see is that when gcc is building its libs,
> it looks for the system headers under prefix, not under destdir.

Which makes sense, since the system headers are not part of GCC itself, so why
would it expect them in the temporary staging area for GCC's own files?


> (In reply to Jonathan Wakely from comment #2)
> > (In reply to Stas Sergeev from comment #0)
> > > Hello.
> > > 
> > > I tried to build gcc with non-empty DESTDIR.
> > 
> > What exact commands did you run?
> 
> I have the script that runs basically "make all-gcc" and
> "make" after setting some env vars. And what fails is the
> plain "make" step. I can show you how exactly:

You didn't show how. What exact commands did you run?

I'm not interested in the libtool command that GCC runs, I want to know what
your script does. Not what it runs basically, but precisely. The configure
command, and the make commands.

> Please note the
> -isystem /usr/local/cross/i586-pc-msdosdjgpp/include -isystem
> /usr/local/cross/i586-pc-msdosdjgpp/sys-include
> 
> above. Clearly it misses the DESTDIR, and feeding the
> DESTDIR there makes the problem to go away.

The GNU coding standards specifically say "DESTDIR should be supported only in
the install* and uninstall* targets, as those are the only targets where it is
useful." -- https://www.gnu.org/prep/standards/html_node/DESTDIR.html

So if you need it defined before that step, you're doing something wrong. We
can't tell what you're doing wrong, because you haven't said what you're doing.

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 Ever confirmed|0   |1

--- Comment #9 from Marek Polacek  ---
Confirming that latest GCC 9 still ICEs.

[Bug other/91879] DESTDIR support seems incomplete

[stsp at users dot sourceforge.net]

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

--- Comment #6 from Stas Sergeev  ---
(In reply to Jonathan Wakely from comment #5)
> Which makes sense, since the system headers are not part of GCC itself, so
> why would it expect them in the temporary staging area for GCC's own files?

OK, I understand.
But then its a bit unclear to me how to build
the cross-compiler. I build both gcc and its libs
on the host, so somehow I need to provide it with
the location of the headers _on host_, which is
different with what will it be later on the target.

> You didn't show how. What exact commands did you run?
If only that would be so easy to tell with the script I have. :)

> I'm not interested in the libtool command that GCC runs, I want to know what
> your script does. Not what it runs basically, but precisely. The configure
> command, and the make commands.
OK, still "basically", but hopefully more informative than before:
---
export DESTDIR=/path/to/somedir
cd builddir

../gnu/gcc-9.2.0/configure --disable-plugin --enable-lto --disable-libssp --
disable-nls --enable-libquadmath-support --enable-version-specific-runtime-libs
--enable-fat --enable-libstdcxx-filesystem-ts --target=i586-pc-msdosdjgpp
--pref
ix=/usr/local/cross --enable-languages=c,c++

make all-gcc
make install-gcc
make [ fails here ]
make install-strip
---

Some things are still stripped, as the script also
sets pathes after make install-gcc and does some other
things. If this is still not enough, I'll work on a
minimal reproducer.

> So if you need it defined before that step, you're doing something wrong. We
> can't tell what you're doing wrong, because you haven't said what you're
> doing.

I am trying to get this build script to work:
https://github.com/stsp/build-gcc/tree/master
to build djgpp tool-chain w/o root privs.
The current strategy of that script is to install
built gcc on host (needs root), then build gcc libs
from there. I want to confine it to the DESTDIR,
including the headers installation, so the way I
run that script (I don't expect you are going to try
it yourself of course):
---
QUIET=1 DESTDIR=`pwd`/ttt ./build-djgpp.sh gcc-9.2.0
---

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[mpolacek at gcc dot gnu.org]

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

--- Comment #10 from Marek Polacek  ---
r266816 is already present gcc-9-branch but it didn't fix the ICE.  I'm afraid
it's r272125, but alas that doesn't seem to be backportable.

[Bug c++/91607] [9 regression] internal compiler error: in equal, at cp/constexpr.c:1088

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
Perhaps we should just remove the assert:

--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1085,7 +1085,6 @@ constexpr_call_hasher::equal (constexpr_call *lhs,
constexpr_call *rhs)
 {
   tree lhs_arg = TREE_VALUE (lhs_bindings);
   tree rhs_arg = TREE_VALUE (rhs_bindings);
-  gcc_assert (same_type_p (TREE_TYPE (lhs_arg), TREE_TYPE (rhs_arg)));
   if (!cp_tree_equal (lhs_arg, rhs_arg))
 return false;
   lhs_bindings = TREE_CHAIN (lhs_bindings);

[Bug c++/78752] [concepts] ICE with constrained variadic member function

[andrew.n.sutton at gmail dot com]

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

Andrew Sutton  changed:

   What|Removed |Added

 CC||andrew.n.sutton at gmail dot 
com

--- Comment #3 from Andrew Sutton  ---
Created attachment 46937
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46937&action=edit
Patch against concepts-cxx2a (git format-patch format)

Adds a test for PR78752, which had been semi-fixed. The attached patch rebuilds
constraints involving abbreviated functions with function argument packs and
updates the corresponding template parameter list. We weren't doing that
before, so we were checking constraints with the wrong arguments.

[Bug debug/91887] New: -fdebug-types-section ICE building chromium

[jason at gcc dot gnu.org]

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

Bug ID: 91887
   Summary: -fdebug-types-section ICE building chromium
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jason at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46938&action=edit
unincluded testcase

Compiling this file with -g -fdebug-types-section hits an ICE under
lookup_external_ref, because we're trying to look up a DW_TAG_typedef that has
no symbol.  We shouldn't be trying to form an external reference to a typedef
in the first place; brief attempts to come up with a small testcase have not
reproduced the problem.

[Bug debug/91887] -fdebug-types-section ICE building chromium

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||needs-bisection,
   ||needs-reduction
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-24
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
ICE reproduced.

[Bug tree-optimization/91570] [10 Regression] ICE in get_range_strlen_dynamic on a conditional of two strings

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Tue Sep 24 19:04:54 2019
New Revision: 276105

URL: https://gcc.gnu.org/viewcvs?rev=276105&root=gcc&view=rev
Log:
PR tree-optimization/91570 - ICE in get_range_strlen_dynamic on a conditional
of two strings

gcc/Changelog:
* tree-ssa-strlen.c (get_range_strlen_dynamic): Handle null and
non-constant minlen, maxlen and maxbound.

gcc/testsuite/Changelog:
* gcc.dg/pr91570.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr91570.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/91570] [10 Regression] ICE in get_range_strlen_dynamic on a conditional of two strings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fixed in r276105.

[Bug debug/91887] [7/8/9/10 Regression] -fdebug-types-section ICE building chromium

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords|needs-bisection |
   Target Milestone|--- |7.5
Summary|-fdebug-types-section ICE   |[7/8/9/10 Regression]
   |building chromium   |-fdebug-types-section ICE
   ||building chromium

--- Comment #2 from Marek Polacek  ---
GCC 6 is fine, GCC 7 ICEs so it's a regression.

Started with r240578.

[Bug other/91879] DESTDIR support seems incomplete

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Stas Sergeev from comment #4)
> (In reply to Harald van Dijk from comment #1)
> > The ways to handle libc being installed in non-standard locations depend on
> > your specific use case. GCC provides the --with-sysroot and
> > --with-native-system-header-dir configure options,
> 
> These ones specify the locations permanently.
> My problem is that I need a different sysroot/system-header-dir
> only for the time of building the gcc libs.

Have you looked into --with-build-sysroot ?
--with-build-sysroot
--with-build-sysroot=dir
Tells GCC to consider dir as the system root (see --with-sysroot) while
building target libraries, instead of the directory specified with
--with-sysroot. This option is only useful when you are already using
--with-sysroot. You can use --with-build-sysroot when you are configuring with
--prefix set to a directory that is different from the one in which you are
installing GCC and your target libraries.

This option affects the system root for the compiler used to build target
libraries (which runs on the build system); it does not affect the compiler
which is used to build GCC itself.

If you specify the --with-native-system-header-dir=dirname option then the
compiler will search that directory within dirname for native system headers
rather than the default /usr/include.