[Bug middle-end/108920] Condition falsely optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108920 Agner Fog changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Agner Fog --- I am not sure I have identified the problem correctly, but there is no need to spend more time on it since the problem disappears with version 9.4.0. You may close this issue.
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846 --- Comment #13 from Jonathan Wakely --- That specialization is only used for trivial types, so moving is equivalent to copying (otherwise we couldn't use memmove anyway). So it doesn't make any difference whether you move an lvalue or rvalue, it's just a bitwise copy anyway.
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846 --- Comment #14 from Jonathan Wakely --- s/move an lvalue or rvalue/assign from an lvalue or rvalue/
[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- > But my attached testcase tests that all the corner cases do have both > the same result value and the same exceptions generated. It seems you forgot to attach that testcase (bench.cpp does not cover corner cases). I guess Uros' claim was based on what Intel and AMD manuals specify rather than observed behavior of CPUs.
[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #4 from Alexander Monakov ---
Plus, Glibc does use fprem/fprem1 for fmodl/remainderl on x86_64, as well as
for {fmod,remainder,remquo}{,f,l} on i386 without any branches for corner
cases. So in practice CPUs apparently implement the expected behavior even
though the manual doesn't promise so.
The ieee_2.f90 testcase attempts to change rounding mode. It 2014 it probably
just was "miscompiled".
[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922 --- Comment #5 from Uroš Bizjak --- (In reply to Alexander Monakov from comment #3) > I guess Uros' claim was based on what Intel and AMD manuals specify rather > than observed behavior of CPUs. As a "committer", I really don't remember the reason to disable the patterns, but there is some analysis in the corresponding e-mail.
[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922 --- Comment #6 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #5) > (In reply to Alexander Monakov from comment #3) > > I guess Uros' claim was based on what Intel and AMD manuals specify rather > > than observed behavior of CPUs. > > As a "committer", I really don't remember the reason to disable the > patterns, but there is some analysis in the corresponding e-mail. Please see Table 3-31 (and Table 3-32) in SDM [1]. If 'x' (AKA st(0)) is infinity, no return is specified, since invalid arith operand exception is generated. In the above case, the SDM declares output as *undefined*, but c99 specifies NaN. [1] https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922 --- Comment #7 from Alexander Monakov --- I saw that. That's why I'm pointing out that Glibc (and musl) uses the instruction without any additional checks: real CPUs produce the expected result in st(0), despite the documentation making no promise about the content of st(0)).
[Bug fortran/108621] [12/13 regression]: bind(c) pointer array spurious maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621
--- Comment #6 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:d3e427f684b0cd7cedbe7b93a06f455e562c5901
commit r13-6341-gd3e427f684b0cd7cedbe7b93a06f455e562c5901
Author: Tobias Burnus
Date: Sat Feb 25 11:55:08 2023 +0100
Fortran: Skip bound conv in gfc_conv_gfc_desc_to_cfi_desc with intent(out)
ptr [PR108621]
When the dummy argument of the bind(C) proc is 'pointer, intent(out)', the
conversion
of the GFC to the CFI bounds can be skipped: it is not needed and avoids
issues with
noninit memory.
Note that the 'cfi->base_addr = gfc->addr' assignment is kept as the C code
of a user
might assume that a nullified pointer arrives as NULL (or even a specific
value).
For instance, gfortran.dg/c-interop/section-{1,2}.f90 assumes the value
NULL.
Note 2: The PR is about a may-be-uninitialized warning with intent(out). In
the PR's
testcase, the pointer was nullified and should not have produced that
warning.
That is a diagnostic issue, now tracked as PR middle-end/108906 as the
issue in principle
still exists (e.g. with 'intent(inout)'). [But no longer for intent(out).]
Note 3: With undefined pointers and no 'intent', accessing uninit memory is
unavoidable
on the caller side as the compiler cannot know what the C function does
(but this usage
determines whether the pointer is permitted be undefined or whether the
bounds must be
gfc-to-cfi converted).
gcc/fortran/ChangeLog:
PR fortran/108621
* trans-expr.cc (gfc_conv_gfc_desc_to_cfi_desc): Skip setting of
bounds of CFI desc for 'pointer,intent(out)'.
gcc/testsuite/ChangeLog:
PR fortran/108621
* gfortran.dg/c-interop/fc-descriptor-pr108621.f90: New test.
[Bug tree-optimization/108906] Bogus may be used uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108906
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:d3e427f684b0cd7cedbe7b93a06f455e562c5901
commit r13-6341-gd3e427f684b0cd7cedbe7b93a06f455e562c5901
Author: Tobias Burnus
Date: Sat Feb 25 11:55:08 2023 +0100
Fortran: Skip bound conv in gfc_conv_gfc_desc_to_cfi_desc with intent(out)
ptr [PR108621]
When the dummy argument of the bind(C) proc is 'pointer, intent(out)', the
conversion
of the GFC to the CFI bounds can be skipped: it is not needed and avoids
issues with
noninit memory.
Note that the 'cfi->base_addr = gfc->addr' assignment is kept as the C code
of a user
might assume that a nullified pointer arrives as NULL (or even a specific
value).
For instance, gfortran.dg/c-interop/section-{1,2}.f90 assumes the value
NULL.
Note 2: The PR is about a may-be-uninitialized warning with intent(out). In
the PR's
testcase, the pointer was nullified and should not have produced that
warning.
That is a diagnostic issue, now tracked as PR middle-end/108906 as the
issue in principle
still exists (e.g. with 'intent(inout)'). [But no longer for intent(out).]
Note 3: With undefined pointers and no 'intent', accessing uninit memory is
unavoidable
on the caller side as the compiler cannot know what the C function does
(but this usage
determines whether the pointer is permitted be undefined or whether the
bounds must be
gfc-to-cfi converted).
gcc/fortran/ChangeLog:
PR fortran/108621
* trans-expr.cc (gfc_conv_gfc_desc_to_cfi_desc): Skip setting of
bounds of CFI desc for 'pointer,intent(out)'.
gcc/testsuite/ChangeLog:
PR fortran/108621
* gfortran.dg/c-interop/fc-descriptor-pr108621.f90: New test.
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #15 from Giuseppe D'Angelo ---
That's not what I meant; a type can be trivial(ly copyable) and move-only.
Here's a modification of Arthur's example:
// move-only
struct B {
B(int i, short j) : i(i), j(j) {}
B(B &&) = default;
B &operator=(B &&) = default;
int i;
short j;
};
struct D : B {
D(int i, short j, short x) : B(i, j), x(x) {}
D(D &&) = default;
D &operator=(D &&) = default;
short x;
};
int main() {
D ddst(1, 2, 3);
D dsrc(4, 5, 6);
B *dst = &ddst;
B *src = &dsrc;
static_assert(std::is_trivially_copyable_v);
std::move(src, src+1, dst);
assert(ddst.x == 3);
}
The call to std::move ends up in the same memmove codepath as std::copy_n (B is
trivially copyable), but with the proposed patch it will fail to compile
because it's not actually copy assignable.
[Bug c/108931] New: conditional operator for variably modified types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108931
Bug ID: 108931
Summary: conditional operator for variably modified types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
Created attachment 54536
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54536&action=edit
patch against trunk
For conditional operators with size expressions in both branches, the behavior
is erratic. While this seems to be undefined behavior (although it shouldn't
be), it is surprising and my cause subtle bugs, e.g. when using such casts or
statement expressions in macros. Also it seems easy to fix by always evaluating
the size of the active branch only and taking this size for the result.
For example, in some cases size expressions from both branches are evaluated:
int foo(void)
{
return sizeof(*(0 ? (char(*)[f()])0
: (char(*)[g()])0));
}
foo:
sub rsp, 8
callg
callf
add rsp, 8
ret
In other cases size from an unevaluated branch is taken as the result:
https://godbolt.org/z/o74e7T16x
[Bug target/108919] pure nested function may clobber its static chain pointer in windowed ABI on xtensa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108919 --- Comment #1 from CVS Commits --- The master branch has been updated by Max Filippov : https://gcc.gnu.org/g:461d3c84a0e5ad045ee54631901cc953d6befa20 commit r13-6342-g461d3c84a0e5ad045ee54631901cc953d6befa20 Author: Max Filippov Date: Wed Feb 22 14:17:11 2023 -0800 gcc: xtensa: fix PR target/108919 gcc/ PR target/108919 * config/xtensa/xtensa-protos.h (xtensa_prepare_expand_call): Rename to xtensa_expand_call. * config/xtensa/xtensa.cc (xtensa_prepare_expand_call): Rename to xtensa_expand_call. (xtensa_expand_call): Emit the call and add a clobber expression for the static chain to it in case of windowed ABI. * config/xtensa/xtensa.md (call, call_value, sibcall) (sibcall_value): Call xtensa_expand_call and complete expansion right after that call. gcc/testsuite/ * gcc.target/xtensa/pr108919.c: New test.
[Bug target/108919] pure nested function may clobber its static chain pointer in windowed ABI on xtensa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108919 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from jcmvbkbc at gcc dot gnu.org --- Fix is committed to the master.
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #16 from Jonathan Wakely ---
Ah gotcha.
So then something like this (untested):
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -422,16 +422,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
static _Tp*
__copy_m(const _Tp* __first, const _Tp* __last, _Tp* __result)
{
-#if __cplusplus >= 201103L
- using __assignable = __conditional_t<_IsMove,
- is_move_assignable<_Tp>,
- is_copy_assignable<_Tp>>;
- // trivial types can have deleted assignment
- static_assert( __assignable::value, "type must be assignable" );
-#endif
const ptrdiff_t _Num = __last - __first;
- if (_Num)
+ if (__builtin_expect(_Num > 1, true))
__builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
+ else if (_Num == 1)
+ return std::__copy_move<_IsMove, false,
+ random_access_iterator_tag>::
+__copy_m(__first, __last, __result);
return __result + _Num;
}
};
@@ -737,16 +734,13 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
static _Tp*
__copy_move_b(const _Tp* __first, const _Tp* __last, _Tp* __result)
{
-#if __cplusplus >= 201103L
- using __assignable = __conditional_t<_IsMove,
- is_move_assignable<_Tp>,
- is_copy_assignable<_Tp>>;
- // trivial types can have deleted assignment
- static_assert( __assignable::value, "type must be assignable" );
-#endif
const ptrdiff_t _Num = __last - __first;
- if (_Num)
+ if (__builtin_expect(_Num > 1, true))
__builtin_memmove(__result - _Num, __first, sizeof(_Tp) * _Num);
+ else if (_Num == 1)
+ return std::__copy_move_backward<_IsMove, false,
+random_access_iterator_tag>::
+__copy_move_b(__first, __last, __result);
return __result - _Num;
}
};
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #4 from Costas Argyris ---
Using the manifest approach described in:
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page
it is possible to convert a full existing gcc + mingw-w64 toolchain (all
executables) to use UTF-8 as their active code page.
The proper solution would be to integrate the UTF-8 manifest into gcc's own
build process.Until that happens, and to enable existing installations to
work with Unicode paths, this is the procedure to convert an existing gcc
(mingw-w64) installation on Windows to use the UTF-8 code page.
Requirements:
1) See above link to check if your version of Windows supports this.
2) You must have the manifest tool mt.exe installed and know its location.
3) Go to a temp dir and create a 'utf8_acp_setting.manifest' file with this
content:
http://schemas.microsoft.com/SMI/2019/WindowsSettings";>UTF-8
Assume that the current installation is at C:\mingw64.We are going to
create a copy of it in C:\mingw64-UTF8 and apply the UTF-8 manifest in every
executable using mt.exe.
Add the folder of mt.exe to the path, for example
set PATH=C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64;%PATH%
('where mt' should find it)
Copy the entire C:\mingw64 directory to C:\mingw64-UTF8 from the UI or using
robocopy C:\mingw64 C:\mingw64-UTF8 /e
Cd into the folder where utf8_acp_setting.manifest is and run:
for /F %f in ('dir /B /S C:\mingw64-UTF8\*.exe') do mt "-outputresource:%f;1"
-manifest "utf8_acp_setting.manifest"
After this, the toolchain under C:\mingw64-UTF8 should be able to compile the
file that was previously failing.
Make sure that you add C:\mingw64-UTF8\bin to the path instead of
C:\mingw64\bin
set PATH=C:\mingw64-UTF8\bin;%PATH%
and check with 'where gcc' - it should return the one under C:\mingw64-UTF8\bin
Now compile the file in the Unicode path that was previously failing:
C:\Users\cargyris\temp>gcc ﹏\src.c
C:\Users\cargyris\temp>echo %errorlevel%
0
no errors this time.
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846 --- Comment #17 from Jonathan Wakely --- We need to change the arguments too, as that specialization takes a const _Tp* as the input range.
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846 --- Comment #18 from Jonathan Wakely --- Created attachment 54537 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54537&action=edit libstdc++: Do not use memmove for 1-element ranges [PR108846] This is a more complete patch that passes Arthur's test in comment 0.
[Bug preprocessor/108900] [libcpp] cpp gives wrong line number information with a file huge number of lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900
--- Comment #1 from Libin Dang ---
For this test case, `-fdump-internal-locations' gives:
...
header3.h:327614|loc:1342177760|#include "header2.h"
|7778
|78889990001112223334
|92582581481470470360
|24680246802468024680
ORDINARY MAP: 10
location_t interval: 1342178464 <= loc < 1342178464
file: header3.h
starting at line: 327615
column and range bits: 7
column bits: 7
range bits: 0
reason: 2 (LC_RENAME)
included from location: 270816 (in ordinary map 8)
ORDINARY MAP: 11
location_t interval: 1342178464 <= loc < 1342178496
file: header2.h
starting at line: 1
column and range bits: 7
column bits: 7
range bits: 0
reason: 0 (LC_ENTER)
included from location: 1342178336 (in ordinary map 9)
header2.h: 1|loc:1342178464|
|
|
|
|
ORDINARY MAP: 12
location_t interval: 1342178496 <= loc < 1342178528
file: header3.h
starting at line: 327614
column and range bits: 7
column bits: 7
range bits: 0
reason: 1 (LC_LEAVE)
included from location: 270816 (in ordinary map 8)
header3.h:327614|loc:1342178496|#include "header2.h"
|
|4445
|99900111
|78901234567890123456
...
Map 10 has `location_t interval: 1342178464 <= loc < 1342178464', this does not
look right. And Map 12 suppose to have location information for `header3 ends'
instead of `#include "header2.h"'.
Both the following changes can fix this issue (at least for this test case):
diff --git a/libcpp/line-map.c b/libcpp/line-map.c
index 8a390d0..991170e 100644
--- a/libcpp/line-map.c
+++ b/libcpp/line-map.c
@@ -524,6 +524,10 @@ linemap_add (line_maps *set, enum lc_reason reason,
/* A TO_FILE of NULL is special - we use the natural values. */
if (to_file == NULL)
{
+ /* Adjust for LC_RENAME in some special cases */
+ while (from->to_file == from[1].to_file && from->included_from ==
from[1].included_from)
+++from;
+
diff --git a/libcpp/line-map.cc b/libcpp/line-map.cc
index 62077c3857c0..452016f377c9 100644
--- a/libcpp/line-map.cc
+++ b/libcpp/line-map.cc
@@ -775,8 +775,6 @@ linemap_line_start (line_maps *set, linenum_type to_line,
&& line_delta * map->m_column_and_range_bits > 1000)
|| (max_column_hint >= (1U << effective_column_bits))
|| (max_column_hint <= 80 && effective_column_bits >= 10)
- || (highest > LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES
- && map->m_range_bits > 0)
|| (highest > LINE_MAP_MAX_LOCATION_WITH_COLS
&& (set->max_column_hint || highest >= LINE_MAP_MAX_LOCATION)))
add_map = true;
However, neither of them looks right.
[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261 --- Comment #27 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:05652ac4e8b8685fe0c0f4ee2f75516d28bbf892 commit r13-6343-g05652ac4e8b8685fe0c0f4ee2f75516d28bbf892 Author: Gaius Mulley Date: Sat Feb 25 16:28:19 2023 + modula-2 module registration process seems to fail with shared libraries [PR108261] The commit adds pathnames to modula-2 which in turn appears in any external symbol. This is necessary to allow different dialects of libraries to coexist (different implementations of SYSTEM and Storage for example in libm2pim and libm2iso). It also makes it easier to debug as the library name forms part of the external mangled name. By default pathnames are not user facing. This commit fixes PR108261. gcc/ChangeLog: PR modula2/108261 * doc/gm2.texi (-fm2-pathname): New option documented. (-fm2-pathnameI): New option documented. (-fm2-prefix=): New option documented. (-fruntime-modules=): Update default module list. gcc/m2/ChangeLog: PR modula2/108261 * Make-lang.in (GM2-COMP-BOOT-DEFS): DynamicStringPath.def remove. DynamicPath.def add. (GM2-COMP-BOOT-MODS): DynamicStringPath.mod remove. DynamicPath.mod add. * Make-maintainer.in (BUILD-BOOT-PPG-H): New dependency. (m2/gm2-ppg-boot/$(SRC_PREFIX)%.o): $(BUILD-BOOT-PPG-H) Add dependency. (PGE-DEF): New definition. (BUILD-BOOT-PG-H): New dependency. (m2/gm2-pg-boot/$(SRC_PREFIX)%.o): $(BUILD-BOOT-PG-H) Add dependency. (BUILD-BOOT-PGE-H): New dependency. (m2/gm2-pge-boot/$(SRC_PREFIX)%.o): $(BUILD-BOOT-PGE-H) Add dependency. (GM2PATH): Add pathname entries. (m2/boot-bin/mc-devel$(exeext)): Add m2/mc-boot-ch/Gm2rtsdummy.o dependency. (m2/boot-bin/mc-opt$(exeext)): Fix -I path. * gm2-compiler/DynamicStringPath.def: Renamed module to DynamicPath. (GetUserPath): Remove. (GetSystemPath): Remove. (SetUserPath): Remove. (SetSystemPath): Remove. (DumpPath): New procedure definition. * gm2-compiler/DynamicStringPath.mod: Renamed module to DynamicPath. (GetUserPath): Remove. (GetSystemPath): Remove. (SetUserPath): Remove. (SetSystemPath): Remove. (DumpPath): Remove Debugging conditional. * gm2-compiler/M2AsmUtil.mod: Import EqualArray, NulName and GetLibName. (Debugging): New declaration. (GetFullSymName): Re-implemented to prefix (mange) libname to any extern variable/procedure which is IsExportQualified. * gm2-compiler/M2Comp.mod (qprintLibName): New procedure. * gm2-compiler/M2Graph.mod (resolveImports): Add libname. * gm2-compiler/M2Options.def (SetM2Prefix): New procedure. (GetM2Prefix): New procedure function. (SetM2PathName): New procedure. (GetM2PathName): New procedure function. * gm2-compiler/M2Options.mod: (SetM2Prefix): New procedure implemented. (GetM2Prefix): New procedure function implemented. (SetM2PathName): New procedure implemented. (GetM2PathName): New procedure function implemented. (RuntimeModuleOverride): Set to DefaultRuntimeModuleOverride. * gm2-compiler/M2Quads.mod: Import GetLibName. (SafeRequestSym) Pass result of GetLibName to RequestDependant. (callRequestDependant): Add libname as a parameter. (BuildM2InitFunction): Add libname as a parameter. (BuildM2FiniFunction): Add libname as a parameter. (BuildM2CtorFunction): Add libname as a parameter. * gm2-compiler/M2Scaffold.mod (LookupModuleSym): Set LibName if a definition source was found. * gm2-compiler/M2Search.def (FindSourceFile): Add named library parameter. (FindSourceDefFile): Add named library parameter. (FindSourceModFile): Add named library parameter. * gm2-compiler/M2Search.mod (FindSourceFile): Reimplement. (FindSourceDefFile): Add named library parameter. (FindSourceModFile): Add named library parameter. * gm2-compiler/SymbolTable.def (MakeProcedureCtorExtern): Add libname parameter. (PutLibName): New procedure. (GetLibName): New procedure function. * gm2-compiler/SymbolTable.mod (MakeProcedureCtorExtern): Add libname parameter. (GenName): Add libname parameter. (InitCtorFields): Add moduleSym as a parameter. (PutCtorExt
[Bug c++/101886] [11/12 Regression][concepts TS] ICE with auto as template argument since r11-7011-g6e0a231a4aa2407b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101886 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|11.4|13.0 Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- Fixed for GCC 13, this doesn't seem worth backporting since the bug is Concepts TS specific.
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-02-25 --- Comment #5 from Andrew Pinski --- .
[Bug driver/108932] New: amd64-pc-solaris2.11:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108932 Bug ID: 108932 Summary: amd64-pc-solaris2.11: Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: jbg...@lug-owl.de Target Milestone: --- Building with --target=amd64-pc-solaris2.11, with Binutils for that target available: ../gcc/configure '--with-pkgversion=basepoints/gcc-13-6140-g63471c50088, built at 1676969143' --prefix=/var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-install --enable-werror-always --enable-languages=all --disable-gcov --disable-shared --disable-threads --target=amd64-pc-solaris2.11 --without-headers [cfg 2023-02-21 08:46:00] checking for as... /var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-install/amd64-pc-solaris2.11/bin/as [...] [cfg 2023-02-21 08:46:00] checking where to find the target as... pre-installed in /var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-install/amd64-pc-solaris2.11/bin [...] make V=1 all-gcc [...] [all 2023-02-21 12:45:52] test -d /var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/gcc/m2/gm2-libs || /bin/bash ../../gcc/gcc/../mkinstalldirs /var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/gcc/m2/gm2-libs [all 2023-02-21 12:45:52] echo "GM2_FOR_TARGET /var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/./gcc/gm2 -B/var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/./gcc/ " [all 2023-02-21 12:45:52] GM2_FOR_TARGET /var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/./gcc/gm2 -B/var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/./gcc/ [all 2023-02-21 12:45:52] echo "GCC_FOR_TARGET /var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/./gcc/xgcc -B/var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/./gcc/ " [all 2023-02-21 12:45:52] GCC_FOR_TARGET /var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/./gcc/xgcc -B/var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/./gcc/ [all 2023-02-21 12:45:52] /bin/bash ../../gcc/gcc/m2/tools-src/makeSystem -fpim \ [all 2023-02-21 12:45:52] ../../gcc/gcc/m2/gm2-libs/SYSTEM.def \ [all 2023-02-21 12:45:52] ../../gcc/gcc/m2/gm2-libs/SYSTEM.mod \ [all 2023-02-21 12:45:52] -I../../gcc/gcc/m2/gm2-libs \ [all 2023-02-21 12:45:52] "/var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/./gcc/gm2 -B/var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/./gcc/ " /var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/gcc/m2/gm2-libs/SYSTEM.def [all 2023-02-21 12:45:52] /var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-install/amd64-pc-solaris2.11/bin/as: unrecognized option '-xarch=generic64' [all 2023-02-21 12:45:52] SYSTEM module creates type: LOC [all 2023-02-21 12:45:52] SYSTEM module creates type: WORD [all 2023-02-21 12:45:52] SYSTEM module creates type: BYTE [all 2023-02-21 12:45:52] SYSTEM module creates type: ADDRESS [all 2023-02-21 12:45:52] SYSTEM module creates type: INTEGER8 [all 2023-02-21 12:45:52] SYSTEM module creates type: INTEGER16 [all 2023-02-21 12:45:52] SYSTEM module creates type: INTEGER32 [all 2023-02-21 12:45:52] SYSTEM module creates type: INTEGER64 [all 2023-02-21 12:45:52] SYSTEM module creates type: CARDINAL8 [all 2023-02-21 12:45:52] SYSTEM module creates type: CARDINAL16 [all 2023-02-21 12:45:52] SYSTEM module creates type: CARDINAL32 [all 2023-02-21 12:45:52] SYSTEM module creates type: CARDINAL64 [all 2023-02-21 12:45:52] SYSTEM module creates type: WORD16 [all 2023-02-21 12:45:52] SYSTEM module creates type: WORD32 [all 2023-02-21 12:45:52] SYSTEM module creates type: WORD64 [all 2023-02-21 12:45:52] SYSTEM module creates type: BITSET8 [all 2023-02-21 12:45:52] SYSTEM module creates type: BITSET16 [all 2023-02-21 12:45:52] SYSTEM module creates type: BITSET32 [all 2023-02-21 12:45:52] SYSTEM module creates type: REAL32 [all 2023-02-21 12:45:52] SYSTEM module creates type: REAL64 [all 2023-02-21 12:45:52] SYSTEM module creates type: REAL128 [all 2023-02-21 12:45:52] SYSTEM module creates type: COMPLEX32 [all 2023-02-21 12:45:52] SYSTEM module creates type: COMPLEX64 [all 2023-02-21 12:45:52] SYSTEM module creates type: COMPLEX128 [all 2023-02-21 12:45:52] SYSTEM module creates type: CSIZE_T [all 2023-02-21 12:45:52] SYSTEM module creates type: CSSIZE_T [all 2023-02-21 12:45:52] /var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-install/amd64-pc-solaris2.11/bin/as: unrecognized option '-xarch=generic64' [all 2023-02-21 12:45:52] make[1]: *** [../../gcc/gcc/m2/Make-lang.in:1564: /var/lib/laminar/run/gcc-amd64-pc-solaris2.11/6/toolchain-build/gcc/m2/gm2-libs/SYSTEM.def] Error 1 [all 2023-02-21 12:45:53] rm m2/gm2-compiler-boot/P2Build.mod m2/gm2-compiler-boot/P0SyntaxCheck.mod m2/gm2-compiler-boot/PCBuild.mod m2/g
[Bug driver/108932] amd64-pc-solaris2.11:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108932
--- Comment #1 from Andrew Pinski ---
if test x$gnu_ld = xyes; then
tm_file="usegld.h ${tm_file}"
fi
if test x$gas = xyes; then
tm_file="usegas.h ${tm_file}"
fi
[Bug tree-optimization/106900] Regression after memchr optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900 Jan-Benedict Glaw changed: What|Removed |Added Target||avr-elf, pru-elf, rl78-elf --- Comment #3 from Jan-Benedict Glaw --- Sure, just a warning, but still there (as of 31303c9b5bab200754cdb7ef8cd91ae4918f3018) and affecting three targets. Maybe we get that understood/fixed?
[Bug driver/108932] amd64-pc-solaris2.11:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108932 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- For building with GAS for the solaris targets, you need --with-gas option passed to configure.
[Bug target/108933] New: [10/11/12/13 Regression] Missing bswap detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933
Bug ID: 108933
Summary: [10/11/12/13 Regression] Missing bswap detection
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org, unassigned at gcc dot gnu.org
Depends on: 108874
Blocks: 94094
Target Milestone: ---
Target: arm
This is the arm version of this bug.
+++ This bug was initially created as a clone of Bug #108874 +++
If we look at the arm testcases in gcc.target/arm/rev16.c
typedef unsigned int __u32;
__u32
__rev16_32_alt (__u32 x)
{
return (((__u32)(x) & (__u32)0xff00ff00UL) >> 8)
| (((__u32)(x) & (__u32)0x00ff00ffUL) << 8);
}
__u32
__rev16_32 (__u32 x)
{
return (((__u32)(x) & (__u32)0x00ff00ffUL) << 8)
| (((__u32)(x) & (__u32)0xff00ff00UL) >> 8);
}
we should be able to generate rev16 instructions for aarch64 (and arm) i.e.
recognise a __builtin_bswap16 essentially.
GCC fails to do so and generates:
__rev16_32_alt:
lsr w1, w0, 8
lsl w0, w0, 8
and w1, w1, 16711935
and w0, w0, -16711936
orr w0, w1, w0
ret
__rev16_32:
lsl w1, w0, 8
lsr w0, w0, 8
and w1, w1, -16711936
and w0, w0, 16711935
orr w0, w1, w0
ret
whereas clang manages to recognise it all into:
__rev16_32_alt: // @__rev16_32_alt
rev16 w0, w0
ret
__rev16_32: // @__rev16_32
rev16 w0, w0
ret
does the bswap pass need some tweaking perhaps?
Looks like this worked fine with GCC 5 but broke in the GCC 6 timeframe so
marking as a regression
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94094
[Bug 94094] [meta-bug] store-merging and/or bswap load/store-merging missed
optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108874
[Bug 108874] [10/11/12/13 Regression] Missing bswap detection
[Bug target/108874] [10/11/12/13 Regression] Missing bswap detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108874 Andrew Pinski changed: What|Removed |Added Target|arm, aarch64|aarch64 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Andrew Pinski --- I split out the arm version to PR 108933 since I am going to implement the aarch64 backend change I recommended in comment #5 .
[Bug target/108933] [10/11/12/13 Regression] Missing bswap detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5
[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923 --- Comment #6 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:5c638095e7e0fa4de4e4f7326384a86830b25732 commit r13-6346-g5c638095e7e0fa4de4e4f7326384a86830b25732 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.
[Bug middle-end/55658] bitfields and __attribute__((packed)) generate horrible code on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55658 --- Comment #6 from Andrew Pinski --- /* ??? For historical reasons, reject modes that would normally receive greater alignment, even if unaligned accesses are acceptable. This has both advantages and disadvantages. Removing this check means that something like:
[Bug middle-end/55658] bitfields and __attribute__((packed)) generate horrible code on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55658
--- Comment #7 from Andrew Pinski ---
diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc
index 45bf2d18639..b44335dd406 100644
--- a/gcc/stor-layout.cc
+++ b/gcc/stor-layout.cc
@@ -3089,7 +3089,8 @@ get_best_mode (int bitsize, int bitpos,
causes store_bit_field to keep a 128-bit memory reference,
so that the final bitfield reference still has a MEM_EXPR
and MEM_OFFSET. */
-&& GET_MODE_ALIGNMENT (mode) <= align
+&& (GET_MODE_ALIGNMENT (mode) <= align
+|| (!STRICT_ALIGNMENT && currently_expanding_to_rtl))
&& GET_MODE_BITSIZE (mode) <= largest_mode_bitsize)
{
*best_mode = mode;
Should fix it, I still need to update the comment since it does say the check
should be disable while expanding and that is what the above does ...
To get rid of the check the rest of the way is remove part of fold which does
the comparison combing which I think might be too early to that ...
[Bug c++/108934] New: bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Bug ID: 108934
Summary: bit_cast'ing to long double errors out with "the
argument cannot be interpreted" since gcc-12
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janpmoeller at gmx dot de
Target Milestone: ---
In gcc-trunk, gcc-12.2 and gcc-12.1, the following code fails to compile, while
gcc-11.3 accepts it:
/
#include
#include
#include
using uint64_x_2_t = std::array;
using uint32_x_2_t = std::array;
using uint16_x_2_t = std::array;
static_assert(sizeof(long double) == sizeof(uint64_x_2_t));
static_assert(sizeof(double) == sizeof(uint32_x_2_t));
static_assert(sizeof(float) == sizeof(uint16_x_2_t));
constexpr long double testld = 42.42;
constexpr double testd = 42.42;
constexpr float testf = 42.42f;
constexpr uint64_x_2_t test_uint64_x_2_t{1u, 2u};
constexpr uint32_x_2_t test_uint32_x_2_t{1u, 2u};
constexpr uint16_x_2_t test_uint16_x_2_t{1u, 2u};
constexpr auto ld_to_uint64_x_2_t = std::bit_cast(testld); //
works! (reverse direction)
constexpr auto d_to_uint32_x_2_t = std::bit_cast(testd);
constexpr auto f_to_uint16_x_2_t = std::bit_cast(testf);
constexpr auto default_uint64_x_2_t_to_ld = std::bit_cast(uint64_x_2_t{}); // works! (default initialized)
constexpr auto default_uint32_x_2_t_to_d =
std::bit_cast(uint32_x_2_t{});
constexpr auto default_uint16_x_2_t_to_f =
std::bit_cast(uint16_x_2_t{});
constexpr auto temp_uint64_x_2_t_to_ld = std::bit_cast(uint64_x_2_t{1u, 2u}); // <= fails
constexpr auto temp_uint32_x_2_t_to_d = std::bit_cast(uint32_x_2_t{1u,
2u});
constexpr auto temp_uint16_x_2_t_to_f = std::bit_cast(uint16_x_2_t{1u,
2u});
constexpr auto uint64_x_2_t_to_ld = std::bit_cast(test_uint64_x_2_t); // <= fails
constexpr auto uint32_x_2_t_to_d = std::bit_cast(test_uint32_x_2_t);
constexpr auto uint16_x_2_t_to_f = std::bit_cast(test_uint16_x_2_t);
/
The compile error for both offending lines is:
/usr/include/c++/12/bit:87:33: sorry, unimplemented: ‘__builtin_bit_cast’
cannot be constant evaluated because the argument cannot be interpreted
The strange thing is that this error only seems to appear if the array is
aggregate-initialized; default initialized arrays do not trigger the error.
float and double do not trigger the error either. Replacing std::array with a
struct aggregate type behaves the same as the array example above.
The reverse direction, i.e. bit_cast'ing from long double to array, seems to be
working fine.
The above example on compiler explorer: https://godbolt.org/z/ba5d6hEG1
[Bug c++/108934] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934 --- Comment #1 from Andrew Pinski --- r12-7240-g2801f23fb82a5e (aka PR 104522) is what changed the behavior but I am not 100% sure the resulting code in GCC 11 was correct ...
[Bug c++/108934] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934 --- Comment #2 from Andrew Pinski --- Note long double on x86_64 has padding bits which almost likely you are running into here ...
[Bug c++/108934] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Andrew Pinski changed:
What|Removed |Added
Target||x86_64
--- Comment #3 from Andrew Pinski ---
That is doing {0u, 0u} works too.
And even {1u, 0u}; does too.
[Bug c++/108934] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934 --- Comment #4 from Andrew Pinski --- Yes GCC 11.x produces wrong code too, remove constexpr from uint64_x_2_t_to_ld and temp_uint64_x_2_t_to_ld to see that: uint64_x_2_t_to_ld: .long 1 .long 0 .long 0 .long 0 temp_uint64_x_2_t_to_ld: .long 1 .long 0 .long 0 .long 0
[Bug c++/108893] attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893 --- Comment #8 from Jonny Grant --- (In reply to Andrew Pinski from comment #7) > access attribute says if it is access, then it will be that. It does not say > it MUST be accessed. That is what nonnull is for. > > >I didn't want to use __attribute__((nonnull)) because the optimizer may use > >that knowledge to remove nullptr checks. > > It only uses it afterwards or inside the function. > It cannot use nonnull attribute to optimize before the access has happened. Thank you for your reply. https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html The manual does state: quote 1: "The compiler may also perform optimizations based on the knowledge that certain function arguments cannot be null. These optimizations can be disabled by the -fno-delete-null-pointer-checks option. See Optimize Options." quote 2: "The compiler may also perform optimizations based on the knowledge that nonnul parameters cannot be null. This can currently not be disabled other than by removing the nonnull attribute." So the caveat is this issue (2). I can't use attribute nonnull due to these optimizations that cannot be disabled. BTW, there is a "nonnul" typo there, if you have a moment and commit access to change (the patches I sent to gcc-patches for documentation didn't get any replies) Thank you again for your reply.
[Bug c++/108893] attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893 --- Comment #9 from Andrew Pinski --- (In reply to Jonny Grant from comment #8) > So the caveat is this issue (2). I can't use attribute nonnull due to these > optimizations that cannot be disabled. But you declare that argument cannot be null. So why keep around a check for it being null. The nonnull attribute is basically saying there is a requirement for it being nonnull no matter what. It basically says if a null is passed undefined behavior happens.
[Bug c++/108893] attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893 --- Comment #10 from Jonny Grant --- (In reply to Andrew Pinski from comment #9) > (In reply to Jonny Grant from comment #8) > > So the caveat is this issue (2). I can't use attribute nonnull due to these > > optimizations that cannot be disabled. > > But you declare that argument cannot be null. So why keep around a check for > it being null. The nonnull attribute is basically saying there is a > requirement for it being nonnull no matter what. It basically says if a null > is passed undefined behavior happens. My concern would be when building a library, the nullptr checks might be removed by the optimizer, and then when linked a nullptr could slip through if they called functions indirectly (ie. not via a header with the same attribute nonnull) I would rather avoid undefined behavior nullptr dereference SEGV, as safety critical software. For instance such functions could check parameters and return -1 if a nullptr is present. So application can handle it, log an issue etc So, I'm adding -fno-delete-null-pointer-checks to my builds as I didn't realise that was on already in -O3.
[Bug c++/108893] attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893 --- Comment #11 from Jonny Grant --- As you say, in your quote from the manual, the access attribute read_only doesn't mean there will be any access at all. However, it doesn't seem to generate any warnings itself, maybe it is only for the optimizer to utilize this knowledge. Quoting the manual: "The read_only access mode specifies that the pointer to which it applies is used to read the referenced object but not write to it. Unless the argument specifying the size of the access denoted by size-index is zero, the referenced object must be initialized." I tried size-index of 0, and 1, but it doesn't make any difference. Updated example: https://godbolt.org/z/Ms3zWThjT So if I need such nullptr warnings where it is passed and the optimizer can see it, I should use -Wnonnull and attribute nonnull on those functions. Perhaps via a macro, so only in a special build run occasionally to check for such issues.
[Bug d/108877] Explicit immutable struct import internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
--- Comment #1 from ibuclaw at gcc dot gnu.org ---
Immutable is the keyword here. Stub debug symbols are only attached to the main
variant of a type. I think this would also be reproducible with `immutable
class` and `immutable enum` as well.
Have fix really to commit and backport once I test it.
---
diff --git a/gcc/d/imports.cc b/gcc/d/imports.cc
index 3b46d1b7560..2efef4ed54f 100644
--- a/gcc/d/imports.cc
+++ b/gcc/d/imports.cc
@@ -106,12 +106,16 @@ public:
tree type = build_ctype (d->type);
/* Not all kinds of D enums create a TYPE_DECL. */
if (TREE_CODE (type) == ENUMERAL_TYPE)
- this->result_ = this->make_import (TYPE_STUB_DECL (type));
+ {
+ type = TYPE_MAIN_VARIANT (type);
+ this->result_ = this->make_import (TYPE_STUB_DECL (type));
+ }
}
void visit (AggregateDeclaration *d) final override
{
tree type = build_ctype (d->type);
+type = TYPE_MAIN_VARIANT (type);
this->result_ = this->make_import (TYPE_STUB_DECL (type));
}
@@ -119,6 +123,7 @@ public:
{
/* Want the RECORD_TYPE, not POINTER_TYPE. */
tree type = TREE_TYPE (build_ctype (d->type));
+type = TYPE_MAIN_VARIANT (type);
this->result_ = this->make_import (TYPE_STUB_DECL (type));
}
[Bug tree-optimization/66364] poor optimization of packed structs containing bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66364 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |--- See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=55658 --- Comment #4 from Andrew Pinski --- So in the end this is not an exact dup of bug 55658 as the patch I did does not change the code here but does fix PR 55658 .
[Bug tree-optimization/66364] poor optimization of packed structs containing bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66364 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Andrew Pinski --- The reason why the patch for PR 55658 didn't have any effect here is because by the time get_best_mode is called, bitregion_start and bitregion_end are set to 0 because they don't get passed down. So if we do lowering of the bitfield early on, then we should be able to get the correct behavior ... Double checking that.
[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922 --- Comment #8 from Jan Kratochvil --- (In reply to Andrew Pinski from comment #2) > So the simple test is run the full GCC bootstrap/test with all languages and > check if the testcase fails or not. I suspect it will. It does not. Tested on Fedora 36 x86-64. I did test only a revert of: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=93ba85fdd253b4b9cf2b9e54e8e5969b1a3db098 The revert makes it 13x faster. But the produced code still falls back to calling glibc fmod() as shown in the disassembly in Comment 0. If I use the "fprem" instruction directly it gets 15x faster - but I did not figure out some (easy) way for me how to patch GCC to no longer produce the call to fmod() at all and produce only the "fprem" instruction. (In reply to Alexander Monakov from comment #4) > Plus, Glibc does use fprem/fprem1 for fmodl/remainderl on x86_64, It is true replacing fmod() with fmodl() makes it 5x faster (but only 5x). There is still some infinity check and I haven't found any real justification in glibc sources for it: 28if (__builtin_expect (isinf (x) || y == 0.0L, 0) 29&& _LIB_VERSION != _IEEE_ && !isnan (y) && !isnan (x)) 30 /* fmod(+-Inf,y) or fmod(x,0) */ 31 return __kernel_standard_l (x, y, 227); > The ieee_2.f90 testcase attempts to change rounding mode. It 2014 it > probably just was "miscompiled". The testsuite run did include "gfortran.dg/ieee/ieee_2.f90" and it has no regression.
[Bug target/108932] amd64-pc-solaris2.11:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108932 --- Comment #3 from Jan-Benedict Glaw --- Thanks a lot! Ftr: `--with-gas` is accepted, but `--with-gnu-as` flags the inclusion of `usegas.h`.
