[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa since r14-6822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113373 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Richard Biener --- Fixed.
[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa since r14-6822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113373 --- Comment #8 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:86f3cbdaa6f60eaff1cdb4ab2f1a9bc796b67207 commit r14-8330-g86f3cbdaa6f60eaff1cdb4ab2f1a9bc796b67207 Author: Richard Biener Date: Fri Jan 19 13:55:09 2024 +0100 tree-optimization/113373 - add missing LC PHIs for live operations The following makes reduction epilogue code generation happy by properly adding LC PHIs to the exit blocks for multiple exit vectorized loops. Some refactoring might make the flow easier to follow but I've refrained from doing that with this patch. I've kept some fixes in reduction epilogue generation from the earlier attempt fixing this PR. PR tree-optimization/113373 * tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg): Create LC PHIs in the exit blocks where necessary. * tree-vect-loop.cc (vectorizable_live_operation): Do not try to handle missing LC PHIs. (find_connected_edge): Remove. (vect_create_epilog_for_reduction): Cleanup use of auto_vec. * gcc.dg/vect/vect-early-break_104-pr113373.c: New testcase.
[Bug target/113420] risc-v vector: ICE when using C compiler compile C++ RVV intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113420 JuzheZhong changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from JuzheZhong --- Fixed.
[Bug go/113530] libgo ftbfs on arc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113530 --- Comment #6 from Matthias Klose --- > Does the GCC 13 branch actually try to build libgo for arc-linux-gnu? I don't know. I usually configure with --enable-languages=go, which I didn't with 13, but by a mistake did with 14. So maybe just let's close this, the libgo/configure also doesn't have a GOARCH set for these two architectures.
[Bug target/113537] ext should be used more for __builtin_shufflevector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113537 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-01-22 --- Comment #3 from Andrew Pinski --- I am going to implement at least the aarch64_vectorize_vec_perm_const part. I will check the other side later on. Note this will be part of the patch set am doing for PR 113458 .
[Bug target/113420] risc-v vector: ICE when using C compiler compile C++ RVV intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113420
--- Comment #1 from GCC Commits ---
The master branch has been updated by Li Xu :
https://gcc.gnu.org/g:46a664dd59ec6c1121914d6857d6edb94501c517
commit r14-8328-g46a664dd59ec6c1121914d6857d6edb94501c517
Author: xuli
Date: Mon Jan 22 06:41:49 2024 +
RISC-V: Bugfix for resolve_overloaded_builtin[PR113420]
v2:
Avoid internal ICE for the case below.
vint8mf8_t test_vle8_v_i8mf8_m(vbool64_t vm, const int32_t *rs1, size_t vl)
{
return __riscv_vle8(vm, rs1, vl);
}
v1:
Change the hash value of overloaded intrinsic from considering
all parameter types to:
1. Encoding vector data type
2. In order to distinguish vle8_v_i8mf8_m(vbool64_t vm, const int8_t *rs1,
size_t vl)
and vle8_v_u8mf8_m(vbool64_t vm, const uint8_t *rs1, size_t vl), encode
the pointer type
3. In order to distinguish vfadd_vv_f32mf2_rm(vfloat32mf2_t vs2,
vfloat32mf2_t vs1, size_t vl)
and vfadd_vv_f32mf2(vfloat32mf2_t vs2, vfloat32mf2_t vs1, size_t vl),
encode the number of
parameters. The same goes for the vxrm intrinsics.
PR target/113420
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc (has_vxrm_or_frm_p):remove.
(registered_function::overloaded_hash):refactor.
(resolve_overloaded_builtin):avoid internal ICE.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr113420-1.c: New test.
* gcc.target/riscv/rvv/base/pr113420-2.c: New test.
[Bug target/113537] ext should be used more for __builtin_shufflevector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113537 --- Comment #2 from Andrew Pinski --- aarch64_vectorize_vec_perm_const does not handle at all the case where the 2 modes are different.
[Bug target/113537] ext should be used more for __builtin_shufflevector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113537 --- Comment #1 from Andrew Pinski --- One gimple level thing I noticed is we produce: ``` _1 = VEC_PERM_EXPR ; _3 = BIT_FIELD_REF <_1, 64, 0>; ``` But Maybe that should just be: ``` _3 = VEC_PERM_EXPR ; ``` Which is what the vector might produce but maybe it is because aarch64_vectorize_vec_perm_const does not know how to handle that ...
[Bug target/113537] New: ext should be used more for __builtin_shufflevector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113537
Bug ID: 113537
Summary: ext should be used more for __builtin_shufflevector
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Take:
```
#define vector4 __attribute__((vector_size(4)))
#define vector8 __attribute__((vector_size(8)))
#define vector16 __attribute__((vector_size(16)))
vector8 char f3(vector16 char a)
{
return __builtin_shufflevector (a, a, 1, 2, 3, 4, 5, 6, 7, 8);
}
vector8 char f2(vector16 char a)
{
return __builtin_shufflevector (a, a, 1, 2, 3, 4, 5, 6, 7, 0);
}
```
Currently GCC produces:
```
f3:
adrpx0, .LC0
ldr q31, [x0, #:lo12:.LC0]
tbl v0.16b, {v0.16b}, v31.16b
ret
f2:
adrpx0, .LC1
ldr q31, [x0, #:lo12:.LC1]
tbl v0.16b, {v0.16b}, v31.16b
ret
```
But these should be optimized to just:
```
f3:
ext v0.16b, v0.16b, v0.16b, #1
ret
f2:
ext v0.8b, v0.8b, v0.8b, #1
ret
```
[Bug ada/113536] New: valid reduction expression rejected by -gnatVo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113536
Bug ID: 113536
Summary: valid reduction expression rejected by -gnatVo
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: devotus at yahoo dot com
CC: dkm at gcc dot gnu.org
Target Milestone: ---
The legal program below fails to compile when `-gnatVo` is active. The error
message is
test_reduction.adb:13:15: error: missing argument for parameter
"Accumulator" in call to "Do_Something" declared at line 9
The error seems to date back at least to gnat 10.2.
pragma Ada_2022;
with Ada.Text_IO;
procedure Test_Reduction is
subtype Value is Natural range 0 .. 255;
function Do_Something (Accumulator : Value; Symbol : Character) return Value
is (((Accumulator + Character'Pos (Symbol)) * 17) mod 256);
function Do_It_By_Reduction (S : String) return Value is
(S'Reduce (Do_Something, 0));
Test_It : constant Value := Do_It_By_Reduction ("Hello, world!");
begin
Ada.Text_IO.Put_Line (Test_It'Image);
end Test_Reduction;
[Bug c++/90463] Documentation: -Wunused not listed among the options enabled by -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90463 --- Comment #2 from sandra at gcc dot gnu.org --- A quick look through the lists of -Wall and -Wextra options turned up some others that are missing, too. I'm trying to do a more thorough patch.
[Bug go/113530] libgo ftbfs on arc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113530 --- Comment #5 from Ian Lance Taylor --- Does the GCC 13 branch actually try to build libgo for arc-linux-gnu?
[Bug target/113507] can't build a cross compiler to rs6000-ibm-aix7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113507 Kewen Lin changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||dje at gcc dot gnu.org, ||linkw at gcc dot gnu.org --- Comment #2 from Kewen Lin --- Guessing /usr/local/bin/ld is a gnu ld? Based on what I heard before, gnu ld has some problems on aix, people pass object files to aix system and use aix ld there. Not sure if the understanding still holds.
[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705 Kewen Lin changed: What|Removed |Added CC||linkw at gcc dot gnu.org --- Comment #7 from Kewen Lin --- (In reply to Peter Bergner from comment #6) > (In reply to GCC Commits from comment #5) > > commit r14-7270-g39fa71a0882928a25bd170580e3e9e89a69dce36 > > Author: Kewen Lin > > Date: Mon Jan 15 20:55:40 2024 -0600 > > > > testsuite: Fix vect_long_mult on Power [PR109705] > > > > As pointed out by the discussion in PR109705, the current > > vect_long_mult effective target check on Power is broken. > > This patch is to fix it accordingly. > > Does this need backporting? I guess no, the only use of vect_long_mult in release branches is gcc/testsuite/gcc.dg/vect/pr60656.c which has another check vect_widen_mult_si_to_di_pattern unsupported on Power.
[Bug testsuite/113535] rs6000, testsuite: Re-visit the current vect_* for Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113535 Kewen Lin changed: What|Removed |Added Last reconfirmed||2024-01-22 Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org CC||bergner at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug testsuite/113535] New: rs6000, testsuite: Re-visit the current vect_* for Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113535 Bug ID: 113535 Summary: rs6000, testsuite: Re-visit the current vect_* for Power Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: linkw at gcc dot gnu.org Target Milestone: --- Inspired by PR109705, open this for tracking the revisit of vect_* checking for Power and fix some if needed.
[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533 --- Comment #5 from Oleg Endo --- (In reply to Andrew Pinski from comment #3) > That seems to make the cost of a load/store if just an index, the same as the > cost > as the index. Which definitely seems wrong. It should be the cost of the > load/store > and the cost of the address formation. Yep, that doesn't seem to be accurate. > The way aarch64 implements its _rtx_costs is that it cases SET and if the LHS > is a > mem, then it is the cost of the store there and returns true (though you > might need > to take into RHS if it can be more than just a register like). And then MEM > includes the cost of the load. That's what I'd also do intuitively. > i386 does something similar too. If every backend does that same thing, isn't it better to do it as a default for everybody? I can imagine the minimalist backends (like RX) will regress on this case as well. (Haven't checked it though)
[Bug target/113534] printf might report segmentation fault under -mabi=ms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113534 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- This is NOT a bug as -mabi=ms changes the ABI of all of the function calls including extern ones. Basically if you mark printf as having the GNU ABI, then it would work.
[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > The way aarch64 implements its _rtx_costs is that it cases SET and if the > LHS is a mem, then it is the cost of the store there and returns true > (though you might need to take into RHS if it can be more than just a > register like). And then MEM includes the cost of the load. i386 does something similar too.
[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533 --- Comment #3 from Andrew Pinski --- (In reply to Oleg Endo from comment #2) > (In reply to Andrew Pinski from comment #1) > > This is most likely a cost model issue on sh3. > > You mean this one (sh.cc, sh_rtx_costs)? > > /* The cost of a mem access is mainly the cost of the address mode. */ > case MEM: > *total = sh_address_cost (XEXP (x, 0), GET_MODE (x), MEM_ADDR_SPACE > (x), > true); > return true; That seems to make the cost of a load/store if just an index, the same as the cost as the index. Which definitely seems wrong. It should be the cost of the load/store and the cost of the address formation. The way aarch64 implements its _rtx_costs is that it cases SET and if the LHS is a mem, then it is the cost of the store there and returns true (though you might need to take into RHS if it can be more than just a register like). And then MEM includes the cost of the load.
[Bug target/113534] New: printf might report segmentation fault under -mabi=ms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113534
Bug ID: 113534
Summary: printf might report segmentation fault under -mabi=ms
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: haochen.jiang at intel dot com
Target Milestone: ---
A reproducer:
$ /export/users/haochenj/env/build_no_bootstrap_master/gcc/xgcc
-B/export/users/haochenj/env/build_no_bootstrap_master/gcc/
/export/users/haochenj/src/gcc/master/gcc/testsuite/gcc.target/i386/pr80969-4a.c
-m64 -DDEBUG -fdiagnostics-plain-output -Ofast -mabi=ms -mavx512f -lm -o
./pr80969-4a.exe
$ ./pr80969-4a.exe
Segmentation fault (core dumped)
After I debug into that, where it core dumped is the "printf ("PASSED\n");" in
avx-check.h.
We got:
Program received signal SIGSEGV, Segmentation fault.
0x77db887c in __strlen_evex () from /lib64/libc.so.6
It seems that the seg fault will only happen under -mabi=ms. If we eliminate
-mabi=ms, no segmentation fault is detected.
[Bug debug/113382] FAIL: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t ]0x6000004[\t ]+[^\n]*btt_info 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113382
--- Comment #3 from John David Anglin ---
btf_kflag is set here:
else if (btf_kind == BTF_KIND_ENUM)
{
btf_kflag = dtd->dtd_enum_unsigned
? BTF_KF_ENUM_UNSIGNED
: BTF_KF_ENUM_SIGNED;
(gdb) p dtd->dtd_enum_unsigned
$10 = false
/* BTF_KF_ENUM_ holds the flags for kflags in BTF_KIND_ENUM{,64}. */
#define BTF_KF_ENUM_UNSIGNED(0)
#define BTF_KF_ENUM_SIGNED (1 << 0)
Test has:
enum foo
{
BAR = 0,
BAZ = 1,
QUZ = 2,
QUX = 3
};
I think the choice of signed int is correct:
https://en.cppreference.com/w/c/language/enum
But then there are articles indicating that the type is implementation
dependent:
https://stackoverflow.com/questions/159034/are-c-enums-signed-or-unsigned
Maybe test needs to handle either case.
[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533 --- Comment #2 from Oleg Endo --- (In reply to Andrew Pinski from comment #1) > This is most likely a cost model issue on sh3. You mean this one (sh.cc, sh_rtx_costs)? /* The cost of a mem access is mainly the cost of the address mode. */ case MEM: *total = sh_address_cost (XEXP (x, 0), GET_MODE (x), MEM_ADDR_SPACE (x), true); return true;
[Bug rtl-optimization/113533] [14 Regression] Code generation regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533 Andrew Pinski changed: What|Removed |Added Target||sh3-linux-gnu Target Milestone|--- |14.0 --- Comment #1 from Andrew Pinski --- This is most likely a cost model issue on sh3.
[Bug rtl-optimization/113533] New: [14 Regression] Code generation regression after change for pr111267
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
Bug ID: 113533
Summary: [14 Regression] Code generation regression after
change for pr111267
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
sh3-linux-gnu or sh3eb-linux-gnu is showing a code generation regression after
the changes for pr111267.
test_01 with -O1 shows the problem nicely:
int
test_01 (unsigned char* a)
{
/* 1x cmp/pz, 1x addc */
return a[0] + (a[0] < 128);
}
Before:
test_01:
mov.b @r4,r1
extu.b r1,r0
cmp/pz r1
mov #0,r1
rts
addcr1,r0
After:
test_01:
mov.b @r4,r0
extu.b r0,r0
mov.b @r4,r1
cmp/pz r1
mov #0,r1
rts
addcr1,r0
Note the extra memory load.
I'm not actively working on this.
[Bug testsuite/113005] 'libgomp.fortran/rwlock_1.f90', 'libgomp.fortran/rwlock_3.f90' execution test timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113005 --- Comment #14 from Lipeng Zhu --- (In reply to Lipeng Zhu from comment #13) > OK, I think I find the root cause of this error, when thread number greater > than 1000, the file_name = 1000_tst.dat, character(11) will overflow. This > will generate the same file_name like ***_tst.dat. > > diff --git a/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 > b/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 > index f90ecbeb00f..1c271ae031d 100644 > --- a/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 > +++ b/libgomp/testsuite/libgomp.fortran/rwlock_1.f90 > @@ -7,13 +7,12 @@ program main >use omp_lib >implicit none >integer:: unit_number, v1, v2, i > - character(11) :: file_name > + character(16) :: file_name >character(3) :: async = "no" >!$omp parallel private (unit_number, v1, v2, file_name, async, i) > do i = 0, 100 >unit_number = 10 + omp_get_thread_num () > - write (file_name, "(I3, A)") unit_number, "_tst.dat" > - file_name = adjustl(file_name) > + write (file_name, "(I5.5, A)") unit_number, "_tst.dat" >open (unit_number, file=file_name, asynchronous="yes") >! call inquire with file parameter to test find_file in unix.c >inquire (file=file_name, asynchronous=async) Hi Thomas, Can you help to verify if this draft patch will fix the error on your side?
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #15 from kargl at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #14)
> On Sun, Jan 21, 2024 at 09:52:39PM +, anlauf at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
> >
> > I think that you cannot do
> >
> > + if (MPFR_HALF_CYCLE)
> >
> > you really must use
> >
> > #if MPFR_HALF_CYCLE
> >
>
...
> Breakpoint 1, gfc_simplify_cospi (x=0x803e24b60)
> at ../../gcc/gcc/fortran/simplify.cc:2085
> 2085 result = gfc_get_constant_expr (x->ts.type, x->ts.kind, >where);
> (gdb) n
> 2101 mpfr_inits2 (2 * mpfr_get_prec (x->value.real), cs, n, r,
> NULL);
Good news is that your testing forced me to look at the
else-{} branch again, and it exposed a shortcoming. I'm
looking at a fix. So an updated patch will be necessary.
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #14 from Steve Kargl ---
On Sun, Jan 21, 2024 at 09:52:39PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
>
> I think that you cannot do
>
> + if (MPFR_HALF_CYCLE)
>
> you really must use
>
> #if MPFR_HALF_CYCLE
>
#include
#include "mpfr.h"
#define MPFR_HALF_CYCLE (MPFR_VERSION_MAJOR * 100 + MPFR_VERSION_MINOR >= 402)
int
main(void)
{
if (MPFR_HALF_CYCLE)
printf("here\n");
else
printf("there\n");
return (0);
}
% cc -o z -I/usr/local/include a.c && ./z
here
% cc -E -I/usr/local/include a.c | grep -v mpfr_ | grep -v gmp | cat -s
...
int
main(void)
{
if ((4 * 100 + 2 >= 402))
printf("here\n");
else
printf("here\n");
return (0);
}
Are you sure that your testing is finding the right mpfr.h?
If I add
#ifdef MPFR_VERSION_MAJOR
#undef MPFR_VERSION_MAJOR
#endif
#define MPFR_VERSION_MAJOR 3
above the define for MPFR_HALF_CYCLE in simplify.cc, it compiles
for me. With this simple program
real, parameter :: x = cospi(1.)
print *,x
end
gdb ends up in the else { } branch.
Breakpoint 1, gfc_simplify_cospi (x=0x803e24b60)
at ../../gcc/gcc/fortran/simplify.cc:2085
2085 result = gfc_get_constant_expr (x->ts.type, x->ts.kind, >where);
(gdb) n
2101 mpfr_inits2 (2 * mpfr_get_prec (x->value.real), cs, n, r, NULL);
[Bug libgcc/113401] Memory (resource) leak in -ftrampoline-impl=heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113401 --- Comment #3 from Iain Sandoe --- for platforms using pthreads as the underlying resource, then perhaps we can do this without thread_atexit (which I do not see in many places) by using pthread_cleanup_push () not sure if gthr.h abstracts that in any way (I do not have a patch at the moment).
[Bug libgcc/113403] [14 Regression] __builtin_nested_func_ptr_created, __builtin_nested_func_ptr should be dynamically linked by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113403 --- Comment #14 from Iain Sandoe --- Created attachment 57182 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57182=edit patch under test this is what I'm testing - these functions are removed from libgcc.a and added to libgcc_eh.a - since most versions of Darwin cannot use libgcc_eh, it arranges to make a CRT containing them that can be linked in cases that require it. - for Darwin, we also make the definitions weak and exported where used in DSOs, this means that a dynamically linked program should only end up with one copy of the cache even if the shared libgcc is not in use.
[Bug target/91681] Missed optimization for 128 bit arithmetic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91681 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 --- Comment #7 from Roger Sayle --- This is now fixed on mainline. GCC is now optimal, and generates one less instruction than clang.
[Bug target/82420] ICE with -malign-int and -m68000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 CC||law at gcc dot gnu.org --- Comment #8 from Jeffrey A. Law --- Fixed on the trunk. No plans to backport.
[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #7 from Jeffrey A. Law --- Should be fixed on the trunk. No plans to backport.
[Bug target/82420] ICE with -malign-int and -m68000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:bdcf7226c9fe87352466eb9a6bfc58fa24b3e5e1
commit r14-8324-gbdcf7226c9fe87352466eb9a6bfc58fa24b3e5e1
Author: Mikael Pettersson
Date: Sun Jan 21 15:55:49 2024 -0700
Re: [PATCH] Avoid ICE with m68k-elf -malign-int and libcalls
>> emit_library_call_value_1 calls emit_push_insn with NULL_TREE
>> for TYPE. Sometimes emit_push_insn needs to assign a temp with
>> that TYPE, which causes a segfault.
>>
>> Fixed by computing the TYPE from MODE when needed.
>>
>> Original patch by Thorsten Otto.
>>
[ ... ]
> This really needs to happen in the two call paths which pass in
> NULL_TREE for the type. Note how the type is used to determine padding
> earlier in emit_push_insn. That would also make the code more
> consistent with the comment before emit_push_insn which implies that
> both MODE and TYPE are valid.
>
>
> Additionally you should bootstrap and regression test this patch on at
> least one target.
Updated as requested, and bootstrapped and tested on
{x86_64,aarch64,m68k}-linux-gnu without regressions.
gcc/
PR target/82420
PR target/111279
* calls.cc (emit_library_call_value_1): Pass valid TYPE
to emit_push_insn.
* expr.cc (emit_push_insn): Likewise.
gcc/testsuite/
PR target/82420
* gcc.target/m68k/pr82420.c: New test.
Co-authored-by: Thorsten Otto
[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:bdcf7226c9fe87352466eb9a6bfc58fa24b3e5e1
commit r14-8324-gbdcf7226c9fe87352466eb9a6bfc58fa24b3e5e1
Author: Mikael Pettersson
Date: Sun Jan 21 15:55:49 2024 -0700
Re: [PATCH] Avoid ICE with m68k-elf -malign-int and libcalls
>> emit_library_call_value_1 calls emit_push_insn with NULL_TREE
>> for TYPE. Sometimes emit_push_insn needs to assign a temp with
>> that TYPE, which causes a segfault.
>>
>> Fixed by computing the TYPE from MODE when needed.
>>
>> Original patch by Thorsten Otto.
>>
[ ... ]
> This really needs to happen in the two call paths which pass in
> NULL_TREE for the type. Note how the type is used to determine padding
> earlier in emit_push_insn. That would also make the code more
> consistent with the comment before emit_push_insn which implies that
> both MODE and TYPE are valid.
>
>
> Additionally you should bootstrap and regression test this patch on at
> least one target.
Updated as requested, and bootstrapped and tested on
{x86_64,aarch64,m68k}-linux-gnu without regressions.
gcc/
PR target/82420
PR target/111279
* calls.cc (emit_library_call_value_1): Pass valid TYPE
to emit_push_insn.
* expr.cc (emit_push_insn): Likewise.
gcc/testsuite/
PR target/82420
* gcc.target/m68k/pr82420.c: New test.
Co-authored-by: Thorsten Otto
[Bug debug/113382] FAIL: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t ]0x6000004[\t ]+[^\n]*btt_info 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113382 --- Comment #2 from John David Anglin --- We have: .word 0x8604 ; btt_info: kind=6, kflag=1, vlen=4 This seems correct encoding: /* Encoding for struct btf_type.info. */ #define BTF_TYPE_INFO(kind, kflag, vlen) \ kflag) ? 1 : 0 ) << 31) | ((kind) << 24) | ((vlen) & 0x)) Problem seems kflag.
[Bug libstdc++/113500] Using std::format with float or double based std::chrono::time_point causes error: no match for 'operator<<'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113500 --- Comment #10 from Jonathan Wakely --- Fixed on trunk so far.
[Bug libstdc++/113500] Using std::format with float or double based std::chrono::time_point causes error: no match for 'operator<<'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113500
--- Comment #9 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:7431fcea6b72beb54abb1932c254ac0e76bd0bde
commit r14-8321-g7431fcea6b72beb54abb1932c254ac0e76bd0bde
Author: Jonathan Wakely
Date: Sun Jan 21 18:16:14 2024 +
libstdc++: Fix std::format for floating-point chrono::time_point [PR113500]
Currently trying to use std::format with certain specializations of
std::chrono::time_point is ill-formed, due to one member function of the
__formatter_chrono type which tries to write a time_point to an ostream.
For sys_time or sys_time with a period greater than days
there is no operator<< that can be used.
That operator<< is only needed when using an empty chrono-specs in the
format string, like "{}", but the ill-formed expression gives an error
even if not actually used. This means it's not possible to format some
other specializations of chrono::time_point, even when using a non-empty
chrono-specs.
This fixes it by avoiding using 'os << t' for all chrono::time_point
specializations, and instead using std::format("{:L%F %T}", t). So that
we continue to reject std::format("{}", sys_time{1.0s}) a check for
empty chrono-specs is added to the formatter, C>
specialization.
While testing this I noticed that the output for %S with a
floating-point duration was incorrect, as the subseconds part was being
appended to the seconds without a decimal point, and without the correct
number of leading zeros.
libstdc++-v3/ChangeLog:
PR libstdc++/113500
* include/bits/chrono_io.h (__formatter_chrono::_M_S): Fix
printing of subseconds with floating-point rep.
(__formatter_chrono::_M_format_to_ostream): Do not write
time_point specializations directly to the ostream.
(formatter, C>::parse): Do not allow an
empty chrono-spec if the type fails to meet the constraints for
writing to an ostream with operator<<.
* testsuite/std/time/clock/file/io.cc: Check formatting
non-integral times with empty chrono-specs.
* testsuite/std/time/clock/gps/io.cc: Likewise.
* testsuite/std/time/clock/utc/io.cc: Likewise.
* testsuite/std/time/hh_mm_ss/io.cc: Likewise.
[Bug middle-end/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 113532, which changed state. Bug 113532 Summary: Warn about definition of macros that shadow keywords https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113532 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/113532] Warn about definition of macros that shadow keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113532 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Oh this is a dup of my own PR. *** This bug has been marked as a duplicate of bug 109994 ***
[Bug preprocessor/109994] Issue a diagnostic when a C++ file defines a macro that hides a keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994 --- Comment #4 from Jonathan Wakely --- *** Bug 113532 has been marked as a duplicate of this bug. ***
[Bug c++/113532] New: Warn about definition of macros that shadow keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113532 Bug ID: 113532 Summary: Warn about definition of macros that shadow keywords Product: gcc Version: 13.2.1 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Blocks: 87403 Target Milestone: --- [macro.names] says: A translation unit shall not #define or #undef names lexically identical to keywords, to the identifiers listed in Table 4, or to the attribute-tokens described in 9.12, except that the names likely and unlikely may be defined as function-like macros (15.6). (Where Table 4 contains "final", "import", "module", and "override".) We should warn when code does something silly like: #define namespace _namespace Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug target/113458] Missed SLP for reduction of multiplication/addition with promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113458 --- Comment #11 from Andrew Pinski --- (In reply to Andrew Pinski from comment #9) > (In reply to Andrew Pinski from comment #8) > > (In reply to Andrew Pinski from comment #7) > > > But the load is still using inserts and tbl. I have not figured out why > > > though. > > > > Looks like I have to support const PERMs. > > Which I have enough supported. Now on to the cost model. > I do get some testsuite failures which means I need to add more support > instruction for the V4QI mode but it is a good start too. Actually it was not the cost model that was the issue. It was just implementing movmisalign for the mode and also not having the PERM support done correctly. Once fixing those 2 issues, V4QI seems enough supported. I am thinking about removing V2HI support from my patches though.
[Bug debug/113382] FAIL: gcc.dg/debug/btf/btf-bitfields-3.c scan-assembler-times [\t ]0x6000004[\t ]+[^\n]*btt_info 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113382 --- Comment #1 from John David Anglin --- Similar fails: FAIL: gcc.dg/debug/btf/btf-enum-1.c scan-assembler-times [\\t ]0x604[\\t ]+[^\\n]*btt_info 1 FAIL: gcc.dg/debug/btf/btf-enum-small.c scan-assembler-times [\\t ]0x602[\\t ]+[^\\n]*btt_info 1 FAIL: gcc.dg/debug/btf/btf-enum64-1.c scan-assembler-times [\\t ]0x1303[\\t ]+[^\\n]*btt_info 2 FAIL: gcc.dg/debug/btf/btf-enum64-1.c scan-assembler-times [\\t ]0x9303[\\t ]+[^\\n]*btt_info 1
[Bug fortran/113152] Fortran 2023 half-cycle trigonometric functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-01-21 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #13 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #12) > Created attachment 57179 [details] > Patch This patch does not compile with older MPFR versions: ../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr* gfc_simplify_cospi(gfc_expr*)': ../../gcc-trunk/gcc/fortran/simplify.cc:2085:7: error: 'mpfr_cospi' was not declared in this scope; did you mean 'mpfr_cosh'? 2085 | mpfr_cospi (result->value.real, result->value.real, GFC_RND_MODE); | ^~ | mpfr_cosh ../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr* gfc_simplify_sinpi(gfc_expr*)': ../../gcc-trunk/gcc/fortran/simplify.cc:7893:7: error: 'mpfr_sinpi' was not declared in this scope; did you mean 'mpfr_sinh'? 7893 | mpfr_sinpi (result->value.real, x->value.real, GFC_RND_MODE); | ^~ | mpfr_sinh ../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr* gfc_simplify_tanpi(gfc_expr*)': ../../gcc-trunk/gcc/fortran/simplify.cc:8265:7: error: 'mpfr_tanpi' was not declared in this scope; did you mean 'mpfr_tanh'? 8265 | mpfr_tanpi (result->value.real, x->value.real, GFC_RND_MODE); | ^~ | mpfr_tanh ../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr* gfc_simplify_atan2pi(gfc_expr*, gfc_expr*)': ../../gcc-trunk/gcc/fortran/simplify.cc:8320:7: error: 'mpfr_atan2pi' was not declared in this scope; did you mean 'mpfr_atan2'? 8320 | mpfr_atan2pi (result->value.real, y->value.real, x->value.real, | ^~~~ | mpfr_atan2 ../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr* gfc_simplify_atanpi(gfc_expr*)': ../../gcc-trunk/gcc/fortran/simplify.cc:8349:7: error: 'mpfr_atanpi' was not declared in this scope; did you mean 'mpfr_atanh'? 8349 | mpfr_atanpi (result->value.real, x->value.real, GFC_RND_MODE); | ^~~ | mpfr_atanh ../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr* gfc_simplify_asinpi(gfc_expr*)': ../../gcc-trunk/gcc/fortran/simplify.cc:8377:7: error: 'mpfr_asinpi' was not declared in this scope; did you mean 'mpfr_asinh'? 8377 | mpfr_asinpi (result->value.real, x->value.real, GFC_RND_MODE); | ^~~ | mpfr_asinh ../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr* gfc_simplify_acospi(gfc_expr*)': ../../gcc-trunk/gcc/fortran/simplify.cc:8405:7: error: 'mpfr_acospi' was not declared in this scope; did you mean 'mpfr_acosh'? 8405 | mpfr_acospi (result->value.real, x->value.real, GFC_RND_MODE); | ^~~ | mpfr_acosh I think that you cannot do + if (MPFR_HALF_CYCLE) you really must use #if MPFR_HALF_CYCLE
[Bug c++/112293] Enhance error reporting with fix-it for missing in gcc 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112293 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #9 from Florian Weimer --- Could we change the C++ standard not to declare std::remove in ?
[Bug rtl-optimization/111267] [14 Regression] Codegen regression from i386 argument passing changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111267
--- Comment #11 from GCC Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:86de9b66480b710202a2898cf513db105d8c432f
commit r14-8319-g86de9b66480b710202a2898cf513db105d8c432f
Author: Roger Sayle
Date: Sun Jan 21 21:22:28 2024 +
PR rtl-optimization/111267: Improved forward propagation.
This patch resolves PR rtl-optimization/111267 by improving RTL-level
forward propagation. This x86_64 code quality regression was caused
(exposed) by my changes to improve how x86's (TImode) argument passing
is represented at the RTL-level (reducing the use of SUBREGs to catch
more optimization opportunities in combine). The pitfall is that the
more complex RTL representations expose a limitation in RTL's fwprop
pass.
At the heart of fwprop, in try_fwprop_subst_pattern, the logic can
be summarized as three steps. Step 1 is a heuristic that rejects the
propagation attempt if the expression is too complex, step 2 calls
the backend's recog to see if the propagated/simplified instruction
is recognizable/valid, and step 3 then calls set_src_cost to compare
the rtx costs of the replacement vs. the original, and accepts the
transformation if the final cost is the same of better.
The logic error (or missed optimization opportunity) is that the
step 1 heuristic that attempts to predict (second guess) the
process is flawed. Ultimately the decision on whether to fwprop
or not should depend solely on actual improvement, as measured
by RTX costs. Hence the prototype fix in the bugzilla PR removes
the heuristic of calling prop.profitable_p entirely, relying
entirely on the cost comparison in step 3.
Unfortunately, things are a tiny bit more complicated. The cost
comparison in fwprop uses the older set_src_cost API and not the
newer (preffered) insn_cost API as currently used in combine.
This means that the cost improvement comparisons are only done
for single_set instructions (more complex PARALLELs etc. aren't
supported). Hence we can only rely on skipping step 1 for that
subset of instructions actually evaluated by step 3.
The other subtlety is that to avoid potential infinite loops
in fwprop we should only reply purely on rtx costs when the
transformation is obviously an improvement. If the replacement
has the same cost as the original, we can use the prop.profitable_p
test to preserve the current behavior.
Finally, to answer Richard Biener's remaining question about this
approach: yes, there is an asymmetry between how patterns are
handled and how REG_EQUAL notes are handled. For example, at
the moment propagation into notes doesn't use rtx costs at all,
and ultimately when fwprop is updated to use insn_cost, this
(and recog) obviously isn't applicable to notes. There's no reason
the logic need be identical between patterns and notes, and during
stage4 we only need update propagation into patterns to fix this
P1 regression (notes and use of cost_insn can be done for GCC 15).
For Jakub's reduced testcase:
struct S { float a, b, c, d; };
int bar (struct S x, struct S y) {
return x.b <= y.d && x.c >= y.a;
}
On x86_64-pc-linux-gnu with -O2 gcc currently generates:
bar:movq%xmm2, %rdx
movq%xmm3, %rax
movq%xmm0, %rsi
xchgq %rdx, %rax
movq%rsi, %rcx
movq%rax, %rsi
movq%rdx, %rax
shrq$32, %rcx
shrq$32, %rax
movd%ecx, %xmm4
movd%eax, %xmm0
comiss %xmm4, %xmm0
jb .L6
movd%esi, %xmm0
xorl%eax, %eax
comiss %xmm0, %xmm1
setnb %al
ret
.L6:xorl%eax, %eax
ret
with this simple patch to fwprop, we now generate:
bar:shufps $85, %xmm0, %xmm0
shufps $85, %xmm3, %xmm3
comiss %xmm0, %xmm3
jb .L6
xorl%eax, %eax
comiss %xmm2, %xmm1
setnb %al
ret
.L6:xorl%eax, %eax
ret
2024-01-21 Roger Sayle
Richard Biener
gcc/ChangeLog
PR rtl-optimization/111267
* fwprop.cc (fwprop_propagation::profitabe_p): Rename
profitable_p method to likely_profitable_p.
(try_fwprop_subst_node): Update call to likely_profitable_p.
Only bail-out early when !prop.likely_profitable_p for instructions
that are not single sets. When comparing costs, bail-out if the
cost is unchanged and !prop.likely_profitable_p.
gcc/testsuite/ChangeLog
PR rtl-optimization/111267
* gcc.target/i386/pr111267.c: New test case.
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 90464, which changed state. Bug 90464 Summary: Documentation: incorrect description of -Wunused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90464 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/90464] Documentation: incorrect description of -Wunused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90464 sandra at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from sandra at gcc dot gnu.org --- Fixed.
[Bug c++/90464] Documentation: incorrect description of -Wunused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90464 --- Comment #1 from GCC Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:5c3e2e134ba8e692f317f21aea10b70bfe14cfc1 commit r14-8318-g5c3e2e134ba8e692f317f21aea10b70bfe14cfc1 Author: Sandra Loosemore Date: Sun Jan 21 20:42:59 2024 + Make the manual clearer about what options -Wunused enables [PR90464] gcc/ChangeLog PR c++/90464 * doc/invoke.texi (Warning Options): Document that -Wunused-parameter isn't enabled by -Wunused unless -Wextra is provided, and that -Wunused does enable -Wunused-const-variable=1 for C. Clarify that -Wunused doesn't enable -Wunused-* options documented as behaving otherwise, and list them explicitly.
[Bug sanitizer/113531] New: AddressSanitizer: stack-use-after-scope when iterating over initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113531
Bug ID: 113531
Summary: AddressSanitizer: stack-use-after-scope when iterating
over initializer list
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at pauldreik dot se
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Sorry for not being able to condense this better, it is reduced from several
thousand lines in multiple files into this. The false alarm easily goes away
when something changes, I guess it is the optimizer removing things. Therefore,
the program is run in catch and not as a simple main() function.
I have git bisected this to happen at commit
4d935f52b0d5c00fcc154461b87415ebd8791a94 "c++: make initializer_list array
static again [PR110070]" which seems related.
Address sanitizer gives me a warning about stack-use-after-scope on the for
loop, which I believe is legal C++.
Here is a godbolt link: https://godbolt.org/z/vrWEWzd9a , but I include the
program and error message below as well:
// compile with -std=c++20 -fsanitize=address -lCatch2Main
#include
#include
struct Inner
{
enum class Indices
{
A,
B,
C
};
Inner()
{
// must be three indices, if only two the problem goes away
for (auto i : { Indices::A, Indices::B, Indices::C }) //
<-- ERROR: AddressSanitizer: stack-use-after-scope
{
}
std::puts("this line must be here");
}
};
struct Outer
{
int return_42() const
{
// not 42, to trigger the test (so the code is not optimized away, I
assume)
return 0;
}
Inner inner;
};
TEST_CASE("demonstrate AddressSanitizer: stack-use-after-scope")
{
Outer c;
WHEN("this WHEN must be here, otherwise the error does not trigger")
{
REQUIRE(c.return_42() == 42);
}
}
And the error message:
Program returned: 1
=
==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x004c3380
at pc 0x0040b924 bp 0x7ffd52eff450 sp 0x7ffd52eff448
READ of size 4 at 0x004c3380 thread T0
#0 0x40b923 in Inner::Inner() /app/example.cpp:17
#1 0x40b9d5 in Outer::Outer() /app/example.cpp:24
#2 0x40a3c7 in C_A_T_C_HT_E_S_T0 /app/example.cpp:37
#3 0x45a68d in Catch::TestInvokerAsFunction::invoke() const
(/app/output.s+0x45a68d) (BuildId: 433ece10f75938fe33f68968e4c7ab9a1f766f29)
#4 0x440c86 in Catch::TestCaseHandle::invoke() const
(/app/output.s+0x440c86) (BuildId: 433ece10f75938fe33f68968e4c7ab9a1f766f29)
#5 0x440062 in Catch::RunContext::invokeActiveTestCase()
(/app/output.s+0x440062) (BuildId: 433ece10f75938fe33f68968e4c7ab9a1f766f29)
#6 0x43fdf1 in
Catch::RunContext::runCurrentTest(std::__cxx11::basic_string, std::allocator >&,
std::__cxx11::basic_string, std::allocator
>&) (/app/output.s+0x43fdf1) (BuildId:
433ece10f75938fe33f68968e4c7ab9a1f766f29)
#7 0x43e99b in Catch::RunContext::runTest(Catch::TestCaseHandle const&)
(/app/output.s+0x43e99b) (BuildId: 433ece10f75938fe33f68968e4c7ab9a1f766f29)
#8 0x447bac in Catch::(anonymous namespace)::TestGroup::execute()
(/app/output.s+0x447bac) (BuildId: 433ece10f75938fe33f68968e4c7ab9a1f766f29)
#9 0x448b6c in Catch::Session::runInternal() (/app/output.s+0x448b6c)
(BuildId: 433ece10f75938fe33f68968e4c7ab9a1f766f29)
#10 0x4488a0 in Catch::Session::run() (/app/output.s+0x4488a0) (BuildId:
433ece10f75938fe33f68968e4c7ab9a1f766f29)
#11 0x40a26a in int Catch::Session::run(int, char const* const*)
(/app/output.s+0x40a26a) (BuildId: 433ece10f75938fe33f68968e4c7ab9a1f766f29)
#12 0x40a18b in main (/app/output.s+0x40a18b) (BuildId:
433ece10f75938fe33f68968e4c7ab9a1f766f29)
#13 0x7f0adaa29d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId:
a43bfc8428df6623cd498c9c0caeb91aec9be4f9)
#14 0x7f0adaa29e3f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId:
a43bfc8428df6623cd498c9c0caeb91aec9be4f9)
#15 0x40a084 in _start (/app/output.s+0x40a084) (BuildId:
433ece10f75938fe33f68968e4c7ab9a1f766f29)
0x004c3380 is located 0 bytes inside of global variable 'C.1' defined in
'/app/example.cpp:17:60' (0x4c3380) of size 12
SUMMARY: AddressSanitizer: stack-use-after-scope /app/example.cpp:17 in
Inner::Inner()
Shadow bytes around the buggy address:
0x004c3100: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
0x004c3180: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
0x004c3200: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
0x004c3280: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9
0x004c3300: 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9
[Bug c++/112293] Enhance error reporting with fix-it for missing in gcc 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112293 --- Comment #8 from Jonathan Wakely --- And here too: https://bugzilla.redhat.com/show_bug.cgi?id=2259394
[Bug fortran/113377] Wrong code passing optional dummy argument to elemental procedure with optional dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377 --- Comment #9 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:68862e5c75ef0e875e690f0880a96fc6200d1682 commit r14-8317-g68862e5c75ef0e875e690f0880a96fc6200d1682 Author: Harald Anlauf Date: Sat Jan 20 22:18:02 2024 +0100 Fortran: passing of optional scalar arguments with VALUE attribute [PR113377] gcc/fortran/ChangeLog: PR fortran/113377 * trans-expr.cc (gfc_conv_procedure_call): Fix handling of optional scalar arguments of intrinsic type with the VALUE attribute. gcc/testsuite/ChangeLog: PR fortran/113377 * gfortran.dg/optional_absent_9.f90: New test.
[Bug c/113492] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields since r14-6808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113492 --- Comment #12 from GCC Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:1ead42f9836a13cbbe6a2be685f76750583ae320 commit r14-8316-g1ead42f9836a13cbbe6a2be685f76750583ae320 Author: Martin Uecker Date: Sat Jan 20 19:03:57 2024 +0100 C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492] This patch fixes a bug when forming a composite type from structs that contain an unsigned bitfield declared with int while using -funsigned-bitfields. In such structs the unsigned integer type was not compatible to the regular unsigned integer type used elsewhere in the C FE. PR c/113492 gcc/c: * c-decl.cc (grokdeclarator): Use c_common_unsigned_type instead of unsigned_type_for to create the unsigned type for bitfields declared with int when using -funsigned-bitfields. gcc/testsuite: * gcc.dg/pr113492.c: New test.
[Bug go/113530] [14 Regression] libgo ftbfs on arc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113530 --- Comment #4 from John David Anglin --- Created attachment 57181 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57181=edit Add defines for hppa and hppa64 to goarch.sh Untested.
[Bug fortran/57360] Implement a warning for implied save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360
--- Comment #8 from Walter Spector ---
Hi,
It is a good point. The message is helpful when issued within a procedure.
At module scope, it doesn't mean much since everything at that level is SAVE
anyway. This is similar to what happens in C:
int x = 3; // statically allocated
void fn () {
int i=3; // stack allocated
}
Walter
-Original Message-
From: kargl at gcc dot gnu.org
Sent: Jan 21, 2024 9:43 AM
To:
Subject: [Bug fortran/57360] Implement a warning for implied save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360
--- Comment #7 from kargl at gcc dot gnu.org ---
Upon some additional thinking, I wonder how useful this will be compared
to the possible volume of warning messages from modern Fortran. Consider
this code:
module foo
integer :: j = 2
type a
integer :: k = 3
end type
type(a) :: b = a(4)
integer, target :: n
integer, pointer :: m => n
end module foo
subroutine t()
integer :: i=1
write(6,*) i
i=i+1
end subroutine t
call t()
call t()
end
with the patch at the end of this email, I see
% gfcx -c -Wsurprising -Wall a.f90
a.f90:2:14:
2 | integer :: j = 2
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:6:14:
6 | type(a) :: b = a(4)
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:7:22:
7 | integer, target :: n
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:8:23:
8 | integer, pointer :: m => n
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:12:13:
12 | integer :: i=1
| 1
Warning: i at (1) has an implicit SAVE attribute [-Wsurprising]
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 503ecb8d9b5..d6ef37e51f2 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2278,7 +2278,12 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_locus)
sym->value = init;
if (sym->attr.save == SAVE_NONE)
- sym->attr.save = SAVE_IMPLICIT;
+ {
+ sym->attr.save = SAVE_IMPLICIT;
+ if (warn_surprising)
+ gfc_warning (OPT_Wsurprising, "%qs at %L has an implicit SAVE "
+ "attribute", sym->name, sym->declared_at);
+ }
*initp = NULL;
}
@@ -5868,7 +5873,12 @@ match_attr_spec (void)
|| gfc_current_state () == COMP_SUBMODULE)
!current_attr.save
(gfc_option.allow_std GFC_STD_F2008) != 0)
- current_attr.save = SAVE_IMPLICIT;
+ {
+ current_attr.save = SAVE_IMPLICIT;
+ if (warn_surprising)
+ gfc_warning (OPT_Wsurprising, "Entity at %C has an implicit SAVE "
+ "attribute");
+ }
colon_seen = 1;
return MATCH_YES;
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug fortran/57360] Implement a warning for implied save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360
--- Comment #7 from kargl at gcc dot gnu.org ---
Upon some additional thinking, I wonder how useful this will be compared
to the possible volume of warning messages from modern Fortran. Consider
this code:
module foo
integer :: j = 2
type a
integer :: k = 3
end type
type(a) :: b = a(4)
integer, target :: n
integer, pointer :: m => n
end module foo
subroutine t()
integer :: i=1
write(6,*) i
i=i+1
end subroutine t
call t()
call t()
end
with the patch at the end of this email, I see
% gfcx -c -Wsurprising -Wall a.f90
a.f90:2:14:
2 |integer :: j = 2
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:6:14:
6 |type(a) :: b = a(4)
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:7:22:
7 |integer, target :: n
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:8:23:
8 |integer, pointer :: m => n
| 1
Warning: Entity at (1) has an implicit SAVE attribute [-Wsurprising]
a.f90:12:13:
12 | integer :: i=1
| 1
Warning: ‘i’ at (1) has an implicit SAVE attribute [-Wsurprising]
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 503ecb8d9b5..d6ef37e51f2 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2278,7 +2278,12 @@ add_init_expr_to_sym (const char *name, gfc_expr
**initp, locus *var_locus)
sym->value = init;
if (sym->attr.save == SAVE_NONE)
- sym->attr.save = SAVE_IMPLICIT;
+ {
+ sym->attr.save = SAVE_IMPLICIT;
+ if (warn_surprising)
+ gfc_warning (OPT_Wsurprising, "%qs at %L has an implicit SAVE "
+ "attribute", sym->name, >declared_at);
+ }
*initp = NULL;
}
@@ -5868,7 +5873,12 @@ match_attr_spec (void)
|| gfc_current_state () == COMP_SUBMODULE)
&& !current_attr.save
&& (gfc_option.allow_std & GFC_STD_F2008) != 0)
-current_attr.save = SAVE_IMPLICIT;
+{
+ current_attr.save = SAVE_IMPLICIT;
+ if (warn_surprising)
+ gfc_warning (OPT_Wsurprising, "Entity at %C has an implicit SAVE "
+"attribute");
+}
colon_seen = 1;
return MATCH_YES;
[Bug go/113530] [14 Regression] libgo ftbfs on arc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113530 --- Comment #3 from John David Anglin --- Looks like a Makefile issue: echo " _BigEndian = `$(SHELL) $(srcdir)/goarch.sh $(GOARCH) bigendian`" >> zgoarch.go.tmp At this time, hppa doesn't support go.
[Bug go/84948] [11/12/13/14 regression] ICE in set_from, at go/gofrontend/types.cc:2660
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84948 Matthias Klose changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #11 from Matthias Klose --- seen with trunk 20240121 on m68k-linux-gnu, trying to build libgo: go1: internal compiler error: in set_from, at go/gofrontend/types.cc:2863 0x67b949 Ptrmask::set_from(Gogo*, Type*, long, long) ../../src/gcc/go/gofrontend/types.cc:2863 0x9681a8 Ptrmask::set_from(Gogo*, Type*, long, long) ../../src/gcc/go/gofrontend/types.cc:2837 0x9681a8 Ptrmask::set_from(Gogo*, Type*, long, long) ../../src/gcc/go/gofrontend/types.cc:2896 0x968668 Ptrmask::set_from(Gogo*, Type*, long, long) ../../src/gcc/go/gofrontend/types.cc:3046 0x968668 Type::gc_ptrmask_var(Gogo*, long, long) ../../src/gcc/go/gofrontend/types.cc:3042 0x969399 Type::make_gc_symbol_var(Gogo*) ../../src/gcc/go/gofrontend/types.cc:2722 0x96953a Type::gc_symbol_pointer(Gogo*) ../../src/gcc/go/gofrontend/types.cc:2672 0x8c7da1 Struct_construction_expression::do_get_backend(Translate_context*) ../../src/gcc/go/gofrontend/expressions.cc:17133 0x8c7da1 Struct_construction_expression::do_get_backend(Translate_context*) ../../src/gcc/go/gofrontend/expressions.cc:17133 0x961e68 Type::make_type_descriptor_var(Gogo*) ../../src/gcc/go/gofrontend/types.cc:1433 0x9623dd Type::type_descriptor_pointer(Gogo*, Location) ../../src/gcc/go/gofrontend/types.cc:1308 0x8fa79d Named_object::get_backend(Gogo*, std::vector >&, std::vector >&, std::vector >&) ../../src/gcc/go/gofrontend/gogo.cc:8976 0x8fc8f9 Gogo::write_globals() ../../src/gcc/go/gofrontend/gogo.cc:1578 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. make[7]: *** [Makefile:3059: runtime.lo] Error 1
[Bug go/113530] [14 Regression] libgo ftbfs on arc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113530 Matthias Klose changed: What|Removed |Added CC||danglin at gcc dot gnu.org Target|arc-linux-gnu |arc-linux-gnu ||hppa-linux-gnu --- Comment #2 from Matthias Klose --- hppa-linux-gnu fails in the same way
[Bug other/113336] libatomic (testsuite) regressions on armv6-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113336 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #2 from Hans-Peter Nilsson --- Whoops, sorry! (no, not actually sorry :) I'm glad you have a handle on this, though!
[Bug go/113530] [14 Regression] libgo ftbfs on arc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113530 --- Comment #1 from Matthias Klose --- sorry, arc-linux-gnu
[Bug go/113530] New: [14 Regression] libgo ftbfs on arc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113530 Bug ID: 113530 Summary: [14 Regression] libgo ftbfs on arc-linux-gnu Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with trunk 20240121 on arch-linux-gnu, works with the gcc-13 branch, building a gccgo cross compiler targeting arc-linux-gnu: [...] libtool: compile: /home/packages/cross/14/p/gcc-cross-ports/gcc/build/./gcc/gccgo -B/home/packa ges/cross/14/p/gcc-cross-ports/gcc/build/./gcc/ -B/usr/arc-linux-gnu/bin/ -B/usr/arc-linux-gnu/l ib/ -isystem /usr/arc-linux-gnu/include -isystem /usr/arc-linux-gnu/sys-include -isystem /home/p ackages/cross/14/p/gcc-cross-ports/gcc/build/sys-include -O2 -g -I . -c -fgo-pkgpath=internal/go arch ../../../src/libgo/go/internal/goarch/goarch.go zgoarch.go -fPIC -o internal/.libs/goarch. o zgoarch.go:7:14: error: expected ';' or ')' or newline 7 | _BigEndian = | ^ zgoarch.go:7:3: error: reference to undefined name '_BigEndian' 7 | _BigEndian = | ^ ../../../src/libgo/go/internal/goarch/goarch.go:18:19: error: reference to undefined name '_BigE ndian' 18 | const BigEndian = _BigEndian | ^ ../../../src/libgo/go/internal/goarch/goarch.go:21:29: error: reference to undefined name '_Defa ultPhysPageSize' 21 | const DefaultPhysPageSize = _DefaultPhysPageSize | ^ ../../../src/libgo/go/internal/goarch/goarch.go:25:19: error: reference to undefined name '_PCQu antum' 25 | const PCQuantum = _PCQuantum | ^ ../../../src/libgo/go/internal/goarch/goarch.go:28:20: error: reference to undefined name '_Int6 4Align' 28 | const Int64Align = _Int64Align |^ ../../../src/libgo/go/internal/goarch/goarch.go:35:22: error: reference to undefined name '_MinF rameSize' 35 | const MinFrameSize = _MinFrameSize | ^ ../../../src/libgo/go/internal/goarch/goarch.go:39:20: error: reference to undefined name '_Stac kAlign' 39 | const StackAlign = _StackAlign |^ make[7]: *** [Makefile:3059: internal/goarch.lo] Error 1
[Bug libstdc++/113512] Incorrect results for std::format("{:#.3g}", flt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113512 --- Comment #1 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a57439d61937925cec48df6166b2a805ae7054d5 commit r14-8315-ga57439d61937925cec48df6166b2a805ae7054d5 Author: Jonathan Wakely Date: Sat Jan 20 00:44:12 2024 + libstdc++: Fix std::format floating-point alternate forms [PR113512] The logic for handling '#' forms was ... not good. The count of significant figures just counted digits, instead of ignoring leading zeros. And when moving the result from the stack buffer to a dynamic string the exponent could get lost in some cases. libstdc++-v3/ChangeLog: PR libstdc++/113512 * include/std/format (__formatter_fp::format): Fix logic for alternate forms. * testsuite/std/format/functions/format.cc: Check buggy cases of alternate forms with g presentation type.
[Bug tree-optimization/113411] ABS*ABS can be simplified to ABS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113411 Andrew Pinski changed: What|Removed |Added Blocks||56355 --- Comment #2 from Andrew Pinski --- PR 56355 is the same but for floating point already ... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56355 [Bug 56355] abs and multiplication
[Bug c++/113529] Incorrect result of requires-expression in case of function call ambiguity and `operator<=>`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113529 Andrew Pinski changed: What|Removed |Added Summary|Incorrect result of |Incorrect result of |requires-expression in case |requires-expression in case |of function call ambiguity |of function call ambiguity ||and `operator<=>` Last reconfirmed||2024-01-21 Keywords||wrong-code Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. I just tried a normal function and not operator<=> and GCC does the correct thing. It is definitely `operator<=>` related because removing `operator<=>` and having an ambigous `operator<` does the correct thing too.
[Bug middle-end/113528] gcc-13 meets PVS-studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113528 --- Comment #3 from Andrew Pinski --- >Fragment N6 So in the tools GCC's code that currenly use gcov_read_profile_dir is not a leak that matters because the program exits if that fails. So it is only an issue if someone externally uses it.
[Bug c++/113529] New: Incorrect result of requires-expression in case of function call ambiguity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113529
Bug ID: 113529
Summary: Incorrect result of requires-expression in case of
function call ambiguity
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
In this program
#include
struct A {
auto operator <=>(const A&) const = default;
bool operator <(const A&) const = default;
};
struct B {
auto operator <=>(const B&) const = default;
};
struct C : A, B {};
template
concept Cmp = requires(T u, T v) { u < v; };
//auto cmp = C{} < C{}; //this correctly fails due to ambiguity
static_assert( !Cmp ); //but this evaluates wrongly in GCC
C{} < C{} is correctly rejected as ambiguous, but for some reason `requires` in
GCC returns that the objects can be compared. This program is accepted by Clang
truck (to be v18). Online demo: https://godbolt.org/z/76zoYMd6h
Explanation of ambiguity: https://stackoverflow.com/a/69245639/7325599
DeepLearn 2024: early registration January 30
*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: January 30, 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 18 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]
[Bug middle-end/113528] gcc-13 meets PVS-studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113528 --- Comment #2 from Andrew Pinski --- > Fragment N3 The number of json::array leaked is 2 per argument to gcov. Not enough to care about since it exits after it finishes. If you are passing 1000 files to gcov well you have other issues to start with.
[Bug middle-end/113528] gcc-13 meets PVS-studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113528
--- Comment #1 from Andrew Pinski ---
> Fragment N4
Is NOT an issue, based on all of the uses of add_char, the character is tested
before adding it ...
And there 256 can hold all values of signed char.
>Fragment N5
Is just a small codiing style issue and actually will be optimized directly to
the same thing really in this case as ' ' and '+' test bit will be in the same
word (the second word/element).
>Fragment N7
Not a bug, was done on purpose, see r5-958-ga33ad58be16a52 (PR 61242 and
https://gcc.gnu.org/pipermail/gcc-patches/2014-May/389815.html).
> Fragment N8
This code is software generated and the length is 0 in the GTY marker:
ctf_dvdef_t ** GTY ((length ("0"))) ctfc_vars_list;
So not a bug.
> Fragment N9
Looks to be a way to avoid a goto, maybe now we could use a lamdba instead. So
just a coding style issue.
I have not looked into the other ones yet.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #29 from David Binderman --- (In reply to Martin Jambor from comment #28) > And is there already a bugzilla bug about these (or should I create one)? Done. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113528
[Bug c/113528] New: gcc-13 meets PVS-studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113528 Bug ID: 113528 Summary: gcc-13 meets PVS-studio Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- The following article describes using static analyser PVS-studio to find potential problems in gcc-13. https://pvs-studio.com/en/blog/posts/cpp/1067/ It might be worth checking the ten problems listed. It might also be worth checking that gcc trunk has no new problems, compared to gcc-13.
