[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns

[lhyatt at gmail dot com]

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gmail dot com

--- Comment #13 from Lewis Hyatt  ---
Created attachment 46882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46882=edit
partial patch illustrating the intended approach

Hello-

I would like to help fix this up. I have another patch, hopefully being
approved soon, that will implement support for extended characters in
identifiers. If that sees some use, then this problem will become more
noticeable, so it would be nice to address the column numbering issue at the
same time.

It's worth noting that there is a related problem not specifically mentioned so
far in this bug report -- in addition to the column number, the caret output in
diagnostic-show-locus.c also goes to the same wrong column.

Attached for comment is a preliminary patch (no tests yet) that fixes the
column number only (not the caret). If the overall approach seems sound, I am
happy to flesh it out to handle all the fancy diagnostics too. I have a couple
questions about the implementation, though, which I thought worthwhile to clear
up before proceeding further.

Here is a useful test case for this:

===
const char* smile = ""; int x = y;
===

Currently it outputs:

t.cpp:1:65: error: ‘y’ was not declared in this scope
 const char* smile = ""; int x = y;
 ^

And indeed the column number and caret are both incorrect (but consistent with
each other). Not visible here is that the 'y' is properly colorized in the
source line. That works as-is because the ANSI color escapes should be inserted
at the proper byte, not the proper display column. So the machinery in
diagnostic-show-locus.c requires both the byte count and the logical column
count in order to both colorize the source line and put the caret at the right
place. 

Therefore the approach I chose was to keep most things exactly as they are --
all locations are tracked via byte counts just as now. Then all that's
necessary is to compute the logical display column just when it's needed, at
the time the diagnostic is output. This seems tenable because
location_get_source_line() already lets us retrieve the line and work with it
efficiently. That's the idea I went with here to adjust the column number;
happy to hear any feedback before diving in to applying the same idea
throughout diagnostic-show-locus.c.

I have one other question though. This quick attempt uses wchar.h, namely the
mbrtowc() and wcwidth() functions. Firstly, it seems unfortunate to introduce a
dependency on those, which may be problematic for Windows, etc. (I borrowed the
same configure checks used in intl.c for that.) But also, this will always
convert multibyte input files using the user's locale, whereas GCC doesn't work
like this when lexing files -- it ignores the locale and rather defaults to
UTF-8 unless overridden by -finput-charset. It seems that in a perfect world
diagnostics parsing of the source should work the same way.

I feel like the most portable solution is just to use directly the necessary
code (from glibc or gnulib or from scratch or wherever) to handle the wcwidth()
functionality, and tweak it for this purpose. It's in essence just a binary
search in a table. Basically I would convert the source line from the input
charset to UTF-8 the same way the file is read on original input (using the
facilities in libcpp/charset.c), and then I would just need a variant of
wcwidth() that, rather than dealing with wchar_t and locales, simply takes
UTF-8 input and returns the necessary width. Does this seem like a good
approach? Otherwise, if I keep the use of wchar APIs, I think it would be
necessary to make a temporary change to the locale when computing the display
column, as dictated by the input charset.

Note that this also brings up an unrelated question with -finput-charset. Say
right now, I have a file in latin1 encoding and it is processed with
-finput-charset=latin1, and then I compile it from a UTF-8 locale. If a source
line is output in diagnostics, currently it gets output in the latin1 encoding
and produces unreadable characters on the terminal. With changes along the
lines I propose in the previous paragraph, the diagnostics would end up being
output in UTF-8 (or whatever the current locale demands), which I think is
maybe an improvement as well.

Thanks for any suggestions.

-Lewis

[Bug objc/90709] [meta-bug] GNU Objective C (C++) cannot consume current headers on Darwin platforms.

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  ---
Author: iains
Date: Sun Sep 15 02:38:25 2019
New Revision: 275724

URL: https://gcc.gnu.org/viewcvs?rev=275724=gcc=rev
Log:
[objective-c/c++, testsuite] Workaround for PR90709.

Since we cannot parse the current NeXT headers, because of PR90709 and its
dependents, we have a large amount of testsuite noise for Darwin platforms.
In order to restore the usefulness of the testsuite, we are going add headers
without the modern syntax elements that trigger the bug, and use these for
test runs on newer Darwin.

The headers are imported from GNUStep, with some local modifications to make
sure that __BLOCKS__ is honoured as a gate for Apple-style blocks closures.

CF-CFString.h, F-NS*.h are proxy headers that use the installed CoreFoundation
or Foundation headers on systems <= Darwin12 and the GNUStep headers for newer.

Use the CF-CFString.h, F-NS*.h proxy headers where needed in the objective-c
testsuite. Make minor adjustments to tests as required, providing that those
do not alter the test intent.

2019-09-15  Iain Sandoe  

Backport from mainline.
2019-06-15  Iain Sandoe  

PR objc/90709
* obj-c++.dg/proto-lossage-7.mm: Use proxy headers.
* obj-c++.dg/strings/const-cfstring-2.mm: Likewise.
* obj-c++.dg/strings/const-cfstring-5.mm: Likewise
* obj-c++.dg/strings/const-str-12.mm: Likewise.
* obj-c++.dg/syntax-error-1.mm: Likewise.
* obj-c++.dg/torture/strings/const-cfstring-1.mm: Likewise.
* obj-c++.dg/torture/strings/const-str-10.mm: Likewise.
* obj-c++.dg/torture/strings/const-str-11.mm: Likewise.
* obj-c++.dg/torture/strings/const-str-9.mm: Likewise.
* obj-c++.dg/cxx-ivars-3.mm: Skip on later Darwin, where the 10.4 API
in no longer supported, also on m64 where there's no meaning to it.
* obj-c++.dg/isa-field-1.mm: Suppress unwanted warning, add comment
why.
* obj-c++.dg/objc-gc-3.mm: Skip for Darwin > 16, the API use is an
error
there.
* obj-c++.dg/qual-types-1.mm: Prune a spurious l64 warning.
* obj-c++.dg/stubify-1.mm: Tidy up after better compiler warnings.
* obj-c++.dg/stubify-2.mm: Likewise.
* obj-c++.dg/try-catch-1.mm: Likewise.
* obj-c++.dg/try-catch-3.mm: Likewise.

Backport from mainline.
2019-06-15  Iain Sandoe  

PR objc/90709
* objc.dg/encode-7-next-64bit.m: Use proxy headers.
* objc.dg/image-info.m: Likewise.
* objc.dg/method-6.m: Likewise.
* objc.dg/no-extra-load.m: Likewise.
* objc.dg/objc-foreach-4.m: Likewise.
* objc.dg/objc-foreach-5.m: Likewise.
* objc.dg/proto-lossage-7.m: Likewise.
* objc.dg/strings/const-cfstring-2.m: Likewise.
* objc.dg/strings/const-cfstring-5.m: Likewise.
* objc.dg/strings/const-str-12b.m: Likewise.
* objc.dg/symtab-1.m: Likewise.
* objc.dg/torture/strings/const-cfstring-1.m: Likewise.
* objc.dg/torture/strings/const-str-10.m: Likewise.
* objc.dg/torture/strings/const-str-11.m: Likewise.
* objc.dg/torture/strings/const-str-9.m: Likewise.
* objc.dg/zero-link-1.m: Likewise.
* objc.dg/zero-link-2.m: Likewise.
* objc.dg/zero-link-3.m: Likewise.
* objc.dg/isa-field-1.m: Suppress unwanted warning, add comment why.
* objc.dg/headers.m: XFAIL for Darwin14-19.
* objc.dg/objc-gc-4.m: Skip for Darwin > 16, the API use is an error
there.

Backport from mainline.
2019-06-15  Iain Sandoe  

PR objc/90709
* objc-obj-c++-shared/CF-CFString.h: New.
* objc-obj-c++-shared/F-NSArray.h: New.
* objc-obj-c++-shared/F-NSAutoreleasePool.h: New.
* objc-obj-c++-shared/F-NSObject.h: New.
* objc-obj-c++-shared/F-NSString.h: New.
* objc-obj-c++-shared/F-NSValue.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFArray.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFAvailability.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFBase.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFCharacterSet.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFData.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFDictionary.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFLocale.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFString.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSArray.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSAutoreleasePool.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSDate.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSEnumerator.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSGeometry.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSObjCRuntime.h: New.
* 

[Bug fortran/91556] Problems with better interface checking

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #29 from Thomas Koenig  ---
I think this is resolved now.

[Bug fortran/91557] [7/8/9/10 Regression] Bogus warning about unused dummy argument _formal_*

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Sep 14 20:40:55 2019
New Revision: 275719

URL: https://gcc.gnu.org/viewcvs?rev=275719=gcc=rev
Log:
2019-09-14  Thomas Koenig  

PR fortran/91557
PR fortran/91556
* frontend-passes.c (check_externals_procedure): Reformat argument
list. Use gfc_compare_actual_formal instead of gfc_procedure_use.
* gfortran.h (gfc_symbol): Add flag error.
* interface.c (gfc_compare_interfaces): Reformat.
(argument_rank_mismatch): Add where_formal argument. If it is
present, note that the error is between different calls.
(compare_parameter): Change warnings that previously dependended
on -Wargument-mismatch to unconditional.  Issue an error / warning
on type mismatch only once.  Pass where_formal to
argument_rank_mismatch for artificial variables.
(compare_actual_formal): Change warnings that previously
dependeded on -Wargument-mismatch to unconditional.
(gfc_check_typebound_override): Likewise.
(gfc_get_formal_from_actual_arglist): Set declared_at for
artificial symbol.
* invoke.texi: Extend description of -fallow-argument-mismatch.
Delete -Wargument-mismatch.
* lang.opt: Change -Wargument-mismatch to do-nothing option.
* resolve.c (resolve_structure_cons): Change warnings that
previously depended on -Wargument-mismatch to unconditional.
* trans-decl.c (generate_local_decl): Do not warn if the symbol is
artificial.

2019-09-14  Thomas Koenig  

PR fortran/91557
PR fortran/91556
* gfortran.dg/argument_checking_20.f90: New test.
* gfortran.dg/argument_checking_21.f90: New test.
* gfortran.dg/argument_checking_22.f90: New test.
* gfortran.dg/argument_checking_23.f90: New test.
* gfortran.dg/warn_unused_dummy_argument_5.f90: New test.
* gfortran.dg/bessel_3.f90: Add pattern for type mismatch.
* gfortran.dg/g77/20010519-1.f: Adjust dg-warning messages to new
handling.
* gfortran.dg/pr24823.f: Likewise.
* gfortran.dg/pr39937.f: Likewise.


Added:
trunk/gcc/testsuite/gfortran.dg/argument_checking_20.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_21.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_22.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_23.f90
trunk/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bessel_3.f90
trunk/gcc/testsuite/gfortran.dg/g77/20010519-1.f
trunk/gcc/testsuite/gfortran.dg/pr24823.f
trunk/gcc/testsuite/gfortran.dg/pr39937.f

[Bug fortran/91556] Problems with better interface checking

[tkoenig at gcc dot gnu.org]

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

--- Comment #28 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Sep 14 20:40:55 2019
New Revision: 275719

URL: https://gcc.gnu.org/viewcvs?rev=275719=gcc=rev
Log:
2019-09-14  Thomas Koenig  

PR fortran/91557
PR fortran/91556
* frontend-passes.c (check_externals_procedure): Reformat argument
list. Use gfc_compare_actual_formal instead of gfc_procedure_use.
* gfortran.h (gfc_symbol): Add flag error.
* interface.c (gfc_compare_interfaces): Reformat.
(argument_rank_mismatch): Add where_formal argument. If it is
present, note that the error is between different calls.
(compare_parameter): Change warnings that previously dependended
on -Wargument-mismatch to unconditional.  Issue an error / warning
on type mismatch only once.  Pass where_formal to
argument_rank_mismatch for artificial variables.
(compare_actual_formal): Change warnings that previously
dependeded on -Wargument-mismatch to unconditional.
(gfc_check_typebound_override): Likewise.
(gfc_get_formal_from_actual_arglist): Set declared_at for
artificial symbol.
* invoke.texi: Extend description of -fallow-argument-mismatch.
Delete -Wargument-mismatch.
* lang.opt: Change -Wargument-mismatch to do-nothing option.
* resolve.c (resolve_structure_cons): Change warnings that
previously depended on -Wargument-mismatch to unconditional.
* trans-decl.c (generate_local_decl): Do not warn if the symbol is
artificial.

2019-09-14  Thomas Koenig  

PR fortran/91557
PR fortran/91556
* gfortran.dg/argument_checking_20.f90: New test.
* gfortran.dg/argument_checking_21.f90: New test.
* gfortran.dg/argument_checking_22.f90: New test.
* gfortran.dg/argument_checking_23.f90: New test.
* gfortran.dg/warn_unused_dummy_argument_5.f90: New test.
* gfortran.dg/bessel_3.f90: Add pattern for type mismatch.
* gfortran.dg/g77/20010519-1.f: Adjust dg-warning messages to new
handling.
* gfortran.dg/pr24823.f: Likewise.
* gfortran.dg/pr39937.f: Likewise.


Added:
trunk/gcc/testsuite/gfortran.dg/argument_checking_20.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_21.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_22.f90
trunk/gcc/testsuite/gfortran.dg/argument_checking_23.f90
trunk/gcc/testsuite/gfortran.dg/warn_unused_dummy_argument_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/interface.c
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/lang.opt
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/bessel_3.f90
trunk/gcc/testsuite/gfortran.dg/g77/20010519-1.f
trunk/gcc/testsuite/gfortran.dg/pr24823.f
trunk/gcc/testsuite/gfortran.dg/pr39937.f

[Bug lto/91772] New: [8/9/10 Regression] ICE in add_dwarf_attr, at dwarf2out.c:4412 since r259749

[marxin at gcc dot gnu.org]

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

Bug ID: 91772
   Summary: [8/9/10 Regression] ICE in add_dwarf_attr, at
dwarf2out.c:4412 since r259749
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Following is ICEing:

$ g++ -flto=16 -c -g1 -O2 1.ii 2.ii 3.ii 4.ii 5.ii 6.ii 7.ii && g++ -g -o
godot.x11.opt.debug.64 -flto=16 1.o 2.o 3.o 4.o 5.o 6.o 7.o -fchecking
...
during IPA pass: materialize-all-clones
lto1: internal compiler error: in add_dwarf_attr, at dwarf2out.c:4413
0x5d67de add_dwarf_attr
/home/marxin/Programming/gcc/gcc/dwarf2out.c:4413
0x5d67de add_dwarf_attr
/home/marxin/Programming/gcc/gcc/dwarf2out.c:4400
0x5d67de add_AT_int
/home/marxin/Programming/gcc/gcc/dwarf2out.c:4473
0x5d67de add_const_value_attribute
/home/marxin/Programming/gcc/gcc/dwarf2out.c:19565
0x9147ca dwarf2out_late_global_decl
/home/marxin/Programming/gcc/gcc/dwarf2out.c:26686
0x9147ca dwarf2out_late_global_decl
/home/marxin/Programming/gcc/gcc/dwarf2out.c:26655
0xab989d symbol_table::remove_unreachable_nodes(_IO_FILE*)
/home/marxin/Programming/gcc/gcc/ipa.c:602
0xab61cf execute
/home/marxin/Programming/gcc/gcc/ipa.c:1396
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [/tmp/ccYgkmEb.mk:2:
/tmp/godot.x11.opt.debug.64.gG99Ba.ltrans0.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/home/marxin/bin/binutils/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Sorry, I can't reduce it more.

[Bug c++/91771] New: Optimization fails to inline final override.

[carlo at gcc dot gnu.org]

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

Bug ID: 91771
   Summary: Optimization fails to inline final override.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlo at gcc dot gnu.org
  Target Milestone: ---

Compiling the following code snippet:

struct Base
{
  int foo(int n) { return do_foo(n); }
  virtual int do_foo(int n) = 0;
};

struct Derived : public Base
{
  int do_foo(int n) override final { return n + 2; }
};

int f(Derived& d)
{
  return d.do_foo(40);
}

with g++ -S -O2 f.cxx

results correctly in the assembly code:

_Z1fR7Derived:
.LFB2:
.cfi_startproc
movl$42, %eax
ret

This does obviously not happen when the 'final' keyword is removed.

However, when we change f() to return foo instead of do_foo:

  return d.foo(40);

the assembly code of f() changes to:

_Z1fR7Derived:
.LFB2:
.cfi_startproc
movq(%rdi), %rax
leaq_ZN7Derived6do_fooEi(%rip), %rdx
movq(%rax), %rax
cmpq%rdx, %rax
jne .L5
movl$42, %eax
ret

In other words, it failed to do the inlining.

The reason I find this bad is because of std::pmr::memory_resource
which follows this exact pattern,

  class memory_resource
  {
...
void*
allocate(size_t __bytes, size_t __alignment = _S_max_align)
{ return do_allocate(__bytes, __alignment); }

void
deallocate(void* __p, size_t __bytes, size_t __alignment = _S_max_align)
{ return do_deallocate(__p, __bytes, __alignment); }
...
virtual void*
do_allocate(size_t __bytes, size_t __alignment) = 0;

virtual void
do_deallocate(void* __p, size_t __bytes, size_t __alignment) = 0;
...
  };

I'd really like to use std::pmr::memory_resource at the moment, but
only when the compiler will do the above optimization; then I can
specify 'final' for the do_allocate and do_deallocate of my ultra fast
pool memory allocators and get rid of the indirection of the virtual
functions by making sure the caller has the right type (which is normally
the case for the lowest level memory resource classes; only
'upstream' classes will be called through the memory_resource::allocate()
member function of the base class, in which we're already one 'level' higher in
the memory resource hierarchy, so speed isn't as much as a requirement anymore.

[Bug middle-end/83889] [8 regression] new failures on some arm targets after r256644

[sandra at gcc dot gnu.org]

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

--- Comment #5 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Sat Sep 14 19:00:15 2019
New Revision: 275718

URL: https://gcc.gnu.org/viewcvs?rev=275718=gcc=rev
Log:
2019-09-14  Sandra Loosemore  

PR testsuite/83889

gcc/testsuite/
* g++.dg/vect/pr87914.cc: Remove explicit dg-do run.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/vect/pr87914.cc

[Bug fortran/91553] ICE in gfc_real2complex, at fortran/arith.c:2208

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.3

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed on trunk and 9-branch.  Closing.  Thanks for bug report.

[Bug fortran/91553] ICE in gfc_real2complex, at fortran/arith.c:2208

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Sep 14 17:05:17 2019
New Revision: 275716

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

PR fortran/91553
* simplify.c (gfc_convert_constant):  During conversion check if the
constant is enclosed in parenthesis, and simplify expression.

2019-09-14  Steven G. Kargl  

PR fortran/91553
* gfortran.dg/pr91553.f90: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91553.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/simplify.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/91566] [9/10 Regression] ICE in gfc_constructor_copy, at fortran/constructor.c:103

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed on trunk and 9-branch.  Closing.  Thanks for bug report.

[Bug fortran/91566] [9/10 Regression] ICE in gfc_constructor_copy, at fortran/constructor.c:103

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Sep 14 16:39:41 2019
New Revision: 275715

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

PR fortran/91566
* simplify.c (gfc_simplify_merge): Need to simplify expression
after insertation of parenthesis.

2019-09-14  Steven G. Kargl  

PR fortran/91566
* gfortran.dg/pr91566.f90: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91566.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/simplify.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/91642] ICE: Bad IO basetype (transfer_expr, at fortran/trans-io.c:2507)

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed on trunk and 9-branch.  Closing.  Thanks for bug report.

[Bug fortran/91642] ICE: Bad IO basetype (transfer_expr, at fortran/trans-io.c:2507)

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Sep 14 16:21:33 2019
New Revision: 275714

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

PR fortran/91642
* io.c (gfc_match_inquire): null() cannot be in an iolength inquire
list.

2019-09-14  Steven G. Kargl  

PR fortran/91642
* gfortran.dg/pr91642.f90: New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91642.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/io.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug c++/91770] warn on #includes inside extern C regions

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-09-14
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Nathan Sidwell  ---
Related to glibc BZ 24998

