DeepLearn 2024: early registration June 10

2024-06-02 Thread IRDTA via Gcc-bugs

*To be removed from our mailing list, please respond to this message with 
UNSUBSCRIBE in the subject line*

--

**

11th INTERNATIONAL SCHOOL ON DEEP LEARNING
(and the Future of Artificial Intelligence)

DeepLearn 2024

Porto – Maia, Portugal

July 15-19, 2024

https://deeplearn.irdta.eu/2024/

**

Co-organized by:

University of Maia

Institute for Research Development, Training and Advice – IRDTA
Brussels/London

**

Early registration: June 10, 2024

**

SCOPE:

DeepLearn 2024 will be a research training event with a global scope aiming at 
updating participants on the most recent advances in the critical and fast 
developing area of deep learning. Previous events were held in Bilbao, Genova, 
Warsaw, Las Palmas de Gran Canaria, Guimarães, Las Palmas de Gran Canaria, 
Luleå, Bournemouth, Bari and Las Palmas de Gran Canaria.

Deep learning is a branch of artificial intelligence covering a spectrum of 
current frontier research and industrial innovation that provides more 
efficient algorithms to deal with large-scale data in a huge variety of 
environments: computer vision, neurosciences, speech recognition, language 
processing, human-computer interaction, drug discovery, health informatics, 
medical image analysis, recommender systems, advertising, fraud detection, 
robotics, games, finance, biotechnology, physics experiments, biometrics, 
communications, climate sciences, geographic information systems, signal 
processing, genomics, materials design, video technology, social systems, etc. 
etc.

The field is also raising a number of relevant questions about robustness of 
the algorithms, explainability, transparency, and important ethical concerns at 
the frontier of current knowledge that deserve careful multidisciplinary 
discussion.

Most deep learning subareas will be displayed, and main challenges identified 
through 16 four-hour and a half courses, 2 keynote lectures, 1 round table and 
a few hackathon-type competitions among students, which will tackle the most 
active and promising topics. Renowned academics and industry pioneers will 
lecture and share their views with the audience. The organizers are convinced 
that outstanding speakers will attract the brightest and most motivated 
students. Face to face interaction and networking will be main ingredients of 
the event. It will be also possible to fully participate in vivo remotely.

ADDRESSED TO:

Graduate students, postgraduate students and industry practitioners will be 
typical profiles of participants. However, there are no formal pre-requisites 
for attendance in terms of academic degrees, so people less or more advanced in 
their career will be welcome as well.

Since there will be a variety of levels, specific knowledge background may be 
assumed for some of the courses.

Overall, DeepLearn 2024 is addressed to students, researchers and practitioners 
who want to keep themselves updated about recent developments and future 
trends. All will surely find it fruitful to listen to and discuss with major 
researchers, industry leaders and innovators.

VENUE:

DeepLearn 2024 will take place in Porto, the second largest city in Portugal, 
recognized by UNESCO in 1996 as a World Heritage Site. The venue will be:

University of Maia
Avenida Carlos de Oliveira Campos - Castlo da Maia
4475-690 Maia
Porto, Portugal

https://www.umaia.pt/en

STRUCTURE:

3 courses will run in parallel during the whole event. Participants will be 
able to freely choose the courses they wish to attend as well as to move from 
one to another.

All lectures will be videorecorded. Participants will be able to watch them 
again for 45 days after the event.

An open session will give participants the opportunity to present their own 
work in progress in 5 minutes. Also companies will be able to present their 
technical developments for 10 minutes.

This year’s edition of the school will schedule hands-on activities including 
mini-hackathons, where participants will work in teams to tackle several 
machine learning challenges.

Full live online participation will be possible. The organizers highlight, 
however, the importance of face to face interaction and networking in this kind 
of research training event.

KEYNOTE SPEAKERS:

Jiawei Han (University of Illinois Urbana-Champaign), How Can Large Language 
Models Contribute to Effective Text Mining?

Katia Sycara (Carnegie Mellon University), Effective Multi Agent Teaming

PROFESSORS AND COURSES:

Luca Benini (Swiss Federal Institute of Technology Zurich), 
[intermediate/advanced] Open Hardware Platforms for Edge Machine Learning

Gustau Camps-Valls (University of València), [intermediate] AI for Earth, 
Climate, and Sustainability

Nitesh Chawla (University of Notre Dame), [introductory/intermediate] 
Intr

