[Bug c++/95932] ICE in redeclare_class_template, at cp/pt.c:6231

[haoxintu at gmail dot com]

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

--- Comment #1 from Haoxin Tu  ---
Add a more meaningful case.

$cat p.cc
template  class a {};
template  > 
struct a < class b{}, struct b {}>;

$g++ p.cc
p.cc:2:28: error: expected ‘class’ or ‘typename’ before ‘>’ token
2 | template  >
  |^
p.cc:3:19: error: types may not be defined in template arguments
3 | struct a < class b{}, struct b {}>;
  |   ^
p.cc:3:30: internal compiler error: in redeclare_class_template, at
cp/pt.c:6231
3 | struct a < class b{}, struct b {}>;
  |  ^
0x6be12f redeclare_class_template(tree_node*, tree_node*, tree_node*)
../../gcc/cp/pt.c:6231
...

While in Clang
$clang++ p.cc
p.cc:2:28: error: template template parameter requires 'class' after the
parameter list
template  > 
   ^
   class 
p.cc:3:18: error: 'b' cannot be defined in a type specifier
struct a < class b{}, struct b {}>;
 ^
2 errors generated.

I guess this is also a possible issue that users may encounter in programming,
but it makes GCC crashed.

[Bug c++/95927] ICE in cp_lexer_new_from_tokens, at cp/parser.c:701

[haoxintu at gmail dot com]

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

--- Comment #1 from Haoxin Tu  ---
Add a more meaningful case.


$cat p.cc
template  struct a {};
class A {
struct a < struct x { void b ( ){}} >;
};

$g++ p.cc
p.cc:3:25: error: types may not be defined in template arguments
3 | struct a < struct x { void b ( ){}} >;
  | ^
p.cc:3:40: error: expected ‘;’ after struct definition
3 | struct a < struct x { void b ( ){}} >;
  |^
  |;
p.cc:3:39: error: expected template-argument before ‘;’ token
3 | struct a < struct x { void b ( ){}} >;
  |   ^
p.cc:3:39: error: expected ‘>’ before ‘;’ token
p.cc:3:5: error: ‘struct a’ redeclared with different access
3 | struct a < struct x { void b ( ){}} >;
  | ^~
p.cc:3:41: error: expected unqualified-id before ‘>’ token
3 | struct a < struct x { void b ( ){}} >;
  | ^
p.cc:4:1: internal compiler error: in cp_lexer_new_from_tokens, at
cp/parser.c:701
4 | };
  | ^
0x6adadc cp_parser_push_lexer_for_tokens
../../gcc/cp/parser.c:701
...


While in Clang
$clang++ p.cc
p.cc:3:23: error: 'x' cannot be defined in a type specifier
struct a < struct x { void b ( ){}} >;
  ^
1 error generated.

I guess Clang is performed better when parsing this case. GCC emits a lot of
error messages even throw an ICE, while Clang just emits one.

[Bug c++/95931] ICE in dependent_type_p, at cp/pt.c:26326

[haoxintu at gmail dot com]

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

--- Comment #1 from Haoxin Tu  ---
Add a more meaningful case.

$cat p.cc
void a() { 
auto var = [] (auto, volatile b) {};
}

$g++ p.cc
p.cc: In function ‘void a()’:
p.cc:2:35: error: ‘b’ does not name a type
2 | auto var = [] (auto, volatile b) {};
  |   ^
p.cc:2:40: error: expected ‘)’ before ‘;’ token
2 | auto var = [] (auto, volatile b) {};
  |   ~^
  |)
p.cc:2:40: internal compiler error: in dependent_type_p, at cp/pt.c:26326
0x6c0f63 dependent_type_p(tree_node*)
../../gcc/cp/pt.c:26326

While in Clang
$clang++ p.cc
p.cc:2:35: error: unknown type name 'b'
auto var = [] (auto, volatile b) {};
  ^
1 error generated.

Noted that why GCC emits "expected ‘)’ before ‘;’ token" and has an ICE on the
";"?

Also, this situation may happen in the real world when someone just leaves a
type specifier out by a mistake.

[Bug bootstrap/77510] genautomata memory footprint for MIPS

[paul.hua.gm at gmail dot com]

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

Paul Hua  changed:

   What|Removed |Added

 CC||paul.hua.gm at gmail dot com

--- Comment #4 from Paul Hua  ---
I do some testing, adding scheduling description file one by one order by on
date.

fileadded date  size(M) 
5400.md 8/20/2002   13 
5500.md 8/20/2002   13 
sr71k.md8/20/2002   18 
7000.md 7/15/2003   20 
9000.md 7/15/2003   22 
sb1.md  4/21/2004   23 
4130.md 5/6/200424 
3000.md 6/24/2004   25 
4000.md 7/12/2004   25 
4100.md 7/12/2004   25 
4300.md 7/12/2004   25 
4600.md 7/12/2004   25 
5000.md 7/12/2004   26 
6000.md 7/12/2004   26 
generic.md  7/12/2004   26 
24k.md  5/9/200535 
4k.md   5/13/2005   36 
5k.md   7/29/2005   38 
74k.md  4/16/2007   42 
20kc.md 7/16/2007   46 
xlr.md  6/6/200847 
loongson2ef.md  6/15/2008   51 
octeon.md   9/21/2008   53 
1.md10/6/2008   58 
xlp.md  7/22/2012   450 
p5600.md6/5/20141370 
m5100.md7/22/2015   1382 
i6400.md7/23/2015   1502 
p6600.md6/13/2018   2393 
gs464.md11/7/2018   2403 
gs464e.md   11/7/2018   2411 
gs264e.md   11/7/2018   2419

[Bug c++/95955] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have union_type in int_fits_type_p, at tree.c:8952

[haoxintu at gmail dot com]

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

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #1 from Haoxin Tu  ---
Add a more readable case

$cat p.c
enum class a : struct{};
template < template  class A > 
enum class a : union b {};
enum class a { c;}

$g++ p.cc
p.cc:1:23: error: underlying type ‘’ of ‘a’ must be an integral
type
1 | enum class a : struct{};
  |   ^
p.cc:4:12: error: different underlying type in enum ‘enum class a’
4 | enum class a { c;}
  |^
p.cc:1:23: note: previous definition here
1 | enum class a : struct{};
  |   ^
p.cc:4:16: internal compiler error: tree check: expected integer_type or
enumeral_type or boolean_type or real_type or fixed_point_type, have union_type
in int_fits_type_p, at tree.c:8952
4 | enum class a { c;}
  |^

[Bug c++/95956] ICE in check_bases, at cp/class.c:1689

[haoxintu at gmail dot com]

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

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #1 from Haoxin Tu  ---
Add a more readable case.

$cat p.cc
int a ( auto struct : decltype ( auto ) {{}}){}


$g++ -w p.cc
p.cc:1:41: error: types may not be defined in parameter types
1 | int a ( auto struct : decltype ( auto ) {{}}){}
  | ^