[Bug c++/91770] New: warn on #includes inside extern C regions

[nathan at gcc dot gnu.org]

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

Bug ID: 91770
   Summary: warn on #includes inside extern C regions
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nathan at gcc dot gnu.org
  Target Milestone: ---

Add a warning to detect:
extern "C" {
#include "foo"
}

as that will cause problems with c++20 header-units & include translation.

Bonus points if the warning triggers only when "foo" itself contains an outer
extern "C" { region.

[Bug target/91769] New: [9 regression] wrong code with -O2 on MIPS

[aurelien at aurel32 dot net]

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

Bug ID: 91769
   Summary: [9 regression] wrong code with -O2 on MIPS
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aurelien at aurel32 dot net
  Target Milestone: ---
  Host: mipsel-unknown-linux-gnu
Target: mipsel-unknown-linux-gnu
 Build: mipsel-unknown-linux-gnu

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

GCC 9.2 generates wrong code for the attached testcase file (extracted from
gnuplot and simplified) when compiled with -O2 -march=mips32r2. This doesn't
happen at -O1 level. This also doesn't happen with GCC 8.3. This is however
reproducible with a snapshot of trunk from 2019-08-28.

Here is the relevant part of the generated assembly code:
   0x00400780 <+80>:lw  v0,8(v1)
   0x00400784 <+84>:lw  v1,12(v1)

Here v1 is clobbered

   0x00400788 <+88>:ldc1$f2,64(sp)
=> 0x0040078c <+92>:ldc1$f0,8(v1)

So it crashes when the double value is loaded from the array.

[Bug target/91766] -fvisibility=hidden during -fpic still uses GOT indirection on arm64

[blu.dark at gmail dot com]

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

--- Comment #5 from martin krastev  ---
For reference, here what -fvisibility=hidden -fpic -fcommon produces on amd64
(https://godbolt.org/z/0aIyhl):

foo:
movl$0, room(%rip)
leaqroom(%rip), %rax
ret

Notice the absence of GOT indirection.

[Bug fortran/91729] ICE in gfc_match_select_rank, at fortran/match.c:6586

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-14
 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
Summary|[10 Regression] ICE in  |ICE in
   |gfc_match_select_rank, at   |gfc_match_select_rank, at
   |fortran/match.c:6586|fortran/match.c:6586
 Ever confirmed|0   |1

--- Comment #2 from Paul Thomas  ---
This can hardly be a regression :-)

I'll take it but will credit Steve for the patch.

Cheers

Paul

[Bug c++/91768] New: gcc try to resolve member of template parameter too soon

[tyker at outlook dot com]

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

Bug ID: 91768
   Summary: gcc try to resolve member of template parameter too
soon
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tyker at outlook dot com
  Target Milestone: ---

the following code is valid according to clang, msvc and icc but not gcc:

template
struct A {
int test(T* Ptr) {
return Ptr->type::test();
}
};

example with use:
https://godbolt.org/z/9XYQ4k

[Bug libfortran/91543] Handling stack overflow more sensibly

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
We could look at https://www.gnu.org/software/libsigsegv/ how to
do this, or maybe even include this as a prerequisite for libgfortran.

Haven't looked in detail yet...

[Bug target/91767] [10 regression] After r274953, clang-compiled xgcc segfaults during RTL pass: stv

[dimitry at andric dot com]

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

--- Comment #3 from Dimitry Andric  ---
(In reply to Jakub Jelinek from comment #2)
> Isn't that a clang bug though?  hash_map has a constructor which should be
> invoked by the general_scalar_chain constructor...

It is possible, though I think it is more likely that clang optimizes some sort
of undefined behavior differently from gcc.  I attempted to get the initial
stage (e.g. the xgcc build, is that the first stage, or the "zeroth" stage?) to
build with -fsanitize=undefined, but it failed with linker errors.

[Bug target/91766] -fvisibility=hidden during -fpic still uses GOT indirection on arm64

[wdijkstr at arm dot com]

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

Wilco  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com

--- Comment #4 from Wilco  ---
(In reply to martin krastev from comment #3)
> So it appears to be a clash between -fcommon and -fvisibility=hidden during
> -fpic -- passing either -fno-common or -fno-pic drops the GOT indirection.
> And explicitly hiding the symbol obviously solves it. But the crux of the
> issue, IMO, is a multi-platform one -- that behavior deviates on gcc-8.2
> from platform to platform. On amd64 it suffices to -fvisibility=hidden to
> stop GOT detours, whereas on aarch64 it's -fvisibility=hidden -fno-common.
> As a result aarch64 performance gets penalized in unsuspecting multi-plats.

-fno-common should really become the default, -fcommon causes way too many
issues.

[Bug tree-optimization/80791] [8/9/10 regression] test case gcc.dg/sms-1.c fail2 starting with r247885

[linkw at gcc dot gnu.org]

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

--- Comment #26 from Kewen Lin  ---
Author: linkw
Date: Sat Sep 14 09:01:21 2019
New Revision: 275713

URL: https://gcc.gnu.org/viewcvs?rev=275713=gcc=rev
Log:
Consider doloop IV in IVOPTs:

   For the targets supporting low-overhead loops, IVOPTs has to take care of
   the loops which will probably be transformed in RTL doloop optimization,
   to try to make selected IV candidate set optimal.  The process of doloop
   support includes:

   1) Analyze the current loop will be transformed to doloop or not, find and
  mark its compare type IV use as doloop use (iv_group field doloop_p), and
  set flag doloop_use_p of ivopts_data to notify subsequent processings on
  doloop.  See analyze_and_mark_doloop_use and its callees for the details.
  The target hook predict_doloop_p can be used for target specific checks.

   2) Add one doloop dedicated IV cand {(may_be_zero ? 1 : (niter + 1)), +,
-1},
  set flag doloop_p of iv_cand, step cost is set as zero and no extra cost
  like biv.  For cost determination between doloop IV cand and IV use, the
  target hooks doloop_cost_for_generic and doloop_cost_for_address are
  provided to add on extra costs for generic type and address type IV use.
  Zero cost is assigned to the pair between doloop IV cand and doloop IV
  use, and bound zero is set for IV elimination.

   3) With the cost setting in step 2), the current cost model based IV
  selection algorithm will process as usual, pick up doloop dedicated IV if
  profitable.