[Bug c/114930] [14/15 regression] ICE in fld_incomplete_type_of when building libwebp with -std=c23 -flto

2024-06-02 Thread uecker at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114930

uecker at gcc dot gnu.org changed:

   What|Removed |Added

  Component|ipa |c

--- Comment #7 from uecker at gcc dot gnu.org ---


This is a C FE bug because the update logic for c_update_type_canonical uses
check_qualified_type that - for some reason - decides that certain types are
not qualified versions of the original. This seems related to TYPE_DECLS. The
new verification code in the FE also detects these problems in similar
examples.

[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94

2024-06-02 Thread admin--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357

Thorsten Otto  changed:

   What|Removed |Added

 CC||ad...@tho-otto.de

--- Comment #7 from Thorsten Otto  ---
I ran into a similar problem. The symptom was that code in
tree-switch-conversion was miscompiled:

if (k == count)
{
  gcc_checking_assert (count < m_max_case_bit_tests);
  test[k].mask = wi::zero (prec);
  test[k].target_bb = n->m_case_bb;
  test[k].label = n->m_case_label_expr;
  test[k].bits = 0;
  test[k].prob = profile_probability::never ();
  count++;
}

--- good.s  2024-06-02 13:20:13.453987931 +0200
+++ bad.s   2024-06-02 13:50:03.452881214 +0200
@@ -26976,11 +26976,10 @@
move.l %d1,-330(%a0)| prephitmp_336, MEM 
[(struct wide_int_storage *)&test][count_1036].mask.D.16112.len
 | gcc/tree-switch-conversion.cc:1639:  test[k].target_bb =
n->m_case_bb;
move.l 4(%a3),%d1   | MEM  [(void *)n_1051
+ 4B], vect__12.3140
-   lea (-322,%fp),%a4  |,,
-   lea (%a4,%d0.l),%a1 |, vectp.3143
+   lea (%fp,%d0.l),%a1 | tmp12, tmp638, vectp.3143
 | gcc/tree-switch-conversion.cc:1639:  test[k].target_bb =
n->m_case_bb;
move.l 8(%a3),(%a1) | MEM  [(void *)n_1051
+ 8B], MEM  [(void *)vectp.3143_425]
-   move.l %d1,4(%a1)   | vect__12.3140, MEM 
[(void *)vectp.3143_425 + 4B]
+   move.l %d1,-318(%a1)| vect__12.3140, MEM 
[(void *)vectp.3143_425 + 4B]
 | gcc/tree-switch-conversion.cc:1641:  test[k].bits = 0;
clr.l -314(%a0) | test[count_1036].bits
 | gcc/tree-switch-conversion.cc:1642:  test[k].prob =
profile_probability::never ();


Apparently the offset to the local test array was optimized away for the first
store, causing the outer loop to not find the previous m_case_bb pointer, and
then either crash or fail with an assertion because the array overflowed.

Seems like this is not the first regression caused by this "optimization".
Maybe it should be disabled for targets other than riscv, atleast until more
tests have been written.

A crash with such a buggy compiler can be produced with eg.

int date_is_valid(int mon)
{
switch (mon) {
case 1:
case 3:
case 5:
case 7:
case 8:
case 10:
case 12:
break;
default:
return 0x2400;
}

return 0;
}

[Bug d/114434] gdc.test/runnable/test23514.d FAILs

2024-06-02 Thread ibuclaw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114434

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuclaw at gcc dot gnu.org

--- Comment #3 from Iain Buclaw  ---
I see the test is pointer + 64-bit int.  Is this UB on 32bit pointer platforms?

[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h

2024-06-02 Thread mkretz at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803

--- Comment #15 from Matthias Kretz (Vir)  ---
I don't know _GLIBCXX_USE_C99_MATH_TR1. AFAIK the simd headers are relying on
standard C++ . But with  it's easy to make incorrect assumptions.

Other tests have a line:
// { dg-require-cmath "" }

If you add it then the test is skipped? But  is still broken
- just not exposed in a test?

[Bug c/115320] New: wrong code with -O2/O3 when using union with different data type

2024-06-02 Thread tangyixuan at mail dot dlut.edu.cn via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115320

Bug ID: 115320
   Summary: wrong code with -O2/O3 when using union with different
data type
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tangyixuan at mail dot dlut.edu.cn
  Target Milestone: ---

Hi, GCC outputs different results with -O1/O3 during the compilation of the
following test case. Since Union allows different data types to be stored in
the same memory locations, the former variables will be impacted by the
recently assigned variables. However, the point "e" seems to have its own value
whatever the value of point "d" could be with the optimization -O3.

$ gcc -fPIC -mcmodel=large -w -fpermissive -O3 s.c & ./a.out
5
2

$ gcc -fPIC -mcmodel=large -w -fpermissive -O0 s.c & ./a.out
6
6

$ cat s.c

int printf(const char *, ...);
union 
{
  int a;
  short b;
} c;
int *d = &c.a;
short *e = &c.b;
int main()
{
  *d = 0;
  *e=(*e)+1;
  *d = 5;
  *e=(*e)+1; 
  printf("%d\n", *d);
  printf("%d\n", *e);
}

[Bug c++/109958] [11/12/13/14/15 Regression] ICE: in build_ptrmem_type, at cp/decl.cc:11066 taking the address of bound static member function brought into derived class by using-declaration

2024-06-02 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958

--- Comment #6 from GCC Commits  ---
The master branch has been updated by Simon Martin :

https://gcc.gnu.org/g:47827293551a3ec339617678c8e938c8ca3790f1

commit r15-972-g47827293551a3ec339617678c8e938c8ca3790f1
Author: Simon Martin 
Date:   Sun Jun 2 17:45:04 2024 +0200

Fix PR c++/109958: ICE taking the address of bound static member function
brought into derived class by using-declaration

We currently ICE upon the following because we don't properly handle the
overload created for B::f through the using statement.

=== cut here ===
struct B { static int f(); };
struct D : B { using B::f; };
void f(D d) { &d.f; }
=== cut here ===

This patch makes build_class_member_access_expr and cp_build_addr_expr_1
handle
such overloads, and fixes the PR.

Successfully tested on x86_64-pc-linux-gnu.

PR c++/109958

gcc/cp/ChangeLog:

* typeck.cc (build_class_member_access_expr): Handle single
OVERLOADs.
(cp_build_addr_expr_1): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/overload/using6.C: New test.

[Bug c++/109958] [11/12/13/14/15 Regression] ICE: in build_ptrmem_type, at cp/decl.cc:11066 taking the address of bound static member function brought into derived class by using-declaration

2024-06-02 Thread simartin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958

Simon Martin  changed:

   What|Removed |Added

   Target Milestone|11.5|14.2
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Simon Martin  ---
Fixed in master

[Bug rtl-optimization/115320] wrong code with -O2/O3 when using union with different data type

2024-06-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115320

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
No. It is only well defined if used directly via the union variable otherwise
it is just another pointer access.

[Bug tree-optimization/56576] wrong code for aliased union at -O3

2024-06-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56576

Andrew Pinski  changed:

   What|Removed |Added

 CC||tangyixuan at mail dot 
dlut.edu.cn

--- Comment #3 from Andrew Pinski  ---
*** Bug 115320 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/115320] wrong code with -O2/O3 when using union with different data type

2024-06-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115320

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Dup of bug 56576 and others.

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

[Bug tree-optimization/56577] wrong code for aliased union on gcc 4.7 only

2024-06-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56577

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #4 from Andrew Pinski  ---
.

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

[Bug tree-optimization/56576] wrong code for aliased union at -O3

2024-06-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56576

--- Comment #4 from Andrew Pinski  ---
*** Bug 56577 has been marked as a duplicate of this bug. ***

[Bug middle-end/93298] GCC 10.0 non-current union member access

2024-06-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93298

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|INVALID |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup of bug 56576 and others.

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

[Bug tree-optimization/56576] wrong code for aliased union at -O3

2024-06-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56576

Andrew Pinski  changed:

   What|Removed |Added

 CC||msl023508 at gmail dot com

--- Comment #5 from Andrew Pinski  ---
*** Bug 93298 has been marked as a duplicate of this bug. ***

[Bug fortran/83865] ICE in wide_int_to_tree_1, at tree.c:1567

2024-06-02 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83865

--- Comment #5 from anlauf at gcc dot gnu.org ---
The ICE is fixed by:

diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 9b497d6bdc6..605107b5168 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6451,6 +6451,7 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist
*omp_allocate)

   /* Special case when string in expr3 is zero.  */
   if (code->expr3->ts.type == BT_CHARACTER
+ && code->expr3->rank == 0
  && integer_zerop (se.string_length))
{
  gfc_init_se (&se, NULL);

Needs further testing.

[Bug middle-end/110027] [11/12 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return

2024-06-02 Thread gcc at sicherha dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027

Christoph Erhardt  changed:

   What|Removed |Added

  Attachment #56169|0   |1
is obsolete||

--- Comment #26 from Christoph Erhardt  ---
Created attachment 58325
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58325&action=edit
Reproducer program, new version

Unfortunately, the fix appears to be incomplete. On x86_64 Fedora Linux 40 with
the latest GCC 14.1.1, my reproducer program still segfaults with a misaligned
`vmovdqa64`.
I have managed to further strip the program down to a now-manageable size - see
attachment.

$ gcc -Wall -Wextra -g -Og -fsanitize=address -fno-stack-protector -mavx512f
a-repro.i
$ ./a.out
AddressSanitizer:DEADLYSIGNAL
=
==107156==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x00401463
bp 0x7ffd76144620 sp 0x7ffd76144200 T0)
==107156==The signal is caused by a READ memory access.
==107156==Hint: this fault was caused by a dereference of a high value address
(see register values below).  Disassemble the provided pc to learn which
register was used.
#0 0x401463 in blake3_compress_subtree_wide
/home/christoph/Projects/gcc-asan-stack-misalign/repro.c:52
#1 0x40158c in main
/home/christoph/Projects/gcc-asan-stack-misalign/repro.c:57
#2 0x7f60dde3d087 in __libc_start_call_main (/lib64/libc.so.6+0x2a087)
(BuildId: 4a92fcedbba6d6d2629ce066a2970017faa9995e)
#3 0x7f60dde3d14a in __libc_start_main_alias_2 (/lib64/libc.so.6+0x2a14a)
(BuildId: 4a92fcedbba6d6d2629ce066a2970017faa9995e)
#4 0x4010b4 in _start
(/home/christoph/Projects/gcc-asan-stack-misalign/a.out+0x4010b4) (BuildId:
9f1d4d25413300b7347d0776d7087844a8d56649)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
/home/christoph/Projects/gcc-asan-stack-misalign/repro.c:52 in
blake3_compress_subtree_wide
==107156==ABORTING

[Bug target/115321] New: [15 regression] ICE when building grub (extract_insn, at recog.cc:2812)

2024-06-02 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115321

Bug ID: 115321
   Summary: [15 regression] ICE when building grub (extract_insn,
at recog.cc:2812)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58326
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58326&action=edit
pgp_module-pgp.i

```
$ gcc -c ./commands/pgp_module-pgp.i -m32 -march=i386
In file included from
/var/tmp/portage/sys-boot/grub-2.12-r4/work/grub-2.12/grub-core/commands/pgp.c:19:
/var/tmp/portage/sys-boot/grub-2.12-r4/work/grub-2.12/include/grub/types.h: In
function ‘grub_swap_bytes32’:
/var/tmp/portage/sys-boot/grub-2.12-r4/work/grub-2.12/include/grub/types.h:218:1:
error: unrecognizable insn:
  218 | }
  | ^
(insn 5 2 6 2 (set (reg:SI 101)
(ior:SI (and:SI (mem/c:SI (reg/f:SI 92 virtual-incoming-args) [2 x+0 S4
A32])
(const_int -65536 [0x]))
(lshiftrt:SI (bswap:SI (mem/c:SI (reg/f:SI 92
virtual-incoming-args) [2 x+0 S4 A32]))
(const_int 16 [0x10]
"/var/tmp/portage/sys-boot/grub-2.12-r4/work/grub-2.12/include/grub/types.h":217:9
-1
 (nil))
during RTL pass: vregs
/var/tmp/portage/sys-boot/grub-2.12-r4/work/grub-2.12/include/grub/types.h:218:1:
internal compiler error: in extract_insn, at recog.cc:2812
0x565212e8b58d _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/rtl-error.cc:108
0x565212e8ca9a _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/rtl-error.cc:116
0x5652124c38e5 extract_insn(rtx_insn*)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/recog.cc:2812
0x565213bbfa20 instantiate_virtual_regs_in_insn
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/function.cc:1612
0x565213bbfa20 instantiate_virtual_regs
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/function.cc:1995
0x565213bbf715 execute
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/function.cc:2042
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened
15.0. p, commit 9a866462097fe24696c924a3874fd307c775e860'
--with-gcc-major-version-only --enable-libstdcxx-time --enable-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --disable-cet
--disable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --with-isl --disable-isl-version-check
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-O3
bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20240601 (experimental)
85f15ea65a97686ad39af0c14b7dd9a9372e3a19 (Gentoo Hardened 15.0. p, commit
9a866462097fe24696c924a3874fd307c775e860)
```

[Bug target/115321] [15 regression] ICE when building grub (extract_insn, at recog.cc:2812) since r15-930

2024-06-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115321

Andrew Pinski  changed:

   What|Removed |Added

Summary|[15 regression] ICE when|[15 regression] ICE when
   |building grub   |building grub
   |(extract_insn, at   |(extract_insn, at
   |recog.cc:2812)  |recog.cc:2812) since
   ||r15-930
Version|unknown |15.0
   Target Milestone|--- |15.0

--- Comment #1 from Andrew Pinski  ---
I am 99.99% sure this was introduced by r15-930-ge715204f203d31 .

[Bug target/115321] [15 regression] ICE when building grub (extract_insn, at recog.cc:2812) since r15-930

2024-06-02 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115321

Sam James  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #2 from Sam James  ---
```
void grub_cmd_distrust() { unsigned x = __builtin_bswap32(x); }
```

[Bug target/115321] [15 regression] ICE when building grub (extract_insn, at recog.cc:2812) since r15-930

2024-06-02 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115321

--- Comment #3 from Sam James  ---
uh, void grub_cmd_distrust(unsigned x) { x = __builtin_bswap32(x); }, obviously
;)

