[Bug target/109167] rs6000: _mm_slli_si128 and _mm_bslli_si128 are inconsistent in wrapper header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109167 --- Comment #2 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:1e20bb6737e1173a0c3ef3e9e48c0eda40985ded commit r13-6871-g1e20bb6737e1173a0c3ef3e9e48c0eda40985ded Author: Kewen Lin Date: Sun Mar 26 21:43:39 2023 -0500 rs6000: Make _mm_slli_si128 and _mm_bslli_si128 consistent [PR109167] As PR109167 shows, it's unexpected to have two different implementation ways for _mm_slli_si128 and _mm_bslli_si128, as gcc/config/i386/emmintrin.h they should be the same. So this patch is to fix it accordingly. PR target/109167 gcc/ChangeLog: * config/rs6000/emmintrin.h (_mm_bslli_si128): Move the implementation from ... (_mm_slli_si128): ... here. Change to call _mm_bslli_si128 directly. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr109167.c: New test.
[Bug target/109082] emmintrin.h:1624:16: error: argument 3 must be a literal between 0 and 15, inclusive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109082 --- Comment #5 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:f33fc0775706e4db80d584c477608e28f4da0a6f commit r13-6870-gf33fc0775706e4db80d584c477608e28f4da0a6f Author: Kewen Lin Date: Sun Mar 26 21:42:23 2023 -0500 rs6000: Ensure vec_sld shift count in allowable range [PR109082] As PR109082 shows, some uses of vec_sld in emmintrin.h don't strictly guarantee the given shift count is in the range 0-15 (inclusive). This patch is to make the argument range constraint honored for those uses. PR target/109082 gcc/ChangeLog: * config/rs6000/emmintrin.h (_mm_bslli_si128): Check __N is not less than zero when calling vec_sld. (_mm_bsrli_si128): Return __A if __N is zero, check __N is bigger than zero when calling vec_sld. (_mm_slli_si128): Return __A if _imm5 is zero, check _imm5 is bigger than zero when calling vec_sld. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr109082.c: New test.
[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:82ec75a726b3f8f874dacb0cb342c9bbd1233cc0 commit r12-9320-g82ec75a726b3f8f874dacb0cb342c9bbd1233cc0 Author: Jerry DeLisle Date: Sun Mar 26 18:44:35 2023 -0700 Fortran: Modify checks to avoid referencing NULL pointer. Backport from mainline. gcc/fortran/ChangeLog: PR fortran/102331 * decl.cc (attr_decl1): Guard against NULL pointer. * parse.cc (match_deferred_characteristics): Include BT_CLASS in check for derived being undefined. gcc/testsuite/ChangeLog: PR fortran/102331 * gfortran.dg/class_result_4.f90: Update error message check. * gfortran.dg/pr85779_3.f90: Update error message check.
[Bug fortran/103506] [10/11/12 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 --- Comment #17 from CVS Commits --- The releases/gcc-12 branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:3d2860f933cc01668272e0aaa354aa96899b3a82 commit r12-9319-g3d2860f933cc01668272e0aaa354aa96899b3a82 Author: Jerry DeLisle Date: Sat Jan 28 20:00:34 2023 -0800 Fortran: ICE in gfc_free_namespace. ice-on-invalid. PR fortran/103506 gcc/fortran/ChangeLog: * parse.cc (parse_module): Remove use of a bool error value that prevented proper setting of the namespace pointer. gcc/testsuite/ChangeLog: * gfortran.dg/pr103506_1.f90: New test. (cherry picked from commit 8011fbba7baa46947341ca8069b5a327163a68d5)
[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289 --- Comment #1 from Andrew Pinski --- Patches should be sent to gcc-patches@ after reading https://gcc.gnu.org/contribute.html
[Bug other/52930] quadmath: missing logbq, modfq, nexttowardq, exp2q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52930 Christoph changed: What|Removed |Added CC||foss at grueninger dot de --- Comment #1 from Christoph --- logbq became part of GCC 6, released in 2016, see https://github.com/gcc-mirror/gcc/commit/03c02a42c59949e6ae0fdb0892fb3e751932d17b
[Bug libgcc/109289] New: Conflicting types for built-in functions in libgcc/emutls.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289 Bug ID: 109289 Summary: Conflicting types for built-in functions in libgcc/emutls.c Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: jdx at o2 dot pl Target Milestone: --- Created attachment 54759 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54759=edit Proposed patch For different hosts (Windows/MSYS2, Linux), different targets and for every libgcc variant, the following messages are reported: /d/Works/xcomp/gcc-build/./gcc/xgcc -B/d/Works/xcomp/gcc-build/./gcc/ -B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem /usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -isystem /d/Works/xcomp/sysroot/h8300-elf/include -ms -O2 -isystem /d/Works/xcomp/sysroot/h8300-elf/include -DIN_GCC -fPIC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -DDF=SF -I. -I. -I../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/. -I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include -o emutls.o -MT emutls.o -MD -MP -MF emutls.dep -fexceptions -c ../../../../../gcc/libgcc/emutls.c -fvisibility=hidden -DHIDE_EXPORTS d:\works\gcc\libgcc\emutls.c:61:7: warning: conflicting types for built-in function '__emutls_get_address'; expected 'void *(void *)' [-Wbuiltin-declaration-mismatch] 61 | void *__emutls_get_address (struct __emutls_object *); | ^~~~ d:\works\gcc\libgcc\emutls.c:63:6: warning: conflicting types for built-in function '__emutls_register_common'; expected 'void(void *, long unsigned int, long unsigned int, void *)' [-Wbuiltin-declaration-mismatch] 63 | void __emutls_register_common (struct __emutls_object *, word, word, void *); | ^~~~ d:\works\gcc\libgcc\emutls.c:140:1: warning: conflicting types for built-in function '__emutls_get_address'; expected 'void *(void *)' [-Wbuiltin-declaration-mismatch] 140 | __emutls_get_address (struct __emutls_object *obj) | ^~~~ d:\works\gcc\libgcc\emutls.c:204:1: warning: conflicting types for built-in function '__emutls_register_common'; expected 'void(void *, long unsigned int, long unsigned int, void *)' [-Wbuiltin-declaration-mismatch] 204 | __emutls_register_common (struct __emutls_object *obj, | ^~~~ Judging by the comment on line 138 the problem is known and acceptable, therefore IMO it would be nice to mute the warnings by wrapping declarations/definitions of these functions with "#pragma GCC diagnostic" e.g. as shown in the attached patch.
[Bug analyzer/109266] Wanalyzer-null-dereference does not warn when struct is at null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266 --- Comment #2 from Jonny Grant --- Thank you for your reply David. Your analyzer is very good already. I played around a bit, a base of nullptr doesn't give a warning. But changing to 0x10 does give array-bounds warning. cc1plus: note: source object is likely at address zero :13:13: warning: array subscript 0 is outside array bounds of 'a_t [0]' [-Warray-bounds=] https://godbolt.org/z/PhhT48xxP Found Andrew Pinski comment says 4096 is not accessible: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106699#c1 I wondered if you know how to turn on that "cc1plus: note: source object is likely at address zero? It seems different from normal warnings. It would be fantastic if there was a way for me to specify on the gcc command line an address range I didn't want read and/or writable. That would be great to get build warnings from those addresses if the compiler could see them being accessed. At the moment, I always need to use the JTAG debugger to set some hw breakpoints on read from various addresses to catch those accesses (as they are mapped to the interrupt vector from 0x0). On Windows I've had various crashes where the access was address 0x10 so felt like that was probably a struct offset too I don't know very much about gcc internals. I did wonder if the analyzer can see the base address of the struct being passed as 0x0 in the RTL file? I tried -fdump-rtl-all but couldn't see the 0x0 address, or when I changed to 0x10 either
[Bug target/106282] [10/11/12/13 Regression] m68k: Problem with thread-local storage and -mcpu=5206 since r9-2326-gede9446c26a929
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106282 --- Comment #3 from CVS Commits --- The master branch has been updated by Andreas Schwab : https://gcc.gnu.org/g:55bc61a75a68d1a8d1e4df170b4beef1020f1e55 commit r13-6867-g55bc61a75a68d1a8d1e4df170b4beef1020f1e55 Author: Andreas Schwab Date: Sun Jul 17 23:35:05 2022 +0200 m68k: handle TLS access with offset This reinstates FINAL_PRESCAN_INSN, and the calls in handle_move_double, so that access to TLS variables with offset are properly handled. gcc: PR target/106282 * config/m68k/m68k.h (FINAL_PRESCAN_INSN): Define. * config/m68k/m68k.cc (m68k_final_prescan_insn): Define. (handle_move_double): Call it before handle_movsi. * config/m68k/m68k-protos.h: Declare it. gcc/testsuite: PR target/106282 * gcc.target/m68k/tls-gd-off.c: New. * gcc.target/m68k/tls-ie-off.c: New. * gcc.target/m68k/tls-ld-off.c: New. * gcc.target/m68k/tls-ld-xtls-off.c: New. * gcc.target/m68k/tls-le-off.c: New. * gcc.target/m68k/tls-le-xtls-off.c: New. * gcc.target/m68k/tls-ld.c: Make pattern less strict. * gcc.target/m68k/tls-le.c: Likewise.
[Bug libstdc++/109288] New: std/time/time_zone/get_info_local.cc failure with tzdata2023a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109288 Bug ID: 109288 Summary: std/time/time_zone/get_info_local.cc failure with tzdata2023a Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- As mentioned in http://mm.icann.org/pipermail/tz-announce/2023-March/77.html tzdata2023a includes Egypt now uses DST again, from April through October. and that change caused FAIL: std/time/time_zone/get_info_local.cc execution test because the test expects it doesn't use DST since 2014 or so.
[Bug debug/108784] '-fcompare-debug' failure (length) w/ --param ira-simple-lra-insn-threshold=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108784 --- Comment #2 from Alexandre Oliva --- Hello, Arseny, I have a hunch this could possibly be related with fixed bug 108573. Is this one by any chance fixed for you?
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 --- Comment #3 from Alexandre Oliva --- dump files now consistently take the base name from the output name, when not overridden since in this case gcc is called for (compiling and) linking, and the final output name is a.* (.out or .exe, depending on the platform), the prefix for dump files is taken to be 'a'. since there could be multiple source files, the source file name is then appended to the prefix to form each compilation's dump file base name. using the randomized temporary output names for each compilation wouldn't make for predictable dump file names, which was a primary motivator for this implementation. enabling separate dump files from multiple compilations of the same source file was another. change can be surprising, but the previous behaviors (they changed over time) were very often undesirable, now (because we have tons of tests for the current behavior) it will hopefully settle down, and will eventually feel intuitive and just "right" :-) thanks for bearing with us,
[Bug tree-optimization/109240] Missed fneg/fsub optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109240 Bug 109240 depends on bug 109230, which changed state. Bug 109230 Summary: [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #19 from Jakub Jelinek --- Fixed.
[Bug ipa/105685] [10/11/12 Regression] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105685 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] Bogus |Bogus |`-Wsuggest-attribute=cold` |`-Wsuggest-attribute=cold` |on function already marked |on function already marked |as `__attribute__((cold))` |as `__attribute__((cold))` | --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug fortran/106856] [12 Regression][OOP] CLASS attribute handling / ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[12/13 Regression][OOP] |[12 Regression][OOP] CLASS |CLASS attribute handling / |attribute handling / ICE in |ICE in |gfc_conv_expr_present, at |gfc_conv_expr_present, at |fortran/trans-expr.cc:1977 |fortran/trans-expr.cc:1977 |since |since |r12-4346-geb92cd57a1ebe7cd |r12-4346-geb92cd57a1ebe7cd | --- Comment #15 from anlauf at gcc dot gnu.org --- Fixed for gcc-13 so far. I'll have a look at whether this is backportable to 12-branch. There is at least a dependency on a part of the fix for pr102331 (r13-4934).
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 --- Comment #18 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:07fc3491260e6b5d261433c977a4e069f5ab40c1 commit r13-6866-g07fc3491260e6b5d261433c977a4e069f5ab40c1 Author: Jakub Jelinek Date: Sun Mar 26 20:17:00 2023 +0200 match.pd: Fix up fneg/fadd simplification [PR109230] The following testcase is miscompiled on aarch64-linux. match.pd has a simplification for addsub, where it negates one of the vectors in twice as large floating point element vector (effectively negating every other element) and then doing addition. But a requirement for that is that the permutation picks the right elements, in particular 0, nelts+1, 2, nelts+3, 4, nelts+5, ... The pattern tests this with sel.series_p (0, 2, 0, 2) check, which as documented verifies that the even elements of the permutation mask are identity, but doesn't say anything about the others. The following patch fixes it by also checking that the odd elements start at nelts + 1 with the same step of 2. 2023-03-26 Jakub Jelinek PR tree-optimization/109230 * match.pd (fneg/fadd simplify): Verify also odd permutation indexes. * gcc.dg/pr109230.c: New test.
[Bug ipa/105685] [10/11/12/13 Regression] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105685 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7eca91d4781bb3df941f25c30b971dac66ba1b3d commit r13-6865-g7eca91d4781bb3df941f25c30b971dac66ba1b3d Author: Jakub Jelinek Date: Sun Mar 26 20:15:05 2023 +0200 predict: Don't emit -Wsuggest-attribute=cold warning for functions which already have that attribute [PR105685] In the following testcase, we predict baz to have cold entry regardless of the user supplied attribute (as it call unconditionally a cold function), but still issue a -Wsuggest-attribute=cold warning despite it having that attribute already. The following patch avoids that. 2023-03-26 Jakub Jelinek PR ipa/105685 * predict.cc (compute_function_frequency): Don't call warn_function_cold if function already has cold attribute. * c-c++-common/cold-2.c: New test.
[Bug target/109285] Unused variable in function __fixunssfdi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109285 Andrew Pinski changed: What|Removed |Added Keywords|internal-improvement| Component|libgcc |target --- Comment #1 from Andrew Pinski --- #if LIBGCC2_HAS_DF_MODE ... #elif FLT_MANT_DIG < W_TYPE_SIZE ... SFtype msb; Which means this code is not well tested at all and most likely only used on this target ...
[Bug target/109286] Assembler warnings about .init/.fini sections defined without attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109286
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-03-26
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from Andrew Pinski ---
crtstuff.c:
CRT_CALL_STATIC_FUNCTION (__LIBGCC_INIT_SECTION_ASM_OP__, frame_dummy)
Then from c-family/c-cppbuiltin.cc:
#ifdef INIT_SECTION_ASM_OP
builtin_define_with_value ("__LIBGCC_INIT_SECTION_ASM_OP__",
INIT_SECTION_ASM_OP, 1);
#endif
>From config/elfos.h:
#define INIT_SECTION_ASM_OP "\t.section\t.init"
#define FINI_SECTION_ASM_OP "\t.section\t.fini"
Most other targets include initfini-array.h which does:
initfini-array.h:#undef INIT_SECTION_ASM_OP
or they do:
frv/frv.h:#define INIT_SECTION_ASM_OP "\t.section .init,\"ax\""
microblaze/microblaze.h:#define INIT_SECTION_ASM_OP
"\t.section\t.init,\"ax\""
rs6000/sysv4.h:#define INIT_SECTION_ASM_OP "\t.section\t\".init\",\"ax\""
h8300 could do the same ...
[Bug preprocessor/105732] [10/11 Regression] internal compiler error: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105732 Jakub Jelinek changed: What|Removed |Added CC||jens.gustedt at inria dot fr --- Comment #24 from Jakub Jelinek --- *** Bug 109284 has been marked as a duplicate of this bug. ***
[Bug preprocessor/109284] __VA_OPT__ triggers internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109284 Jakub Jelinek changed: What|Removed |Added Resolution|--- |DUPLICATE CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jakub Jelinek --- Fixed almost a year ago on all release branches. *** This bug has been marked as a duplicate of bug 105732 ***
[Bug analyzer/109266] Wanalyzer-null-dereference does not warn when struct is at null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266 --- Comment #1 from David Malcolm --- Thanks for filing this bug. We probably want to allow accesses to hard-coded addresses, for the case of embedded development, so we presumably need some way to distinguish between accesses of: ((struct foo *)NULL->field) due to buggy code versus poking specific memory locations. One approach to this might be for the analyzer to complain if it sees a memory access to a "low enough" address: rather than merely complaining about accesses to memory location 0, to have some kind of configurable threshold of pointer values below which to complain, e.g. "complain about accesses to locations 0 through 4095". I dimly recall something similar to this inside the Linux kernel at run time - what memory accesses close to NULL should trigger a crash - but I can't find a reference right now.
[Bug c++/109287] New: Optimizing sal shr pairs when inlining function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109287
Bug ID: 109287
Summary: Optimizing sal shr pairs when inlining function
Product: gcc
Version: 12.2.0
URL: https://gcc.godbolt.org/z/aPTsjc1sM
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: milasudril at gmail dot com
Target Milestone: ---
Target: x86-64_linux_gnu
I was trying to construct a span type to be used for working with a tile-based
image
```
#include
#include
#include
template
class span_2d_tiled
{
public:
using IndexType = size_t;
static constexpr size_t tile_size()
{
return TileSize;
}
constexpr explicit span_2d_tiled(): span_2d_tiled{0u, 0u, nullptr} {}
constexpr explicit span_2d_tiled(IndexType w, IndexType h, T* ptr):
m_tilecount_x{1 + (w - 1)/TileSize},
m_tilecount_y{1 + (h - 1)/TileSize},
m_ptr{ptr}
{}
constexpr auto tilecount_x() const { return m_tilecount_x; }
constexpr auto tilecount_y() const { return m_tilecount_y; }
constexpr T& operator()(IndexType x, IndexType y) const
{
auto const x_tile = x/TileSize;
auto const y_tile = y/TileSize;
auto const x_offset = x%TileSize;
auto const y_offset = y%TileSize;
auto const tile_start = y_tile*m_tilecount_x + x_tile;
return *(m_ptr + tile_start + y_offset*TileSize + x_offset);
}
private:
IndexType m_tilecount_x;
IndexType m_tilecount_y;
T* m_ptr;
};
template
void visit_tiles(size_t x_count, size_t y_count, Func&& f)
{
for(size_t k = 0; k != y_count; ++k)
{
for(size_t l = 0; l != x_count; ++l)
{
for(size_t y = 0; y != TileSize; ++y)
{
for(size_t x = 0; x != TileSize; ++x)
{
f(l*TileSize + x, k*TileSize + y);
}
}
}
}
}
void do_stuff(float);
void call_do_stuff(span_2d_tiled foo)
{
visit_tiles(foo.tilecount_x(),
foo.tilecount_y(), [foo](size_t x, size_t y){
do_stuff(foo(x, y));
});
}
```
Here, the user of this API wants to access individual pixels. Thus, the
coordinates are transformed before calling f. To do so, we multiply by TileSize
and adds the appropriate offset. In the callback, the pixel value is looked up.
But now we must find out what tile it is, and the offset within that tile,
which means that the inverse transformation must be applied. As can be seen in
the Godbolt link, GCC does not fully understand what is going on here. However,
latest clang appears to do a much better job with the same settings. It also
unrolls the inner loop, much better than if I used
```
#pragma GCC unroll 16
```
[Bug libgcc/109286] Assembler warnings about .init/.fini sections defined without attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109286 --- Comment #2 from Jan Dubiec --- $ h8300-elf-as --version GNU assembler (GNU Toolchain for Renesas H8 Family [Built by jdx]) 2.40 Copyright (C) 2023 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `h8300-elf'.
[Bug libgcc/109286] Assembler warnings about .init/.fini sections defined without attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109286 --- Comment #1 from Jan Dubiec --- Created attachment 54758 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54758=edit crtend.S
[Bug libgcc/109286] New: Assembler warnings about .init/.fini sections defined without attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109286 Bug ID: 109286 Summary: Assembler warnings about .init/.fini sections defined without attributes Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: inline-asm, internal-improvement Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: jdx at o2 dot pl Target Milestone: --- Host: x86_64-w64-mingw32 Target: h8300-elf Created attachment 54757 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54757=edit crtbegin.S For every possible libgcc variant (H8/300H, H8S, etc) I get following warnings: /d/Works/xcomp/gcc-build/./gcc/xgcc -B/d/Works/xcomp/gcc-build/./gcc/ -B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem /usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -isystem /d/Works/xcomp/sysroot/h8300-elf/include -ms -O2 -isystem /d/Works/xcomp/sysroot/h8300-elf/include -DIN_GCC -fPIC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/. -I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include -g0 -finhibit-size-directive -fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/. -I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include -o crtbegin.o -MT crtbegin.o -MD -MP -MF crtbegin.dep -c ../../../../../gcc/libgcc/crtstuff.c -DCRT_BEGIN R:\Users\jdx\AppData\Local\Temp\ccvtc9ju.s: Assembler messages: R:\Users\jdx\AppData\Local\Temp\ccvtc9ju.s:101: Warning: new section '.fini' defined without attributes - this might cause problems R:\Users\jdx\AppData\Local\Temp\ccvtc9ju.s:124: Warning: new section '.init' defined without attributes - this might cause problems /d/Works/xcomp/gcc-build/./gcc/xgcc -B/d/Works/xcomp/gcc-build/./gcc/ -B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem /usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -isystem /d/Works/xcomp/sysroot/h8300-elf/include -ms -O2 -isystem /d/Works/xcomp/sysroot/h8300-elf/include -DIN_GCC -fPIC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/. -I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include -g0 -finhibit-size-directive -fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/. -I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include -o crtend.o -MT crtend.o -MD -MP -MF crtend.dep -c ../../../../../gcc/libgcc/crtstuff.c -DCRT_END R:\Users\jdx\AppData\Local\Temp\ccbb20TH.s: Assembler messages: R:\Users\jdx\AppData\Local\Temp\ccbb20TH.s:48: Warning: new section '.init' defined without attributes - this might cause problems In the attachement there are crtbegin.S and crtend.S created "manually" with /d/Works/xcomp/gcc-build/./gcc/xgcc -B/d/Works/xcomp/gcc-build/./gcc/ -B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem /usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -isystem /d/Works/xcomp/sysroot/h8300-elf/include -ms -O2 -isystem /d/Works/xcomp/sysroot/h8300-elf/include -DIN_GCC -fPIC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/. -I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include -g0 -finhibit-size-directive -fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/. -I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include -S -o crtbegin.S -MT crtbegin.o -MD -MP -MF crtbegin.dep ../../../../../gcc/libgcc/crtstuff.c -DCRT_BEGIN and /d/Works/xcomp/gcc-build/./gcc/xgcc -B/d/Works/xcomp/gcc-build/./gcc/ -B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem /usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -isystem /d/Works/xcomp/sysroot/h8300-elf/include -ms -O2 -isystem
[Bug libgcc/109285] New: Unused variable in function __fixunssfdi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109285 Bug ID: 109285 Summary: Unused variable in function __fixunssfdi Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: jdx at o2 dot pl Target Milestone: --- Host: x86_64-w64-mingw32 Target: h8300-elf Created attachment 54756 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54756=edit Proposed patch I get the following warning when I build master (but it also applies to 12.2): [...] /d/Works/xcomp/gcc-build/./gcc/xgcc -B/d/Works/xcomp/gcc-build/./gcc/ -B/usr/local/h8300-elf/bin/ -B/usr/local/h8300-elf/lib/ -isystem /usr/local/h8300-elf/include -isystem /usr/local/h8300-elf/sys-include -isystem /d/Works/xcomp/sysroot/h8300-elf/include -ms -O2 -isystem /d/Works/xcomp/sysroot/h8300-elf/include -DIN_GCC -fPIC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -DDF=SF -I. -I. -I../../.././gcc -I../../../../../gcc/libgcc -I../../../../../gcc/libgcc/. -I../../../../../gcc/libgcc/../gcc -I../../../../../gcc/libgcc/../include -o _fixunssfdi.o -MT _fixunssfdi.o -MD -MP -MF _fixunssfdi.dep -DL_fixunssfdi -c ../../../../../gcc/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS d:\works\gcc\libgcc\libgcc2.c: In function '__fixunssfdi': d:\works\gcc\libgcc\libgcc2.c:1459:14: warning: unused variable 'msb' [-Wunused-variable] 1459 | SFtype msb; | ^~~
[Bug c/109284] New: __VA_OPT__ triggers internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109284 Bug ID: 109284 Summary: __VA_OPT__ triggers internal compiler error Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jens.gustedt at inria dot fr Target Milestone: --- Created attachment 54755 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54755=edit simple pre-pro only file that crashes gcc-12 Hi, the attached code, meant to provide a feature test for `__VA_OPT__`, crashes my compiler: gcc-12-va-opt-bug.c:15:1: internal compiler error: unspellable token PADDING I am on an standard Ubuntu, nothing fancy: gcc version 12.1.0 (Ubuntu 12.1.0-2ubuntu1~22.04) Jens
