[Bug libstdc++/103013] Underconstrained constructor span(_Range&&)

2021-10-31 Thread andrey.davydov at jetbrains dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013

--- Comment #5 from Andrey  ---
Sorry, my fault, spanhttps://eel.is/c++draft/views.span#span.overview-4. It looks strange for me,
but of course, it's not a topic for this tracker.

[Bug target/102991] [12 regression] gcc.dg/vect/vect-simd-17.c fails after r12-4757

2021-10-31 Thread luoxhu at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102991

--- Comment #3 from luoxhu at gcc dot gnu.org ---
(In reply to Kewen Lin from comment #2)
> (In reply to luoxhu from comment #1)
> > Couldn't reproduce on rain6p1 (P10):
> > 
> 
> It's weird, I can reproduce this on rain6p1.
> 
> FAIL: gcc.dg/vect/vect-simd-17.c execution test
> FAIL: gcc.dg/vect/vect-simd-17.c -flto -ffat-lto-objects execution test
> 
> >--->---=== gcc Summary ===
> 
> # of expected passes>--->---2
> # of unexpected failures>---2
> 
> Probably due to you still specified --with-cpu=power9 instead of
> --with-cpu=power10 in gcc configuration?

Thanks, confirmed. --with-cpu=power9 doesn't fail on both P9 and P10 with the
patch.

It aborts at vect-simd-17.c of line 274.

[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck

2021-10-31 Thread egallager at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402

--- Comment #45 from Eric Gallager  ---
(In reply to Martin Liška from comment #0)
> [...]
> Then I built GCC with -j1 and used following parser to generate reports:
> https://github.com/marxin/script-misc/blob/master/parse-make-log.py

The new URL for that script is now this, btw:
https://github.com/marxin/script-misc/blob/master/legacy/parse-make-log.py

[Bug debug/102955] [12 Regression] ICE with #pragma optimize "0" or attribute optimize and -g -gtoggle

2021-10-31 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102955

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Liška  ---
Mine, thanks for the reduction.

[Bug other/102657] libcody makefile is missing a mostlyclean target

2021-10-31 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102657

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:7a71ea4df7e97a640e6747d6787a1885eb3bbc40

commit r12-4817-g7a71ea4df7e97a640e6747d6787a1885eb3bbc40
Author: Martin Liska 
Date:   Mon Oct 25 16:32:55 2021 +0200

libcody: add mostlyclean Makefile target

PR other/102657

libcody/ChangeLog:

* Makefile.in: Add mostlyclean Makefile target.

[Bug tree-optimization/103007] [12 Regression] ice in vect_normalize_conj_loc, at tree-vect-slp-patterns.c:722 since r12-4785-ged3de62ac949c92ad41ef6de7cc926fbb2a510ce

2021-10-31 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
Summary|[12 Regression] ice in  |[12 Regression] ice in
   |vect_normalize_conj_loc, at |vect_normalize_conj_loc, at
   |tree-vect-slp-patterns.c:72 |tree-vect-slp-patterns.c:72
   |2   |2 since
   ||r12-4785-ged3de62ac949c92ad
   ||41ef6de7cc926fbb2a510ce
 Blocks||26163

--- Comment #3 from Martin Liška  ---
Btw. it affects quite some SPEC benchmarks.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug libstdc++/103013] Underconstrained constructor span(_Range&&)

2021-10-31 Thread rs2740 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #4 from TC  ---
I don't think this needs an extra constraint, just reordering the existing ones
to check not-a-span (14.3, "remove_­cvref_­t is not a specialization of
span") first.

But this is very much undefined anyway.

[Bug c++/102990] ICE in tsubst_copy_and_build with coroutines and concepts

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Keywords|needs-reduction |

--- Comment #2 from Andrew Pinski  ---
Still reducing it, down to 2.2M file

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread hboetes at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

--- Comment #12 from Han Boetes  ---
Wow, thanks, let's see if I can manage that.

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #10)
> I looked and I see openbsd has a patch which adds fname_as_string to one of
> the generic parts of GCC which is causing this.
> apinski@xeond:~/src/openbsd-ports/lang/gcc/11/patches$ git grep
> fname_as_string
> patch-gcc_ada_adaint_c:+fname_as_string(int pretty_p
> __attribute__((__unused__)))
> patch-gcc_d_d-lang_cc:+fname_as_string(int pretty_p
> __attribute__((__unused__)))
> patch-gcc_fortran_f95-lang_c:+fname_as_string(int pretty_p
> __attribute__((__unused__)))
> patch-gcc_go_go-lang_c:+fname_as_string(int pretty_p
> __attribute__((__unused__)))
> patch-gcc_lto_lto-common_c:+fname_as_string(int pretty_p
> __attribute__((__unused__)))
> patch-gcc_targhooks_c:+  if (NULL == (tmp_name = fname_as_string (0))) {

Basically you need to do a similar patch to the jit sources as was done for
Ada, D, go, and lto front-ends.

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #10 from Andrew Pinski  ---
I looked and I see openbsd has a patch which adds fname_as_string to one of the
generic parts of GCC which is causing this.
apinski@xeond:~/src/openbsd-ports/lang/gcc/11/patches$ git grep fname_as_string
patch-gcc_ada_adaint_c:+fname_as_string(int pretty_p
__attribute__((__unused__)))
patch-gcc_d_d-lang_cc:+fname_as_string(int pretty_p
__attribute__((__unused__)))
patch-gcc_fortran_f95-lang_c:+fname_as_string(int pretty_p
__attribute__((__unused__)))
patch-gcc_go_go-lang_c:+fname_as_string(int pretty_p
__attribute__((__unused__)))
patch-gcc_lto_lto-common_c:+fname_as_string(int pretty_p
__attribute__((__unused__)))
patch-gcc_targhooks_c:+  if (NULL == (tmp_name = fname_as_string (0))) {

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

--- Comment #9 from Andrew Pinski  ---
Do you have any patches that gets applied to the gcc sources from say openbsd?

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread hboetes at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

--- Comment #8 from Han Boetes  ---
Well that's unexpected…

/usr/local/lib % ag -a fname_as_string
Binary file libgccjit.so.0.0.1 matches.

gcc/x86_64-unknown-openbsd7.0/11.2.0/plugin/include/c-family/c-common.h
extern const char *fname_as_string (int);


% nm /usr/local/lib/libgccjit.so.0.0.1
 W _ITM_RU1
 W _ITM_RU8
 W _ITM_addUserCommitAction
 W _ITM_memcpyRnWt
 W _ITM_memcpyRtWn
 W _Jv_RegisterClasses
 U _Z15fname_as_stringi
 W _ZGTtdlPv
 W _ZGTtnam
 U __cxa_atexit
 W __cxa_finalize
 W __cxa_pure_virtual
 U __errno
 U __gmp_version
 U __gmpz_add
 U __gmpz_add_ui
 U __gmpz_clear
 U __gmpz_cmp
 U __gmpz_com
 U __gmpz_export
 U __gmpz_fdiv_q
 U __gmpz_import
 U __gmpz_init
 U __gmpz_init_set
 U __gmpz_out_str
 U __gmpz_set
 U __gmpz_set_ui
 U __gmpz_sizeinbase
 U __gmpz_sub
 U __gmpz_sub_ui
 U __gmpz_swap
 U __isthreaded
 U __sF
 U __srget
 U __stack_smash_handler
 U __swbuf
 U _ctype_
 U _exit
 W _thread_atfork
 U _tolower_tab_
 U abort
 U access
 U asctime
 U atoi
 U bsearch
 U calloc
 U close
 U closedir
 U deflate
 U deflateEnd
 U deflateInit_
 U dl_iterate_phdr
 U dlclose
 U dlerror
 U dlopen
 U dlsym
 U dup2
 U environ
 U execv
 U execvp
 U exit
 U fchmod
 U fclose
 U fcntl
 U fdopen
 U feof
 U ferror
 U fflush
 U fgetc
 U fgets
 U fileno
 U fopen
 U fprintf
 U fputc
 U fputs
 U fread
 U free
 U freopen
 U fseek
 U fstat
 U ftell
 U fwrite
00918140 T gcc_jit_block_add_assignment
00918350 T gcc_jit_block_add_assignment_op
00918880 T gcc_jit_block_add_comment
00917f80 T gcc_jit_block_add_eval
0091ad30 T gcc_jit_block_add_extended_asm
00915360 T gcc_jit_block_as_object
009185a0 T gcc_jit_block_end_with_conditional
0091ae80 T gcc_jit_block_end_with_extended_asm_goto
00918a20 T gcc_jit_block_end_with_jump
00918c00 T gcc_jit_block_end_with_return
0091bd20 T gcc_jit_block_end_with_switch
00918e00 T gcc_jit_block_end_with_void_return
009153b0 T gcc_jit_block_get_function
00918ff0 T gcc_jit_case_as_object
009134b0 T gcc_jit_context_acquire
00919510 T gcc_jit_context_add_command_line_option
00919630 T gcc_jit_context_add_driver_option
0091b480 T gcc_jit_context_add_top_level_asm
00919840 T gcc_jit_context_compile
00919960 T gcc_jit_context_compile_to_file
00919d30 T gcc_jit_context_dump_reproducer_to_file
00919ac0 T gcc_jit_context_dump_to_file
00919750 T gcc_jit_context_enable_dump
00914ec0 T gcc_jit_context_get_builtin_function
00919e50 T gcc_jit_context_get_first_error
00913980 T gcc_jit_context_get_int_type
00919f10 T gcc_jit_context_get_last_error
0091a330 T gcc_jit_context_get_timer
009138a0 T gcc_jit_context_get_type
00917370 T gcc_jit_context_new_array_access
00913b30 T gcc_jit_context_new_array_type
00916600 T gcc_jit_context_new_binary_op
00913e30 T gcc_jit_context_new_bitfield
00916a80 T gcc_jit_context_new_call
00916d60 T gcc_jit_context_new_call_through_ptr
0091b5c0 T gcc_jit_context_new_case
00917110 T gcc_jit_context_new_cast
009135e0 T gcc_jit_context_new_child_context
009168b0 T gcc_jit_context_new_comparison
00913c80 T gcc_jit_context_new_field
00914bd0 T gcc_jit_context_new_function
009147c0 T gcc_jit_context_new_function_ptr_type
009153f0 T gcc_jit_context_new_global
00913710 T gcc_jit_context_new_location
00914280 T gcc_jit_context_new_opaque_struct
009149a0 T gcc_jit_context_new_param
00915ec0 T gcc_jit_context_new_rvalue_from_double
009158f0 T gcc_jit_context_new_rvalue_from_int
00915a80 T gcc_jit_context_new_rvalue_from_long
00916050 T gcc_jit_context_new_rvalue_from_ptr
0091a990 T gcc_jit_context_new_rvalue_from_vector
00916310 T gcc_jit_context_new_string_literal
00914090 T gcc_jit_context_new_struct_type
00916400 T gcc_jit_context_new_unary_op
009145d0 T gcc_jit_context_new_union_type
009161e0 T gcc_jit_context_null
00915d60 T gcc_jit_context_one
009134f0 T gcc_jit_context_release
009193a0 T gcc_jit_context_set_bool_allow_unreachable_blocks
009192e0 T gcc_jit_context_set_bool_option
00919450 T gcc_jit_context_set_bool_use_external_driver
00919220 T gcc_jit_context_set_int_option
00919c00 T gcc_jit_context_set_logfile
00919160 T gcc_jit_context_set_str_option
0091a2e0 T gcc_jit_context_set_timer
00915c10 T gcc_jit_context_zero
0091b350 T gcc_jit_extended_asm_add_clobber
0091b230 T gcc_jit_extended_asm_add_input_operand
0091b0f0 T gcc_jit_extended_asm_add_output_operand
0091b040 T 

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

--- Comment #7 from Andrew Pinski  ---
Can you post the output of "nm /usr/local/lib/libgccjit.so.0.0.1"?

[Bug d/102837] [12 regression] Many 32-bit gdc tests FAIL

2021-10-31 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #7 from Iain Buclaw  ---
Fix committed.

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread hboetes at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

--- Comment #6 from Han Boetes  ---
So this is what I did:

% export LD_DEBUG=yes
% /usr/pkgmk/work/emacs/src/emacs/lisp % ../src/bootstrap-emacs -batch
--no-site-file --no-site-lisp --eval '(setq load-prefer-newer t)' -l comp -f
batch-byte+native-
compile international/titdic-cnv.el > output 2>&1

And here is the output:

ld.so loading: 'bootstrap-emacs'
exe load offset:  0x60f1c0be000
 flags ../src/bootstrap-emacs = 0x800
head ../src/bootstrap-emacs
obj ../src/bootstrap-emacs has ../src/bootstrap-emacs as head
examining: '../src/bootstrap-emacs'
loading: libgmp.so.11.0 required by ../src/bootstrap-emacs
 flags /usr/local/lib/libgmp.so.11.0 = 0x0
obj /usr/local/lib/libgmp.so.11.0 has ../src/bootstrap-emacs as head
loading: libpthread.so.26.1 required by ../src/bootstrap-emacs
 flags /usr/lib/libpthread.so.26.1 = 0x8
obj /usr/lib/libpthread.so.26.1 has ../src/bootstrap-emacs as head
loading: libxml2.so.17.0 required by ../src/bootstrap-emacs
 flags /usr/local/lib/libxml2.so.17.0 = 0x0
obj /usr/local/lib/libxml2.so.17.0 has ../src/bootstrap-emacs as head
loading: libc.so.96.1 required by ../src/bootstrap-emacs
 flags /usr/lib/libc.so.96.1 = 0x21
obj /usr/lib/libc.so.96.1 has ../src/bootstrap-emacs as head
loading: libgccjit.so.0 required by ../src/bootstrap-emacs
 flags /usr/local/lib/libgccjit.so.0.0.1 = 0x0
obj /usr/local/lib/libgccjit.so.0.0.1 has ../src/bootstrap-emacs as head
loading: libcurses.so.14.0 required by ../src/bootstrap-emacs
 flags /usr/lib/libcurses.so.14.0 = 0x0
obj /usr/lib/libcurses.so.14.0 has ../src/bootstrap-emacs as head
loading: liblcms2.so.1.4 required by ../src/bootstrap-emacs
 flags /usr/local/lib/liblcms2.so.1.4 = 0x0
obj /usr/local/lib/liblcms2.so.1.4 has ../src/bootstrap-emacs as head
loading: libexecinfo.so.3.0 required by ../src/bootstrap-emacs
 flags /usr/lib/libexecinfo.so.3.0 = 0x0
obj /usr/lib/libexecinfo.so.3.0 has ../src/bootstrap-emacs as head
loading: libdbus-1.so.11.2 required by ../src/bootstrap-emacs
 flags /usr/local/lib/libdbus-1.so.11.2 = 0x0
obj /usr/local/lib/libdbus-1.so.11.2 has ../src/bootstrap-emacs as head
loading: libossaudio.so.4.0 required by ../src/bootstrap-emacs
 flags /usr/lib/libossaudio.so.4.0 = 0x0
obj /usr/lib/libossaudio.so.4.0 has ../src/bootstrap-emacs as head
loading: libjansson.so.4.1 required by ../src/bootstrap-emacs
 flags /usr/local/lib/libjansson.so.4.1 = 0x0
obj /usr/local/lib/libjansson.so.4.1 has ../src/bootstrap-emacs as head
loading: libm.so.10.1 required by ../src/bootstrap-emacs
 flags /usr/lib/libm.so.10.1 = 0x0
obj /usr/lib/libm.so.10.1 has ../src/bootstrap-emacs as head
loading: libz.so.6.0 required by ../src/bootstrap-emacs
 flags /usr/lib/libz.so.6.0 = 0x0
obj /usr/lib/libz.so.6.0 has ../src/bootstrap-emacs as head
loading: libgnutls.so.47.1 required by ../src/bootstrap-emacs
 flags /usr/local/lib/libgnutls.so.47.1 = 0x0
obj /usr/local/lib/libgnutls.so.47.1 has ../src/bootstrap-emacs as head
linking dep /usr/lib/libossaudio.so.4.0 as child of ../src/bootstrap-emacs
linking dep /usr/local/lib/libdbus-1.so.11.2 as child of ../src/bootstrap-emacs
linking dep /usr/lib/libexecinfo.so.3.0 as child of ../src/bootstrap-emacs
linking dep /usr/local/lib/libxml2.so.17.0 as child of ../src/bootstrap-emacs
linking dep /usr/lib/libcurses.so.14.0 as child of ../src/bootstrap-emacs
linking dep /usr/local/lib/libgnutls.so.47.1 as child of ../src/bootstrap-emacs
objname /usr/lib/libpthread.so.26.1 is nodelete
linking dep /usr/lib/libpthread.so.26.1 as child of ../src/bootstrap-emacs
linking dep /usr/local/lib/liblcms2.so.1.4 as child of ../src/bootstrap-emacs
linking dep /usr/lib/libm.so.10.1 as child of ../src/bootstrap-emacs
linking dep /usr/lib/libz.so.6.0 as child of ../src/bootstrap-emacs
linking dep /usr/local/lib/libjansson.so.4.1 as child of ../src/bootstrap-emacs
linking dep /usr/local/lib/libgmp.so.11.0 as child of ../src/bootstrap-emacs
linking dep /usr/local/lib/libgccjit.so.0.0.1 as child of
../src/bootstrap-emacs
linking dep /usr/lib/libc.so.96.1 as child of ../src/bootstrap-emacs
examining: '/usr/lib/libossaudio.so.4.0'
examining: '/usr/local/lib/libdbus-1.so.11.2'
loading: libexecinfo.so.3.0 required by /usr/local/lib/libdbus-1.so.11.2
loading: libpthread.so.26.1 required by /usr/local/lib/libdbus-1.so.11.2
linking dep /usr/lib/libpthread.so.26.1 as child of
/usr/local/lib/libdbus-1.so.11.2
linking dep /usr/lib/libexecinfo.so.3.0 as child of
/usr/local/lib/libdbus-1.so.11.2
examining: '/usr/lib/libexecinfo.so.3.0'
examining: '/usr/local/lib/libxml2.so.17.0'
loading: libm.so.10.1 required by /usr/local/lib/libxml2.so.17.0
loading: libiconv.so.7.0 required by /usr/local/lib/libxml2.so.17.0
 flags /usr/local/lib/libiconv.so.7.0 = 0x0
obj /usr/local/lib/libiconv.so.7.0 has ../src/bootstrap-emacs as head
loading: libpthread.so.26.1 required by /usr/local/lib/libxml2.so.17.0
loading: liblzma.so.2.1 required by /usr/local/lib/libxml2.so.17.0
 flags 

[Bug fortran/102715] [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8184 since r12-4278-g74ccca380cde5e79

2021-10-31 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102715

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Patch: https://gcc.gnu.org/pipermail/fortran/2021-October/056904.html

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

--- Comment #5 from David Malcolm  ---
(In reply to David Malcolm from comment #4)
> Hopefully that will give a hint as to where that symbol is coming from.
...or, rather, where the *usage* of that symbol is coming from.

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

--- Comment #4 from David Malcolm  ---
I'm not sure how best to debug this.

$ echo _Z15fname_as_stringi | c++filt
fname_as_string(int)

and indeed, that seems to be just for the C/C++ frontends, not for libgccjit.

Some ideas:
Given:
  bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol
'_Z15fname_as_stringi'
  ld.so: bootstrap-emacs: lazy binding failed!
...it appears to be an issue with dynamic linkage.

You could try turning up the verbosity of the dynamic linker; if it's glibc you
could try setting
  LD_DEBUG=all
in the environment, which I believe is the most verbose option (see "man ld.so"
for other options, if that's overkill).  Hopefully that will give a hint as to
where that symbol is coming from.

If that doesn't help, is there a way to figure out what the command line is at
the point of failure, and what it's trying to do?

[Bug d/102959] gdc.dg/torture/pr96435.d FAILs

2021-10-31 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102959

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Buclaw  ---
Fix committed.

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread hboetes at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

--- Comment #3 from Han Boetes  ---
I've just grepped the Emacs code for 'fname_as_string' and it isn't in there
either.

[Bug c/102939] Ridiculously long compilation times on (admittedly itself ridiculous) pointer declaration

2021-10-31 Thread hp at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102939

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #3 from Hans-Peter Nilsson  ---
(In reply to Gabriel Ravier from comment #0)
...
> #define PTR4 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3 PTR3
> #define PTR5 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4 PTR4
> #define PTR6 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5 PTR5
> 
> int PTR4 q3_var = 0;
...

Is the use of PTR4 instead of PTR6 or PTR5, intended to provoke comments such
as this one, or are there untold additional related observations?

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

--- Comment #2 from Andrew Pinski  ---
gcc/ChangeLog-2001: (fname_as_string): Likewise.
gcc/ChangeLog-2001: (fname_as_string): New function from remnants of
gcc/ChangeLog-2003: * c-common.c (fname_as_string): Use
lang_hooks.decl_printable_name
gcc/ChangeLog-2004: * c-common.c (fname_as_string): Free namep if we are
returning
gcc/ChangeLog-2004: * c-common.c (fname_as_string): Fix xcalloc to xmalloc.
gcc/ChangeLog-2004: fname_as_string.
gcc/ChangeLog-2004: fname_as_string.
gcc/ChangeLog-2004: * c-common.c (fname_as_string): Translate if necessary.
gcc/ChangeLog-2004: * c-common.c (fname_as_string,
c_common_truthvalue_conversion,
gcc/ChangeLog-2007: * c-common.c (fname_as_string): Update.
gcc/ChangeLog-2007: * c-common.c (fname_as_string, c_type_hash): Constify.
gcc/ChangeLog-2008: (fname_as_string): Match updated cpp_interpret_string
prototype.
gcc/c-family/ChangeLog: * c-common.c (fname_as_string): Use cxx_printable_name
for
gcc/c-family/c-common.c:fname_as_string (int pretty_p)
gcc/c-family/c-common.h:extern const char *fname_as_string (int);
gcc/c/c-decl.c:  const char *name = fname_as_string (type_dep);
gcc/cp/ChangeLog-2004:  fname_as_string.
gcc/cp/decl.c:name = fname_as_string (type_dep);

There should be no reference to fname_as_string in libgccjit at all ...

[Bug jit/103016] libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

--- Comment #1 from Andrew Pinski  ---
fname_as_string is only defined in the C/C++ front-ends ...

c-family/ChangeLog: * c-common.c (fname_as_string): Use cxx_printable_name
for
c-family/c-common.c:fname_as_string (int pretty_p)
c-family/c-common.h:extern const char *fname_as_string (int);
c/c-decl.c:  const char *name = fname_as_string (type_dep);
cp/ChangeLog-2004:  fname_as_string.
cp/decl.c:name = fname_as_string (type_dep);

[Bug jit/103016] New: libgccjit on OpenBSD-7.0 fails with bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol '_Z15fname_as_stringi'

2021-10-31 Thread hboetes at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103016

Bug ID: 103016
   Summary: libgccjit on OpenBSD-7.0 fails with
bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1:
undefined symbol '_Z15fname_as_stringi'
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: hboetes at gmail dot com
  Target Milestone: ---

I already reported this bug to the Emacs bug list and Eli Zaretskii, the Emacs
maintainer, insisted it was an issue with GCC. Please bear with me, since this
is not a normal bug-report.

Whilst compiling Emacs with the --with-native-compilation, which uses
libgccjit, I ran into the following issue:


gmake[2]: Entering directory '/usr/obj/work/emacs/src/emacs/lisp'
  ELC+ELN  international/titdic-cnv.elc
bootstrap-emacs:/usr/local/lib/libgccjit.so.0.0.1: undefined symbol
'_Z15fname_as_stringi'
ld.so: bootstrap-emacs: lazy binding failed!
Killed 
gmake[2]: *** [Makefile:316: international/titdic-cnv.elc] Error 137
gmake[2]: Leaving directory '/usr/obj/work/emacs/src/emacs/lisp'
gmake[1]: *** [Makefile:835: ../lisp/loaddefs.el] Error 2
gmake[1]: Leaving directory '/usr/obj/work/emacs/src/emacs/src'
gmake: *** [Makefile:450: src] Error 2


Since OpenBSD ports & packages does not yet include libgccjit I modified the
port (instructions to build a package) to include the required options as per
https://gcc.gnu.org/onlinedocs/gcc-11.2.0/jit/internals/index.html,
bootstrapped GCC and, got a package with libgccjit.


% egcc --version
egcc (GCC) 11.2.0

The OpenBSD version is: 7.0-amd64

How can I help debugging this problem?


Thanks,
Han

[Bug tree-optimization/102943] [12 Regression] VRP threader compile-time hog with 521.wrf_r

2021-10-31 Thread hubicka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943

--- Comment #7 from Jan Hubicka  ---
this is compile time plot
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=227.270.8
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=289.270.8
(-O2 and -Ofast with lto)
Things has improved but build times are still a lot worse than before.

[Bug target/103008] poor inlined builtin_fmod on x86_64

2021-10-31 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103008

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-31
 Ever confirmed|0   |1

--- Comment #6 from Uroš Bizjak  ---
Please see PR29852. The only way to avoid the libcall in 2006 was to inline the
x87 version also for SSE math. Nowadays a (generic) arithmetic sequence can be
provided and x87 fmod builtins can be enabled for x87 math only with:

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index e733a40fc90..ed818232ae7 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -17378,6 +17378,8 @@
(use (match_operand:MODEF 1 "general_operand"))
(use (match_operand:MODEF 2 "general_operand"))]
   "TARGET_USE_FANCY_MATH_387
+   && (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
+   || TARGET_MIX_SSE_I387)
&& flag_finite_math_only"
 {
   rtx (*gen_truncxf) (rtx, rtx);

[Bug fortran/101337] gfortran doesn't diagnose all operands with constraint violations

2021-10-31 Thread aldot at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-October
   ||/582983.html
 CC||aldot at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-31

--- Comment #2 from Bernhard Reutner-Fischer  ---
confirmed

[Bug d/102837] [12 regression] Many 32-bit gdc tests FAIL

2021-10-31 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102837

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r12-4813-gd41092ec52f46d2f4b08fff8d1519e50354331b0
Author: Iain Buclaw 
Date:   Sun Oct 31 18:07:16 2021 +0100

d: Fix regressing test failures on ix86-solaris2.11

The _Unwind_Exception struct had its alignment adjusted to 16-bytes,
however malloc() on Solaris X86 is not guaranteed to allocate memory
aligned to 16-bytes as well.

PR d/102837

libphobos/ChangeLog:

* libdruntime/gcc/deh.d (ExceptionHeader.free): Use memset to reset
contents of internal EH storage.

[Bug d/102959] gdc.dg/torture/pr96435.d FAILs

2021-10-31 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102959

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:1b5f73858412731bb2e821bdf0fc85d6cc012d33

commit r12-4812-g1b5f73858412731bb2e821bdf0fc85d6cc012d33
Author: Iain Buclaw 
Date:   Sun Oct 31 16:49:33 2021 +0100

d: Fix pr96435.d failing on SPARC and HPPA

The value used to initialize the integer field in the union didn't
account for BigEndian targets running this code.

PR d/102959

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr96435.d: Adjust for BigEndian.

[Bug libstdc++/103013] Underconstrained constructor span(_Range&&)

2021-10-31 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013

--- Comment #3 from Jonathan Wakely  ---
And libstdc++ has exactly the constraints required by the C++ draft. I suggest
reporting this as an LWG defect.

[Bug libstdc++/103013] Underconstrained constructor span(_Range&&)

2021-10-31 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013

--- Comment #2 from Jonathan Wakely  ---
According to the standard, span is undefined behaviour, see the
last bullet of [res.on.functions].

[Bug fortran/100991] [OpenMP] firstprivate for optional arguments is mishandled

2021-10-31 Thread aldot at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100991

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||aldot at gcc dot gnu.org
   Last reconfirmed||2021-10-31

[Bug fortran/100972] Missing error with "implicit none (external)"

2021-10-31 Thread aldot at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100972

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||patch
   Last reconfirmed||2021-10-31
 CC||aldot at gcc dot gnu.org
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-October
   ||/582979.html

--- Comment #2 from Bernhard Reutner-Fischer  ---
Confirmed

[Bug fortran/99884] Double spaces in warning message

2021-10-31 Thread aldot at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99884

Bernhard Reutner-Fischer  changed:

   What|Removed |Added

   Keywords||patch
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-31
 CC||aldot at gcc dot gnu.org
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-October
   ||/582974.html
 Status|UNCONFIRMED |NEW

--- Comment #1 from Bernhard Reutner-Fischer  ---
Confirmed.

[Bug target/103015] [pentium4][solaris] Segmentation fault loading pointer to TLS

2021-10-31 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103015

--- Comment #3 from Iain Buclaw  ---
(In reply to Andrew Pinski from comment #2)
> Are you using Solaris's ld or as? Or what version of binutils are you using?
> Yes it does matter here.
Configured gcc --without-gnu-ld --with-ld=/usr/bin/ld --with-gnu-as
--with-as=/usr/gnu/bin/as

ld version: Solaris Link Editors: 5.11-1.3159
as version: GNU Binutils: 2.30

[Bug ada/103014] [11/12 Regression] gnat1 segfaults in tree_could_trap_p when C double parameter, -O2 -gnatn -gnatVa

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103014

Andrew Pinski  changed:

   What|Removed |Added

Summary|gnat1 segfaults in  |[11/12 Regression] gnat1
   |tree_could_trap_p when C|segfaults in
   |double parameter, -O2   |tree_could_trap_p when C
   |-gnatn -gnatVa  |double parameter, -O2
   ||-gnatn -gnatVa
   Target Milestone|--- |11.3
   Keywords||ice-on-valid-code

[Bug target/103015] [pentium4][solaris] Segmentation fault loading pointer to TLS

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103015

--- Comment #2 from Andrew Pinski  ---
Are you using Solaris's ld or as? Or what version of binutils are you using?
Yes it does matter here.

[Bug c++/102975] Local alias diagnosed as unused when used in failing constraint

2021-10-31 Thread johelegp at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102975

--- Comment #4 from Johel Ernesto Guerrero Peña  ---
I'm fine with closing this as RESOLVED INVALID or something along those lines.

[Bug c++/102975] Local alias diagnosed as unused when used in failing constraint

2021-10-31 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102975

--- Comment #3 from Patrick Palka  ---
(In reply to Patrick Palka from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Hmm, this is interesting:
> > template concept Never = false;
> > template concept C = Never;
> > void f() {
> >   struct X {
> >// using type = int;
> >   };
> >   static_assert(not C);
> > }
> > 
> > is able to compile. I don't know enough about C++ concepts to say if this is
> > valid or not but it looks like the type is really unused in the above case
> > ...
> > This is different from "constexpr bool" which requires the type to be
> > defined ...
> 
> Yeah, when evaluating a concept-id such as C (which is done by
> substituting {X} into the normal form of C), the normalization process
> (https://eel.is/c++draft/temp.constr.normal) ignores arguments to unused
> template parameters.
> 
> So since 'Never' doesn't use its template parameter, during normalization of
> C we discard the template argument 'typename T::type' passed to Never.  The
> normal form of C ends up being 'false (with empty parameter mapping)' which
> is trivially satisfied for all T.

... trivially _unsatisfied_ rather

[Bug c++/102975] Local alias diagnosed as unused when used in failing constraint

2021-10-31 Thread ppalka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102975

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
(In reply to Andrew Pinski from comment #1)
> Hmm, this is interesting:
> template concept Never = false;
> template concept C = Never;
> void f() {
>   struct X {
>// using type = int;
>   };
>   static_assert(not C);
> }
> 
> is able to compile. I don't know enough about C++ concepts to say if this is
> valid or not but it looks like the type is really unused in the above case
> ...
> This is different from "constexpr bool" which requires the type to be
> defined ...

Yeah, when evaluating a concept-id such as C (which is done by substituting
{X} into the normal form of C), the normalization process
(https://eel.is/c++draft/temp.constr.normal) ignores arguments to unused
template parameters.

So since 'Never' doesn't use its template parameter, during normalization of C
we discard the template argument 'typename T::type' passed to Never.  The
normal form of C ends up being 'false (with empty parameter mapping)' which is
trivially satisfied for all T.  So it seems to me the warning is correct since
evaluating C doesn't actually use X::type, and the alias is never otherwise
used.

(If this discarding unused template parameters of a concept is undesirable, one
can define the concept in question in a way that trivially uses its template
parameter, e.g.:

  template concept Never = requires { typename T; } && false;)

[Bug c/103015] [i386][solaris] Segmentation fault loading pointer to TLS

2021-10-31 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103015

--- Comment #1 from Iain Buclaw  ---
The specific CPU config options of -m32 are: -mcpu=generic -march=pentium4
-mtune=generic

[Bug c/103015] New: [i386][solaris] Segmentation fault loading pointer to TLS

2021-10-31 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103015

Bug ID: 103015
   Summary: [i386][solaris] Segmentation fault loading pointer to
TLS
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Translation of D test gdc.test/runnable/testv.d that segfaults when compiled
with -O2, and linking libraries in dynamically.

---
// Compiled with -m32 -O2
int printf(const char*, ...);

_Thread_local int a1[2] = {5,6};
_Thread_local int a2[3] = {5,6,7};
_Thread_local int a3[4] = {5,6,7,8};

int sum3(int* xx, int length)
{
int s = 0;
for (int i = 0; i < length; i++)
{
int x = xx[i];
s += x;
}
return s;
}

int main()
{
printf("%d\n", sum3(a3, sizeof(a3) / sizeof(a3[0])));
return 0;
}
---

---
Dump of assembler code for function main:
   0x08050c60 <+0>: lea0x4(%esp),%ecx
   0x08050c64 <+4>: and$0xfff0,%esp
   0x08050c67 <+7>: pushl  -0x4(%ecx)
   0x08050c6a <+10>:push   %ebp
   0x08050c6b <+11>:mov%esp,%ebp
   0x08050c6d <+13>:push   %ecx
   0x08050c6e <+14>:sub$0xc,%esp
   0x08050c71 <+17>:mov%gs:0x0,%eax
   0x08050c77 <+23>:lea-0x4(%esp),%esp
=> 0x08050c7b <+27>:movdqa -0x28(%eax),%xmm0
   0x08050c83 <+35>:movdqa %xmm0,%xmm1
   0x08050c87 <+39>:psrldq $0x8,%xmm1
   0x08050c8c <+44>:paddd  %xmm1,%xmm0
   0x08050c90 <+48>:movdqa %xmm0,%xmm1
   0x08050c94 <+52>:psrldq $0x4,%xmm1
   0x08050c99 <+57>:paddd  %xmm1,%xmm0
   0x08050c9d <+61>:movd   %xmm0,(%esp)
   0x08050ca2 <+66>:push   $0x80509f8
   0x08050ca7 <+71>:call   0x8050a4c 
   0x08050cac <+76>:mov-0x4(%ebp),%ecx
   0x08050caf <+79>:add$0x10,%esp
   0x08050cb2 <+82>:xor%eax,%eax
   0x08050cb4 <+84>:leave  
   0x08050cb5 <+85>:lea-0x4(%ecx),%esp
   0x08050cb8 <+88>:ret
End of assembler dump.
---

[Bug ada/103014] New: gnat1 segfaults in tree_could_trap_p when C double parameter, -O2 -gnatn -gnatVa

2021-10-31 Thread nicolas at debian dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103014

Bug ID: 103014
   Summary: gnat1 segfaults in tree_could_trap_p when C double
parameter, -O2 -gnatn -gnatVa
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicolas at debian dot org
  Target Milestone: ---

Hello.

The following valid Ada sources crash 'gcc-11 -O2 -gnatn -gnatVa' as shown
below.
All goes well with gcc-10, with -O1, without inlining or without validity
checks.

The tests have been performed on Debian/x86_64-linux-gnu, with gcc-11/11.2.0-10
and gcc-10/10.3.12.

cat > p.ads < p.adb < {heap 2040k}  {heap 2040k} 
{heap 2040k}  {heap 2040k}  {heap 2936k}
 {heap 2936k}  {heap 2936k}Streaming LTO
 {heap 2936k}  {heap 2936k}  {heap 2936k}
 {heap 2936k}  {heap 2936k}  {heap 2936k}  {heap
2936k}  {heap 2936k}  {heap 2936k}  {heap 2936k}
 {heap 2936k}  {heap 2936k}  {heap 2936k}
 {heap 2936k}Assembling functions:
 {heap 2936k} P.P3
Program received signal SIGSEGV, Segmentation fault.
0x0119a4f6 in tree_could_trap_p(tree_node*) ()

[Bug libstdc++/103013] Underconstrained constructor span(_Range&&)

2021-10-31 Thread andrey.davydov at jetbrains dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013

--- Comment #1 from Andrey  ---
Sorry, the first link to godbolt in the starter message is wrong, it should be
https://gcc.godbolt.org/z/jWeqs6cM4.

[Bug libstdc++/103013] New: Underconstrained constructor span(_Range&&)

2021-10-31 Thread andrey.davydov at jetbrains dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103013

Bug ID: 103013
   Summary: Underconstrained constructor span(_Range&&)
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.davydov at jetbrains dot com
  Target Milestone: ---

During calculation of type trait `is_move_constructible` span constructor
from `_Range &&` is checked and concept `contiguous_range>`
instantiated. It requires T to be complete type
(https://gcc.godbolt.org/z/fYWa3KdTs). It means that
`optional>` couldn't be instantiated
(https://gcc.godbolt.org/z/1PWdE4YK3).

This issue could be solved if make the constructor span(_Range&&) more
constrained, something like this:
template
  requires (!__is_same(_Range, span)) && ...
span(_Range&& __range);

[Bug c++/103012] ICE with #pragma GCC optimize followed by long line

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103012

--- Comment #2 from Andrew Pinski  ---
Someone else has to reduce the testcase and such.
I found this while trying to reduce PR 102990.

[Bug c++/103012] ICE with #pragma GCC optimize followed by long line

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103012

--- Comment #1 from Andrew Pinski  ---
Created attachment 51714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51714=edit
testcase

[Bug c++/103012] New: ICE with #pragma GCC optimize followed by long line

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103012

Bug ID: 103012
   Summary: ICE with #pragma GCC optimize followed by long line
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

t0.cc:1:26: internal compiler error: in linemap_add, at libcpp/line-map.c:502
1 | #pragma GCC optimize("Og")
  |  ^
0x2094272 linemap_add(line_maps*, lc_reason, unsigned int, char const*,
unsigned int)
/home/apinski/src/upstream-gcc/gcc/libcpp/line-map.c:502
0x2094486 linemap_line_start(line_maps*, unsigned int, unsigned int)
/home/apinski/src/upstream-gcc/gcc/libcpp/line-map.c:827
0x2094798 linemap_position_for_column(line_maps*, unsigned int)
/home/apinski/src/upstream-gcc/gcc/libcpp/line-map.c:898
0x208fd00 _cpp_lex_direct
/home/apinski/src/upstream-gcc/gcc/libcpp/lex.c:2994
0x2091670 _cpp_lex_token
/home/apinski/src/upstream-gcc/gcc/libcpp/lex.c:2810
0x207fddf lex_macro_node
/home/apinski/src/upstream-gcc/gcc/libcpp/directives.c:601
0x20805a2 do_define
/home/apinski/src/upstream-gcc/gcc/libcpp/directives.c:639
0x20836ef run_directive
/home/apinski/src/upstream-gcc/gcc/libcpp/directives.c:589
0x20837a7 cpp_define(cpp_reader*, char const*)
/home/apinski/src/upstream-gcc/gcc/libcpp/directives.c:2511
0x20837fb cpp_define_unused(cpp_reader*, char const*)
/home/apinski/src/upstream-gcc/gcc/libcpp/directives.c:2520
0xc7a234 c_cpp_builtins_optimize_pragma(cpp_reader*, tree_node*, tree_node*)
/home/apinski/src/upstream-gcc/gcc/gcc/c-family/c-cppbuiltin.c:600
0xc9c8e3 handle_pragma_optimize
/home/apinski/src/upstream-gcc/gcc/gcc/c-family/c-pragma.c:997
0xb35c40 cp_parser_pragma
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:47773
0xb6cbfb cp_parser_toplevel_declaration
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:14852
0xb6cbfb cp_parser_toplevel_declaration
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:14843
0xb6cbfb cp_parser_translation_unit
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:4987
0xb6cbfb c_parse_file()
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.c:47832
0xc9a5ed c_common_parse_file()
/home/apinski/src/upstream-gcc/gcc/gcc/c-family/c-opts.c:1237
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/102990] ICE in tsubst_copy_and_build, à cp/pt.c:19856

2021-10-31 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990

--- Comment #1 from Andrew Pinski  ---
Reducing.

[Bug d/102959] gdc.dg/torture/pr96435.d FAILs

2021-10-31 Thread ibuclaw at gdcproject dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102959

--- Comment #1 from Iain Buclaw  ---
(In reply to Rainer Orth from comment #0)
> (gdb) p array
> $2 = {16, 678}
> (gdb) p u
> $3 = {i = 0, b = false}
> (gdb) n
> 9 u.i = 0xDEADBEEF;
> (gdb) n
> 10assert(array[u.b] == 678);
> (gdb) p u
> $4 = {i = -559038737, b = 222}
> (gdb) p/x u.i
> $7 = 0xdeadbeef
OK, so the test didn't account for endianess.  Will adjust the value or add a
version condition for BigEndian to assert the value is the other index.

[Bug libbacktrace/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32

2021-10-31 Thread unlvsur at live dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011

--- Comment #3 from cqwrteur  ---
compilation succeeded when comment out process.h. HAVE_PROCESS_H does not make
sense tbh. Actually #if __has_include() can replace all headers. Are
you trying to support old versions' compilers by not using __has_include guard?

but it is still weird, shouldn't that be pex-win32.h??

[Bug libbacktrace/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32

2021-10-31 Thread unlvsur at live dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011

--- Comment #2 from cqwrteur  ---
Probably because of this that breaks compilation
https://github.com/gcc-mirror/gcc/commit/c3e80a16af287e804b87b8015307085399755cd4#diff-6499efb534d0a9459d3af89fe12f0ee024636b275addb16130c9dbe6c5c3dda9

[Bug libbacktrace/103011] fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32

2021-10-31 Thread unlvsur at live dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011

cqwrteur  changed:

   What|Removed |Added

 CC||unlvsur at live dot com

--- Comment #1 from cqwrteur  ---
Created attachment 51713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51713=edit
config

[Bug libbacktrace/103011] New: fatal error: process.h: No such file or directory when canadian compile x86_64-w64-mingw32

2021-10-31 Thread unlvsur at live dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011

Bug ID: 103011
   Summary: fatal error: process.h: No such file or directory when
canadian compile x86_64-w64-mingw32
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libbacktrace
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
CC: ian at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51712
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51712=edit
error log

make[2]: Entering directory
'/home/cqwrteur/myhome/gcc_build/x86_64-w64-mingw32/x86_64-w64-mingw32/x86_64-w64-mingw32-host/gcc/libbacktrace'
../../../../../../../gcc/libiberty/pex-unix.c:59:10: fatal error: process.h: No
such file or directory
   59 | #include 
  |  ^~~