[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral

2024-06-02 Thread peter0x44 at disroot dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438

Peter Damianov  changed:

   What|Removed |Added

 CC||peter0x44 at disroot dot org

--- Comment #13 from Peter Damianov  ---
This still applies to GCC 14.1.

[Bug target/113609] EQ/NE comparison between avx512 kmask and -1 can be optimized with kxortest with checking CF.

2024-06-02 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113609

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Hu :

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

commit r15-974-gbf7745f887c765e06f2e75508f263debb60aeb2e
Author: Hu, Lin1 
Date:   Thu May 9 09:29:07 2024 +0800

i386: Optimize EQ/NE comparison between avx512 kmask and -1.

Acheive EQ/NE comparison between avx512 kmask and -1 by using kxortest
with checking CF.

gcc/ChangeLog:

PR target/113609
* config/i386/sse.md
(*kortest_cmp_setcc): New define_insn_and_split.
(*kortest_cmp_jcc): Ditto.

gcc/testsuite/ChangeLog:

PR target/113609
* gcc.target/i386/pr113609-1.c: New test.
* gcc.target/i386/pr113609-2.c: Ditto.

[Bug c/115322] New: SPEC2006 403.gcc internal error

2024-06-02 Thread sundongya at nucleisys dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115322

Bug ID: 115322
   Summary: SPEC2006 403.gcc internal error
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sundongya at nucleisys dot com
  Target Milestone: ---

Hi,

GCC version: 
gcc version 14.1.1 20240507 (g7e8fae89f)  

Build SPEC2006 cfg1: 

# Compiler selection

CC  = riscv64-unknown-linux-gnu-gcc 
-march=rv64imafdcv_zba_zbb_zbc_zbs_zvl128b -mabi=lp64d  -static
-mrvv-vector-bits=zvl -mrvv-max-lmul=m1 
CXX = riscv64-unknown-linux-gnu-g++ 
-march=rv64imafdcv_zba_zbb_zbc_zbs_zvl128b -mabi=lp64d  -static
-mrvv-vector-bits=zvl -mrvv-max-lmul=m1 
FC  = riscv64-unknown-linux-gnu-gfortran
-march=rv64imafdcv_zba_zbb_zbc_zbs_zvl128b -mabi=lp64d  -static
-mrvv-vector-bits=zvl -mrvv-max-lmul=m1   

# Optimization

default=base=default=default:
COPTIMIZE  = -Ofast -flto 
CXXOPTIMIZE= -Ofast -flto
FOPTIMIZE  = -Ofast -flto 

# 32/64 bit Portability Flags - all  
default=base=default=default:
PORTABILITY= -Wno-error=implicit-int
-Wno-error=implicit-function-declaration
-Wno-error=declaration-missing-parameter-type -Wno-error=return-mismatch
-Wno-error=int-conversion -Wno-error=incompatible-pointer-types -DSPEC_CPU_LP64 

Build SPEC2006 cfg2: 

# Compiler selection

CC  = riscv64-unknown-linux-gnu-gcc 
-march=rv64imafdcv_zba_zbb_zbc_zbs_zvl128b -mabi=lp64d  -static
-mrvv-vector-bits=zvl -mrvv-max-lmul=m4 
CXX = riscv64-unknown-linux-gnu-g++ 
-march=rv64imafdcv_zba_zbb_zbc_zbs_zvl128b -mabi=lp64d  -static
-mrvv-vector-bits=zvl -mrvv-max-lmul=m4
FC  = riscv64-unknown-linux-gnu-gfortran
-march=rv64imafdcv_zba_zbb_zbc_zbs_zvl128b -mabi=lp64d  -static
-mrvv-vector-bits=zvl -mrvv-max-lmul=m4   

# Optimization

default=base=default=default:
COPTIMIZE  = -Ofast -flto 
CXXOPTIMIZE= -Ofast -flto
FOPTIMIZE  = -Ofast -flto 

# 32/64 bit Portability Flags - all  
default=base=default=default:
PORTABILITY= -Wno-error=implicit-int
-Wno-error=implicit-function-declaration
-Wno-error=declaration-missing-parameter-type -Wno-error=return-mismatch
-Wno-error=int-conversion -Wno-error=incompatible-pointer-types -DSPEC_CPU_LP64 



After successfully compiling SPEC2006 using the above configuration, the
following problem will occur in 403.gcc when running the intspeed/test data
set.

gcc_base.riscv: internal error: 4
It is possible that you may be trying to use SPEC's version of gcc
without first defining the appropriate flags.  Please check the flags
that are in the config files from recently-published results on your
platform, and check that you are using an up-to-date compiler.  If
you still need help, please contact SPEC, reporting your hw/os
platform, your compiler version, and your compilation flags.
Contact SPEC at http://www.spec.org/>

Similar error will occur when running the simulation in user mode in qemu. The
running command is as follows:  

# qemu version  
qemu-riscv64 version 8.2.93 (v9.0.0-rc3-5-g824ebb92c3)  

#running command
qemu-riscv64 -cpu rv64,v=true,vext_spec=v1.0,zicond=true ./gcc_base.riscv
cccp.in -o cccp.s  

cccp.in:1679: internal error: 11
It is possible that you may be trying to use SPEC's version of gcc
without first defining the appropriate flags.  Please check the flags
that are in the config files from recently-published results on your
platform, and check that you are using an up-to-date compiler.  If
you still need help, please contact SPEC, reporting your hw/os
platform, your compiler version, and your compilation flags.
Contact SPEC at http://www.spec.org/>

[Bug target/115322] SPEC2006 403.gcc internal error

2024-06-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115322

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Component|c   |target
   Last reconfirmed||2024-06-03
 Target||riscv
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
Does adding -fno-strict-aliasing help?

[Bug target/115255] sibcall at -O0 causes ICE in df_refs_verify on arm

2024-06-02 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115255

Richard Biener  changed:

   What|Removed |Added

 CC|richard.guenther at gmail dot com  |rguenth at gcc dot 
gnu.org

--- Comment #8 from Richard Biener  ---
(In reply to Andrew Pinski from comment #5)
> The question comes is musttail going to always work at -O0 or should it just
> fail at -O0 with an error message. Or rather is musttail is just a hack in
> itself and should never be implemented.

I think it's going to be quite useless if it doesn't work at -O0.  I suppose
even demoting the error to must-tail to a warning when not optimizing
will be an improvement.  OTOH doing that generally (a warning, not error)
might be a possibility as well.  This isn't going to be a very portable
feature since the ability to tail-call depends on the ABI.

[Bug target/115321] [15 regression] ICE when building grub (extract_insn, at recog.cc:2812) since r15-930

2024-06-02 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115321

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-06-03
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #4 from Uroš Bizjak  ---
Created attachment 58327
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58327&action=edit
Patch

[Bug target/113609] EQ/NE comparison between avx512 kmask and -1 can be optimized with kxortest with checking CF.

2024-06-02 Thread liuhongt at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113609

Hongtao Liu  changed:

   What|Removed |Added

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

--- Comment #4 from Hongtao Liu  ---
Fixed in GCC15

[Bug c/115311] -fno-builtin-xxx allowing anything for xxx

2024-06-02 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115311

--- Comment #3 from Richard Biener  ---
Note we handle -Wno-xyz similarly, but of course a typo like -fno-builtin-sun
(s/sun/sin) isn't noticed this way which is the drawback.