p.cc:1:42: error: expected unqualified-id before ‘{’ token
1 | int a ( auto struct : decltype ( auto ) {{}}){}
  |  ^
p.cc:1:21: internal compiler error: in check_bases, at cp/class.c:1689
1 | int a ( auto struct : decltype ( auto ) {{}}){}
  | ^
0x658963 check_bases
../../gcc/cp/class.c:1689
0x658963 check_bases_and_members
../../gcc/cp/class.c:5900

[Bug c++/95945] ICE in poplevel, at cp/decl.c:585

[haoxintu at gmail dot com]

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

--- Comment #1 from Haoxin Tu  ---
Add a more meaningful case

$cat p.cc
int a ( auto struct x { int b ();}) {}

$g++ -w p.cc
p.cc:1:23: error: types may not be defined in parameter types
1 | int a ( auto struct x { int b ();}) {}
  |   ^
p.cc:1:32: internal compiler error: in poplevel, at cp/decl.c:585
1 | int a ( auto struct x { int b ();}) {}
  |^
0x683eae poplevel(int, int, int)
../../gcc/cp/decl.c:585
0xa45d68 end_template_decl()
../../gcc/cp/pt.c:4688
0x9f86c2 finish_fully_implicit_template
../../gcc/cp/parser.c:44280
0xa3a12a cp_parser_member_declaration
../../gcc/cp/parser.c:25414
0xa0e061 cp_parser_member_specification_opt
../../gcc/cp/parser.c:24850
0xa0e061 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23947
0xa10213 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0xa10213 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0xa11172 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
0xa2db8f cp_parser_parameter_declaration
../../gcc/cp/parser.c:22818
0xa2e582 cp_parser_parameter_declaration_list
../../gcc/cp/parser.c:22641
0xa2e95c cp_parser_parameter_declaration_clause
../../gcc/cp/parser.c:22568
0xa1bda7 cp_parser_direct_declarator
../../gcc/cp/parser.c:21245
0xa1bda7 cp_parser_declarator
../../gcc/cp/parser.c:21109
0xa30346 cp_parser_init_declarator
../../gcc/cp/parser.c:20609
0xa11e42 cp_parser_simple_declaration
../../gcc/cp/parser.c:13785
0xa3b0b6 cp_parser_declaration
../../gcc/cp/parser.c:13484
0xa3b7fa cp_parser_translation_unit
../../gcc/cp/parser.c:4761
0xa3b7fa c_parse_file()
../../gcc/cp/parser.c:44043
0xb5473b c_common_parse_file()
../../gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

In Clang
$clang++ -w p.cc
p.cc:1:21: error: 'x' cannot be defined in a parameter type
int a ( auto struct x { int b ();}) {}
^
1 error generated.

[Bug c++/95972] ICE in check_member_template, at cp/decl2.c:570

[haoxintu at gmail dot com]

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

--- Comment #1 from Haoxin Tu  ---
Hi, there.

I guess I shouldn't use C-Reduce to reduce my ICE on invalid code cases. After
using C-Reduce, the cases are more like a "garbage" code.

Here is a more readable code to reproduce the ICE.

$cat p.cc
int a() { 
auto var = [] ( struct s{ int b( auto);} ){};
}

$g++ -w p.cc
p.cc: In function ‘int a()’:
p.cc:2:29: error: types may not be defined in parameter types
2 | auto var = [] ( struct s{ int b( auto);} ){};
  | ^
p.cc:2:42: internal compiler error: in check_member_template, at cp/decl2.c:570
2 | auto var = [] ( struct s{ int b( auto);} ){};
  |  ^
0x6890c4 check_member_template(tree_node*)
../../gcc/cp/decl2.c:570
0xa41c20 finish_member_template_decl(tree_node*)
../../gcc/cp/pt.c:308
0x9f86ba finish_fully_implicit_template
../../gcc/cp/parser.c:44279
0xa3a12a cp_parser_member_declaration
../../gcc/cp/parser.c:25414
0xa0e061 cp_parser_member_specification_opt
../../gcc/cp/parser.c:24850
0xa0e061 cp_parser_class_specifier_1
../../gcc/cp/parser.c:23947
0xa10213 cp_parser_class_specifier
../../gcc/cp/parser.c:24254
0xa10213 cp_parser_type_specifier
../../gcc/cp/parser.c:17762
0xa11172 cp_parser_decl_specifier_seq
../../gcc/cp/parser.c:14410
0xa2db8f cp_parser_parameter_declaration
../../gcc/cp/parser.c:22818
0xa2e582 cp_parser_parameter_declaration_list
../../gcc/cp/parser.c:22641
0xa2e95c cp_parser_parameter_declaration_clause
../../gcc/cp/parser.c:22568
0xa2f34e cp_parser_lambda_declarator_opt
../../gcc/cp/parser.c:11102
0xa16fb8 cp_parser_lambda_expression
../../gcc/cp/parser.c:10633
0xa16fb8 cp_parser_primary_expression
../../gcc/cp/parser.c:5443
0xa21110 cp_parser_postfix_expression
../../gcc/cp/parser.c:7296
0xa03d6a cp_parser_binary_expression
../../gcc/cp/parser.c:9609
0xa058ce cp_parser_assignment_expression
../../gcc/cp/parser.c:9914
0xa0468d cp_parser_constant_expression
../../gcc/cp/parser.c:10208
0xa04df1 cp_parser_initializer_clause
../../gcc/cp/parser.c:23272
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

While in Clang
$clang++ -w p.cc
p.cc:2:28: error: 's' cannot be defined in a parameter type
auto var = [] ( struct s{ int b( auto);} ){};
   ^
1 error generated.

The ICE just cased by the struct used as a lambda expression parameter. And ICE
point out the parser can not deal with the "auto" keywords and then crashed on
it.

[Bug fortran/96030] AArch64: Add an option to control 64bits simdclone of math functions for fortran

[bule1 at huawei dot com]

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

--- Comment #2 from Bu Le  ---
(In reply to Jakub Jelinek from comment #1)
> The directive should be doing what
> #pragma omp declare simd
> does on the target and it is an ABI decision what exactly it does.

I tried this test case. But I haven't found a way to prevent V2SF 64 bits
simdclone (e.g. _ZGVnN2v_cosf )from being generated.

!GCC$ builtin (cosf) attributes simd (notinbranch)

subroutine test_cos(a_cos, b_cos, is_cos, ie_cos)
  integer, intent(in) :: is_cos, ie_cos
  REAL(4), dimension(is_cos:ie_cos), intent(inout) :: a_cos, b_cos
  do i = 1, 3
  b_cos(i) = cos(a_cos(i))
  enddo

end subroutine test_cos


Are you suggesting we already have a way to prevent the generation of
_ZGVnN2v_cosf with !GCC$ builtin derivative? Or We haven' solve the problem
yet, but the correct way to solve this problem is to implement more feature for
the !GCC$ builtin derivative?

[Bug ipa/96040] [10/11 Regression] Compiled code causes SIGBUS at -O2

[josephcsible at gmail dot com]

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

--- Comment #2 from Joseph C. Sible  ---
Andrew Gierth posted this to the Lua mailing list:

> I think I see what's happening here, but I don't think I have an account
> on the gcc bug tracker to post it there (feel free to forward this).
> It's not (I think) a confusion over how many arguments the specialized
> tostringbuff.part.0.isra function has, but rather over the type, or
> equivalently the register allocation, for the first parameter.
> 
> The callsite is putting num->value_.n into %rdi, and  into %rsi,
> as if the function were declared as taking (long long v, char *buf)
> rather than (double v, char *buf) which would require that num->value_.n
> be placed in %xmm0 and  into %rdi.
> 
> But the code of the function itself is assuming that the incoming values
> are in %xmm0 and %rdi - %xmm0 is not touched because it's already in the
> right place for the snprintf call, while %rdi is left as the first arg
> to snprintf. The value 0x3ff0 is of course 1.0 as a double,
> which naturally does not work well as a pointer so it blows up.

I agree with the gist of that. I think this is more of a calling convention
issue than an argument count issue. It's as if the following pseudo-C were
written:

static int tostringbuff.part.0.isra.0 (union { long long i; double n; } value_
/* rdi */, char *str /* rsi */);

void addnum2buff (int *buff, struct TValue *num) {
if(num->tt_ == 3) {
buff += snprintf(space,50,"%lld",num->value_.i);
} else {
buff += tostringbuff.part.0.isra.0(num->value_ /* rdi */, space /* rsi
*/);
}
}

static int tostringbuff.part.0.isra.0 (double n /* xmm0 */, char *str /* rdi
*/) {
int len;
len = snprintf(str,50,"%.14g",n);
if(str[strspn(str, "-0123456789")] == '\0') {
  str[len++] = '.';
  str[len++] = '0';
}
return len;
}

In English, the compiler couldn't make up its mind as to how
tostringbuff.part.0.isra.0 was declared. At the call site, the first parameter
was a union, but at the definition, the first parameter was a double. Mixing up
a union and its element is fine when they only live in memory since they have
the same address, but here it was in a register. Since the calling convention
puts those types in different kinds of registers, what the function thought was
a pointer was actually the double value, predictably causing a crash when it
was dereferenced.

[Bug jit/95498] unhandled conversion

[bouanto at zoho dot com]

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

--- Comment #4 from Antoni  ---
Created attachment 48829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48829=edit
Smaller reproducer for the bug

I was able to reduce the size of the reproducer. I attached it.

[Bug target/95420] arm-wrs-vxworks7: xgcc: error: unrecognised -mcpu target: armv7-a

[ibuclaw at gdcproject dot org]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #5 from Iain Buclaw  ---
Done.

[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
 Status|WAITING |ASSIGNED

--- Comment #26 from Eric Botcazou  ---
I'm going to have a look.

[Bug c++/94100] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in tsubst_pack_expansion, at cp/pt.c:12765

[hstong at ca dot ibm.com]

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

--- Comment #2 from Hubert Tong  ---
The following ICEs in a similar fashion:
internal compiler error: tree check: accessed elt 2 of 'tree_vec' with 1 elts
in tsubst, at cp/pt.c:15334

### SOURCE:
template  struct ValListWithTypes {
  template  struct WithVals {
using TypeList = ValListWithTypes;
  };
};

template 
struct Widget;

template 
struct Widget> {
  template  struct Impl {};
};

template 
template 
struct Widget>::Impl<
typename ValListWithTypes::template WithVals> {};

int main(void) { Widget::WithVals<0>>::Impl<> impl; }

[Bug rtl-optimization/89310] Poor code generation returning float field from a struct

[segher at gcc dot gnu.org]

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

--- Comment #7 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #6)
> rldicr is one of the insns generated by "*rotl3_mask", which
> recognises all canonical formulations of all our rotate-and-mask
> instructions.

Yes, rldicr could also be generated by "and3_mask", for this case, I
suppose use and_di3_mask without shift right and left is enough? (Below is
minor change with hard code 0xULL replaced.)


   rtx mask = GEN_INT (HOST_WIDE_INT_M1U << 32);
   emit_insn (gen_anddi3 (tmp, op1, mask));
   emit_insn (gen_p8_mtvsrd_sf (op0, tmp));
   emit_insn (gen_vsx_xscvspdpn_directmove (op0, op0));
   DONE;

--- Comment #8 from Segher Boessenkool  ---
That looks good yes.

[Bug libstdc++/96042] New: Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 96042
   Summary: Reference type of std::ranges::iota is __int128 with
-std=c++2a?!
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

The following code

```c++
#include 

using iota_view = std::ranges::iota_view;
using reference_t = std::ranges::range_difference_t;

static_assert(std::same_as); // why?

// but std::numeric_limits is not specialised which indicates that we use
__STRICT_ANSI__

using t = std::numeric_limits<__int128>;
static_assert(t::is_specialized);
```

https://godbolt.org/z/-XFyYN

I don't fully understand what `__int128` and `__STRICT_ANSI__` means, but I
think it is unexpected that I get a type that is not described in the standard.

I know that `std::indirectly_readable` allows (compiler) implementation defined
signed integer types, but from what I have seen, `__int128` is normally only
supported / exposed in the gnu standard library if `__STRICT_ANSI__` is not
defined.

Since `-std=c++2a` does not provide a specialisation for `std::numeric_limits`,
I assume that this means, that `__STRICT_ANSI__` is not defined in that mode,
and I think this is inconsistent behaviour.

Related issues in the range-v3 library:
* https://github.com/ericniebler/range-v3/issues/1514
* https://github.com/ericniebler/range-v3/issues/1516

[Bug fortran/96041] New: [11 regression] ICE in gfortran.dg/pr93423.f90 after r11-1792

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 96041
   Summary: [11 regression] ICE in gfortran.dg/pr93423.f90 after
r11-1792
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:b88744905a46be44ffa3c57d46080f601ae832b8, r11-1792

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgfortran/
exceptions_enabled44873.cc -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -S -o exceptions_enabled44873.s
FAIL: gfortran.dg/pr93423.f90   -O  (test for excess errors)
Excess errors:
f951: internal compiler error: Segmentation fault
0x10be671b crash_signal
/home/seurer/gcc/git/gcc-test/gcc/toplev.c:328
0x103a6484 free_st_labels
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
0x103a648f free_st_labels
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
0x103a648f free_st_labels
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:2662
0x103afd63 gfc_free_namespace(gfc_namespace*)
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:4044
0x103aff67 gfc_free_symbol(gfc_symbol*)
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3084
0x103b01af free_sym_tree
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3896
0x103b01a7 free_sym_tree
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3894
0x103b019f free_sym_tree
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:3893
0x103afcdb gfc_free_namespace(gfc_namespace*)
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:4035
0x103b067b gfc_symbol_done_2()
/home/seurer/gcc/git/gcc-test/gcc/fortran/symbol.c:4095
0x1031f8cf gfc_done_2()
/home/seurer/gcc/git/gcc-test/gcc/fortran/misc.c:358
0x10345cdb clean_up_modules
/home/seurer/gcc/git/gcc-test/gcc/fortran/parse.c:6267
0x10356413 translate_all_program_units
/home/seurer/gcc/git/gcc-test/gcc/fortran/parse.c:6330
0x10356413 gfc_parse_file()
/home/seurer/gcc/git/gcc-test/gcc/fortran/parse.c:6546
0x103c757f gfc_be_parse_file
/home/seurer/gcc/git/gcc-test/gcc/fortran/f95-lang.c:212

testcase /home/seurer/gcc/git/gcc-test/gcc/testsuite/gfortran.dg/dg.exp
completed in 0 seconds

=== gfortran Summary ===

# of expected passes2
# of unexpected failures2

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #25 from Sergei Trofimovich  ---
(In reply to Sergei Trofimovich from comment #22)
> (In reply to Martin Liška from comment #17)
> > For me tree optimized dump is correct, so likely a target issue.
> 
> Yeah, I agree. I finally understood why memory loads disappear (duh!).
> 
> > @Sergei: Is GCC 9 working properly?
> > Would it be possible to bisect that?
> 
> gcc-9 seems to work, bu I'm not sure if it's intentional or unrelated
> optimization passes change the code enough.
> 
> I'll try to cook up even smaller example given that -fno-delayed-branch
> seems to be a culprit and then bisect gcc.

Bisected down to:

$ git bisect good
8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf is the first bad commit
commit 8c3785c43d490d4f234e21c9dee6bb1bb8d1dbdf
Author: Martin Liska 
Date:   Wed Dec 4 11:13:49 2019 +0100

Initialize a BB count in switch lowering.

2019-12-04  Martin Liska  

* tree-switch-conversion.c
(switch_decision_tree::try_switch_expansion):
Initialize count of newly created BB.

From-SVN: r278959

 gcc/ChangeLog| 5 +
 gcc/tree-switch-conversion.c | 1 +
 2 files changed, 6 insertions(+)

[Bug ipa/96040] [10/11 Regression] Compiled code causes SIGBUS at -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|Compiled code causes SIGBUS |[10/11 Regression] Compiled
   |at -O2  |code causes SIGBUS at -O2
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Component|c   |ipa
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-02
   Target Milestone|--- |10.2

--- Comment #1 from Jakub Jelinek  ---
Started with r10-4651-gafeb887562af17ea235fbec650ff6d16c412682a
>From quick look it seems like a disagreement on how many arguments
tostringbuff.part.0.isra has.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #24 from Sergei Trofimovich  ---
(In reply to Sergei Trofimovich from comment #23)
> cvise managed to shrink example down to the following:

For completeness assembly output difference is very clear now:

$ hppa2.0-unknown-linux-gnu-gcc -O2 -S ../bug_test.c -o bug.S
a:
bv %r0(%r2)
ldi 0,%r28

$ hppa2.0-unknown-linux-gnu-gcc -O2 -S ../bug_test.c -o bug.S
-fno-delayed-branch
a:
comclr,<> %r26,%r25,%r0
b,n .L11
nop
.L4:
.L12:
ldil L'.L6,%r28
ldo R'.L6(%r28),%r28
ldwx,s %r24(%r28),%r28
bv,n %r0(%r28)
.section.rodata
.align 4
.L6:
.begin_brtab
.word .L8
.word .L5
.word .L4
.word .L5
.word .L4
.word .L5
.end_brtab
.text
.L5:
ldi 10,%r28
bv,n %r0(%r2)
.L11:
ldi 0,%r28
bv,n %r0(%r2)
.L8:
ldi 1,%r28
bv,n %r0(%r2)

[Bug target/96026] overlap register bewteen DEST and SOURCE in different machine mode

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Jim Wilson  ---
This is 3 different places where you have asked the same question now.  One
place would have been good enough.  Already answered in other places.

[Bug target/96017] Powerpc suboptimal register spill in likely path

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #9)
> (In reply to Peter Bergner from comment #8)
> > At first, I thought that split_live_ranges_for_shrink_wrap() split this
> > nicely, but what I found is that IRA assigned a volatile register to a
> > pseudo that is live across a call.
> 
> ...and that is because somehow flag_caller_saves is true.  I can't believe
> that is a good idea in general.

'-fcaller-saves'
 Enable allocation of values to registers that are clobbered by
 function calls, by emitting extra instructions to save and restore
 the registers around such calls.  Such allocation is done only when
 it seems to result in better code.

 This option is always enabled by default on certain machines,
 usually those which have no call-preserved registers to use
 instead.

 Enabled at levels '-O2', '-O3', '-Os'.

Note the "only when" line...  It sounds like (in spite of that promise) we
do it too aggressively currently?

[Bug target/96017] Powerpc suboptimal register spill in likely path

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
(In reply to Peter Bergner from comment #6)
> Right, that's why we need to add the copies before RA, so we don't have to
> look for unused regs.  But we don't want to add the copies too early just
> for the optimizer to remove them on us.

RA itself will want to use the same hard register most of the time, already.
And that *is* the best choice, except when you need to split the range later.

We would need to do (some of) shrink wrapping before RA, but that means we
need to change our abstraction of prologue/epilogue.  Not a bad idea probably,
but a lot of work.  Many targets do many special things in their own *logue
hooks (and patterns and code called from those) currently, it all would need
to be disentangled.

[Bug c/96040] New: Compiled code causes SIGBUS at -O2

[josephcsible at gmail dot com]

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

Bug ID: 96040
   Summary: Compiled code causes SIGBUS at -O2
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josephcsible at gmail dot com
  Target Milestone: ---
Target: x86_64-linux-gnu

Consider this C code:

int puts(const char *);
int snprintf(char *, unsigned long, const char *, ...);
unsigned long strspn(const char *, const char *);

struct TValue {
  union {
long long i;
double n;
  } value_;
  unsigned char tt_;
};

static int tostringbuff (struct TValue *num, char *str) {
  int len;
  if (num->tt_ == 3) {
len = snprintf(str,50,"%lld",num->value_.i);
  } else {
len = snprintf(str,50,"%.14g",num->value_.n);
if (str[strspn(str, "-0123456789")] == '\0') {
  str[len++] = '.';
  str[len++] = '0';
}
  }
  return len;
}

void unused (int *buff, struct TValue *num) {
  char junk[50];
  *buff += tostringbuff(num, junk);
}

char space[400];

void addnum2buff (int *buff, struct TValue *num) __attribute__((__noinline__));
void addnum2buff (int *buff, struct TValue *num) {
  *buff += tostringbuff(num, space);
}

int main(void) {
int buff = 0;
struct TValue num;
num.value_.n = 1.0;
num.tt_ = 19;
addnum2buff(, );
puts(space);
}

It's supposed to print "1.0". When compiled with "gcc -O2", it instead crashes
with SIGBUS. This appears to be a regression, since it works fine on GCC 9.

The minimization is my own, but the bug was originally found in the wild by
actboy168 compiling Lua 5.4.0 on Arch Linux:
http://lua-users.org/lists/lua-l/2020-07/msg1.html

https://godbolt.org/z/RMc3RX

[Bug testsuite/95706] New test case gfortran.dg/pr95690.f90 fails

[dje at gcc dot gnu.org]

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

--- Comment #11 from David Edelsohn  ---
I added Solaris to the list of targets that see the error on line 5.  Add it
wherever your target sees it.

[Bug testsuite/95706] New test case gfortran.dg/pr95690.f90 fails

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu,
   ||sparc-sun-solaris2.11
   Host|powerpc64*-linux-gnu|powerpc64*-linux-gnu,
   ||sparc-sun-solaris2.11
 CC||ro at gcc dot gnu.org
  Build|powerpc64*-linux-gnu|powerpc64*-linux-gnu,
   ||sparc-sun-solaris2.11

--- Comment #10 from Rainer Orth  ---
(In reply to Richard Biener from comment #9)
> David "fixed" this on trunk with the following, the testcase still fails on
> the branch and of course we don't know why it exhibits this particular
> behavior.

This change broke the test on sparc-sun-solaris2.11 (both 32 and 64-bit):

+FAIL: gfortran.dg/pr95690.f90   -O   (test for errors, line 6)
+FAIL: gfortran.dg/pr95690.f90   -O  (test for excess errors)

Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/pr95690.f90:5:0: Error:
initializer for floating value is not a floating constant

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #23 from Sergei Trofimovich  ---
cvise managed to shrink example down to the following:

"""
int b, c;
int a() __attribute__((noipa));
int a(int *d, int *f, int g) {
  int e;
  if (d == f)
e = 0;
  else
e = 1;
  switch (g) {
  case 0:
return e;
  case 1:
  case 3:
  case 5:
if (e)
  return 10;
  default:
__builtin_unreachable();
  }
}
int main() { return a(, , 0); }
"""


$ hppa2.0-unknown-linux-gnu-gcc -O2 bug_test.c -o bad; ./bad; echo $?
0
$ hppa2.0-unknown-linux-gnu-gcc -O2 bug_test.c -o good -fno-delayed-branch;
./good; echo $?
1

gcc-9.2.0 returns '1' in both cases. I'll bisect gcc against this example.

[Bug fortran/95709] [9/10/11 Regression] ICE in gfc_resolve_code, at fortran/resolve.c:11807

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch for review: https://gcc.gnu.org/pipermail/fortran/2020-July/054686.html

[Bug c++/96039] Missing diagnostic: C++11 alignment specifier on bit-fields

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Marek Polacek  ---
Dup.

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

[Bug c++/90847] misplaced alignment-specifier not diagnosed

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||hstong at ca dot ibm.com

--- Comment #4 from Marek Polacek  ---
*** Bug 96039 has been marked as a duplicate of this bug. ***

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #22 from Sergei Trofimovich  ---
(In reply to Martin Liška from comment #17)
> For me tree optimized dump is correct, so likely a target issue.

Yeah, I agree. I finally understood why memory loads disappear (duh!).

> @Sergei: Is GCC 9 working properly?
> Would it be possible to bisect that?

gcc-9 seems to work, bu I'm not sure if it's intentional or unrelated
optimization passes change the code enough.

I'll try to cook up even smaller example given that -fno-delayed-branch seems
to be a culprit and then bisect gcc.

[Bug c++/96039] New: Missing diagnostic: C++11 alignment specifier on bit-fields

[hstong at ca dot ibm.com]

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

Bug ID: 96039
   Summary: Missing diagnostic: C++11 alignment specifier on
bit-fields
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hstong at ca dot ibm.com
  Target Milestone: ---

According to [dcl.align] in the 2020 DIS for C++, an alignment-specifier shall
not be applied to a bit-field. GCC allows such alignment-specifiers with no
diagnostic.

### SOURCE ():
struct A {
  int x alignas(long long) : 32;
};


### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++11 -Wall -Wextra -pedantic-errors -xc++ -


### ACTUAL OUTPUT:
(rc=0)


### EXPECTED OUTPUT:
Diagnostic message; likely an error.


### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200701 (experimental) (GCC)

[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[vgupta at synopsys dot com]

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

Vineet Gupta  changed:

   What|Removed |Added

 CC||claziss at gmail dot com,
   ||vgupta at synopsys dot com

--- Comment #7 from Vineet Gupta  ---
FWIW this is also applicable to ARC glibc + upstream gcc 10

https://sourceware.org/pipermail/libc-alpha/2020-July/115679.html
https://sourceware.org/pipermail/libc-alpha/2020-July/115694.html

[Bug fortran/96038] Confirming implicitly type parameter causes an invalid error

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug fortran/96038] New: Confirming implicitly type parameter causes an invalid error

[kargl at gcc dot gnu.org]

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

Bug ID: 96038
   Summary: Confirming implicitly type parameter causes an invalid
error
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kargl at gcc dot gnu.org
  Target Milestone: ---

Consider the following fixed-form source code:

  function ifoo()
  parameter (n = 50)
  integer n
  ifoo = n
  end

Everything is implicitly type.  Gfortran gives

  function ifoo()
  parameter (n = 50)
  integer n
  ifoo = n
  end

% gfortran -c a.f
a.f:3:15:

3 |   integer n
  |   1
Error: PARAMETER at (1) is missing an initializer

which is wrong.  The code should compile as an implicitly type
entity can appear in a declaration statement if that declaration
statement confirms the implicit type.

The patch is straight forward.  This is against svn revision 280156.
The patch has not been regression tested.

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c  (revision 280157)
+++ gcc/fortran/decl.c  (working copy)
@@ -1864,13 +1864,16 @@ add_init_expr_to_sym (const char *name, gfc_expr **ini

   /* If this symbol is confirming an implicit parameter type,
  then an initialization expression is not allowed.  */
-  if (attr.flavor == FL_PARAMETER
-  && sym->value != NULL
-  && *initp != NULL)
+  if (attr.flavor == FL_PARAMETER && sym->value != NULL)
 {
-  gfc_error ("Initializer not allowed for PARAMETER %qs at %C",
-sym->name);
-  return false;
+  if (*initp != NULL)
+   {
+ gfc_error ("Initializer not allowed for PARAMETER %qs at %C",
+sym->name);
+ return false;
+   }
+  else
+   return true;
 }

   if (init == NULL)

[Bug libstdc++/96036] Please make std::optinal noexcept constructible when possible

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-07-02
 Ever confirmed|0   |1
   Target Milestone|--- |11.0

[Bug libstdc++/91807] [9/10/11 Regression] std::variant with multiple identical types assignment fail to compile

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #7 from Ville Voutilainen  ---
Fixed.

[Bug libstdc++/91807] [9/10/11 Regression] std::variant with multiple identical types assignment fail to compile

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Ville Voutilainen
:

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

commit r9-8716-geb77f6f1b74aa200b70eb0a9e261c9f3b68294a0
Author: Ville Voutilainen 
Date:   Thu Jul 2 22:16:39 2020 +0300

PR libstdc++/91807

PR libstdc++/91807
* include/std/variant
(_Copy_assign_base::operator=(const _Copy_assign_base&):
Do the move-assignment from a temporary so that the temporary
is constructed with an explicit index.
* testsuite/20_util/variant/91807.cc: New.

(cherry picked from commit dbca7a69f276e4829354f87f2747ebff36f6090e)

[Bug tree-optimization/96037] New: [11 regression] ICE at tree-ssa-loop.c:414 after r11-1782

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 96037
   Summary: [11 regression] ICE at tree-ssa-loop.c:414 after
r11-1782
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

g:d5d9f7834ab809841c4ccc90bca74808b4bcaf8d, r11-1782

FAIL: libgomp.c++/../libgomp.c-c++-common/simd-15.c (internal compiler error)
FAIL: libgomp.c++/../libgomp.c-c++-common/simd-15.c (test for excess errors)
FAIL: libgomp.c/../libgomp.c-c++-common/simd-15.c (internal compiler error)
FAIL: libgomp.c/../libgomp.c-c++-common/simd-15.c (test for excess errors)


Executing on host: /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include  

/home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.c/../libgomp.c-c++-common/simd-15.c
  -B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp
-I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/../../include
-I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp  -O2  
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs
-lm  -o ./simd-15.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
/home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.c/../libgomp.c-c++-common/simd-15.c
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp
-I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/../../include
-I/home/seurer/gcc/git/gcc-test/libgomp/testsuite/.. -fmessage-length=0
-fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -O2
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libgomp/.libs
-lm -o ./simd-15.exe
during GIMPLE pass: vect
/home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.c/../libgomp.c-c++-common/simd-15.c:
In function 'main':
/home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.c/../libgomp.c-c++-common/simd-15.c:12:1:
internal compiler error: Segmentation fault
0x10b5873b crash_signal
/home/seurer/gcc/git/gcc-test/gcc/toplev.c:328
0x10eb10c0 get_vectype_for_scalar_type(vec_info*, tree_node*, _slp_tree*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:10999
0x10eb10c0 vectorizable_shift
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:5404
0x10ece83b vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-stmts.c:10642
0x10ed4153 vect_transform_loop_stmt
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.c:8327
0x10eed06f vect_transform_loop(_loop_vec_info*, gimple*)
/home/seurer/gcc/git/gcc-test/gcc/tree-vect-loop.c:8730
0x10f1577f try_vectorize_loop_1
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1053
0x10f1614f vectorize_loops()
/home/seurer/gcc/git/gcc-test/gcc/tree-vectorizer.c:1189
0x10d870a7 execute
/home/seurer/gcc/git/gcc-test/gcc/tree-ssa-loop.c:414
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: libgomp.c/../libgomp.c-c++-common/simd-15.c (internal compiler error)

[Bug libstdc++/91807] [9/10/11 Regression] std::variant with multiple identical types assignment fail to compile

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Ville Voutilainen
:

https://gcc.gnu.org/g:9cba1b9a6333dcc6623865b7a0ed4d57cec4088e

commit r10-8418-g9cba1b9a6333dcc6623865b7a0ed4d57cec4088e
Author: Ville Voutilainen 
Date:   Thu Jul 2 22:16:39 2020 +0300

PR libstdc++/91807

PR libstdc++/91807
* include/std/variant
(_Copy_assign_base::operator=(const _Copy_assign_base&):
Do the move-assignment from a temporary so that the temporary
is constructed with an explicit index.
* testsuite/20_util/variant/91807.cc: New.

(cherry picked from commit dbca7a69f276e4829354f87f2747ebff36f6090e)

[Bug libstdc++/91807] [9/10/11 Regression] std::variant with multiple identical types assignment fail to compile

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Ville Voutilainen :

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

commit r11-1793-gdbca7a69f276e4829354f87f2747ebff36f6090e
Author: Ville Voutilainen 
Date:   Thu Jul 2 22:16:39 2020 +0300

PR libstdc++/91807

PR libstdc++/91807
* include/std/variant
(_Copy_assign_base::operator=(const _Copy_assign_base&):
Do the move-assignment from a temporary so that the temporary
is constructed with an explicit index.
* testsuite/20_util/variant/91807.cc: New.

[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Thu, Jul 02, 2020 at 06:30:40PM +, sgk at troutmask dot
apl.washington.edu wrote:
> 
> It isn't a matter of simply switching rules.  It's a matter of bugs
> and whether the bug is reported.  In the small snippet you posted,
> there is clearly a problem with implicit typing and parameter statements.
> This compiles
> 
>   function jfoo()
>   parameter (MSHLNG=50)
>   jfoo = mshlng
>   end
> 
> and this doesn't
> 
>   function ifoo()
>   parameter (MSHLNG=50)
>   integer   MSHLNG
>   ifoo = mshlng
>   end
> 
> % gfcx -c a.f
> a.f:3:22:
> 
> 3 | integer   MSHLNG
>   |1
> Error: PARAMETER at (1) is missing an initializer
> 
> The Fortran standard has
> 
>   If a named constant is defined by a PARAMETER statement, it shall
>   not be subsequently declared to have a type or type parameter value
>   that differs from the type and type parameters it would have if
>   declared implicitly (8.7).
> 
> What is puzzling is that the 'parameter (mshlng=50)' is
> correctly parsed.  The declaration statement is incorrectly
> parsed, but I don't know why, yet.
> 

When bugs are reported, they sometime get fixed.

(Copy-n-paste tab corruption in patch)

Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -1864,13 +1864,16 @@ add_init_expr_to_sym (const char *name, gfc_expr **ini

   /* If this symbol is confirming an implicit parameter type,
  then an initialization expression is not allowed.  */
-  if (attr.flavor == FL_PARAMETER
-  && sym->value != NULL
-  && *initp != NULL)
+  if (attr.flavor == FL_PARAMETER && sym->value != NULL)
 {
-  gfc_error ("Initializer not allowed for PARAMETER %qs at %C",
-   sym->name);
-  return false;
+  if (*initp != NULL)
+ {
+   gfc_error ("Initializer not allowed for PARAMETER %qs at %C",
+   sym->name);
+   return false;
+ }
+  else
+ return true;
 }

   if (init == NULL)

[Bug fortran/88379] [8/9 Regression] [Coarray] ICE with allocatable coarray, class and associate in resolve_assoc_var, at fortran/resolve.c:8750

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9 Regression] [Coarray]
   |[Coarray] ICE with  |ICE with allocatable
   |allocatable coarray, class  |coarray, class and
   |and associate in|associate in
   |resolve_assoc_var, at   |resolve_assoc_var, at
   |fortran/resolve.c:8750  |fortran/resolve.c:8750

--- Comment #7 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11, and 10-branch so far.

[Bug fortran/88379] [8/9/10/11 Regression] [Coarray] ICE with allocatable coarray, class and associate in resolve_assoc_var, at fortran/resolve.c:8750

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:66640d910595faded4425cfe2729ddf9d16e457b

commit r10-8417-g66640d910595faded4425cfe2729ddf9d16e457b
Author: Harald Anlauf 
Date:   Tue Jun 30 23:36:56 2020 +0200

PR fortran/88379 - ICE with allocatable coarray, class and associate

Catch NULL pointer dereference for ASSOCIATE on allocatable coarray
variable.

gcc/fortran/
PR fortran/88379
* resolve.c (resolve_assoc_var): Avoid NULL pointer dereference.

(cherry picked from commit 267f84c6035c9380c8d1e9cb83ffe299c23e3a85)

[Bug libstdc++/96036] New: Please make std::optinal noexcept constructible when possible

[rafael at espindo dot la]

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

Bug ID: 96036
   Summary: Please make std::optinal noexcept constructible when
possible
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rafael at espindo dot la
  Target Milestone: ---

Only the move constructor of std::optional is conditionally noexcept.

The standard in res.on.exception.handling says:

An implementation may strengthen the exception specification for a non-virtual
function by adding a non-throwing exception specification.

So it should be possible to also make

template < class U = value_type >
constexpr optional( U&& value );

conditionally noexcept.

libstdc++ already does that for std::tuple.

[Bug libstdc++/91153] New test case 29_atomics/atomic_float/1.cc execution test fails

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Fixed for 10.2

[Bug target/93224] 29_atomics/atomic_ref/float.cc fails with a tweaked IPA inliner

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:14d4e7bc303a92f620eddcba9cef88da7e91514c

commit r10-8416-g14d4e7bc303a92f620eddcba9cef88da7e91514c
Author: Jonathan Wakely 
Date:   Thu Jul 2 17:11:10 2020 +

libstdc++: Fix atomic tests (PR 91153, PR 93224)

These tests fail with AIX double double. Use different floating point
values that behave less surprisingly.

libstdc++-v3/ChangeLog:

PR libstdc++/91153
PR target/93224
* testsuite/29_atomics/atomic_float/1.cc: Use different values
for tests.
* testsuite/29_atomics/atomic_ref/float.cc: Likewise.

(cherry picked from commit c6f431bba531bac3212b66069cf0f9718edf0132)

[Bug target/93224] 29_atomics/atomic_ref/float.cc fails with a tweaked IPA inliner

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
Fixed for 10.2

[Bug libstdc++/91153] New test case 29_atomics/atomic_float/1.cc execution test fails

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:14d4e7bc303a92f620eddcba9cef88da7e91514c

commit r10-8416-g14d4e7bc303a92f620eddcba9cef88da7e91514c
Author: Jonathan Wakely 
Date:   Thu Jul 2 17:11:10 2020 +

libstdc++: Fix atomic tests (PR 91153, PR 93224)

These tests fail with AIX double double. Use different floating point
values that behave less surprisingly.

libstdc++-v3/ChangeLog:

PR libstdc++/91153
PR target/93224
* testsuite/29_atomics/atomic_float/1.cc: Use different values
for tests.
* testsuite/29_atomics/atomic_ref/float.cc: Likewise.

(cherry picked from commit c6f431bba531bac3212b66069cf0f9718edf0132)

[Bug fortran/93423] [8/9/10/11 Regression] ICE on invalid with argument list for module procedure

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r11-1792-gb88744905a46be44ffa3c57d46080f601ae832b8
Author: Harald Anlauf 
Date:   Thu Jul 2 20:48:16 2020 +0200

PR fortran/93423 - ICE on invalid with argument list for module procedure

When recovering from an error, a NULL pointer dereference could occur.
Check for that situation and punt.

gcc/fortran/
PR fortran/93423
* resolve.c (resolve_symbol): Avoid NULL pointer dereference.

[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r11-1791-gd9fb6f2b4f1321b059807ff6073156f07d9d376b
Author: Harald Anlauf 
Date:   Thu Jul 2 20:41:51 2020 +0200

PR fortran/93337 - ICE in gfc_dt_upper_string, at fortran/module.c:441

When declaring a polymorphic variable that is not a dummy, allocatable or
pointer, an ICE occurred due to a NULL pointer dereference.  Check for
that situation and punt.

gcc/fortran/
PR fortran/93337
* class.c (gfc_find_derived_vtab): Punt if name is not set.

[Bug fortran/52279] Fortran translation issues

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl  ---
On Thu, Jul 02, 2020 at 05:24:36PM +, sch...@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279
> 
> --- Comment #11 from Andreas Schwab  ---
> If it was enabled by default, you cannot negate it.
> 

I have no idea what you're writing about, or if you're
addressing me or jakub.

All I can do is explain what gfortran does, and the intended
designed behavior of the -fallow-invalid-boz option.  The
negation of the option is to not specify it among your options.

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

[anlauf at gcc dot gnu.org]

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

Bug 71706 Summary: [8/9 Regression] [Coarray] ICE on using sync images with 
integer(kind<>4), with -fcoarray=lib -fcheck=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71706

   What|Removed |Added

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

[Bug fortran/27766] [meta-bug] -fbounds-check related bugs

[anlauf at gcc dot gnu.org]

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

Bug 71706 Summary: [8/9 Regression] [Coarray] ICE on using sync images with 
integer(kind<>4), with -fcoarray=lib -fcheck=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71706

   What|Removed |Added

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

[Bug fortran/71706] [8/9 Regression] [Coarray] ICE on using sync images with integer(kind<>4), with -fcoarray=lib -fcheck=bounds

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #19 from anlauf at gcc dot gnu.org ---
Fixed down to 8-branch.  Closing.

Thanks for the report!

[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Thu, Jul 02, 2020 at 05:31:21PM +, skorzennik at cfa dot harvard.edu
wrote:
> 
> I gave up on gfortran when the 64b record marker made it unusable for me. I'm
> not surprised it was fixed, but this pointed to poor decision making and
> ignoring the need to backward compatibility. When you don't need to sell your
> product, your "customers" needs might not be your highest priority.

It's a very small group of volunteers who hack on gfortran.  No
one is paid to do it (except for perhaps the OpenMP and OpenACC
extensions).  It has been a hobby for me.  I fix bugs that affect
my own codes and then address bugs reported by others as time
permits.  If Fortran were a more popular language, then things
may be different.

> Backward compatibility is a wide spread problem, in commercial products
> (trust me, some have hear mn more than once) and in 'free' ones (the
> Python 2.x vs 3.x debacle comes to mind). When you've been at it for 3
> decades, it matters.

gfortran supports a large number of extension.  I know as I either
implemented the extension (e.g., real do-loop indices and nonstandard
intrinsic subprograms) or sheparded the extension into the tree (Cray
pointers and DEC structure/union/map).  Unfortunately, extensions
make it more difficult to maintain and add the new language features
in the Fortran standards.

> PANDORA can be downloaded, and it is ugly coding (I know the author,
> he retired a while back and I was for a while helping maintain the
> code), but it may be a good example why you can't easily all a sudden
> switch to new rules, and why we maintain multiple versions of multiple
> compilers.

It isn't a matter of simply switching rules.  It's a matter of bugs
and whether the bug is reported.  In the small snippet you posted,
there is clearly a problem with implicit typing and parameter statements.
This compiles

  function jfoo()
  parameter (MSHLNG=50)
  jfoo = mshlng
  end

and this doesn't

  function ifoo()
  parameter (MSHLNG=50)
  integer   MSHLNG
  ifoo = mshlng
  end

% gfcx -c a.f
a.f:3:22:

3 | integer   MSHLNG
  |1
Error: PARAMETER at (1) is missing an initializer

The Fortran standard has

  If a named constant is defined by a PARAMETER statement, it shall
  not be subsequently declared to have a type or type parameter value
  that differs from the type and type parameters it would have if
  declared implicitly (8.7).

What is puzzling is that the 'parameter (mshlng=50)' is
correctly parsed.  The declaration statement is incorrectly
parsed, but I don't know why, yet.

[Bug fortran/71706] [8/9 Regression] [Coarray] ICE on using sync images with integer(kind<>4), with -fcoarray=lib -fcheck=bounds

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:10b028c2813f683a8ebab7d36c9d0d05b49a710b

commit r8-10340-g10b028c2813f683a8ebab7d36c9d0d05b49a710b
Author: Harald Anlauf 
Date:   Mon Jun 29 15:15:49 2020 +0200

PR fortran/71706 - ICE on using sync images with -fcheck=bounds

The run-time checking code did not properly convert the kind of the
argument to SYNC IMAGES, leading to an error in verify_gimple.  Fix that.

gcc/fortran/
PR fortran/71706
* trans-stmt.c (gfc_trans_sync): Do proper kind conversion in
bounds-checking code.

(cherry picked from commit e6cc67f6616c96f3e18a434e0c74ba2f3818cb6d)

[Bug tree-optimization/96034] missed optimization with extended registers

[sshannin at gmail dot com]

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

sshannin at gmail dot com changed:

   What|Removed |Added

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

--- Comment #2 from sshannin at gmail dot com ---
Ah, yes, you're correct on both counts.

For future reference if anybody comes across this, I can confirm on both a
sandy bridge and skylake that the pxor does actually make it faster. I
should've checked first; I got too excited by "fewer instructions = better".

As far as the ABI, I'm certainly not an expert and if you claim that the upper
bits are undefined I certainly defer to you. As you intuited, I was checking
against llvm output (and it does omit the sign extend).

Sorry for the bother and thanks for such a helpful response.

[Bug libstdc++/91153] New test case 29_atomics/atomic_float/1.cc execution test fails

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-1790-gc6f431bba531bac3212b66069cf0f9718edf0132
Author: Jonathan Wakely 
Date:   Thu Jul 2 17:11:10 2020 +

libstdc++: Fix atomic tests (PR 91153, PR 93224)

These tests fail with AIX double double. Use different floating point
values that behave less surprisingly.

libstdc++-v3/ChangeLog:

PR libstdc++/91153
PR target/93224
* testsuite/29_atomics/atomic_float/1.cc: Use different values
for tests.
* testsuite/29_atomics/atomic_ref/float.cc: Likewise.

[Bug target/93224] 29_atomics/atomic_ref/float.cc fails with a tweaked IPA inliner

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r11-1790-gc6f431bba531bac3212b66069cf0f9718edf0132
Author: Jonathan Wakely 
Date:   Thu Jul 2 17:11:10 2020 +

libstdc++: Fix atomic tests (PR 91153, PR 93224)

These tests fail with AIX double double. Use different floating point
values that behave less surprisingly.

libstdc++-v3/ChangeLog:

PR libstdc++/91153
PR target/93224
* testsuite/29_atomics/atomic_float/1.cc: Use different values
for tests.
* testsuite/29_atomics/atomic_ref/float.cc: Likewise.

[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.

[skorzennik at cfa dot harvard.edu]

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

--- Comment #7 from Sylvain Korzennik  ---
Thanks for following up, Steve.

I gave up on gfortran when the 64b record marker made it unusable for me. I'm
not surprised it was fixed, but this pointed to poor decision making and
ignoring the need to backward compatibility. When you don't need to sell your
product, your "customers" needs might not be your highest priority.

Backward compatibility is a wide spread problem, in commercial products (trust
me, some have hear mn more than once) and in 'free' ones (the Python 2.x vs 3.x
debacle comes to mind). When you've been at it for 3 decades, it matters.

PANDORA can be downloaded, and it is ugly coding (I know the author, he retired
a while back and I was for a while helping maintain the code), but it may be a
good example why you can't easily all a sudden switch to new rules, and why we
maintain multiple versions of multiple compilers.

Have a great 4th of July, stay sane, safe and healthy, 6+ft away!
 Cheers,
  Sylvain

[Bug fortran/52279] Fortran translation issues

[sch...@linux-m68k.org]

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

--- Comment #11 from Andreas Schwab  ---
If it was enabled by default, you cannot negate it.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #21 from Sergei Trofimovich  ---
(In reply to Eric Botcazou from comment #18)
> If the control flow goes through .L12:
> 
> .L12:
> b .L3; return 0; (not interesting, fall through)
>   ldi 1,%r28
> 
> the return value will be 1 since ldi is in the delay slot of the branch.
> 
> What happens if you compile with -O2 -fno-delayed-branch instead?

Oh, -fno-delayed-branch makes test magically pass! Attaching both bad.S and
good.S for comparison.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #20 from Sergei Trofimovich  ---
Created attachment 48828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48828=edit
good.S

[Bug fortran/52279] Fortran translation issues

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  ---
On Thu, Jul 02, 2020 at 05:10:51PM +, sch...@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52279
> 
> --- Comment #9 from Andreas Schwab  ---
> That means you cannot override a default.
> 

Huh?

By default you get an error.  The option down-grades the
error to a warning.  If you don't want the warning, then
don't use the option.  You'll get the error.

[Bug target/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa

[slyfox at inbox dot ru]

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

--- Comment #19 from Sergei Trofimovich  ---
Created attachment 48827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48827=edit
bad.S

[Bug fortran/52279] Fortran translation issues

[sch...@linux-m68k.org]

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

--- Comment #9 from Andreas Schwab  ---
That means you cannot override a default.

[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Thu, Jul 02, 2020 at 04:10:38PM +, skorzennik at cfa dot harvard.edu
wrote:
> 
>   GCC is the single one that decides that old code is trash and needs to be
> rewritten. When 64b was introduced, gfortran decided that the UNIX record
> integer embedded in the binary files ought to be 64b, making it impossible to
> use existing binary files. That's simply shooting yourself in the foot. 
> 

That problem was recognized and fixed long ago.  See the
-frecord-marker and -fmax-subrecord-length options.

> As for a specific URL: https://www.cfa.harvard.edu/~avrett/pandora/, the
> PANDORA radiative transfer code is made up of 4,559 routines.

Thanks for the URL.  If the code is freely downloadable, I'll grab it
and check out what gfortran does.

> It was not well
> designed, but it was started in 1959, with computers and compilers that had
> many limitations, yet I can build it w/ Intel's and PGI's F77 compilers. It
> needed minor one or two tweaks for runtime errors when moved from VMS to 
> Linux. 
> 
>   Yet by writing
>   parameter   (MSHLNG=50)
>   integer MSHCNO,MSHLNG
>   dimension   MSHCLR(MSHLNG)
>   data MSHCLR,MSHCNO /MSHLNG*' ', 0/
> gfortran imposes a rule that did not exist -or wasn't enforced- back when: the
> integer declaration must be before the parameter one. The developer used
> VAX/VMS tools and saw no reasons to code differently (GNU did not exists).
> 
> PGI and Intel do accept this order. 
> 

There can be bugs in the compiler.  Unreported bugs tend to go unfixed.
Ufortunately, there are more bugs than volunteers to fix them.

[Bug tree-optimization/96034] missed optimization with extended registers

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The pxor is in there for performance reasons:
;; Break partial SSE register dependency stall.  This splitter should split
;; late in the pass sequence (after register rename pass), so allocated
;; registers won't change anymore
So sure, at -Os it is not present, because it makes the code larger (but
faster).

I also don't understand why you think the 8-bit to 32-bit sign extension is
unnecessary, the x86_64 ABI says that the upper bits have unspecified values.
It is true that LLVM ignores that part of ABI and makes its own incompatible
one and so doesn't add that, but it is wrong.

[Bug fortran/52279] Fortran translation issues

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Thu, Jul 02, 2020 at 03:53:22PM +, jakub at gcc dot gnu.org wrote:
> 
> --- Comment #7 from Jakub Jelinek  ---
> (In reply to kargl from comment #6)
> > There is no -fno-allow-invalid-boz option.  The option is
> > -fallow-invalid-boz.  fortan/lang.opt defines the options
> > with the RejectNegative annotation.
> 
> Why is it RejectNegative?

Because there is nothing to negate.

  real :: x = z'1234'
  end

is an invalid use of a BOZ.  gfortran 10.1 will issue an error
for this construct (and a number of previously documented and 
undocumented extensions).  Unfortunately, older vesions of
gfortran accepted the above without error or warning.  When I
fixed gfortran's handling of BOZ to conform to the Fortran
2008/2018 standard (i.e., emit an error for the above code),
I introduced -fallow-invalid-boz to down-grade the error to
a warning, so that older codes will compile.  

gfortran -c a.f90<-- error
gfortran -c -fallow-invalid-boz a.f90<-- warning
gfortran -c -fallow-invalid-boz -fno-allow-invalid-boz a.f90 <-- stupidity

> Is there some other option that acts as it negative option?

IMO, there is nothing to negative.  If you don't want the
option, then don't use it.

> If it is just a standalone boolean option, it should have a negative,
> so that if e.g. one uses -fallow-invalid-boz in $FFLAGS for most of
> files in some project, but there is a specific one that shouldn't
> allow it, one can just append -fno-allow-invalid-boz for it to cancel
> the earlier option.

This makes no sense to me.  gfortran will accept valid uses of a BOZ
without any option.  If you add -fallow-invalid-boz to $FFLAGS,
then you're simply accepting invalid Fortran (with a warning) in
addition to valid Fortran.  If a programmer is adding a new file 
to a project and $FFLAGS includes -fallow-invalid-boz, then programmer
will get a warning about invalid code instead of an error.  The
programmer is informed about the issue, and can make the necessary 
change, e.g., 

   real :: x = real(z'1234', 4)
   end

in the new file.

The point of the option is to allow backwards compatibility,
but to be verbose about the invalid Fortran; hopefully, to 
encourage the programmer to fix their code.

[Bug libgcc/96035] directories created when writing gcov data have limited rights compared to umask

[michelpalleau at yahoo dot fr]

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

--- Comment #1 from Michel Palleau  ---
Created attachment 48826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48826=edit
Proposal to create directories with process umask

[Bug libgcc/96035] New: directories created when writing gcov data have limited rights compared to umask

[michelpalleau at yahoo dot fr]

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

Bug ID: 96035
   Summary: directories created when writing gcov data have
limited rights compared to umask
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michelpalleau at yahoo dot fr
  Target Milestone: ---

In libgcov-driver-system.c, function create_file_directory(), any missing
directory is created with "mkdir(filename, 0755)".

>From mkdir's man page: the argument mode specifies the permissions to use. It
is modified by the process's umask in the usual way: the permissions of the
created directory are (mode & ~umask & 0777).

So if the process umask is set to 0, the directories will be created with
rights=0755, while gocv data files will be created with rights=0666.

I do not see the rationale to prevent group & other write permissions on the
created directories if the process umask is not preventing it.
I think the code should be "mkdir(filename, 0777)", so that all directories and
files are created with the process umask. No more, no less.

Long story: I work on an embedded project (with cross compilation), consisting
of several executables that are running with different uids. Even with a
umask=0, the first executable that ends will create the directories and its
coverage files, and the other executables won't be able to write their own
files. If I run all the executables with the same uid, I do not face the
problem.

[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.

[skorzennik at cfa dot harvard.edu]

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

--- Comment #5 from Sylvain Korzennik  ---
Hi Kargl,

  I am not interested in a protracted religious discussion, I simply do not use
gfortran for my work (research), but need to provides it form my users
(Smithsonian HPC cluster) as part of my duties.

  I've been doing HPC for 30+ years, and have used a long list of fortran
compilers, all with their own extensions (SUN, VAX/VMS, CRAY, you name it) and
idiosyncrasies. 

  Most/all vendors recognize that legacy code exists, so they incorporated
other's extensions and use a flexible approach to enforcing rules.

  GCC is the single one that decides that old code is trash and needs to be
rewritten. When 64b was introduced, gfortran decided that the UNIX record
integer embedded in the binary files ought to be 64b, making it impossible to
use existing binary files. That's simply shooting yourself in the foot. 

  As for a specific URL: https://www.cfa.harvard.edu/~avrett/pandora/, the
PANDORA radiative transfer code is made up of 4,559 routines. It was not well
designed, but it was started in 1959, with computers and compilers that had
many limitations, yet I can build it w/ Intel's and PGI's F77 compilers. It
needed minor one or two tweaks for runtime errors when moved from VMS to Linux. 

  Yet by writing
  parameter   (MSHLNG=50)
  integer MSHCNO,MSHLNG
  dimension   MSHCLR(MSHLNG)
  data MSHCLR,MSHCNO /MSHLNG*' ', 0/
gfortran imposes a rule that did not exist -or wasn't enforced- back when: the
integer declaration must be before the parameter one. The developer used
VAX/VMS tools and saw no reasons to code differently (GNU did not exists).

PGI and Intel do accept this order. 

I would have to reorder zillions of lines of code, going thru 4,000+ routines,
and re-validate this complex code... unless there is a magic/hidden flag
(-std=legacy isn't helping).

 At the end, you get what you paid for, hence we pay for PGI and Intel's
compilers. I stay away from gfortran, because I have things to get done...

 Best,
   Sylvain.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[mikpelinux at gmail dot com]

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

--- Comment #12 from Mikael Pettersson  ---
(In reply to Peter Bergner from comment #11)
> At some point in the past, GCC used to disable some instruction patterns
> depending on whether the binutils you're building against supports those
> instructions or not.  Now, GCC will always generate every instruction you
> ask it to, but you might get an assembler error trying to assemble those
> instructions.  I think that change was somewhere in the GCC8 or GCC9
> timeframe.  It could be your old binutils in GCC8 is silently turning off
> some support and that is causing the problem.  I'll try building a 2.23ish
> binutils and using that for my GCC8 build.

OK.  Meanwhile I had a successful bootstrap of GCC8 with binutils-2.34.

[Bug fortran/52279] Fortran translation issues

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
(In reply to kargl from comment #6)
> There is no -fno-allow-invalid-boz option.  The option is
> -fallow-invalid-boz.  fortan/lang.opt defines the options
> with the RejectNegative annotation.

Why is it RejectNegative?  Is there some other option that acts as it negative
option?  If it is just a standalone boolean option, it should have a negative,
so that if e.g. one uses -fallow-invalid-boz in $FFLAGS for most of files in
some project, but there is a specific one that shouldn't allow it, one can just
append -fno-allow-invalid-boz for it to cancel the earlier option.

[Bug c++/94905] Bogus warning -Werror=maybe-uninitialized

[moller at mollerware dot com]

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

--- Comment #8 from Chris Moller  ---
Created attachment 48825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48825=edit
Preprocessed testcase

gunzip  then compile with 

g++ -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Werror -rdynamic -g -O2 -MT
apl-Shape.o -MD -MP -MF .deps/apl-Shape.Tpo -c Shape-preprocessed.cc

[Bug c++/94905] Bogus warning -Werror=maybe-uninitialized

[moller at mollerware dot com]

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

Chris Moller  changed:

   What|Removed |Added

 CC||moller at mollerware dot com

--- Comment #7 from Chris Moller  ---
A little follow-up:

What's happening is that in gcc/tree-ssa-uninit.c, in
pass_late_warn_uninitialized::execute (function *fun),
warn_uninitialized_vars() is called with an argument of 1.  Then, in
warn_uninitialized_vars(), walk_aliased_vdefs (, use, check_defs, ,
NULL,_reached, limit); is called, returning with fentry_reached set to
false, which then leads to the warning being generated.

In gcc/tree-ssa-alias.c, in walk_aliased_vdefs_1(), *function_entry_reached =
true; is never reached because gimple_nop_p (def_stmt) never returns true.

I've attached a bit of preprocessed sample code that reliably fails with 

g++ -DHAVE_CONFIG_H -I. -I..-Wall -I sql -Werror -rdynamic -g -O2 -MT
apl-Shape.o -MD -MP -MF .deps/apl-Shape.Tpo -c Shape-preprocessed.cc

[Bug tree-optimization/96034] New: missed optimization with extended registers

[sshannin at gmail dot com]

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

Bug ID: 96034
   Summary: missed optimization with extended registers
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sshannin at gmail dot com
  Target Milestone: ---

Noticed in example for PR96009.

Consider this simple function:

double bar(char i) {
return i;
}

Compiled with -O3, we get:

movsbl  %dil, %edi
pxor  %xmm0, %xmm0
cvtsi2sdl %edi, %xmm0
ret

But aren't the movsb and pxor unnecessary? I think we should be able to just
cvtsi2sd and then ret.

Interestingly, compiling with -OS instead of -O3 manages to remove the pxor:
movsbl  %dil, %edi
cvtsi2sdl %edi, %xmm0
ret

Which is a one instruction better (unless -O3 is trying to keep the pxor for
alignment?), but even here I think the movsb could still go too.

Closest thing I find is PR48701, in that it also doesn't seem to understand
which registers are the same.

seth@fr-dev3:$ /toolchain14/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/toolchain14/bin/gcc
COLLECT_LTO_WRAPPER=/toolchain14/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc_9_1_0/configure --prefix=/toolchain14
--enable-languages=c,c++,fortran --enable-lto --disable-plugin
--program-suffix=-9.1.0 --disable-multilib
Thread model: posix
gcc version 9.1.0 (GCC)

[Bug fortran/52279] Fortran translation issues

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to markeggleston from comment #5)
> (In reply to markeggleston from comment #4)
> > Regarding comment 2.
> > 
> > Using -fallow-invalid-boz results in an ICE. I'll create a new PR.
> 
> Not true, tried it on the wrong file and jumped to the wrong conclusion.

This is wrong.

index 26ea01f..8ecf4ff 100644 (file)
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -67,7 +67,7 @@ gfc_invalid_boz (const char *msg, locus *loc)
   return false;
 }

-  const char hint[] = " [see %<-fno-allow-invalid-boz%>]";
+  const char *hint = " [see %<-fno-allow-invalid-boz%>]";
   size_t len = strlen (msg) + strlen (hint) + 1;
   char *msg2 = (char *) alloca (len);
   strcpy (msg2, msg);

There is no -fno-allow-invalid-boz option.  The option is
-fallow-invalid-boz.  fortan/lang.opt defines the options
with the RejectNegative annotation.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[bergner at gcc dot gnu.org]

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

--- Comment #11 from Peter Bergner  ---
(In reply to Mikael Pettersson from comment #9)
> binutils-2.23.88.0.1-13.fc20.ppc64
> 
> I can build a recent binutils release and retry the gcc-8 bootstrap with
> that tomorrow.  But since gcc-9/10/11 all bootstrap Ok, I find it difficult
> to suspect it's a binutils issue.

At some point in the past, GCC used to disable some instruction patterns
depending on whether the binutils you're building against supports those
instructions or not.  Now, GCC will always generate every instruction you ask
it to, but you might get an assembler error trying to assemble those
instructions.  I think that change was somewhere in the GCC8 or GCC9 timeframe.
 It could be your old binutils in GCC8 is silently turning off some support and
that is causing the problem.  I'll try building a 2.23ish binutils and using
that for my GCC8 build.

[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Sylvain Korzennik from comment #2)
> Merci Dominique. 
> 
> Will transmit info to MVAPICH2 ppl. 
> 
> The configuration script needs to be changed, this is not "faulty code", it
> is a test code part of the package configuration specifically to test if the
> "Fortran compiler gfortran will compile files that call the same routine
> with arguments of different types".

It is faulty code according to the Fortran standard.  It's been faulty code
since it was written.

  Fortran 66

  8.3.2 Referencing External Functions.

  An external function is referenced by using its reference (5.2) as
  a primary in an arithmetic or logical expression.  The actual arguments,
  which constitute the argument list, must agree in order, number, and
  type with the corresponding dummy argumets in the defining program
  unit.

  8.4.2 Referencing Subroutines.

  A subroutine is referenced by a CALL statement (7.1.2.4).  The actual
  arguments, which constitute the argument list, must agree in order,
  number, and type with the corresponding dummy arguments in the defining
  subprogram.

Modern Fortran allows a programmer to write a generic interfaces, which
allows one to handle this situation in a standard conforming way.

> Backward compatibility of gfortran is dismal (legacy code that builds fine
> w/ plethora of other fortran compiler fails to build w/ gfortran - ppl were
> writing fortran code for quite a wile, like one big scientific package
> started 60+ years ago, yet gfortran is the one that can't handle it - ifort
> and pgfortran do fine, it was written/developed on a VAX/VMS back when -
> author have long retired - desn't make the code obsolete, tho).

URLs to the actual code, please.  All that unnamed legacy code violates
the Fortran standard in one or more ways.  gfortran, unlikely the plethora
of compilers, is not a garbage disposal.

[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux

[willschm at gcc dot gnu.org]

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

--- Comment #10 from Will Schmidt  ---
(In reply to Segher Boessenkool from comment #8)
> So what is the instruction / builtin / anything where it fails?

I've managed to recreate the altivec_init_builtins ICE issue on a yellowdog
box.  (4-core 970MP).

Looks like it is trying to parse 
__builtin_altivec_vcmpnezb_p
at the time it fails.

Continuing to debug.

[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
You can find a quite long discussion about legacy at

https://groups.google.com/forum/#!topic/comp.lang.fortran/Ed8Mccy9zo8

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

[sinbal2l at gmail dot com]

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

--- Comment #10 from Inbal Levi  ---
Actually, you're right about the origin being [dcl.align]p5 here too, though
the test cases are different. 
Thanks.

[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.

[skorzennik at cfa dot harvard.edu]

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

--- Comment #2 from Sylvain Korzennik  ---
Merci Dominique. 

Will transmit info to MVAPICH2 ppl. 

The configuration script needs to be changed, this is not "faulty code", it is
a test code part of the package configuration specifically to test if the
"Fortran compiler gfortran will compile files that call the same routine with
arguments of different types".

I ran the configurator ok by setting env vars FFLAGS and FCFLAGS to -std=legacy
- hopefully it will build fine.

These kind of changes make GCC harder and harder to use/maintain in a
professional setting, IM(H)O. 

Backward compatibility of gfortran is dismal (legacy code that builds fine w/
plethora of other fortran compiler fails to build w/ gfortran - ppl were
writing fortran code for quite a wile, like one big scientific package started
60+ years ago, yet gfortran is the one that can't handle it - ifort and
pgfortran do fine, it was written/developed on a VAX/VMS back when - author
have long retired - desn't make the code obsolete, tho).

A bien entendeur.

[Bug fortran/96033] error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
This is the intended behavior. Compile the faulty code with
-std=legacy

[Bug fortran/96033] New: error: The Fortran compiler gfortran will not compile files that call the same routine with arguments of different types.

[skorzennik at cfa dot harvard.edu]

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

Bug ID: 96033
   Summary: error: The Fortran compiler gfortran will not compile
files that call the same routine with arguments of
different types.
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skorzennik at cfa dot harvard.edu
  Target Milestone: ---

Failed to configure to build mvapich2-2.3.[14] (both versions) using GCC
10.1.0. I have no problem building mvapich2 w/ GCC pre-10.x (9.3, 9.2, etc...)

Boils down to trying to compile
conftest.f
::
  program main
  integer a
  real b
  character c
  call foo1(a)
  call foo1(b)
  call foo1(c)
  end

This test code compiles fine w/ 9.3.0, or older GCC I have installed and tried
(9.2.0, 7.3.0 or 4.8.5).

[Bug fortran/96030] AArch64: Add an option to control 64bits simdclone of math functions for fortran

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The directive should be doing what
#pragma omp declare simd
does on the target and it is an ABI decision what exactly it does.

[Bug libstdc++/96029] [8/9/10/11 Regression] Inconsistencies with associative/unordered containers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |8.5

[Bug c++/94569] alignas(object) with a weaker (smaller) alignment than the alignas(type) of it's type compiles, inconsistent with the C++ standard

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Both bugs are violations of [dcl.align] p5 though. The bug is not that GCC
doesn't follow [basic.align] p1 (it does) but that it allows alignas to weaken
the alignment later. GCC should not allow alignas to weaken alignment on any
declaration, whether a class declaration or variable declaration, and that's PR
65685. I've added a more complete testcase there, which includes alignas on
object declarations.

[Bug c++/65685] Reducing alignment with alignas should be rejected

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
There are two facets to this. GCC allows alignas with a weaker alignment on a
type, and ignores it. GCC also allows alignas with a weaker alignment on an
object declaration, and reduces the alignment. In both cases it would be
conforming to issue a warning, even if the current behaviour is retained.

struct alignas(8) S {};
struct alignas(2) U {
  S s;
}; // { dg-error "alignment" }

// This assertion passes, meaning the invalid alignas(2) was silently ignored.
static_assert( alignof(U) == alignof(S), "" );

alignas(1) S s;  // { dg-error "align" }
alignas(1) U u;  // { dg-error "align" }

#ifdef __GNUC__
// These assertions pass, so GCC honours the invalid alignas(1) requests.
static_assert( alignof(s) == 1, "GCC reduced alignment of s" ); // WRONG!
static_assert( alignof(u) == 1, "GCC reduced alignment of u" ); // WRONG!
#endif

[Bug other/96032] Feature request: Add a way to format output from --fdiagnostics-format=json

[christian.friedl at gmx dot at]

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

--- Comment #1 from Christian Friedl  ---
Disclaimer: I posted a request for help regarding this exact feature on the
gcc-help list. (https://gcc.gnu.org/pipermail/gcc-help/2020-July/139110.html)

After reading through the list I came to the conclusion that this is not
implemented and probably a feature request would be more appropriate.

[Bug other/96032] New: Feature request: Add a way to format output from --fdiagnostics-format=json

[christian.friedl at gmx dot at]

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

Bug ID: 96032
   Summary: Feature request: Add a way to format output from
--fdiagnostics-format=json
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christian.friedl at gmx dot at
  Target Milestone: ---

I would like to implement a filter for warnings from gfortran using
--fdiagnostics-format=json . To print out the warnings in the way gfortran does
normally I would need a way to convert them to text which should be the same as
what --fdiagnostics-format=json produces. Since gfortran itself knows best how
to print its warnings - could you provide that functionality?

[Bug rtl-optimization/96031] New: suboptimal codegen for store low 16-bits value

[zhongyunde at tom dot com]

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

Bug ID: 96031
   Summary: suboptimal codegen for store low 16-bits value
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhongyunde at tom dot com
  Target Milestone: ---

For the following code, as instruction strh only store the low 16-bits value,
so the 'and w2, w2, 65535 ' is redundant.
test base on the ARM64 gcc 8.2 on https://gcc.godbolt.org/, so get complicated
assemble.

typedef unsigned int UINT32;
typedef unsigned short UINT16;


UINT16 array[12];

void foo (UINT32 len, UINT32 step)  
{
UINT32 index = 1;

for (index = 1 ; index < len; index++ )
{
array[index] = index * step;
}
}

// the assemble of kernel loop body --
b   .L4 //
.L6:
add x3, x3, 2 // ivtmp.6, ivtmp.6,
.L4:
strhw2, [x4, 2] // ivtmp.4, MEM[base: _2, offset: 2B]
add w2, w1, w2// tmp105, _12, ivtmp.4
and w2, w2, 65535 // ivtmp.4, tmp105 
cmp x3, x0// ivtmp.6, _23
mov x4, x3// ivtmp.6, ivtmp.6
bne .L6 //,

[Bug libstdc++/96029] [8/9/10/11 Regression] Inconsistencies with associative/unordered containers

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||6.5.0
Version|unknown |10.1.0
Summary|Inconsistencies with|[8/9/10/11 Regression]
   |associative/unordered   |Inconsistencies with
   |containers  |associative/unordered
   ||containers
 Ever confirmed|0   |1
   Last reconfirmed||2020-07-02
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
There are two separate regressions here, the unordered_xxx one starting with
4.9.0 and the RB tree one starting with 7.1.0

[Bug tree-optimization/96028] [11 Regression] SEGV in vect_create_constant_vectors

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Fixed.

[Bug tree-optimization/96028] [11 Regression] SEGV in vect_create_constant_vectors

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:105ecbea5f402713130fef4d41bb000e2d23493b

commit r11-1788-g105ecbea5f402713130fef4d41bb000e2d23493b
Author: Richard Biener 
Date:   Thu Jul 2 11:45:06 2020 +0200

tree-optimization/96028 - fix bogus externalizing of SLP node

This guards externalizing a SLP node when it fails to code generate
to actually have scalar defs we can use.  It also makes failure
to do so not fell the whole SLP instance but instead try this again
on the parent.

2020-07-02  Richard Biener  

PR tree-optimization/96028
* tree-vect-slp.c (vect_slp_convert_to_external): Make sure
we have scalar stmts to use.
(vect_slp_analyze_node_operations): When analyzing a child
failed try externalizing the parent node.

[Bug debug/95343] IPA-SRA can result in wrong debug info about removed function arguments

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:053c88093a45f175f446eda009f3312e4e508514

commit r11-1787-g053c88093a45f175f446eda009f3312e4e508514
Author: Martin Jambor 
Date:   Thu Jul 2 14:30:50 2020 +0200

ipa-sra: Prevent constructing debug info from wrong argument

The mechanism generating debug info for removed parameters did not
adjust index of the argument in the call statement to take into
account extra arguments IPA-SRA might have produced when splitting a
strucutre.  This patch addresses that omission and stops gdb from
showing incorrect value for the removed parameter and says "value
optimized out" instead.  The guality testcase will end up as
UNSUPPORTED in the results which is how Richi told me on IRC we deal
with this.

It is possible to generate debug info to actually show the value of
the removed parameter but so far my approaches to do just that seem
toocontroversial
(https://gcc.gnu.org/pipermail/gcc-patches/2020-May/546705.html), so
before I come up with something better I'd like to push this to master
and the gcc-10 branch in time for the GCC 10.2 release.

gcc/ChangeLog:

2020-07-01  Martin Jambor  

PR debug/95343
* ipa-param-manipulation.c (ipa_param_adjustments::modify_call):
Adjust
argument index if necessary.

gcc/testsuite/ChangeLog:

2020-07-01  Martin Jambor  

PR debug/95343
* gcc.dg/guality/pr95343.c: New test.

[Bug target/90932] [nvptx] internal compiler error: in tree_to_shwi, at tree.c

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #4 from Tom de Vries  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/549100.html

[Bug fortran/96030] New: AArch64: Add an option to control 64bits simdclone of math functions for fortran

[bule1 at huawei dot com]

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

Bug ID: 96030
   Summary: AArch64: Add an option to control 64bits simdclone of
math functions for fortran
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bule1 at huawei dot com
  Target Milestone: ---
Target: AARCH64

Created attachment 48824
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48824=edit
patch for the problem

Hi,

I found that currently fortran can only enable simdclone of math functions by
declare "!GCC$ builtin (exp) attributes simd" derivative. This kind of
declaration seems cannot indicate whether the simdlen is 64bits or 128bits. By
reading the source code and some tests, I believe the simdclone of both mode
will be generated with a single derivative declaration. At present, vector math
lib for aarch64  (mathlib and sleef) donot support the 64bits mode functions.
So when I want to enable the simd math on some application, if the application
has an oppotunity for 64bits mode simdclone, there is no matching math library
call, which leads to a link time error. 

For now, to solve this problem, I added a new backend option -msimdmath-64 to
control the generation of the 64bits mode simdclone, which is default to
disable. The patch is attached.

I think it is reasonable to set a switch to control the generation of the
64bits mode simdclone. Do we have something alike already? 

If not, is this the right way to go?

Thanks.