[Bug middle-end/54183] Generate __udivmoddi4 instead of __udivdi3 plus __umoddi3

[b7.10110111 at gmail dot com]

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

--- Comment #5 from Ruslan  ---
Yes, this is exactly the problem: the generic case is optimized while the
special case, where the divisor is a compile-time constant, isn't.

[Bug c++/71251] [6/7/8 regression] ICE on invalid code, with unusual template name

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #6 from Alexandre Oliva  ---
Created attachment 43689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43689&action=edit
candidate patch

Mine.  Here's the patch I'm testing.

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

--- Comment #15 from Zhendong Su  ---
(In reply to Jakub Jelinek from comment #12)
> Can you attach -fdump-tree-optimized and -fdump-rtl-cse2
> -fdump-rtl-pro_and_epilogue -fdump-rtl-dse ?  I really wonder what is
> different in our vs. your compiler.

Jakub, I've just added the two files.  For -fdump-rtl-dse, I assume that you
meant -fdump-rtl-dse2 instead.

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

--- Comment #14 from Zhendong Su  ---
Created attachment 43688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43688&action=edit
output from "gcctk -fdump-rtl-cse2 -fdump-rtl-pro_and_epilogue -fdump-rtl-dse2
-c small.c"

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

--- Comment #13 from Zhendong Su  ---
Created attachment 43687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43687&action=edit
output from "gcctk -fdump-rtl-cse2 -c small.c"

[Bug fortran/84922] New: fortran reports inconsistency in rank of arguments in interface and contained procedures

[w.clodius at icloud dot com]

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

Bug ID: 84922
   Summary: fortran reports inconsistency in rank of arguments in
interface and contained procedures
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: w.clodius at icloud dot com
  Target Milestone: ---

When compiling modules it is sometimes useful to provide an interface for the
contained procedure. For some of my procedures gfortran 7.1 is reporting an
inconsistency in the ranks for some of the arguments. This has occurred for
using a simple interface, a generic interface, or for using an interface for a
procedure defined in a submodule. The following file causes the problem for
fortran 7.1

module copy

use, intrinsic :: iso_fortran_env, only : int8


interface

module subroutine copy_byte_data( data, copy ) ! Chase's copier
integer(int8), intent(in)   :: data(:)
integer(int8), allocatable, intent(out) :: copy(:)
end subroutine copy_byte_data

end interface



contains


subroutine copy_byte_data( data, copy ) ! Chase's copier
integer(int8), intent(in)   :: data(:)
integer(int8), allocatable, intent(out) :: copy(:)

if ( allocated( copy ) ) then
deallocate( copy )
end if
allocate( copy( size(data) ) )
copy = data

return

end subroutine copy_byte_data

end module copy

program test_copy

use copy

integer(int8)  :: data(8) = 0_int8
integer(int8), allocatable :: acopy(:)

write(*,*) 'DATA = ', data

call copy_byte_data( data, acopy)

write(*, *) 'ACOPY = ', acopy

stop

end program test_copy

When compiled from the Terminal command line on Mac OS X 10.13.3, using the
command
gfortran test_copy.f90

I get the following response

test_copy.f90:21:35:

 subroutine copy_byte_data( data, copy ) ! Chase's copier
   1
Error: Shape mismatch in argument 'data' at (1)
test_copy.f90:39:8:

 use copy
1
Fatal Error: Can't open module file ‘copy.mod’ for reading at (1): No such file
or directory
compilation terminated.

[Bug fortran/78593] [6/7 Regression] ICE in gfc_match_varspec, at fortran/primary.c:2053

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||kimwooyoung at gmail dot com

--- Comment #7 from Dominique d'Humieres  ---
*** Bug 58904 has been marked as a duplicate of this bug. ***

[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #9 from Dominique d'Humieres  ---
>So, it can be closed?

Marked as duplicate of pr78593.

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

[Bug c/84919] [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
(In reply to Jeffrey A. Law from comment #3)
> Umm, isn't that invalid code?  The whole point of the warning is to catch
> precisely this kind of broken idiom.  Right?

Why is it invalid?  Argument 4 is for %p. It looks valid to me.

[Bug c/84919] [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #3 from Jeffrey A. Law  ---
Umm, isn't that invalid code?  The whole point of the warning is to catch
precisely this kind of broken idiom.  Right?

[Bug fortran/65453] ICE in build_function_decl, at fortran/trans-decl.c:2001

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |ASSIGNED
 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
patch submitted.

[Bug c/84919] [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #2 from H.J. Lu  ---
This is caused by r258455.

[Bug tree-optimization/84921] New: [5 Regression] With -O3 gcc incorrectly assumes aligned SSE instructions (e.g. movdqa) can be used

[jim at meyering dot net]

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

Bug ID: 84921
   Summary: [5 Regression] With -O3 gcc incorrectly assumes
aligned SSE instructions (e.g. movdqa) can be used
   Product: gcc
   Version: 5.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jim at meyering dot net
  Target Milestone: ---

Created attachment 43686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43686&action=edit
5.5 reproducer, with g++ -O3

Much like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598, this affects only
the gcc-5-branch (I tested with head of 5) and appears to have been fixed on
trunk by a combination of changes terminating with the 2015-06-18 commit, PR
tree-optimization/66510 (git commit c1bee668987f371617586edafa0dfccf04162a83).

This may also be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564,
but someone claimed that was still present in 6.3, which this is not. Bisection
suggests that this was fixed on master before the gcc-6-branch point by the
commit mentioned above.

Running the following minimized reproducer elicits a segfault from 5.5, but not
from 6.1 (6.1 generates a movdqu rather than movdqa):

  g++ -std=c++14 -O3 unaligned-movdqa.cpp && ./a.out

I considered back-porting the above commit and even took a shot at resolving
the four conflicts, but that commit introduces uses of two functions
(vect_slp_analyze_operations and vect_update_vf_for_slp) that were added in
preceding diffs, so did not pursue it.

[Bug fortran/58787] ICE (error recovery) in check_proc_interface

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  ---
On Fri, Mar 16, 2018 at 10:57:46PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787
> 
> --- Comment #8 from Dominique d'Humieres  ---
> > Does it still fail for you?
> 
> Yep!-(
> 

Ah, so one needs to use a sanitizer.  Compiles without
issue on FreeBSD.

[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl  ---
On Fri, Mar 16, 2018 at 11:03:30PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58904
> 
> --- Comment #6 from Dominique d'Humieres  ---
> I get
> 
> pr58904.f90:5:4:
> 
>  r%b = b
> 1
> Error: Unclassifiable statement at (1)
> pr58904.f90:3:2:
> 
>TYPE(mytype) FUNCTION create_sort_range(b) result(r)
>   1
> Error: The type for function 'create_sort_range' at (1) is not accessible
> 
> with 6.4, 7.3, and trunk (8.0) and an ICE with 5.5.
> 

So, it can be closed?

[Bug middle-end/54183] Generate __udivmoddi4 instead of __udivdi3 plus __umoddi3

[jimis at gmx dot net]

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

--- Comment #4 from jimis  ---
Indeed, as showcased by this example:

https://godbolt.org/g/nsSTHG

The function calls __udivmoddi4, like you said. However, the call is inlined in
main, but there we see separate calls for __udivdi3 and __umoddi3. Is it
because in main the divisor is the same constant?

If so I can close this bug and monitor bug 84759.

Thanks!

[Bug c++/84892] Missing accessor hint for private field

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 CC||egallager at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Gallager  ---
(In reply to David Malcolm from comment #0)
> Reddit user "evaned" reports that we fail to offer a fix-it hint code
> suggesting the "get_field" accessor on this code:
> https://godbolt.org/g/y2cbuv
> 
> 
> class S {
> private:
> bool field;
> 
> public:
> bool get_field() const {
> return field;
> }
> };
> 
> bool thingy(const S & s) {
>   return s.field;
> }
> 
> 
> Removing the "const" from "thingy" seems to fix it.

Link to evaned's original comment is here:
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvrh7jf/
Thus, confirmed.

[Bug c++/84898] Fix-it hints for '.' vs '->'

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to David Malcolm from comment #0)
> Reddit user "Boojum" suggested:
> 
> > [...] Clang offers fix-its for both errors and gets the symmetry correct:
> 

Link to that comment is:
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvrj48o/

[Bug c++/84897] Better handling of unqualified "string"

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
(In reply to David Malcolm from comment #0)
> Reddit user "Boojum" suggested:
> 
> > As far as other paper cuts, here's one that catches me
> > surprisingly frequently:
> 
> #include 
> int main() {
> string x("foo");
> }
> 
> > Obviously, I "forgot" to either qualify string as std::string,
> > add using namespace std;, or add using std::string;.
> >
> > Here's what GCC 7.2 tells me (header paths elided):
> 
> namespace.cpp: In function ‘int main()’:
> namespace.cpp:3:5: error: ‘string’ was not declared in this scope
>  string x("foo");
>  ^~
> namespace.cpp:3:5: note: suggested alternatives:
> In file included from .../string:39:0,
>  from namespace.cpp:1:
> .../stringfwd.h:74:33: note:   ‘std::__cxx11::string’
>typedef basic_stringstring;
>  ^~
> .../stringfwd.h:74:33: note:   ‘std::__cxx11::string’
> 
> > On the other hand, here's what Clang 6 tells me:
> 
> namespace.cpp:3:5: error: unknown type name 'string'; did you mean
> 'std::string'?
> string x("foo");
> ^~
> std::string
> .../stringfwd.h:74:33: note: 'std::string' declared here
>   typedef basic_stringstring;
> ^
> 1 error generated.
> 
> > Much nicer. It tells me exactly which namespace I probably
> > meant to use and proposes a fix-it qualifying the identifier.
> 

Link to this comment is here:
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvrj48o/

[Bug rtl-optimization/84660] Combine doing wrong optimization for 64 bits with SHIFT_COUNT_TRUNCATED target

[wilson at gcc dot gnu.org]

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

--- Comment #5 from Jim Wilson  ---
This is what the original patch I wrote looked like.  But then I tried to
optimize it a bit to eliminate the redundant nonzero_bits call, and that is
where I screwed up.  Then I got overwhelmed by work and haven't had a chance to
get back to it yet.

I can't self approve patches to combine, so it needs to be submitted to
gcc-patches for review.

It probably should be tested on at least one other target that isn't
SHIFT_COUNT_TRUNCATED.

[Bug c/84888] C/C++: Improve wording of unclosed paren/brace

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
(In reply to Eric Gallager from comment #1)
> 
> As in bug 84887, I'd like a link to the reddit thread mentioned here, too

Thread is here:
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvr93d4/
Confirming on the basis that your original bug was actually a confirmation of
the linked comment.

[Bug c/84887] missing semicolon: further improvements

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
(In reply to Eric Gallager from comment #2)
> link to thread on reddit?
> 

Never mind, I found it:
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvr93d4/
I'll confirm this bug after finding the Hacker News one, too.

[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
The change occurred between revisions r242984 (2016-11-29, ICE) and r243219
(2016-12-03, errors), likely fixed by r243020 (pr78593) for gcc7 and r243485
for gcc6.

[Bug other/84889] Ideas on revamping how we format diagnostics

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

--- Comment #6 from Eric Gallager  ---
(In reply to David Malcolm from comment #4)
> (In reply to Eric Gallager from comment #3)
> > Link for this next one though?
> https://news.ycombinator.com/item?id=16598074

(In reply to David Malcolm from comment #5)
> ...and according to:
> https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/
> dvspoet/
> the rust developers took ideas on diagnostics-printing from Elm.  
> 
> Note to self: need to look at Elm.

Thanks, confirmed.

[Bug c/84890] Overly verbose notes for missing headers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

--- Comment #4 from Eric Gallager  ---
(In reply to David Malcolm from comment #3)
> (In reply to Eric Gallager from comment #2)
> > (In reply to David Malcolm from comment #0)
> > > 
> > > Reddit user "ramennoodle" comments:
> [...]
> > ...link for this one?
> https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/
> dvr6psr/

Thanks, confirmed.

[Bug middle-end/54183] Generate __udivmoddi4 instead of __udivdi3 plus __umoddi3

[b7.10110111 at gmail dot com]

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

--- Comment #3 from Ruslan  ---
Ah, actually your problem is with a constant divisor. I reported it as bug
84759. If you change 10 to e.g. a function parameter, then you'll get
__udivmoddi4.

[Bug c++/71167] Long typenames produce extremely hard to read diagnostics and slow down compilation time

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> Most likely a dup of bug 17693.

I'll just put it under "See Also" until there's more certainty that this is a
dup of it

[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
I get

pr58904.f90:5:4:

 r%b = b
1
Error: Unclassifiable statement at (1)
pr58904.f90:3:2:

   TYPE(mytype) FUNCTION create_sort_range(b) result(r)
  1
Error: The type for function 'create_sort_range' at (1) is not accessible

with 6.4, 7.3, and trunk (8.0) and an ICE with 5.5.

[Bug c++/84916] Tweaks to template type elision

[vittorio.romeo at outlook dot com]

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

Vittorio Romeo  changed:

   What|Removed |Added

 CC||vittorio.romeo at outlook dot 
com

--- Comment #2 from Vittorio Romeo  ---
This might be of interest as well:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71167

[Bug fortran/58787] ICE (error recovery) in check_proc_interface

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  ---
> Does it still fail for you?

Yep!-(

...
Error: Expecting END SUBROUTINE statement at (1)
=
==19146==ERROR: AddressSanitizer: heap-use-after-free on address 0x61305b90
at pc 0x00010042c261 bp 0x7ffeefbfe830 sp 0x7ffeefbfe828
READ of size 1 at 0x61305b90 thread T0
#0 0x10042c260 in resolve_formal_arglist(gfc_symbol*) resolve.c:281
#1 0x10042fb23 in find_arglists(gfc_symbol*) resolve.c:551
#2 0x1004acd3e in do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*),
void (*)(gfc_symbol*)) symbol.c:4159
#3 0x1004cafa3 in gfc_traverse_ns(gfc_namespace*, void (*)(gfc_symbol*))
symbol.c:4184
#4 0x1003731a5 in resolve_formal_arglists(gfc_namespace*) resolve.c:564
#5 0x1003af5a2 in resolve_contained_functions(gfc_namespace*)
resolve.c:1119
#6 0x10042fec6 in resolve_types(gfc_namespace*) resolve.c:16470
#7 0x1003c3d32 in gfc_resolve(gfc_namespace*) resolve.c:16595
#8 0x1003290b2 in resolve_all_program_units(gfc_namespace*) parse.c:6060
#9 0x100348734 in gfc_parse_file() parse.c:6308
#10 0x100515192 in gfc_be_parse_file() f95-lang.c:204
#11 0x105d1be48 in compile_file() toplev.c:455
#12 0x105d26f8a in do_compile() toplev.c:2132
#13 0x108294d19 in toplev::main(int, char**) toplev.c:2267
#14 0x10829a1ff in main main.c:39
#15 0x7fff5260c114 in start (libdyld.dylib:x86_64+0x1114)

0x61305b90 is located 80 bytes inside of 336-byte region
[0x61305b40,0x61305c90)
freed by thread T0 here:
#0 0x156eff370 in wrap_free.part.0 sanitizer_malloc_mac.inc:142
#1 0x1004ca6da in gfc_free_symbol(gfc_symbol*) symbol.c:3063
#2 0x1004caa26 in gfc_release_symbol(gfc_symbol*) symbol.c:3090
#3 0x1004caea2 in free_sym_tree(gfc_symtree*) symbol.c:3892
#4 0x1004c9c5a in gfc_free_namespace(gfc_namespace*) symbol.c:4047
#5 0x1004caba2 in gfc_release_symbol(gfc_symbol*) symbol.c:3082
#6 0x1004caea2 in free_sym_tree(gfc_symtree*) symbol.c:3892
#7 0x1004c9c5a in gfc_free_namespace(gfc_namespace*) symbol.c:4047
#8 0x100347983 in parse_contained(int) parse.c:5616
#9 0x10034687f in parse_progunit(gfc_statement) parse.c:5739
#10 0x100348892 in gfc_parse_file() parse.c:6214
#11 0x100515192 in gfc_be_parse_file() f95-lang.c:204
#12 0x105d1be48 in compile_file() toplev.c:455
#13 0x105d26f8a in do_compile() toplev.c:2132
#14 0x108294d19 in toplev::main(int, char**) toplev.c:2267
#15 0x10829a1ff in main main.c:39
#16 0x7fff5260c114 in start (libdyld.dylib:x86_64+0x1114)

previously allocated by thread T0 here:
#0 0x156efe9e0 in wrap_calloc sanitizer_malloc_mac.inc:153
#1 0x108242032 in xcalloc xmalloc.c:162
#2 0x1004c1ac1 in gfc_new_symbol(char const*, gfc_namespace*) symbol.c:3099
#3 0x10028842e in load_needed(pointer_info*) module.c:4922
#4 0x100287e4f in load_needed(pointer_info*) module.c:4890
#5 0x100287e9a in load_needed(pointer_info*) module.c:4891
#6 0x10028db10 in read_module() module.c:5370
#7 0x10028f4d5 in gfc_use_module(gfc_use_list*) module.c:7072
#8 0x1002935f6 in gfc_use_modules() module.c:7196
#9 0x100329dc6 in use_modules() parse.c:114
#10 0x100335f2a in decode_statement() parse.c:332
#11 0x100338870 in next_free() parse.c:1230
#12 0x10033923e in next_statement() parse.c:1462
#13 0x10033f7eb in parse_spec(gfc_statement) parse.c:3854
#14 0x100346376 in parse_progunit(gfc_statement) parse.c:5667
#15 0x100348892 in gfc_parse_file() parse.c:6214
#16 0x100515192 in gfc_be_parse_file() f95-lang.c:204
#17 0x105d1be48 in compile_file() toplev.c:455
#18 0x105d26f8a in do_compile() toplev.c:2132
#19 0x108294d19 in toplev::main(int, char**) toplev.c:2267
#20 0x10829a1ff in main main.c:39
#21 0x7fff5260c114 in start (libdyld.dylib:x86_64+0x1114)

SUMMARY: AddressSanitizer: heap-use-after-free resolve.c:281 in
resolve_formal_arglist(gfc_symbol*)
Shadow bytes around the buggy address:
  0x1c260b20: 00 00 fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c260b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c260b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1c260b50: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
  0x1c260b60: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
=>0x1c260b70: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c260b80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c260b90: fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c260ba0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c260bb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x1c260bc0: fd fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone: 

[Bug middle-end/54183] Generate __udivmoddi4 instead of __udivdi3 plus __umoddi3

[jimis at gmx dot net]

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

--- Comment #2 from jimis  ---
No, I still see the same behaviour with gcc 7.3 on my Fedora box.

Is the this link from godbolt showcasing it for you?

https://godbolt.org/g/dKEf39

[Bug fortran/58904] ICE: accessing a component field of an unavailable type results in a seg fault

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
The original testcase on FreeBSD gives

troutmask:sgk[209] gfcx -c a.f90
a.f90:4:4:

 r%b = b
1
Error: Unclassifiable statement at (1)
a.f90:2:2:

   TYPE(mytype) FUNCTION create_sort_range(b) result(r)
  1
Error: The type for function 'create_sort_range' at (1) is not accessible
a.f90:6:3:

 END MODULE mymod
   1
Error: Expecting END PROGRAM statement at (1)
f951: Error: Unexpected end of file in 'a.f90'

without an ICE.

[Bug fortran/58787] ICE (error recovery) in check_proc_interface

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #6)
> > No longer ICEs with r238822.
> 
> It still fails for me:
> 
> [book15] f90/bug% /opt/gcc/gcc7p-238822p2/bin/gfortran pr58787.f90
> pr58787.f90:15:27:
>

>   1
> Error: Expecting END SUBROUTINE statement at (1)
> f951: internal compiler error: Segmentation fault: 11
> 
> f951: internal compiler error: Abort trap: 6
> gfortran: internal compiler error: Abort trap: 6 (program f951)
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

Does it still fail for you?

[Bug c++/84920] Better handling of unmatched/ambiguous calls

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug c++/84920] New: Better handling of unmatched/ambiguous calls

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 84920
   Summary: Better handling of unmatched/ambiguous calls
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

As reported by user "jcoffland" on Hacker News:
https://news.ycombinator.com/item?id=16598071

> One improvement I'd like to see is a simplified error message
> for mismatched overloaded calls. If you make an overloaded call
> for which the is no matching conversion or if the conversation is
> ambiguous the compiler will "helpfully" dump a list of possibly
> matching overloaded function signatures. The list can be hundreds
> of lines long.
>
> For example, when you try to pipe a class to std::cout that
> doesn't have an std::ostream &operator<<(std::ostream &, const X &).
> Perhaps instead of dumping the complete function signatures it
> could show one function signature followed by a list of types
> accepted as the second parameter. Since the signatures are
> otherwise the same. Such improvements could also reduce
> template error spew.

I hope to have a look at this in the GCC 9 timeframe, so filing this here.

[Bug c/84919] [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
[hjl@gnu-bdx-1 tmp]$ cat x.c
#include 
#include 
char *str_error_r(char *buf, size_t buflen)
{
snprintf(buf, buflen, "(%p, %zd)", buf, buflen);
return buf;
}
[hjl@gnu-bdx-1 tmp]$ /usr/gcc-8.0.1-x32/bin/gcc -O2 -S -Wall x.c
x.c: In function ‘str_error_r’:
x.c:5:2: warning: passing argument 1 to restrict-qualified parameter aliases
with argument 4 [-Wrestrict]
  snprintf(buf, buflen, "(%p, %zd)", buf, buflen);
  ^~~~
[hjl@gnu-bdx-1 tmp]$

[Bug c/84919] New: [8 Regression] error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict]

[hjl.tools at gmail dot com]

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

Bug ID: 84919
   Summary: [8 Regression] error: passing argument 1 to
restrict-qualified parameter aliases with argument 5
[-Werror=restrict]
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

When building Linux/x86-64 kernel 4.16-rc5, r258590 gave

gcc -Wp,-MD,/export/ssd/git/kernel.org/linux-cet/tools/objtool/.str_error_r.o.d
-Wp,-MT,/export/ssd/git/kernel.org/linux-cet/tools/objtool/str_error_r.o -Wall
-Werror -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security
-Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked
-Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum
-Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 -Wno-switch-default
-Wno-switch-enum -Wno-packed -fomit-frame-pointer -O2 -g
-I/export/ssd/git/kernel.org/linux-cet/tools/include
-I/export/ssd/git/kernel.org/linux-cet/tools/arch/x86/include/uapi
-I/export/ssd/git/kernel.org/linux-cet/tools/objtool/arch/x86/include
-I/export/ssd/git/kernel.org/linux-cet/tools/lib -D"BUILD_STR(s)=\#s" -c -o
/export/ssd/git/kernel.org/linux-cet/tools/objtool/str_error_r.o
../lib/str_error_r.c
gnu-bdx-1:pts/7[63]> /usr/gcc-8.0.1-x32/bin/gcc
-Wp,-MD,/export/ssd/git/kernel.org/linux-cet/tools/objtool/.str_error_r.o.d
-Wp,-MT,/export/ssd/git/kernel.org/linux-cet/tools/objtool/str_error_r.o -Wall
-Werror -Wbad-function-cast -Wdeclaration-after-statement -Wformat-security
-Wformat-y2k -Winit-self -Wmissing-declarations -Wmissing-prototypes
-Wnested-externs -Wno-system-headers -Wold-style-definition -Wpacked
-Wredundant-decls -Wshadow -Wstrict-prototypes -Wswitch-default -Wswitch-enum
-Wundef -Wwrite-strings -Wformat -Wstrict-aliasing=3 -Wno-switch-default
-Wno-switch-enum -Wno-packed -fomit-frame-pointer -O2 -g
-I/export/ssd/git/kernel.org/linux-cet/tools/include
-I/export/ssd/git/kernel.org/linux-cet/tools/arch/x86/include/uapi
-I/export/ssd/git/kernel.org/linux-cet/tools/objtool/arch/x86/include
-I/export/ssd/git/kernel.org/linux-cet/tools/lib -D"BUILD_STR(s)=\#s" -c -o
/export/ssd/git/kernel.org/linux-cet/tools/objtool/str_error_r.o
../lib/str_error_r.c
../lib/str_error_r.c: In function ‘str_error_r’:
../lib/str_error_r.c:25:3: error: passing argument 1 to restrict-qualified
parameter aliases with argument 5 [-Werror=restrict]
   snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", errnum,
buf, buflen, err);
   ^~~~
cc1: all warnings being treated as errors

[Bug c++/84918] Better handling of "std::cout >> 42;"

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug c++/84918] New: Better handling of "std::cout >> 42;"

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 84918
   Summary: Better handling of "std::cout >> 42;"
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/dvs5hjj/
points out:

> What is the current error message for

std::cout >> 42;

> On older compilers this would generate roughly 100 lines of unreadable
> error messages, so I detect and fix it in the static analyzer I wrote.

Checking on godbolt.org:

#include 
void test ()
{
std::cout >> 42;
}

we currently spew dozens of lines of diagnostics.

May be worth special-casing this, and offering a fix-it hint to convert ">>" to
"<<", if sane (and vice-versa).

[Bug c++/84269] C++ FE does not suggest which #include to use for "memset"

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Another one:

void test (char *dst, const char *src)
{
strncpy (dst, 10, src);
}

In function 'void test(char*, const char*)':
:3:5: error: 'strncpy' was not declared in this scope
 strncpy (dst, 10, src);
 ^~~
:3:5: note: suggested alternative: 'struct'
 strncpy (dst, 10, src);
 ^~~
 struct

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  ---
(In reply to H.J. Lu from comment #3)
> (In reply to Jason Vas Dias from comment #2)
> > Thanks H.J. -
> > 
> > RE:
> > > vDSO isn't compiled with -mindirect-branch=thunk-extern in kernel
> > > 4.16-rc5.  Why isn't it the case for you? 
> > 
> > All I know is ,  when submitting a patched vclock_gettime.c 
> > in which the switch in vdso_clock_gettime() had 6 clauses
> > instead of 5, I received in response a mail from 
> 
> 4.16-rc5 has
> 
> ifdef CONFIG_RETPOLINE
> ifneq ($(RETPOLINE_CFLAGS),)
>   KBUILD_CFLAGS += $(RETPOLINE_CFLAGS) -DRETPOLINE
> endif
> endif
> 
> vDSO isn't compiled with $(KBUILD_CFLAGS).  Why does your kernel do it?
> 

Please try my kernel patch at comment 4.

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
Created attachment 43685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43685&action=edit
Kernel patch for 4.16-rc5

[Bug c++/84360] unnecessary aka in error message

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Target Milestone|--- |9.0

[Bug c++/84917] Verbosity when dealing with nested template data structures

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/84917] New: Verbosity when dealing with nested template data structures

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 84917
   Summary: Verbosity when dealing with nested template data
structures
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

In
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvsa8dw/
Reddit user "rifeid" reports excess verbosity...

> [...] when dealing with nested template data structures. For example,

#include 
#include 
using vec = std::vector;
void blah() {
vec x;
x.foo();
}

> results in

test.cpp: In function ‘void blah()’:
test.cpp:6:4: error: ‘using vec = class
std::vector > {aka class
std::vector >}’ has no member named ‘foo’
  x.foo();
^~~

> My issues with this:
>
> It may look better if the error: line just uses vec, and
> have the full expansion relegated to a note: line. Not sure.
>
> The expansion is printed twice.
>
> As std::string is part of the C++ standard, I'd prefer it unexpanded.

Confirmed on godbolt.org.

I think parts of these are a dup (maybe of PR c++/84360) but it seems worth
capturing here and fixing.

[Bug other/84889] Ideas on revamping how we format diagnostics

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
...and according to:
https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/dvspoet/
the rust developers took ideas on diagnostics-printing from Elm.  

Note to self: need to look at Elm.

[Bug c++/84789] [6/7/8 Regression] ICE with broken variable declaration in template class

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Alexandre Oliva  ---
Patch posted, unchanged
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00823.html

[Bug c++/84916] Tweaks to template type elision

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Or just textual length? (perhaps with a param)?

[Bug c++/84916] Tweaks to template type elision

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c++/84916] New: Tweaks to template type elision

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 84916
   Summary: Tweaks to template type elision
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

In
https://www.reddit.com/r/programming/comments/84oizv/usability_improvements_in_gcc_8/dvrdyhv/
Reddit user "Liorithiel" pointed out:

> Have you considered performing elision conditionally on the length on the
> elided part? I see the benefits of changing, let say,

   std::map>, std::string>

> into

   std::map<[...], std::string>,

> but for me,

  std::map

> is clearer than

  std::map<[...], int>.

(see the other comments downthread from thread).

I'm filing this reminder to take a look at tweaking this for gcc 9.

Maybe only elide common items if there's "more than one thing" e.g. if it's a
template itself, or is multiple args?

[Bug target/84899] [6/7/8 Regression] ICE: in final_scan_insn_1, at final.c:3139 (error: could not split insn)

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/84899] [6/7/8 Regression] ICE: in final_scan_insn_1, at final.c:3139 (error: could not split insn)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 16 21:01:16 2018
New Revision: 258610

URL: https://gcc.gnu.org/viewcvs?rev=258610&root=gcc&view=rev
Log:
PR target/84899
* postreload.c (reload_combine_recognize_pattern): Perform
INTVAL addition in unsigned HOST_WIDE_INT type to avoid UB and
truncate_int_for_mode the result for the destination's mode.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr84899.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/postreload.c
trunk/gcc/testsuite/ChangeLog

[Bug target/84876] [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #5 from Jeffrey A. Law  ---
Fixed by Vlad's commit on the trunk.

[Bug c/84909] typo: conversion from %qT to to %qT

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed for 8.1+.

[Bug c/84910] typo: "%qs follows inline declaration "

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed for 8.1+.

[Bug c/84909] typo: conversion from %qT to to %qT

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 16 20:12:27 2018
New Revision: 258609

URL: https://gcc.gnu.org/viewcvs?rev=258609&root=gcc&view=rev
Log:
PR c/84909
* c-warn.c (conversion_warning): Replace "to to" with "to" in
diagnostics.

* hsa-gen.c (mem_type_for_type): Fix comment typo.
* tree-vect-loop-manip.c (vect_create_cond_for_niters_checks):
Likewise.
* gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset):
Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-warn.c
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/hsa-gen.c
trunk/gcc/tree-vect-loop-manip.c

[Bug c/84915] New: documentation: __FUNCTION__ is said by gcc-6 info to be a preprocessor macro

[galex-...@galex-713.eu]

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

Bug ID: 84915
   Summary: documentation: __FUNCTION__ is said by gcc-6 info to
be a preprocessor macro
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: galex-...@galex-713.eu
  Target Milestone: ---

(info "(gcc-6) Other Builtins") says __FUNCTION__ is a preprocessor macro,
however, cpp info says it’s not. Am I missing something? do most cpp
implementation parse C code and implement it as a macro so gcc claims it is
while itself interprets it as not being one?

Look by yourselves:

 -- Built-in Function: const char * __builtin_FUNCTION ()
 This function is the equivalent to the preprocessor '__FUNCTION__'
 macro and returns the function name the invocation of the built-in
 is in.

It is not a bug of gcc but rather of its documentation, I don’t know if here is
the right place to ask…

[Bug c/84910] typo: "%qs follows inline declaration "

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar 16 20:11:40 2018
New Revision: 258608

URL: https://gcc.gnu.org/viewcvs?rev=258608&root=gcc&view=rev
Log:
PR c/84910
* c-warn.c (diagnose_mismatched_attributes): Remove trailing space from
diagnostics.

* parser.c (cp_parser_lambda_introducer): Remove trailing space from
diagnostics.
* method.c (synthesize_method): Likewise.
* pt.c (convert_nontype_argument): Likewise.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-warn.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c

[Bug target/84912] __builtin_divde* produce Internal Compiler Error when compiled -m32

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
It requires TARGET_POWERPC64 (not TARGET_64BIT).

[Bug c/84890] Overly verbose notes for missing headers

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
(In reply to Eric Gallager from comment #2)
> (In reply to David Malcolm from comment #0)
> > 
> > Reddit user "ramennoodle" comments:
[...]
> ...link for this one?
https://www.reddit.com/r/cpp/comments/84op5c/usability_improvements_in_gcc_8/dvr6psr/

[Bug other/84889] Ideas on revamping how we format diagnostics

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
(In reply to Eric Gallager from comment #3)
> Link for this next one though?
https://news.ycombinator.com/item?id=16598074

[Bug other/84889] Ideas on revamping how we format diagnostics

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
Thanks for these links:

(In reply to David Malcolm from comment #0)
> Quoting an example from:
>  
> https://stackoverflow.com/questions/44003622/implementing-trait-for-
> fnsomething-in-rust

(In reply to David Malcolm from comment #1)
> Example of Rust error (showing colorization):
>   https://i.redd.it/qm4oceuuckyy.png

Link for this next one though?

(In reply to David Malcolm from comment #2)
> Hacker News user "earenndil" suggested:
> 
> > What about a line of ─ in between different unassociated errors?
> > So if there is a group of related errors that are about the same actual
> > problem, or a note associated with an error, they're together, but then
> > there's a line of coloured ─ separating them from the next set.

[Bug c/84890] Overly verbose notes for missing headers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to David Malcolm from comment #1)
> Hacker News user "dmckeon" commented:
>   https://news.ycombinator.com/item?id=16603185
> 

Thanks for including this link, but:

(In reply to David Malcolm from comment #0)
> 
> Reddit user "ramennoodle" comments:
> 
> > This seems redundantly verbose. Why not just:
> > 
> > incomplete.c:4:17: note: ‘INT_MAX’ is defined in header ‘
> > 
> > ?

...link for this one?

[Bug fortran/69395] ICE on declaring array with more than 7 dimensions+codimensions

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Fri Mar 16 19:20:15 2018
New Revision: 258607

URL: https://gcc.gnu.org/viewcvs?rev=258607&root=gcc&view=rev
Log:
2018-03-16  Steven G. Kargl  

PR fortran/69395
* decl.c (merge_array_spec): Correct the error condition.

2018-03-16  Steven G. Kargl  

PR fortran/69395
* gfortran.dg/pr69395.f90: Add test for max dimensions

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr69395.f90

[Bug c/84890] Overly verbose notes for missing headers

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Hacker News user "dmckeon" commented:
  https://news.ycombinator.com/item?id=16603185

> A small idea: reframe suggestions to be positive, future-looking,
> and pro-active, such as replacing:
>
>   did you forget to ‘#include ’?
> 
> with:
> 
>   do you want to ‘#include ’?
>
> or, perhaps better:
>
>   you may want to ‘#include ’.
>
> It may seem a small thing, but focusing on the solution rather
> than the problem may tend to sooth the mind of the coder, rather
> than to magnify their annoyance.

I like this.

> Consider it a path that is the opposite of Nedry's
> "You didn't say the magic word!"

Indeed.  We want the feeling that the compiler is the servant of the user, not
the other way around.

[Bug c++/71834] [6/7/8 Regression] accepts invalid C++11 code with too few number of template arguments for class template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/84906] [8 Regression] Ambiguous conversion not diagnosed, causes entire selection-statement to be omitted

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c++/80227] [6/7/8 Regression] SFINAE ambiguity with a pointer to array argument

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Mar 16 18:56:01 2018
New Revision: 258604

URL: https://gcc.gnu.org/viewcvs?rev=258604&root=gcc&view=rev
Log:
PR c++/80227 - SFINAE and negative array size.

* decl.c (compute_array_index_type): Use
build_converted_constant_expr and valid_constant_size_p.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg8.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/g++.dg/gomp/pr47963.C
trunk/gcc/testsuite/g++.dg/init/new37.C
trunk/gcc/testsuite/g++.dg/init/new44.C
trunk/gcc/testsuite/g++.dg/ubsan/pr81530.C

[Bug c++/84720] [7 Regression] internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at cp/tree.c:3472

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Mar 16 18:56:06 2018
New Revision: 258605

URL: https://gcc.gnu.org/viewcvs?rev=258605&root=gcc&view=rev
Log:
PR c++/84720 - ICE with rvalue ref non-type argument.

* pt.c (invalid_nontype_parm_type_p): Prohibit rvalue reference.
(convert_nontype_argument): Revert earlier change.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/g++.dg/cpp0x/rv-targ1.C

[Bug c++/84906] [8 Regression] Ambiguous conversion not diagnosed, causes entire selection-statement to be omitted

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Mar 16 18:55:54 2018
New Revision: 258603

URL: https://gcc.gnu.org/viewcvs?rev=258603&root=gcc&view=rev
Log:
PR c++/84906 - silent wrong code with ambiguous conversion.

* call.c (build_user_type_conversion_1): Set need_temporary_p on
ambiguous conversion.
(convert_like_real): Check it.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn50.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Jason Vas Dias from comment #2)
> Thanks H.J. -
> 
> RE:
> > vDSO isn't compiled with -mindirect-branch=thunk-extern in kernel
> > 4.16-rc5.  Why isn't it the case for you? 
> 
> All I know is ,  when submitting a patched vclock_gettime.c 
> in which the switch in vdso_clock_gettime() had 6 clauses
> instead of 5, I received in response a mail from 

4.16-rc5 has

ifdef CONFIG_RETPOLINE
ifneq ($(RETPOLINE_CFLAGS),)
  KBUILD_CFLAGS += $(RETPOLINE_CFLAGS) -DRETPOLINE
endif
endif

vDSO isn't compiled with $(KBUILD_CFLAGS).  Why does your kernel do it?

> 
> But I don't want my patch to have to depend on this being removed -
> the removal of these flags effectively removes retpoline support, no ?
> It is a shame to have to do that after it was carefully added.
> 
> My gripe is really that nothing in GCC should work with a switch
> with < 6 clauses, and fail with a switch with >= 6 clauses.
> 

This is if statement vs jump table for switch implementation.

[Bug target/84876] [8 Regression] ICE on invalid code in lra_assign at gcc/lra-assigns.c:1601 since r258504

[vmakarov at gcc dot gnu.org]

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

--- Comment #4 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Mar 16 18:48:26 2018
New Revision: 258602

URL: https://gcc.gnu.org/viewcvs?rev=258602&root=gcc&view=rev
Log:
2018-03-16  Vladimir Makarov  

PR target/84876
* lra-assigns.c (lra_split_hard_reg_for): Don't use
regno_allocno_class_array and sorted_pseudos.
* lra-constraints.c (spill_hard_reg_in_range): Ignore hard regs in
insns where regno is used.

2018-03-16  Vladimir Makarov  

PR target/84876
* gcc.target/i386/pr84876.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr84876.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/84897] Better handling of unqualified "string"

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #2)
> Yes, we want to special case the inline namespaces std::__cxx11 and std::_V2
> so that they only show their contents as std::xxx not std::_V2::xxx. Or
> maybe automatically elide any inline namespace under std, so that we show
> std::experimental::source_location not
> std::experimental::fundamentals_v2::source_location. The point of an inline
> namespace is that you don't need to use it to refer to the type, the type
> can be named as though it was declared in the enclosing namespace.

I don't think we want to special case anything.  I think we want to
automtically elide any (all) inline namespace even ones which are not under
std.

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[jason.vas.dias at gmail dot com]

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

--- Comment #2 from Jason Vas Dias  ---
Thanks H.J. -

RE:
> vDSO isn't compiled with -mindirect-branch=thunk-extern in kernel
> 4.16-rc5.  Why isn't it the case for you? 

All I know is ,  when submitting a patched vclock_gettime.c 
in which the switch in vdso_clock_gettime() had 6 clauses
instead of 5, I received in response a mail from 
kbuild test robot:

>Hi
>
>Thank you for the patch! Yet something to improve:
>
>[auto build test ERROR on v4.16-rc4]
>[also build test ERROR on next-20180315]
>[if your patch is applied to the wrong git tree, please drop us a note to help 
>>improve the system]
>
>url:
>https://github.com/0day-ci/linux/commits/jason-vas-dias-gmail-com/x86-vdso-on-Intel-VDSO-should-handle-CLOCK_MONOTONIC_RAW/20180316-070319
>config: x86_64-rhel (attached as .config)
>compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
>reproduce:
># save the attached .config to linux build tree
>make ARCH=x86_64
>
>All errors (new ones prefixed by >>):
>
>   arch/x86/entry/vdso/vclock_gettime.o: In function `__vdso_clock_gettime':
>   vclock_gettime.c:(.text+0xf7): undefined reference to 
> >`__x86_indirect_thunk_rax'
>   /usr/bin/ld: arch/x86/entry/vdso/vclock_gettime.o: relocation R_X86_64_PC32 
> >against undefined symbol `__x86_indirect_thunk_rax' can not be used when 
> making >a shared object; recompile with -fPIC
>   /usr/bin/ld: final link failed: Bad value
>>> collect2: error: ld returned 1 exit status
>--
>>> arch/x86/entry/vdso/vdso32.so.dbg: undefined symbols found
>--
>>> objcopy: 'arch/x86/entry/vdso/vdso64.so.dbg': No such file
>---
>0-DAY kernel test infrastructureOpen Source Technology Center
>https://lists.01.org/pipermail/kbuild-all   Intel Corporation

That github URL does not point to anything anymore.

So it was 4.16-rc4 they were compiling against.
Maybe it is fixed in 4.16-rc5.

I had seen exactly the same problem when compiling the same
patch with the RHEL-7 4.8.5-16-el7_4.2.x86_64 compiler,
which did not happen when compiling the same code with
the previous RHEL-7 4.8.5-16-el7_4.1.x86_64 compiler.

So it is caused by  -mindirect-branch=thunk-extern ?


Aha, I see in kernel Makefile of the RHEL 3.10.0-21.1.el7 kernel:
  RETPOLINE_CFLAGS += $(call cc-option,-mindirect-branch=thunk-extern
-mindirect-branch-register)

And it is still in the CFLAGS of the kernel tagged 'v4.16-rc5:'

$ grep RETPOLINE linux-4.16-rc5/Makefile
RETPOLINE_CFLAGS_GCC := -mindirect-branch=thunk-extern
-mindirect-branch-register
RETPOLINE_CFLAGS_CLANG := -mretpoline-external-thunk
RETPOLINE_CFLAGS := $(call cc-option,$(RETPOLINE_CFLAGS_GCC),$(call
cc-option,$(RETPOLINE_CFLAGS_CLANG)))

But the compiler I am using for the 4.x builds is 6.4.1 , which
does not support -mindirect-branch=thunk-extern / -mindirect-branch-register .

I will get round to building one of the latest compilers with
retpoline support eventually, but it is not a priority for me
at the moment, for my Linux 4.x builds.

I just want to be able to build the patched vclock_gettime.c
under RHEL, with the new 4.8.5-16 retpoline supporting compiler,
and to be able to submit patches that don't break to the 4.16-rc5
branch .


YES, I have just tested, removing 
  '-mindirect-branch=thunk-extern -mindirect-branch-register'
from the 3.10.0-693.21.1.el7 build DOES allow it to succeed 
with the 6-clause version of the switch in vclock_gettime.c .

But I don't want my patch to have to depend on this being removed -
the removal of these flags effectively removes retpoline support, no ?
It is a shame to have to do that after it was carefully added.

My gripe is really that nothing in GCC should work with a switch
with < 6 clauses, and fail with a switch with >= 6 clauses.

Just reporting this issue so it can be fixed.

Thanks & Best Regards,
Jason

[Bug target/84914] PowerPC complex multiply/divide calls the wrong function when -mabi=ieeelongdouble

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

[Bug target/84914] New: PowerPC complex multiply/divide calls the wrong function when -mabi=ieeelongdouble

[meissner at gcc dot gnu.org]

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

Bug ID: 84914
   Summary: PowerPC complex multiply/divide calls the wrong
function when -mabi=ieeelongdouble
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meissner at gcc dot gnu.org
  Target Milestone: ---

Joseph Meyers had pointed out in January that we are calling the wrong function
for complex multiply/divide when using -mabi=ieeelongdouble -Wno-psabi:

long double _Complex cm (long double _Complex a, long double _Complex b)
{
  return a*b;
}

It should call __mulkc3 instead of __multc3.  Similarly for divide.

[Bug c/84903] internal compiler error: in convert_move, at expr.c:229

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This got fixed with r258272 aka PR84687 fix on the trunk.

[Bug target/84902] [8 Regression] 549.fotonik3d_r from SPEC2017 fails verification with -Ofast -march=native on Zen since r258518

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Just a wild guess, does this fix it?

[Bug middle-end/84891] -fno-signed-zeros leads to optimization which should be possible only if also -ffinite-math-only is on

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
I'm not sure what the C++ complex multiplication / division requirements 
are here (for that matter, C doesn't seem to precisely define which NaN - 
which value with at least one NaN part and the other part not infinite - 
is produced from complex multiplication / division in this case, though 
NaN + iNaN probably makes more sense).

[Bug target/84899] [6/7/8 Regression] ICE: in final_scan_insn_1, at final.c:3139 (error: could not split insn)

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug target/84899] [6/7/8 Regression] ICE: in final_scan_insn_1, at final.c:3139 (error: could not split insn)

[jakub at gcc dot gnu.org]

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

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  ---
In *.reload we have:
(insn 119 28 23 5 (set (reg/v:SI 9 9 [orig:129 b ] [129])
(const_int 2147483647 [0x7fff])) "pr84899.c":6 503
{*movsi_internal1}
 (expr_list:REG_EQUIV (const_int 2147483647 [0x7fff])
(nil)))
(insn 23 119 24 5 (set (reg:SI 9 9 [130])
(plus:SI (reg/v:SI 9 9 [orig:129 b ] [129])
(reg/v:SI 10 10 [orig:124 a ] [124]))) "pr84899.c":6 72 {*addsi3}
 (nil))
(insn 24 23 26 5 (set (reg:SI 9 9 [orig:131 _2 ] [131])
(plus:SI (reg:SI 9 9 [130])
(const_int 1 [0x1]))) "pr84899.c":6 72 {*addsi3}
 (nil))
but postreload turns that into invalid:
(insn 119 28 24 5 (set (reg/v:SI 9 9 [orig:129 b ] [129])
(const_int 2147483648 [0x8000])) "pr84899.c":6 503
{*movsi_internal1}
 (nil))
(insn 24 119 26 5 (set (reg:SI 9 9 [orig:131 _2 ] [131])
(plus:SI (reg/v:SI 9 9 [orig:129 b ] [129])
(reg/v:SI 10 10 [orig:124 a ] [124]))) "pr84899.c":6 72 {*addsi3}
 (nil))
The bug is that 2147483648 is not valid SImode constant, -2147483648 is.

[Bug fortran/84885] c_char bind length

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Fri, Mar 16, 2018 at 01:11:30PM +, mdblack98 at yahoo dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885
> 
> --- Comment #5 from mdblack98 at yahoo dot com ---
> I've been using Fortran since 1980 so caps is natural to me :-)
> My concern is that if gfortran has supported the len>1 convention for many
> years than perhaps it should continue supporting it to prevent breaking code
> like ours which will take some major effort to rewrite.Consider it an
> "extension" to gfortran which apparently it was.  Still fully 2018 compliant
> with this one little extension.  Enable it via a switch if you want to. 

First, gcc-bugzilla is probably not the appropriate forum
for learning nuances of BIND(C).  I suggest posting your
questions to the comp.lang.fortran newsgroup or Stack Overflow.

I've quoted two difference standards.  Both state

   If the type is character, the length type parameter is
   interoperable if and only if its value is one.

The above isn't a numbered constraint, so gfortran is not
obligated to tell a user that in the following

subroutine foo(c)
  use, intrinsic iso_c_binding
  character(len=1000, kind=c_char), bind(c) :: c
end subroutine foo

'c' is not interoperable.  Perhaps, gfortran should issue
at least a warning.  As long as a program does not try to
use 'c' in an interoperable manner, gfortran appears to
ignore the bind(c) attribute.  If a program, however, uses
'c' in an interoperable manner, the user may get a result
he expects even though it technically violates the Fortran
standard. 

Now, when you wrap the character statement in a derived type

subroutine foo(c)
  use, intrinsic :: iso_c_binding
  type, bind(c) :: bar
 character(len=1000, kind=c_char) :: c
  end type
  type(bar) bah
  bah%c = "123"
end subroutine foo

a numbered constraint comes into play.  gfortran must tell
the user that 'c' in type 'bar' is not interoperable.  I quoted
the relevant text already.  From F2018 (and similar appears in
other versions of the standard)

   C1806 (R726) Each component of a derived type with the BIND
   attribute shall be a nonpointer, nonallocatable data component
   with interoperable type and type parameters.

[Bug tree-optimization/84913] New: ICE vectorising chained conditional reduction

[rsandifo at gcc dot gnu.org]

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

Bug ID: 84913
   Summary: ICE vectorising chained conditional reduction
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

This testcase:

function foo(a, b, c, n)
  integer :: a(n), b(n), c(n), n, i, foo
  foo = 0
  do i = 1, n
if (a(i) .eq. b(i)) then
  foo = 1
else if (a(i) .eq. c(i)) then
  foo = 2
end if
  end do
end function foo

triggers an ICE with call stack:

crash_signal
tree_check(tree_node*, char const*, int, char const*, tree_code)
vectorizable_reduction(gimple*, gimple_stmt_iterator*, gimple**, _slp_tree*,
_slp_instance*)
vect_analyze_stmt(gimple*, bool*, _slp_tree*, _slp_instance*)
vect_analyze_loop_operations
vect_analyze_loop_2
vect_analyze_loop(loop*, _loop_vec_info*)
vectorize_loops()

when compiled with -O3 -march=armv8-a+sve (aarch64) or -O3
-march=skylake-avx512 (x86_64).

[Bug tree-optimization/84913] ICE vectorising chained conditional reduction

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Can you attach -fdump-tree-optimized and -fdump-rtl-cse2
-fdump-rtl-pro_and_epilogue -fdump-rtl-dse ?  I really wonder what is different
in our vs. your compiler.

[Bug target/84908] retpoline weirdness: 7.3.0-1 and 4.8.5-16: with -fPIC: R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax'

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
vDSO isn't compiled with -mindirect-branch=thunk-extern in kernel
4.16-rc5.  Why isn't it the case for you?

[Bug target/84912] New: __builtin_divde* produce Internal Compiler Error when compiled -m32

[kelvin at gcc dot gnu.org]

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

Bug ID: 84912
   Summary: __builtin_divde* produce Internal Compiler Error when
compiled -m32
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kelvin at gcc dot gnu.org
  Target Milestone: ---

__builtin_divde, __builtin_divdeo, __builtin_divdeu, __builtin_divdeou are all
documented to require a 64-bit environment.  However, the implementation of
these builtins does not enforce this.

Compile $GCC_SRC/gcc/testsuite/gcc.target/powerpc/extend-divide-2.c with
options -m32 to see the problem.  Here is a captured trace:

$GCC_INSTALL/bin/gcc -B$GCC_BUILD/gcc/ -m32 -o0 -Wall -Wno-deprecated -o
extend-divide-2 extend-divide-2.c
extend-divide-2.c: In function ‘div_de’:
extend-divide-2.c:17:1: error: unrecognizable insn:
 }
 ^
(insn 15 14 16 2 (set (reg:DI 123 [ _3 ])
(unspec:DI [
(reg:DI 121 [ _1 ])
(reg:DI 122 [ _2 ])
] UNSPEC_DIVE)) "extend-divide-2.c":16 -1
 (nil))
during RTL pass: vregs
extend-divide-2.c:17:1: internal compiler error: in extract_insn, at
recog.c:2304
0x1013775f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/kelvin/gcc/gcc-trunk/gcc/rtl-error.c:108
0x101377a3 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/kelvin/gcc/gcc-trunk/gcc/rtl-error.c:116
0x1087eb4b extract_insn(rtx_insn*)
/home/kelvin/gcc/gcc-trunk/gcc/recog.c:2304
0x105751af instantiate_virtual_regs_in_insn
/home/kelvin/gcc/gcc-trunk/gcc/function.c:1591
0x105751af instantiate_virtual_regs
/home/kelvin/gcc/gcc-trunk/gcc/function.c:1959
0x105751af execute
/home/kelvin/gcc/gcc-trunk/gcc/function.c:2008
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [extend-divide-2] Error 1

[Bug c/84909] typo: conversion from %qT to to %qT

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 43682
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43682&action=edit
gcc8-pr84909.patch

Untested fix.

[Bug c++/84898] Fix-it hints for '.' vs '->'

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1

[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #9)
> So GCC's definition of max_align_t is not consistent with malloc in Solaris

Oh, I'm assuming here that the definition of max_align_t is coming from GCC's
.

Wherever that max_align_t definitions comes from, it should match what malloc
does.

[Bug c/84910] typo: "%qs follows inline declaration "

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 43681
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43681&action=edit
gcc8-pr84910.patch

Untested fix.

[Bug libstdc++/77691] [7/8 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
This doesn't seem like a libstdc++ bug. malloc must return memory suitably
aligned for any type of object with a fundamental alignment, i.e. <=
_Alignof(max_align_t).

So GCC's definition of max_align_t is not consistent with malloc in Solaris 12,
which means that GCC and malloc don't agree on the maximum fundamental
alignment for the target.

[Bug c++/71882] elaborated-type-specifier friend not looked up in unnamed namespace

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
IMHO that's a reasonable interpretation, but so is GCC's :-)

Transforming the program as per 10.3.1.1 [namespace.unnamed] we get:

namespace N { }
using namespace N;
namespace N { struct S; }
  class C {
friend struct S;
static void f();
  };
namespace N { struct S { void f() { C::f(); } }; }


GCC and EDG still reject this, and Clang still accepts it.

This seems related to https://wg21.link/cwg138

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[jakub at gcc dot gnu.org]

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

Bug 84907 Summary: [8 Regression] ppc64le gromacs miscompilation since r256656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84907

   What|Removed |Added

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

[Bug target/84907] [8 Regression] ppc64le gromacs miscompilation since r256656

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Ok, confirmed that it works with
  return { __builtin_vec_xl (0, m) };
as the body of simdLoadU.

[Bug tree-optimization/84811] ICE on valid code at -O3 in 64-bit mode on x86_64-linux-gnu: in smallest_mode_for_size, at stor-layout.c:355

[su at cs dot ucdavis.edu]

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

--- Comment #11 from Zhendong Su  ---
(In reply to Martin Liška from comment #9)
> Sorry, I meant --verbose.

$ gcctk -O3 -c --verbose small.c
Using built-in specs.
COLLECT_GCC=gcctk
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 8.0.1 20180316 (experimental) [trunk revision 258587] (GCC) 
COLLECT_GCC_OPTIONS='-O3' '-c' '-v' '-mtune=generic' '-march=x86-64'
 /home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/cc1
-quiet -v -imultiarch x86_64-linux-gnu small.c -quiet -dumpbase small.c
-mtune=generic -march=x86-64 -auxbase small -O3 -version -o /tmp/cculQbQT.s
GNU C17 (GCC) version 8.0.1 20180316 (experimental) [trunk revision 258587]
(x86_64-pc-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/home/su/software/tmp/gcc/gcc-trunk/lib/gcc/x86_64-pc-linux-gnu/8.0.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/su/software/tmp/gcc/gcc-trunk/lib/gcc/x86_64-pc-linux-gnu/8.0.1/include
 /usr/local/include
 /home/su/software/tmp/gcc/gcc-trunk/include

/home/su/software/tmp/gcc/gcc-trunk/lib/gcc/x86_64-pc-linux-gnu/8.0.1/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C17 (GCC) version 8.0.1 20180316 (experimental) [trunk revision 258587]
(x86_64-pc-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: f6266f581518b6147a3db5aa3f80d40c
during RTL pass: dse1
small.c: In function ‘fn1’:
small.c:12:1: internal compiler error: in smallest_mode_for_size, at
stor-layout.c:355
 }
 ^
0xc9009b smallest_mode_for_size(poly_int<1u, unsigned long>, mode_class)
../../gcc-source-trunk/gcc/stor-layout.c:355
0x14376fc smallest_int_mode_for_size(poly_int<1u, unsigned long>)
../../gcc-source-trunk/gcc/machmode.h:842
0x14376fc find_shift_sequence
../../gcc-source-trunk/gcc/dse.c:1701
0x14376fc get_stored_val
../../gcc-source-trunk/gcc/dse.c:1847
0x143a05c record_store
../../gcc-source-trunk/gcc/dse.c:1557
0x143af02 scan_insn
../../gcc-source-trunk/gcc/dse.c:2545
0x143c0f2 dse_step1
../../gcc-source-trunk/gcc/dse.c:2657
0x143c0f2 rest_of_handle_dse
../../gcc-source-trunk/gcc/dse.c:3574
0x143c0f2 execute
../../gcc-source-trunk/gcc/dse.c:3672
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$

[Bug c++/71882] elaborated-type-specifier friend not looked up in unnamed namespace

[sbergman at redhat dot com]

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

--- Comment #3 from Stephan Bergmann  ---
(In reply to Jonathan Wakely from comment #2)
> 10.3.1.2 [namespace.memdef] p3 says "the lookup to determine whether the
> entity has been previously declared shall not consider any scopes outside
> the innermost enclosing namespace." The struct S is not declared in the
> innermost enclosing namespace, but it is visible there, so normal name
> lookup would find it. But then this isn't normal name lookup, because it
> doesn't keep looking in enclosing namespaces, only the innermost.

I guess when I originally filed this bug I interpreted the quoted part of
[namespace.memdef] to mean that the lookup is done as per 6.4.1
[basic.lookup.unqual] but ignores scopes *outside* the innermost enclosing
namespace, but not scopes *inside* it, like a nested unnamed namespace.

[Bug c++/71882] elaborated-type-specifier friend not looked up in unnamed namespace

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
GCC adds a declaration of struct S to the enclosing namespace, and makes that a
friend, rather than the struct S in the unnamed namespace.

10.3.1.2 [namespace.memdef] p3 says "the lookup to determine whether the entity
has been previously declared shall not consider any scopes outside the
innermost enclosing namespace." The struct S is not declared in the innermost
enclosing namespace, but it is visible there, so normal name lookup would find
it. But then this isn't normal name lookup, because it doesn't keep looking in
enclosing namespaces, only the innermost.


Given that this seems to be valid (at least, accepted by all of GCC, Clang and
EDG):

namespace { struct S { }; }
struct S { };

It is apparently OK to declare ::S, but it's unclear to me whether the friend
declaration should do that. EDG agrees with GCC and rejects the original
testcase.

[Bug target/84907] [8 Regression] ppc64le gromacs miscompilation since r256656

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||wschmidt at gcc dot gnu.org

--- Comment #4 from Bill Schmidt  ---
Agreed.  The supported way to do an unaligned vector load on Power is with the
vec_xl intrinsic.

[Bug c/84909] typo: conversion from %qT to to %qT

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-03-16
 Ever confirmed|0   |1