[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Mikael Morin : https://gcc.gnu.org/g:cd65c727fd6d5a252964dbeb3a735daa0a521a89 commit r12-9243-gcd65c727fd6d5a252964dbeb3a735daa0a521a89 Author: Mikael Morin Date: Fri Feb 24 22:11:17 2023 +0100 fortran: Plug leak of associated_dummy memory. [PR108923] This fixes a memory leak by accompanying the release of gfc_actual_arglist elements' memory with a release of the associated_dummy field memory (if allocated). Actual argument copy is adjusted as well so that each copy can free its field independently. PR fortran/108923 gcc/fortran/ChangeLog: * expr.cc (gfc_free_actual_arglist): Free associated_dummy memory. (gfc_copy_actual_arglist): Make a copy of the associated_dummy field if it is set in the original element. (cherry picked from commit 24c9edfa73632276d7698c103f35833f29804d98)
[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Mikael Morin : https://gcc.gnu.org/g:7b0c9631ccb492c4457a91dbb91e7a5bcd0bc2a6 commit r12-9244-g7b0c9631ccb492c4457a91dbb91e7a5bcd0bc2a6 Author: Mikael Morin Date: Sat Feb 25 21:37:46 2023 +0100 fortran: Reuse associated_dummy memory if previously allocated [PR108923] This avoids making the associted_dummy field point to a new memory chunk if it's already pointing somewhere, in which case doing so would leak the previously allocated chunk. PR fortran/108923 gcc/fortran/ChangeLog: * intrinsic.cc (get_intrinsic_dummy_arg, set_intrinsic_dummy_arg): Rename the former to the latter. Remove the return value, add a reference to the lhs as argument, and do the pointer assignment inside the function. Don't do it if the pointer is already non-NULL. (sort_actual): Update caller. (cherry picked from commit 5c638095e7e0fa4de4e4f7326384a86830b25732)
[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
--- Comment #20 from Rolf Eike Beer ---
I'm running this rev:
g++-13 (Gentoo 13.0.1. p, commit 27495bc8fe028d4a68e97ad12b52231772e48dcf)
13.0.1 20230308 (experimental)
And I still get a warning for this testcase:
// $ cat ref.cpp
#include
const std::string &trigger(const std::string &server);
int verifyDevXml()
{
const auto &str = trigger("");
if (str.empty())
return 1;
return 0;
}
// $ g++-13 -Wdangling-reference -c -o ref.o ref.cpp
ref.cpp: In function ?int verifyDevXml()?:
ref.cpp:7:15: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
7 | const auto &str = trigger("");
| ^~~
ref.cpp:7:28: note: the temporary was destroyed at the end of the full
expression ?trigger(std::__cxx11::basic_string(((const char*)""),
std::allocator()))?
7 | const auto &str = trigger("");
| ~~~^~~~
The problem is to my understanding that this warns about the temporary
constructed in the argument, i.e. it warns that the std::string() formed from
"" could be bound here. Which could be true if the function does that, but in
my case it is just used as a lookup for a map and not returned.
[Bug fortran/107426] [12/13 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- Created attachment 54641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54641&action=edit Draft patch I couldn't track the exact path of the memory error reported by valgrind, but the attached patch "fixes" (well, it makes it latent I guess) the problem by removing from the use statement list the statements that are rejected.
[Bug analyzer/109106] New: GCC Static Analyzer doesn't model printf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109106
Bug ID: 109106
Summary: GCC Static Analyzer doesn't model printf
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: geoffreydgr at icloud dot com
Target Milestone: ---
GCC Static Analyzer does not model `printf`.
see it live: https://godbolt.org/z/6ooW44sPq
Input:
```c
#include
int main() {
int *j = 0;
printf("NPD_FLAG\n") || *j;
}
```
Output:
```
: In function 'main':
:10:27: warning: dereference of NULL 'j' [CWE-476]
[-Wanalyzer-null-dereference]
10 | printf("NPD_FLAG\n") || *j;
| ^~
'main': events 1-4
|
|9 | int *j = 0;
| |^
| ||
| |(1) 'j' is NULL
| 10 | printf("NPD_FLAG\n") || *j;
| | ~~
| || |
| || (3) ...to here
| || (4) dereference of NULL 'j'
| |(2) following 'false' branch...
|
Compiler returned: 0
```
[Bug modula2/109089] implementation of boolean should be C++/C bool rather than int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109089 --- Comment #2 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:431c06691dcbb84c7d999d91202537442e6a60f0 commit r13-6614-g431c06691dcbb84c7d999d91202537442e6a60f0 Author: Gaius Mulley Date: Sun Mar 12 13:27:23 2023 + [PR modula2/109089] implementation of boolean should be C++/C bool [PR modula2/109089]. This patch implements BOOLEAN using bool (boolean_type_node) thoughout cc1gm2. The patch also includes a patched version of the bootstrap tool mc. gcc/ChangeLog: * doc/gm2.texi (Elementary data types): Equivalence BOOLEAN with bool. gcc/m2/ChangeLog: PR modula2/109089 * gm2-compiler/M2GCCDeclare.mod (DeclareKnownType): Import. * gm2-gcc/gcc-consolidation.h (stdbool.h): Include. * gm2-gcc/init.h (defined): Change block start. * gm2-gcc/m2block.cc: Change FALSE to false, change TRUE to true. * gm2-gcc/m2block.h: Change int to bool. * gm2-gcc/m2builtins.cc: Ditto. * gm2-gcc/m2builtins.h: Ditto. * gm2-gcc/m2convert.cc: Change FALSE to false, TRUE to true and int to bool. * gm2-gcc/m2convert.h: Change int to bool. * gm2-gcc/m2decl.cc: Change int to bool. * gm2-gcc/m2decl.h: Change int to bool. * gm2-gcc/m2expr.cc: Change FALSE to false, TRUE to true and int to bool. * gm2-gcc/m2expr.h: Change int to bool. * gm2-gcc/m2statement.cc: Change FALSE to false, TRUE to true and int to bool. * gm2-gcc/m2statement.h: Change int to bool. * gm2-gcc/m2top.cc: Change int to bool. * gm2-gcc/m2top.h: Change int to bool. * gm2-gcc/m2tree.cc: Change int to bool. * gm2-gcc/m2tree.h: Change int to bool. * gm2-gcc/m2type.cc: Change int to bool. * gm2-gcc/m2type.h: Change int to bool. * gm2-lang.cc (convert_loc): Call convert_to_integer for BOOLEAN_TYPE. * gm2-libs/Builtins.def (isfinitef): Change return value from BOOLEAN to INTEGER. (isfinite): Ditto. (isfinitel): Ditto. * gm2-libs/Builtins.mod (isfinitef): Change return value from BOOLEAN to INTEGER. (isfinite): Ditto. (isfinitel): Ditto. * mc-boot/GASCII.cc: Rebuild. * mc-boot/GASCII.h: Rebuild. * mc-boot/GArgs.cc: Rebuild. * mc-boot/GArgs.h: Rebuild. * mc-boot/GAssertion.cc: Rebuild. * mc-boot/GAssertion.h: Rebuild. * mc-boot/GBreak.cc: Rebuild. * mc-boot/GBreak.h: Rebuild. * mc-boot/GCOROUTINES.h: Rebuild. * mc-boot/GCmdArgs.cc: Rebuild. * mc-boot/GCmdArgs.h: Rebuild. * mc-boot/GDebug.cc: Rebuild. * mc-boot/GDebug.h: Rebuild. * mc-boot/GDynamicStrings.cc: Rebuild. * mc-boot/GDynamicStrings.h: Rebuild. * mc-boot/GEnvironment.cc: Rebuild. * mc-boot/GEnvironment.h: Rebuild. * mc-boot/GFIO.cc: Rebuild. * mc-boot/GFIO.h: Rebuild. * mc-boot/GFormatStrings.cc: Rebuild. * mc-boot/GFormatStrings.h: Rebuild. * mc-boot/GFpuIO.cc: Rebuild. * mc-boot/GFpuIO.h: Rebuild. * mc-boot/GIO.cc: Rebuild. * mc-boot/GIO.h: Rebuild. * mc-boot/GIndexing.cc: Rebuild. * mc-boot/GIndexing.h: Rebuild. * mc-boot/GM2Dependent.cc: Rebuild. * mc-boot/GM2Dependent.h: Rebuild. * mc-boot/GM2EXCEPTION.cc: Rebuild. * mc-boot/GM2EXCEPTION.h: Rebuild. * mc-boot/GM2LINK.h: Rebuild. * mc-boot/GM2RTS.cc: Rebuild. * mc-boot/GM2RTS.h: Rebuild. * mc-boot/GMemUtils.cc: Rebuild. * mc-boot/GMemUtils.h: Rebuild. * mc-boot/GNumberIO.cc: Rebuild. * mc-boot/GNumberIO.h: Rebuild. * mc-boot/GPushBackInput.cc: Rebuild. * mc-boot/GPushBackInput.h: Rebuild. * mc-boot/GRTExceptions.cc: Rebuild. * mc-boot/GRTExceptions.h: Rebuild. * mc-boot/GRTco.h: Rebuild. * mc-boot/GRTentity.h: Rebuild. * mc-boot/GRTint.cc: Rebuild. * mc-boot/GRTint.h: Rebuild. * mc-boot/GSArgs.cc: Rebuild. * mc-boot/GSArgs.h: Rebuild. * mc-boot/GSFIO.cc: Rebuild. * mc-boot/GSFIO.h: Rebuild. * mc-boot/GSYSTEM.h: Rebuild. * mc-boot/GSelective.h: Rebuild. * mc-boot/GStdIO.cc: Rebuild. * mc-boot/GStdIO.h: Rebuild. * mc-boot/GStorage.cc: Rebuild. * mc-boot/GStorage.h: Rebuild. * mc-boot/GStrCase.cc: Rebuild. * mc-boot/GStrCase
[Bug modula2/109089] implementation of boolean should be C++/C bool rather than int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109089 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Gaius Mulley --- Closing after applying patch.
[Bug c++/107532] [13 Regression] -Werror=dangling-reference false positives in libcamera-0.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532 --- Comment #21 from Kohei Takahashi --- (In reply to Marek Polacek from comment #18) > (In reply to Barnabás Pőcze from comment #17) > > The simple test case with std::span still triggers the warning: > > https://gcc.godbolt.org/z/43cKxdqr3. I feel that without deeper code > > analysis such a warning will generate too many false positives and people > > will simply turn it off. > > There really haven't been that many, except this and one with range-based > for loops. I think it warns many usage of zip_iterator idiom such as boost.iterator and P2321 style flat_map. Those uses tuple of references like std::tuple by dereferencing iterator, so that any algorithms may yield this warning.
[Bug sanitizer/109107] New: UBsan since GCC-8 misses an integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109107
Bug ID: 109107
Summary: UBsan since GCC-8 misses an integer-overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
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, marxin at
gcc dot gnu.org
Target Milestone: ---
For the following code, UBsan since GCC-8 at -O1 and above misses the integer
overflow. GCC-7 can detect it at all opt levels.
Clang can detect it at all opt levels.
Compiler explorer: https://godbolt.org/z/Pez4jd5aj
% cat a.c
int a = -2147468918, c;
const long b = 676540;
int main() {
c = 1 + a - (short)b;
return c;
}
%
% gcc-tk -O1 -fsanitize=undefined a.c &&./a.out
%
% gcc-7 -O1 -fsanitize=undefined a.c &&./a.out
/a.c:4:15: runtime error: signed integer overflow: -2147468918 - 21179 cannot
be represented in type 'int'
%
[Bug analyzer/109106] GCC Static Analyzer doesn't model printf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109106 --- Comment #1 from Andrew Pinski --- printf can still return 0.
[Bug d/109108] New: d: Undefined reference to lambda in private enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109108
Bug ID: 109108
Summary: d: Undefined reference to lambda in private enum
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gcc dot gnu.org
Target Milestone: ---
Similar to pr108055. Lambdas should be emitted in every module they are
referenced from.
```
import other;
void main()
{
auto a = callFun(1);
}
```
```
private enum int function(ref int)[] funs =
[
0: (ref idx) => 0,
1: (ref idx) => 1,
];
int callFun(I)(I idx)
{
return funs[idx](idx);
}
```
Only compiling the "main" module results in linker errors.
---
$ gdc test.d -Wl,--demangle=dlang
/usr/x86_64-pc-linux-gnu/bin/ld: /tmp/ccDW8iNw.o: in function
`other.callFun!(int).callFun(int)':
test.d:(.text+0x4b): undefined reference to
`other.__lambda4!(int).__lambda4(ref int)'
test.d:(.text+0x56): undefined reference to
`other.__lambda5!(int).__lambda5(ref int)'
collect2: error: ld returned 1 exit status
[Bug fortran/107426] [12/13 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 --- Comment #4 from Mikael Morin --- Created attachment 54642 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54642&action=edit Dra (In reply to Mikael Morin from comment #3) > Created attachment 54641 [details] > Draft patch > > I couldn't track the exact path of the memory error reported by valgrind, > but the attached patch "fixes" (well, it makes it latent I guess) the > problem by removing from the use statement list the statements that are > rejected. There is a bug in it: new use statements are at the end of the linked list, not at the beginning.
[Bug fortran/107426] [12/13 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 Mikael Morin changed: What|Removed |Added Attachment #54641|0 |1 is obsolete|| Attachment #54642|0 |1 is obsolete|| --- Comment #5 from Mikael Morin --- Created attachment 54643 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54643&action=edit Corrected draft patch (In reply to Mikael Morin from comment #4) > Created attachment 54642 [details] > Dra > I was meaning: Draft patch, corrected.
[Bug fortran/107426] [12/13 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 Mikael Morin changed: What|Removed |Added Attachment #54643|0 |1 is obsolete|| --- Comment #6 from Mikael Morin --- Created attachment 54644 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54644&action=edit Corrected patch The previous patch was broken in multiple ways. This one works.
[Bug target/108583] [13 Regression] wrong code with vector division by uint16 at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583 --- Comment #27 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:03c6ba86757f0684c5419c90651106900f5ecb5a commit r13-6617-g03c6ba86757f0684c5419c90651106900f5ecb5a Author: Tamar Christina Date: Sun Mar 12 18:40:12 2023 + ranger: Add range-ops for widen addition and widen multiplication [PR108583] This adds range-ops for widening addition and widening multiplication. I couldn't figure out how to write a test for this. It looks like there are self tests but not a way to write standalone ones? I did create testcases in the patch 3/4 which tests the end result. gcc/ChangeLog: PR target/108583 * gimple-range-op.h (gimple_range_op_handler): Add maybe_non_standard. * gimple-range-op.cc (gimple_range_op_handler::gimple_range_op_handler): Use it. (gimple_range_op_handler::maybe_non_standard): New. * range-op.cc (class operator_widen_plus_signed, operator_widen_plus_signed::wi_fold, class operator_widen_plus_unsigned, operator_widen_plus_unsigned::wi_fold, class operator_widen_mult_signed, operator_widen_mult_signed::wi_fold, class operator_widen_mult_unsigned, operator_widen_mult_unsigned::wi_fold, ptr_op_widen_mult_signed, ptr_op_widen_mult_unsigned, ptr_op_widen_plus_signed, ptr_op_widen_plus_unsigned): New. * range-op.h (ptr_op_widen_mult_signed, ptr_op_widen_mult_unsigned, ptr_op_widen_plus_signed, ptr_op_widen_plus_unsigned): New Co-Authored-By: Andrew MacLeod
[Bug target/108583] [13 Regression] wrong code with vector division by uint16 at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583 --- Comment #26 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:2246d576f922bae3629da0fe1dbfcc6ff06769ad commit r13-6616-g2246d576f922bae3629da0fe1dbfcc6ff06769ad Author: Tamar Christina Date: Sun Mar 12 18:39:33 2023 + middle-end: Revert can_special_div_by_const changes [PR108583] This reverts the changes for the CAN_SPECIAL_DIV_BY_CONST hook. gcc/ChangeLog: PR target/108583 * doc/tm.texi (TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST): Remove. * doc/tm.texi.in: Likewise. * explow.cc (round_push, align_dynamic_address): Revert previous patch. * expmed.cc (expand_divmod): Likewise. * expmed.h (expand_divmod): Likewise. * expr.cc (force_operand, expand_expr_divmod): Likewise. * optabs.cc (expand_doubleword_mod, expand_doubleword_divmod): Likewise. * target.def (can_special_div_by_const): Remove. * target.h: Remove tree-core.h include * targhooks.cc (default_can_special_div_by_const): Remove. * targhooks.h (default_can_special_div_by_const): Remove. * tree-vect-generic.cc (expand_vector_operation): Remove hook. * tree-vect-patterns.cc (vect_recog_divmod_pattern): Remove hook. * tree-vect-stmts.cc (vectorizable_operation): Remove hook.
[Bug target/108583] [13 Regression] wrong code with vector division by uint16 at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #28 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:0b3c630fcc44063a61f6131af48a4171b1de2b37
commit r13-6618-g0b3c630fcc44063a61f6131af48a4171b1de2b37
Author: Tamar Christina
Date: Sun Mar 12 18:40:50 2023 +
middle-end: don't form FMAs when multiplication is not single use.
[PR108583]
The testcase
typedef unsigned int vec __attribute__((vector_size(32)));
vec
f3 (vec a, vec b, vec c)
{
vec d = a * b;
return d + ((c + d) >> 1);
}
shows a case where we don't want to form an FMA due to the MUL not being
single
use. In this case to form an FMA we have to redo the MUL as well as we no
longer have it to share.
As such making an FMA here would be a de-optimization.
gcc/ChangeLog:
PR target/108583
* tree-ssa-math-opts.cc (convert_mult_to_fma): Inhibit FMA in case
not
single use.
gcc/testsuite/ChangeLog:
PR target/108583
* gcc.dg/mla_1.c: New test.
Co-Authored-By: Richard Sandiford
[Bug target/108583] [13 Regression] wrong code with vector division by uint16 at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583 --- Comment #29 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:81fd62d1378b7ddc1fa0967cbddcdcdcdd2d8d8c commit r13-6619-g81fd62d1378b7ddc1fa0967cbddcdcdcdd2d8d8c Author: Tamar Christina Date: Sun Mar 12 18:42:04 2023 + middle-end: Implement preferred_div_as_shifts_over_mult [PR108583] This now implements a hook preferred_div_as_shifts_over_mult that indicates whether a target prefers that the vectorizer decomposes division as shifts rather than multiplication when possible. In order to be able to use this we need to check whether the current precision has enough bits to do the operation without any of the additions overflowing. We use range information to determine this and only do the operation if we're sure am overflow won't occur. This now uses ranger to do this range check. This seems to work better than vect_get_range_info which uses range_query, but I have not switched the interface of vect_get_range_info over in this PR fix. As Andy said before initializing a ranger instance is cheap but not free, and if the intention is to call it often during a pass it should be instantiated at pass startup and passed along to the places that need it. This is a big refactoring and doesn't seem right to do in this PR. But we should in GCC 14. Currently we only instantiate it after a long series of much cheaper checks. gcc/ChangeLog: PR target/108583 * target.def (preferred_div_as_shifts_over_mult): New. * doc/tm.texi.in: Document it. * doc/tm.texi: Regenerate. * targhooks.cc (default_preferred_div_as_shifts_over_mult): New. * targhooks.h (default_preferred_div_as_shifts_over_mult): New. * tree-vect-patterns.cc (vect_recog_divmod_pattern): Use it. gcc/testsuite/ChangeLog: PR target/108583 * gcc.dg/vect/vect-div-bitmask-4.c: New test. * gcc.dg/vect/vect-div-bitmask-5.c: New test.
[Bug target/108583] [13 Regression] wrong code with vector division by uint16 at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583 --- Comment #30 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:f23dc726875c26f2c38dfded453aa9beba0b9be9 commit r13-6620-gf23dc726875c26f2c38dfded453aa9beba0b9be9 Author: Tamar Christina Date: Sun Mar 12 18:42:59 2023 + AArch64: Update div-bitmask to implement new optab instead of target hook [PR108583] This replaces the custom division hook with just an implementation through add_highpart. For NEON we implement the add highpart (Addition + extraction of the upper highpart of the register in the same precision) as ADD + LSR. This representation allows us to easily optimize the sequence using existing sequences. This gets us a pretty decent sequence using SRA: umull v1.8h, v0.8b, v3.8b umull2 v0.8h, v0.16b, v3.16b add v5.8h, v1.8h, v2.8h add v4.8h, v0.8h, v2.8h usrav1.8h, v5.8h, 8 usrav0.8h, v4.8h, 8 uzp2v1.16b, v1.16b, v0.16b To get the most optimal sequence however we match (a + ((b + c) >> n)) where n is half the precision of the mode of the operation into addhn + uaddw which is a general good optimization on its own and gets us back to: .L4: ldr q0, [x3] umull v1.8h, v0.8b, v5.8b umull2 v0.8h, v0.16b, v5.16b addhn v3.8b, v1.8h, v4.8h addhn v2.8b, v0.8h, v4.8h uaddw v1.8h, v1.8h, v3.8b uaddw v0.8h, v0.8h, v2.8b uzp2v1.16b, v1.16b, v0.16b str q1, [x3], 16 cmp x3, x4 bne .L4 For SVE2 we optimize the initial sequence to the same ADD + LSR which gets us: .L3: ld1bz0.h, p0/z, [x0, x3] mul z0.h, p1/m, z0.h, z2.h add z1.h, z0.h, z3.h usraz0.h, z1.h, #8 lsr z0.h, z0.h, #8 st1bz0.h, p0, [x0, x3] inchx3 whilelo p0.h, w3, w2 b.any .L3 .L1: ret and to get the most optimal sequence I match (a + b) >> n (same constraint on n) to addhnb which gets us to: .L3: ld1bz0.h, p0/z, [x0, x3] mul z0.h, p1/m, z0.h, z2.h addhnb z1.b, z0.h, z3.h addhnb z0.b, z0.h, z1.h st1bz0.h, p0, [x0, x3] inchx3 whilelo p0.h, w3, w2 b.any .L3 There are multiple RTL representations possible for these optimizations, I did not represent them using a zero_extend because we seem very inconsistent in this in the backend. Since they are unspecs we won't match them from vector ops anyway. I figured maintainers would prefer this, but my maintainer ouija board is still out for repairs :) There are no new test as new correctness tests were added to the mid-end and the existing codegen tests for this already exist. gcc/ChangeLog: PR target/108583 * config/aarch64/aarch64-simd.md (@aarch64_bitmask_udiv3): Remove. (*bitmask_shift_plus): New. * config/aarch64/aarch64-sve2.md (*bitmask_shift_plus): New. (@aarch64_bitmask_udiv3): Remove. * config/aarch64/aarch64.cc (aarch64_vectorize_can_special_div_by_constant, TARGET_VECTORIZE_CAN_SPECIAL_DIV_BY_CONST): Removed. (TARGET_VECTORIZE_PREFERRED_DIV_AS_SHIFTS_OVER_MULT, aarch64_vectorize_preferred_div_as_shifts_over_mult): New.
[Bug target/108583] [13 Regression] wrong code with vector division by uint16 at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #31 from Tamar Christina --- Fixed, thanks for the report.
[Bug libfortran/109099] Assignment in NAMELIST input does not fill in row-column order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109099 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Severity|normal |enhancement Keywords||diagnostic Status|WAITING |NEW Component|fortran |libfortran --- Comment #4 from anlauf at gcc dot gnu.org --- I've checked the behavior with other compilers: Nvidia 23.1 and Flang: FIO-F-233/namelist read/internal file/too many constants to initialize group item. In source file pr109099.f90, at line number 9 Crayftn 14.0.0: &GROUP X = 7*999, 1, 2, 3, 4, 999 / Ifort 2021.8: &GROUP X = 7*999, 1, 2, 3, 4, 999 / Changing component to libfortran as this is a missing runtime diagnostic.
[Bug analyzer/109106] GCC Static Analyzer doesn't model printf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109106 --- Comment #2 from Andrew Pinski --- Why do you think printf will not return zero in some cases? Especially if stdout is write fails.
[Bug analyzer/109106] GCC Static Analyzer doesn't model printf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109106
--- Comment #3 from Andreas Schwab ---
When an output error occurs it returns < 0. Only printf("") or printf("%s",
"") can return 0.
[Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109074 --- Comment #12 from Jonathan Wakely --- (In reply to Murugesan Nagarajan from comment #10) > Hence sigabrt signal needs to be handler at libc.so.6 Library Stop trying to "handle" the error and FIX IT. The error is that you didn't link to libpthread. Build your program with -pthread and there will be no error, so you don't need to handle it.
[Bug middle-end/109031] csmith: possible bad code with -O2 -fno-strict-aliasing since r13-254-gdd3c7873a61019e9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031
--- Comment #30 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:eb1d8df792f990574cbb695b55c92ee2684fc96b
commit r13-6621-geb1d8df792f990574cbb695b55c92ee2684fc96b
Author: Roger Sayle
Date: Sun Mar 12 22:52:41 2023 +
PR middle-end/109031: Fix final value replacement from narrower IVs.
This patch fixes a P1 regression, a problem with my February 2022 patch
to improve folding for final value replacement:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590618.html
The motivation for the original patch is that because we know the number
of loop iterations can't be negative, final value expressions such as
(int) ((unsigned int) x + 4294967295) + 1 can be simplified to x,
as this is effectively ((x - 1) + 1) without overflow.
The bug/oversight is that using integer_all_onesp to check for the
implicit tree constant -1 it didn't consider that the inner (unsigned)
type might be narrower than hthe outer result type. For the case in the
PR, (int)((unsigned char)x + 255) + 1 gets simplified to (int)x, but
when x is originally zero, the correct result should be 256.
The fix is to check that the inner type's precision (the width of the
subtraction) is at least as wide as the result type (that of the addition).
I've also added a test for signed types, but without -fwrapv this
invokes undefined behaviour, and with -fwrapv it doesn't exhibit the
problem in the PR.
2023-03-12 Roger Sayle
gcc/ChangeLog
PR middle-end/109031
* tree-chrec.cc (chrec_apply): When folding "{a, +, a} (x-1)",
ensure that the type of x is as wide or wider than the type of a.
gcc/testsuite/ChangeLog
PR middle-end/109031
* gcc.dg/tree-ssa/pr109031-1.c: New test case.
* gcc.dg/tree-ssa/pr109031-2.c: Likewise.
[Bug libstdc++/108886] Add basic_string throw logic_error when assigned a nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108886
--- Comment #4 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Jonny Grant from comment #2)
> > I was taught to validate parameters at University. Personally I always
> > follow defensive programming approaches to avoid crashes.
>
> So stop passing null to these functions then :-)
Feels like we have a different opinion. I know you know more about C++ than
me.
Defensive programming is carefulness in libraries too; particularly interfaces.
The C++ standard group have a paper "P2698R0 Unconditional termination is a
serious problem" you may have seen.
What I see is that the nullptr keyword is part of the language, and is used in
many places to indicate an object is not available. For me, a function that
requires a valid pointer, should check for the nullptr constant. The crash is
the code that de-references the nullptr because it requires a valid pointer. Of
course I would like all code to check for nullptr before passing to
std::string, and I would do those checks myself as well :-)
A nullptr is different from passing a use-after-free pointer.
Wrapping std::string is the workaround, as it doesn't always throw logic_error
for the nullptr constant.
It would just use up time when the STL implementation could handle it, as need
to check every method on std::string in the codebase to check for nullptr,
because it doesn't throw logic_error say for assign or other operators.
> > So I would check
> > parameters on all interface methods and operators. I would rely on the
> > compiler to remove any unnecessary duplicate sanity checks.
>
> That doesn't necessarily work when the member functions are separately
> compiled, as with most std::string member functions.
Ok, that's a shame. If it showed up in some performance measurements it could
be adjusted.
> > > What would be the point of _GLIBCXX_DEBUG_PEDASSERT when there's already a
> > > debug assertion there? Compiling with _GLIBCXX_DEBUG will already abort.
> >
> > I don't see a debug assertion for _GLIBCXX_DEBUG_PEDASSERT could you point
> > out the file and line number to me please.
>
> You already quoted it in your comment 0 above, it's right there in
> assign(const _CharT*)!
>
> basic_string&
> assign(const _CharT* __s)
> {
> __glibcxx_requires_string(__s);
Ok I see. Thank you for that example __glibcxx_requires_string is a macro that
compiles down to _GLIBCXX_DEBUG_PEDASSERT. I wonder why it wasn't written in
capitals as __GLIBCXX_REQUIRES_STRING_ASSERT?
Anyway, it is good there are asserts that report nullptr issues at runtime.
> > Just compiled with -D_GLIBCXX_DEBUG but I don't get any abort, just the same
> > SEGV
> > https://godbolt.org/z/rjYG8Yrnh
>
> If you want a PEDASSERT to fire you need to actually request pedantic
> assertions.
>
> https://godbolt.org/z/874x18G1G
>
> /opt/compiler-explorer/gcc-trunk-20230227/include/c++/13.0.1/bits/
> basic_string.h:1645: constexpr std::__cxx11::basic_string<_CharT, _Traits,
> _Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::assign(const
> _CharT*) [with _CharT = char; _Traits = std::char_traits; _Alloc =
> std::allocator]: Assertion '__s != nullptr' failed.
>
> I'm not persuaded to change anything here. The performance of string
> assignments is very important and adding an extra branch and throwing an
> exception isn't free.
It sounds like you know the implementation really well.
Personally on embedded systems I don't find the cost of checking for NULL an
issue. The 'throw' should not impact performance, as it is within the if() and
code shouldn't often throw, still better than SEGV! Maybe you have some
performance comparison statistics showing that a NULL check really impacts
performance? STL string heap allocations and actual memory read/write are the
biggest performance impact on performance in my experience on embedded.
I doubt all uses of std::string are performance intensive. For performance
critical code identified by a profiler I just re-write that function in C.
Usually graphics code.
There is what might be a performance issue, I don't know if anyone has
measured, _M_construct() appears to copy copies byte by byte in
basic_string.tcc:177 rather than using an optimized memcpy(). I've not measured
this myself.
[Bug c/101766] Microblaze gcc misses symver but __has_attribute(symver) returns true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101766 Vincent Fazio changed: What|Removed |Added CC||vfazio at gmail dot com --- Comment #5 from Vincent Fazio --- There's a mail discussion about this topic https://gcc.gnu.org/pipermail/gcc/2023-March/240834.html The "easy" route is to just add the proper macro to config/microblaze/microblaze.h The more correct, but more arduous, route is "porting" microblaze to correctly use the elfos.h header and provide the proper overrides in a separate header. I've tested the former with zero issues and tested a version of the latter and was able to compile both a kernel and ramfs and successfully boot but doubt all cases are accounted for. attaching patches for posterity
[Bug c/101766] Microblaze gcc misses symver but __has_attribute(symver) returns true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101766 --- Comment #6 from Vincent Fazio --- Created attachment 54645 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54645&action=edit add macro to microblaze.h
[Bug c/101766] Microblaze gcc misses symver but __has_attribute(symver) returns true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101766 --- Comment #7 from Vincent Fazio --- Created attachment 54646 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54646&action=edit partial patch for microblaze migration to elfos.h
[Bug libstdc++/109074] SIGABRT signal without using -lpthread at Linux RHEL 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109074 --- Comment #13 from Murugesan Nagarajan --- MY LAST COMMENT: I agree. Normally I used to handle bug fix using following ways: 1. Steps to reproduce to issue creating core dump files. There are some other ways which may work(Example: -pthread or -lmurugesanopenssl or -lrfcsdk or -lnwrfcsdk or ... options) After this I used to receive/send that test result to/from test/development team. Few libraries I faced a lot of errors during 2008 to 2013 and FEW of them(I guess 4 out of six) were fixed during. 2. Hence I reported this error at current(old version) library. I agree that it is working when we use -pthread. However, this may report some other issue in future.
[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476 Jiang An changed: What|Removed |Added CC||de34 at live dot cn --- Comment #12 from Jiang An --- It seems that the current specification is still broken for extern "C" functions with internal linkage.(In reply to Maciej S. Szmigiero from comment #8) > Having functions with "C" language linkage (calling convention, etc) but > internal linkage is useful for writing callbacks provided to C functions. > > It's not an significant issue, however, as one can get the same effect by > declaring the callback function "static" inside an "extern C" block. This is not so useful in practice because most compilers don't make extern "C" and extern "C++" differentiate function types (implying calling conventions etc.). There's a long battle story, and the divergence between the standard and implementations is not resolved yet. See https://cplusplus.github.io/CWG/issues/1555.html https://lists.isocpp.org/sg12/2020/04/0900.php
[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70476
--- Comment #13 from Jiang An ---
(In reply to Maciej S. Szmigiero from comment #11)
> (In reply to Andrew Pinski from comment #9)
> > Does these two functions the same name then?
> > ```
> > namespace a {
> >extern "C" void f(void);
> > }
> >
> > namespace {
> > extern "C" void f(void) {}
> > }
> >
> > void g(void)
> > {
> > f();
> > a::f();
> > }
> >
> > ```
> > It seems counter intuitive that a::f and the ::f map to different functions.
>
> According to [dcl.link] "Two declarations for a function with C language
> linkage with the same function name (ignoring the namespace names that
> qualify it) that
> appear in different namespace scopes refer to the same function", so it
> would seem that both refer to the same function indeed.
>
> > Here is an example where GCC produces an assembly failure:
> >
> > namespace a {
> >extern "C" void f(void){}
> > }
> >
> > namespace {
> > extern "C" void f(void) {}
> > }
>
> If they are the same function then this shouldn't work (it would be a
> re-definition).
Oh, I think they shouldn't be the same function.
[dcl.link]/1 says:
> All functions and variables whose names have external linkage and all
> function types have a language linkage.
which implies that a function with internal linkage doesn't have a language
linkage, and thus [dcl.link]/7 doesn't apply to it.
