[Bug c++/91933] [10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_simple_base_path, at cp/class.c:541

[asolokha at gmx dot com]

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

--- Comment #1 from Arseny Solokha  ---
clang++ 9 and icc 18 actually accept this code.

[Bug c++/91933] New: [10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_simple_base_path, at cp/class.c:541

[asolokha at gmx dot com]

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

Bug ID: 91933
   Summary: [10 Regression] ICE: tree check: expected class
'type', have 'exceptional' (error_mark) in
build_simple_base_path, at cp/class.c:541
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.0-alpha20190929 snapshot (r276272) ICEs when compiling the following
testcase extracted from test/CXX/drs/dr20xx.cpp from the clang 9.0.0 test
suite:

struct NoMut1 { int a, b; };
struct NoMut3 : NoMut1 {
  constexpr NoMut3(int a, int b) : NoMut1{a, b} {}
};
void mutable_subobjects() {
  constexpr NoMut3 nm3 = {1, 2};
  struct A {
void f() {
  static_assert(nm3.a == 1, "");
}
  };
}

% g++-10.0.0-alpha20190929 -c jigwb82y.cpp
jigwb82y.cpp: In member function 'void mutable_subobjects()::A::f()':
jigwb82y.cpp:9:21: error: use of local variable with automatic storage from
containing function
9 |   static_assert(nm3.a == 1, "");
  | ^~~
jigwb82y.cpp:6:20: note: 'constexpr const NoMut3 nm3' declared here
6 |   constexpr NoMut3 nm3 = {1, 2};
  |^~~
jigwb82y.cpp:9:25: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in build_simple_base_path, at cp/class.c:541
9 |   static_assert(nm3.a == 1, "");
  | ^
0x7d4e37 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/tree.c:9973
0x5bb172 build_simple_base_path
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/tree.h:3390
0x8bfd62 build_simple_base_path
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/class.c:555
0x8d809d build_base_path(tree_code, tree_node*, tree_node*, int, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/class.c:424
0xa7b714 build_class_member_access_expr(cp_expr, tree_node*, tree_node*, bool,
int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/typeck.c:2557
0xa825f3 finish_class_member_access_expr(cp_expr, tree_node*, bool, int)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/typeck.c:3162
0x9ca816 cp_parser_postfix_dot_deref_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:7800
0x9c0eca cp_parser_postfix_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:7445
0x9a4db0 cp_parser_binary_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:9479
0x9a5cd2 cp_parser_assignment_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:9777
0x9a573e cp_parser_constant_expression
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:10071
0x9a59a7 cp_parser_static_assert
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:14505
0x9b4108 cp_parser_declaration_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:13012
0x9b4ba0 cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:11337
0x9b5d25 cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:11699
0x9b5df5 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:11653
0x9cae29 cp_parser_function_body
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:22702
0x9cae29 cp_parser_ctor_initializer_opt_and_function_body
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:22753
0x9cdd55 cp_parser_function_definition_after_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:28074
0x9cef18 cp_parser_late_parsing_for_member
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190929/work/gcc-10-20190929/gcc/cp/parser.c:28959

[Bug fortran/87908] ICE in check_interface0, at fortran/interface.c:1841

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 CC||egallager at gcc dot gnu.org
   Severity|normal  |minor

--- Comment #2 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #1)
> > ICE affects versions 8/9 :
> 
> For gcc7 I see
> 
> (null):0: confused by earlier errors, bailing out
> 
> which is equivalent to an ICE when gcc is configured with
> --enable-checking=release
> 
> gcc6 gives
> 
> pr87908.f90:6:21:
> 
>generic :: read(formatted) => g
>  1
> Error: Expected '=>' at (1)
> pr87908.f90:12:20:
> 
>interface read(formatted)
> 1
> Error: Syntax error: Trailing garbage in INTERFACE statement at (1)
> pr87908.f90:13:9:
> 
>   procedure g
>  1
> Error: Unclassifiable statement at (1)
> pr87908.f90:14:9:
> 
>end interface
>  1
> Error: Expecting END SUBROUTINE statement at (1)
> 

so that makes this an ice-on-invalid then

[Bug fortran/84245] [7/8/9/10 Regression] ICE in delete_root, at fortran/bbt.c:150

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||error-recovery
 CC||egallager at gcc dot gnu.org
   Severity|normal  |minor

[Bug c++/80496] missing diagnostic regarding noreturn mismatch in function pointer initialization

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> cc-ing diagnostics maintainers

Since this has to do with attribute mismatches, Martin Sebor might be
interested in this, too.

[Bug middle-end/90043] Turn on -Winit-self by default for -Wuninitialized

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-29
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Confirmed.  Let me try to remember to submit a patch for GCC 10.

[Bug middle-end/90043] Turn on -Winit-self by default for -Wuninitialized

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug c/60256] No -Wuninitialized warning for strcpy copying to self

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #12 from Martin Sebor  ---
I'm going to close this as WONTFIX.  The -Wrestrict warning seems good enough
for the unlikely strcpy(s, s) case, and the much more probable test case below
does get diagnosed by -Wuninitialized:

$ cat pr60256.c && gcc -O2 -S -Wall pr60256.c
void f (char *d)
{
  char* s;
  strcpy (d, s);
}
pr60256.c: In function ‘f’:
pr60256.c:6:3: warning: ‘s’ is used uninitialized in this function
[-Wuninitialized]
6 |   strcpy (d, s);
  |   ^

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org]

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

Bug 60256 Summary: No -Wuninitialized warning for strcpy copying to self
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60256

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

[Bug c++/35278] extern declaration causes uninitialized reference to go unnoticed

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail||10.0, 6.3.0, 7.0.1, 8.3.0,
   ||9.1.0

--- Comment #2 from Martin Sebor  ---
No change in GCC 9 or 10.

[Bug middle-end/83859] Please add new attribute which will establish relation between parameters for buffer and its size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||madcoder at debian dot org

--- Comment #9 from Martin Sebor  ---
*** Bug 31893 has been marked as a duplicate of this bug. ***

[Bug middle-end/31893] Please provide an "inout" attribute for function parameters.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic,
   ||missed-optimization
 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
  Component|c   |middle-end
 Resolution|--- |DUPLICATE

--- Comment #10 from Martin Sebor  ---
With the patch for pr83859 applied
(https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01690.html) GCC diagnoses the
uninitialized access in the test case from comment #1:

$ cat pr31893.c && gcc -S -Wall pr31893.c
struct foo { int toto; };

__attribute__ ((read_only)) void do_bar(const struct foo *);

int main(void) {
struct foo foo;
do_bar();
return 0;
}
pr31893.c: In function ‘main’:
pr31893.c:7:5: warning: ‘foo’ is used uninitialized in this function
[-Wuninitialized]
7 | do_bar();
  | ^~~~

I'm going to resolve this request as a duplicate of pr83859.

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

[Bug middle-end/31279] Uninitialized warning for call-by-reference arguments with known intent(in)

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
The C family patch: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01690.html

[Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #28 from Martin Sebor  ---
The patch I developed for pr80806 introduces the read_only and read_write
attributes that both enable this warning and also make optimizations possible:

$ cat pr10138.c && gcc -O -S -Wall pr10138.c
__attribute__ ((read_only)) int atoi (const char *);

int foo()
{
  char buf[10];
  return atoi (buf);
}
pr10138.c: In function ‘foo’:
pr10138.c:6:10: warning: ‘buf’ is used uninitialized in this function
[-Wuninitialized]
6 |   return atoi (buf);
  |  ^~

For read-only functions like atoi it would be easy to issue the warning even in
the absence of the attribute.  There's some potential for false positives, such
as in C++ and mutable members, but I expect those would be rare and more than
offset by the bugs the warning would find.  Let me see about it.

[Bug c++/90463] Documentation: -Wunused not listed among the options enabled by -Wall

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
The manual also says:

  Some options, such as -Wall and -Wextra, turn on other options, such as
-Wunused, which may turn on further options, such as -Wunused-value. 

So the list under -Wall should include -Wunused.  Confirmed.

[Bug c/88660] [8/9/10 Regression] Invalid report of "set but used variable" with -O

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-29
 CC||msebor at gcc dot gnu.org
  Known to work||7.3.0
 Blocks||89180
Summary|Invalid report of "set but  |[8/9/10 Regression] Invalid
   |used variable" with -O  |report of "set but used
   ||variable" with -O
 Ever confirmed|0   |1
  Known to fail||10.0, 8.3.0, 9.2.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Bisection points to r254930 as the revision that caused the
regression:

r254930 | jakub | 2017-11-19 12:17:01 -0500 (Sun, 19 Nov 2017) | 28 lines

PR c/66618
PR c/69960
c-family/
* c-common.h (c_fully_fold): Add LVAL argument defaulted to false.
c/
* c-parser.c (c_parser_omp_atomic): Pass true as LVAL to c_fully_fold
where needed.
* c-typeck.c (build_unary_op, build_modify_expr, build_asm_expr,
handle_omp_array_sections): Likewise.
(digest_init): Don't call decl_constant_value_for_optimization.
* c-tree.h (decl_constant_value_for_optimization): Removed.
* c-fold.c (c_fold_array_ref): New function.
(c_fully_fold_internal): Add LVAL argument, propagate it through
recursive calls.  For VAR_P call decl_constant_value and
unshare if not LVAL and either optimizing or IN_INIT.  Remove
decl_constant_value_for_optimization calls.  If IN_INIT and not LVAL,
fold ARRAY_REF with STRING_CST and INTEGER_CST operands.
(c_fully_fold): Add LVAL argument, pass it through to
c_fully_fold_internal.
(decl_constant_value_for_optimization): Removed.
cp/
* cp-gimplify.c (c_fully_fold): Add LVAL argument, call
cp_fold_maybe_rvalue instead of cp_fold_rvalue and pass it !LVAL.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180
[Bug 89180] [meta-bug] bogus/missing -Wunused warnings

[Bug c/80806] gcc does not warn if local array is memset only

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Target Milestone|--- |10.0

--- Comment #8 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01690.html

[Bug middle-end/83859] Please add new attribute which will establish relation between parameters for buffer and its size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
  Component|c   |middle-end
   Target Milestone|--- |10.0

--- Comment #8 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01690.html

[Bug target/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc

[joey.dumont at gmail dot com]

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

Joey Dumont  changed:

   What|Removed |Added

Version|9.1.0   |9.2.0

--- Comment #7 from Joey Dumont  ---
I realized I made a silly mistake after I posted this. I was meant to try this
version for the target compiler, not the host compiler.

I successfully built the target compiler (mips64-elf) with r273174. 

I changed the affected version to 9.2.0, as 9.1.0 was my host compiler, not the
target compiler. I can test with 9.2.1 and other versions, if necessary.

[Bug target/91474] Internal compiler error when building mabi=32 mips64-elf cross-compiler: segfault in parallel_settings.cc

[joey.dumont at gmail dot com]

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

--- Comment #8 from Joey Dumont  ---
I realized I made a silly mistake after I posted this. I was meant to try this
version for the target compiler, not the host compiler.

I successfully built the target compiler (mips64-elf) with r273174. 

I changed the affected version to 9.2.0, as 9.1.0 was my host compiler, not the
target compiler. I can test with 9.2.1 and other versions, if necessary.

[Bug fortran/91641] [9/10 Regression] ICE in gfc_conv_is_contiguous_expr, at fortran/trans-intrinsic.c:2857

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Sep 29 19:12:08 2019
New Revision: 276272

URL: https://gcc.gnu.org/viewcvs?rev=276272=gcc=rev
Log:
2019-09-29  Steven G. Kargl  

PR fortran/91641
* check.c (gfc_check_is_contiguous): null() cannot be an actual
argument to is_contiguous().

2019-09-29  Steven G. Kargl  

PR fortran/91641
* gfortran.dg/pr91641.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr91641.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog

[Bug c/44677] Warn for variables incremented but not used

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #8)
> I would expect handling -Wunused-but-set-variable during Gimplification to
> make detecting these sorts of things possible at least in the basic cases.

That is way too late.

[Bug c/44677] Warn for variables incremented but not used

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||89180

--- Comment #8 from Martin Sebor  ---
I would expect handling -Wunused-but-set-variable during Gimplification to make
detecting these sorts of things possible at least in the basic cases.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180
[Bug 89180] [meta-bug] bogus/missing -Wunused warnings

[Bug c/41142] make implicit pointer conversions an error when sizeof(int) != sizeof(void *)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Martin Sebor  ---
Closing due to no feedback.

[Bug c++/86465] [7/8/9/10 Regression] C++17 triggers: ‘’ may be used uninitialized in this function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
See also pr80635.

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

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #1 from John Paul Adrian Glaubitz  ---
I have created a guide which explains how to install Debian inside an emulated
qemu-system-m68k VM:

> https://wiki.debian.org/M68k/QemuSystemM68k

The guide is not complete yet, I will finish it throughout next week.

The bounty on BountySource.com can be found at:

> https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases

[Bug preprocessor/91932] New: #pragma does not silence floating constant overflow warnings

[lh_mouse at 126 dot com]

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

Bug ID: 91932
   Summary: #pragma does not silence floating constant overflow
warnings
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

### Testcase 1:

```c
#pragma GCC diagnostic ignored "-Woverflow"
double x = 1.0e1;
```
results in
```
prog.cc:2:1: warning: floating constant exceeds range of 'double' [-Woverflow]
2 | double x = 1.0e1;
  | ^~
```


### Testcase 2:  

```c
#pragma GCC diagnostic ignored "-Woverflow"

#define CONS(a,b)  1.0##e##a##b

int main()
  {
double x = CONS(-,1);
double y = CONS(+,1);
(void)(x+y);
  }
```
results in:
```
prog.cc:7:3: warning: floating constant truncated to zero [-Woverflow]
7 |   double x = CONS(-,1);
  |   ^~
prog.cc:8:3: warning: floating constant exceeds range of 'double' [-Woverflow]
8 |   double y = CONS(+,1);
  |   ^~
```


This overflow/underflow is intended sometimes.

[Bug fortran/91714] Accepts type statement without delimiter in free form

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sun Sep 29 16:19:58 2019
New Revision: 276270

URL: https://gcc.gnu.org/viewcvs?rev=276270=gcc=rev
Log:
2019-09-29  Steven G. Kargl  

PR fortran/91714
* decl.c (gfc_match_decl_type_spec):  Issue errors for a few
mangled types.

2019-09-29  Steven G. Kargl  

PR fortran/91714
* gfortran.dg/dec_type_print_3.f90: Update dg-error regex.
* gfortran.dg/pr91714.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr91714.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dec_type_print_3.f90

[Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended

[steinar+gcc at gunderson dot no]

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

--- Comment #22 from Steinar H. Gunderson  ---
Yes; I had a project recently where I won 15% overall performance (!) by using
an asm statement with bsf instead of ffsll(). (This skipped both the sign
extension and the check for zero; my argument could never be zero, due to a
loop condition, but GCC didn't manage to remove the check nevertheless.)

[Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended

[david.bolvansky at gmail dot com]

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

Dávid Bolvanský  changed:

   What|Removed |Added

 CC||david.bolvansky at gmail dot 
com

--- Comment #21 from Dávid Bolvanský  ---
long long foo (int x) { return __builtin_ctz (x); }

still produces 

foo(int):
xor eax, eax
tzcnt   eax, edi
cdqe
ret


instead of

foo(int):# @foo(int)
tzcnt   eax, edi
ret

[Bug target/91931] [10 Regression] ICE in decompose, at rtl.h:2277

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 46977
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46977=edit
gcc10-pr91931.patch

Untested fix.

[Bug rtl-optimization/91931] [10 Regression] ICE in decompose, at rtl.h:2277

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Seems to be a x86 backend bug, will have a look.

[Bug rtl-optimization/91931] [10 Regression] ICE in decompose, at rtl.h:2277

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-29
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r275959.

[Bug fortran/91726] [7/8/9/10 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas  ---
Author: pault
Date: Sun Sep 29 10:12:42 2019
New Revision: 276269

URL: https://gcc.gnu.org/viewcvs?rev=276269=gcc=rev
Log:
2019-09-29  Paul Thomas  

PR fortran/91726
* resolve.c (gfc_expr_to_initialize): Bail out with a copy of
the original expression if the array ref is a scalar and the
array_spec has corank.
* trans-array.c (gfc_conv_array_ref): Such expressions are OK
even if the array ref codimen is zero.
* trans-expr.c (gfc_get_class_from_expr): New function taken
from gfc_get_vptr_from_expr.
(gfc_get_vptr_from_expr): Call new function.
* trans-stmt.c (trans_associate_var): If one of these is a
target expression, extract the class expression from the target
and copy its fields to a new target variable.
* trans.h : Add prototype for gfc_get_class_from_expr.

2019-09-29  Paul Thomas  

PR fortran/91726
* gfortran.dg/coarray_poly_9.f90 : New test.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray_poly_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/90543] Build failure on MINGW for gcc-9.1.0

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Sun Sep 29 10:06:40 2019
New Revision: 276268

URL: https://gcc.gnu.org/viewcvs?rev=276268=gcc=rev
Log:
PR bootstrap/90543
* optc-save-gen.awk: Fix up printing string option differences.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/optc-save-gen.awk

[Bug c++/88562] Incorrect pointer incrementing on SH4

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #5 from Oleg Endo  ---
I have tried this on current trunk (GCC 10) and it shows the same issue. 
During SH specific sign/zero extension optimizations, the function
sh_extending_set_of_reg::use_as_extended_reg drops the REG_INC note from the
memory insn, when it converts the non-extending memory load (with post-inc
address) into sign-extending memory load.