gcc/ChangeLog

2019-09-14  Kewen Lin  

PR middle-end/80791
* config/rs6000/rs6000.c (TARGET_HAVE_COUNT_REG_DECR_P): New macro.
(TARGET_DOLOOP_COST_FOR_GENERIC): Likewise.
(TARGET_DOLOOP_COST_FOR_ADDRESS): Likewise.
* target.def (have_count_reg_decr_p): New hook.
(doloop_cost_for_generic): Likewise.
(doloop_cost_for_address): Likewise.
* doc/tm.texi.in (TARGET_HAVE_COUNT_REG_DECR_P): Likewise.
(TARGET_DOLOOP_COST_FOR_GENERIC): Likewise.
(TARGET_DOLOOP_COST_FOR_ADDRESS): Likewise.
* doc/tm.texi: Regenerate.
* tree-ssa-loop-ivopts.c (comp_cost::operator+=): Consider infinite cost
addend.
(record_group): Init doloop_p.
(add_candidate_1): Add optional argument doloop, change the handlings
accordingly.
(add_candidate): Likewise.
(generic_predict_doloop_p): Update attribute.
(force_expr_to_var_cost): Add costing for expressions COND_EXPR/LT_EXPR/
LE_EXPR/GT_EXPR/GE_EXPR/EQ_EXPR/NE_EXPR/UNORDERED_EXPR/ORDERED_EXPR/
UNLT_EXPR/UNLE_EXPR/UNGT_EXPR/UNGE_EXPR/UNEQ_EXPR/LTGT_EXPR/MAX_EXPR/
MIN_EXPR.
(get_computation_cost): Update for doloop IV cand extra cost.
(determine_group_iv_cost_cond): Update for doloop IV cand.
(determine_iv_cost): Likewise.
(ivopts_estimate_reg_pressure): Likewise.
(may_eliminate_iv): Update handlings for doloop IV cand.
(add_iv_candidate_for_doloop): New function.
(find_iv_candidates): Call function add_iv_candidate_for_doloop.
(iv_ca_set_no_cp): Update for doloop IV cand.
(iv_ca_set_cp): Likewise.
(iv_ca_dump): Dump register cost.
(find_doloop_use): New function.
(analyze_and_mark_doloop_use): Likewise.
(tree_ssa_iv_optimize_loop): Call function analyze_and_mark_doloop_use.

gcc/testsuite/ChangeLog

2019-09-14  Kewen Lin  

PR middle-end/80791
* gcc.dg/tree-ssa/ivopts-3.c: Adjust for doloop change.
* gcc.dg/tree-ssa/ivopts-lt.c: Likewise.
* gcc.dg/tree-ssa/pr32044.c: Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/target.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopts-3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ivopts-lt.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr32044.c
trunk/gcc/tree-ssa-loop-ivopts.c

[Bug target/91766] -fvisibility=hidden during -fpic still uses GOT indirection on arm64

[blu.dark at gmail dot com]

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

--- Comment #3 from martin krastev  ---
So it appears to be a clash between -fcommon and -fvisibility=hidden during
-fpic -- passing either -fno-common or -fno-pic drops the GOT indirection. And
explicitly hiding the symbol obviously solves it. But the crux of the issue,
IMO, is a multi-platform one -- that behavior deviates on gcc-8.2 from platform
to platform. On amd64 it suffices to -fvisibility=hidden to stop GOT detours,
whereas on aarch64 it's -fvisibility=hidden -fno-common. As a result aarch64
performance gets penalized in unsuspecting multi-plats.