[Bug d/99691] OpenBSD support for GDC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99691 --- Comment #1 from Iain Buclaw --- Thanks, I have an OpenBSD VM with a WIP port as well, so I'll compare the two - I don't recall any problems with shared libraries, though the host system demands that PIC/PIE is forced for all built compilers/generator programs.
[Bug c++/99672] std::source_location yield different column numbers between free function and template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99672
--- Comment #3 from 康桓瑋 ---
I think the issue of line() function also needs to do a patch.
https://godbolt.org/z/q8EPnG
constexpr int g(auto...) {
return std::source_location::current( // < opening paren line number
).line();
}
constexpr int f() {
return std::source_location::current(
).line(); // < closing paren line number
}
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 Brecht Sanders changed: What|Removed |Added CC||brechtsanders at users dot sourcef ||orge.net --- Comment #4 from Brecht Sanders --- I tried to build gcc 10 snapshot 20210320 for Windows 64-bit with the proposed patch. First I got this error: make[2]: Entering directory '/R/winlibs64_stage/gcc-10-20210320/build_mingw/gcc'make[2]: *** No rule to make target 'config/winnt-d.c', needed by 'winnt-d.o'. Stop. After copying the file manually there like this: mkdir -p build_mingw/gcc/config cp -u gcc/config/i386/winnt-d.c build_mingw/gcc/config/ I got this error: d:/prog/winlibs64_stage/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.0.1/../../../../x86_64-w64-mingw32/bin/ld.exe: winnt-d.o:R:\winlibs64_stage\gcc-10-20210320\build_mingw\gcc/config/winnt-d.c:60: multiple definition of `targetdm'; winnt-d.o:R:\winlibs64_stage\gcc-10-20210320\build_mingw\gcc/config/winnt-d.c:60: first defined here collect2.exe: error: ld returned 1 exit status
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 --- Comment #5 from Iain Buclaw --- (In reply to Brecht Sanders from comment #4) > I tried to build gcc 10 snapshot 20210320 for Windows 64-bit with the > proposed patch. > > First I got this error: > > make[2]: Entering directory > '/R/winlibs64_stage/gcc-10-20210320/build_mingw/gcc'make[2]: *** No rule to > make target 'config/winnt-d.c', needed by 'winnt-d.o'. > Stop. > That is because the build rule is not correct, it should be config/i386/winnt-d.c according to the location of the file in the patch. > After copying the file manually there like this: > > mkdir -p build_mingw/gcc/config > cp -u gcc/config/i386/winnt-d.c build_mingw/gcc/config/ > > I got this error: > > d:/prog/winlibs64_stage/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.0.1/../. > ./../../x86_64-w64-mingw32/bin/ld.exe: > winnt-d.o:R:\winlibs64_stage\gcc-10-20210320\build_mingw\gcc/config/winnt-d. > c:60: multiple definition of `targetdm'; > winnt-d.o:R:\winlibs64_stage\gcc-10-20210320\build_mingw\gcc/config/winnt-d. > c:60: first defined here > collect2.exe: error: ld returned 1 exit status Because I imagine it's now picked up the object file from two different locations.
[Bug c/99693] New: -O2 not move 'if' checks on const data outside the loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99693 Bug ID: 99693 Summary: -O2 not move 'if' checks on const data outside the loops Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rafal at bursig dot org Target Milestone: --- -g -o /tmp/compiler-explorer-compiler2021221-5538-b8yy15.yzw9n/output.s -masm=intel -S -fdiagnostics-color=always -O2 /tmp/compiler-explorer-compiler2021221-5538-b8yy15.yzw9n/example.c
[Bug c++/61961] Add new warning when initializer-list constructor chosen for uniform init that doesn't intend to use initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61961
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> The semantics I suggest are to warn when:
>
> * an initializer-list constructor is selected by overload resolution
> * the elements of the braced-init-list are not all the same type
> * another (non-initializer-list) constructor is viable
This would also be useful to warn for the CWG 2137 / PR 76262 / PR 85577 cases
where an initializer-list constructor is chosen for a braced-init-list with a
single element of the same type as the class being constructed. Users almost
always want A{a} to use a copy constructor, and are surprised when GCC chooses
an initializer-list constructor (which other compilers don't do).
So revised suggestion for the semantics:
* an initializer-list constructor is selected by overload resolution
* another (non-initializer-list) constructor is viable
* either the braced-init-list has more than one element and they are not all
the same type, or it has exactly one element and its type is the same as the
class being constructed.
I think this should be included in -Wall. If the initializer-list constructor
is really intended then the warning can be suppressed by explicitly converting
the initializers to the intended type, which more clearly expresses the
intended meaning of the code anyway.
[Bug libstdc++/99692] Lookup for operator<< skips global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692 --- Comment #4 from Jonathan Wakely --- (In reply to Sergey Kaniskin from comment #3) > I was unsure whether to file it under compiler or stdlibc++ as it’s accepted > by another compilers using stdlibc++. There's no such component, it's libstdc++. But if the same libstdc++ code works with other compilers then it's probably not a libstdc++ bug. The __rvalue_ostream_type constraints are going away soon: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566863.html
[Bug libstdc++/99692] Lookup for operator<< skips global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692 --- Comment #5 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > But by definition at this point operator << does not exist and is not > considered as it is not found via ADL because both std::basic_ostream > and std::vector are in the std namespace and the global namespace is > not considered. Which seems correct to me. Users should not be overloading operator<< for types defined by the standard library anyway. You don't own vector so you don't get to say how it should be output to std::ostream.
[Bug c/99693] -O2 not move 'if' checks on const data outside the loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99693
--- Comment #1 from rafal at bursig dot org ---
I'm not saying that this is a regression because I see proper results on -O3
level but IMHO such results should be available in -O2 level... but to topic:
I have such code:
typedef struct Update {
int m_update;
//...
} Update;
extern void antagonizer( Update * );
void antagonize(Update *data, unsigned int n)
{
while(--n)
{
if (data->m_update)
{
antagonizer( data );
}
}
}
then -O2 level give me such asm:
antagonize:
sub esi, 1
je .L10
pushrbp
mov rbp, rdi
pushrbx
mov ebx, esi
sub rsp, 8
jmp .L4
.L3:
sub ebx, 1
je .L14
.L4:
mov eax, DWORD PTR [rbp+0]
testeax, eax
je .L3
mov rdi, rbp
callantagonizer
sub ebx, 1
jne .L4
.L14:
add rsp, 8
pop rbx
pop rbp
ret
.L10:
ret
Which is OK because the "antagonizer( data );" call can change "Update *data"
struct and the "if (data->m_update)" can't be moved outside loop.
But when If I create local copy of "data->m_update" then this check could be
moved outside loop without problem. But below code:
typedef struct Update {
int m_update;
//...
} Update;
extern void antagonizer( Update * );
void antagonize(Update *data, unsigned int n)
{
const int _update = data->m_update;
while(--n)
{
if (_update)
{
antagonizer( data );
}
}
}
Do not move "if (_update)" outside the loop and asm looks like:
antagonize:
pushr12
pushrbp
pushrbx
mov ebp, DWORD PTR [rdi]
sub esi, 1
je .L1
mov r12, rdi
mov ebx, esi
jmp .L4
.L3:
sub ebx, 1
je .L1
.L4:
testebp, ebp // the check
je .L3 // is still in loop
mov rdi, r12
callantagonizer
sub ebx, 1
jne .L4
.L1:
pop rbx
pop rbp
pop r12
ret
When I build this code with -O3 level then the check is moved out the loop
properly, but I got several others effects which I don't know if it will have
proper impact in my application (I will prefer stay with -O2). The asm for -O3
level:
antagonize:
mov eax, DWORD PTR [rdi]
sub esi, 1
je .L12
pushrbp
mov rbp, rdi
pushrbx
mov ebx, esi
sub rsp, 8
testeax, eax
jne .L3
.L1:
add rsp, 8
pop rbx
pop rbp
ret
.L3:
mov rdi, rbp
callantagonizer
sub ebx, 1
je .L1
mov rdi, rbp
callantagonizer
sub ebx, 1
jne .L3
jmp .L1
.L12:
ret
[Bug c++/91873] -Wreturn-type diagnostic location changes depending on optimization level and destructor declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91873
Dov Murik changed:
What|Removed |Added
CC||dov.murik at gmail dot com
--- Comment #2 from Dov Murik ---
I encountered a similar issue to the one reported by m101010a, in which the
following program bug.cpp causes a -Wreturn-type with -O0 (and with
-DHAS_DESTRUCTOR -DUSE_A_AFTER_RETURN).
$ cat bug.cpp
struct st {
#ifdef HAS_DESTRUCTOR
~st();
#endif
void g();
};
int f() {
st a;
return 0;
#ifdef USE_A_AFTER_RETURN
a.g();
#else
return 7;
#endif
}
$ g++ -O0 -DHAS_DESTRUCTOR -DUSE_A_AFTER_RETURN -Werror -c bug.cpp
bug.cpp: In function ‘int f()’:
bug.cpp:16:1: error: control reaches end of non-void function
[-Werror=return-type]
16 | }
| ^
cc1plus: all warnings being treated as errors
The following changes causes the compiler to behave nicely and
not issue the warning:
* Use -O1 or higher.
* Remove the destructor (compile without -DHAS_DESTRUCTOR)
* Don't use the object in the dead code area (compile without
-DUSE_A_AFTER_RETURN).
* Use clang++
* Use g++ 7.5.0
$ g++ -O1 -DHAS_DESTRUCTOR -DUSE_A_AFTER_RETURN -Werror -c bug.cpp
$ g++ -O0 -DUSE_A_AFTER_RETURN -Werror -c bug.cpp
$ g++ -O0 -DHAS_DESTRUCTOR -Werror -c bug.cpp
$ clang++ -O0 -DHAS_DESTRUCTOR -DUSE_A_AFTER_RETURN -Werror -c bug.cpp
I'm not sure if this is the exact same issue as the original post or not, but
looks very similar.
As mentioned, this doesn't reproduce with gcc 7.5.0. I managed to reproduce
this
with gcc 8.3.0, gcc 9.3.0, 10.2.0, and also with gcc 11.0.1 20210320
(using godbolt). The full -v reports are below:
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.3.0-17ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-9-HskZEa/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20210321/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595
--- Comment #6 from Brecht Sanders
---
The patch for gcc/config/i386/t-cygming added a line:
winnt-d.o: config/winnt-d.c
I changed it to:
winnt-d.o: config/i386/winnt-d.c
Then I got one step further.
Output is now:
libtool: compile: /R/winlibs64_stage/gcc-10-20210320/build_mingw/./gcc/gdc
-B/R/winlibs64_stage/gcc-10-20210320/build_mingw/./gcc/
-L/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/lib
-L/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/mingw/lib -isystem
/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/include
-isystem /R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/mingw/include
-B/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/bin/
-B/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/lib/
-isystem
/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/include
-isystem
/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/sys-include
--sysroot=/R/winlibs64_stage/gcc-10-20210320/build_mingw/mingw-w64 -DDLL_EXPORT
-Wall -frelease -O2 -g -nostdinc -I ../../../../libphobos/libdruntime -I . -c
../../../../libphobos/libdruntime/core/demangle.d -fversion=Shared -o
core/.libs/demangle.o
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:134:5:
error: undefined identifier 'FILE'
134 | int fwprintf(FILE* stream, in wchar_t* format, ...);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:136:5:
error: undefined identifier 'FILE'
136 | int fwscanf(FILE* stream, in wchar_t* format, ...);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:139:5:
error: undefined identifier 'FILE'
139 | int vfwprintf(FILE* stream, in wchar_t* format, va_list arg);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:141:5:
error: undefined identifier 'FILE'
141 | int vfwscanf(FILE* stream, in wchar_t* format, va_list arg);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:177:12:
error: undefined identifier 'FILE'
177 | wint_t fgetwc(FILE* stream);
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:179:12:
error: undefined identifier 'FILE'
179 | wint_t fputwc(wchar_t c, FILE* stream);
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:183:10:
error: undefined identifier 'FILE'
183 | wchar_t* fgetws(wchar_t* s, int n, FILE* stream);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:185:10:
error: undefined identifier 'FILE'
185 | int fputws(in wchar_t* s, FILE* stream);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:195:12:
error: undefined identifier 'FILE'
195 | wint_t getwc(FILE* stream){ return fgetwc(stream);}
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:197:12:
error: undefined identifier 'FILE'
197 | wint_t putwc(wchar_t c, FILE* stream) { return fputwc(c, stream); }
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:204:12:
error: undefined identifier 'FILE'
204 | wint_t ungetwc(wint_t c, FILE* stream);
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:213:16:
error: undefined identifier 'FILE'
213 | intfwide(FILE* stream, int mode);
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1140:16:
error: undefined identifier 'FILE'
1140 | @trusted FILE* tmpfile(); // No unsafe pointer manipulation.
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1145:7:
error: undefined identifier 'FILE'
1145 | int fclose(FILE* stream);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1151:11:
error: undefined identifier 'FILE'
1151 | int fflush(FILE* stream);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1155:7:
error: undefined identifier 'FILE'
1155 | FILE* fopen(scope const char* filename, scope const char* mode);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1157:7:
error: undefined identifier 'FILE'
1157 | FILE* freopen(scope const char* filename, scope const char* mode, FILE*
stream);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1157:7:
error: undefined identifier 'FILE'
1157 | FILE* freopen(scope const char* filename, scope const char* mode, FILE*
stream);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1160:6:
error: undefined identifier 'FILE'
1160 | vo
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 --- Comment #7 from Iain Buclaw --- (In reply to Brecht Sanders from comment #6) > The patch for gcc/config/i386/t-cygming added a line: > winnt-d.o: config/winnt-d.c > I changed it to: > winnt-d.o: config/i386/winnt-d.c > > Then I got one step further. > > Output is now: > libtool: compile: /R/winlibs64_stage/gcc-10-20210320/build_mingw/./gcc/gdc > -B/R/winlibs64_stage/gcc-10-20210320/build_mingw/./gcc/ > -L/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/lib > -L/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/mingw/lib -isystem > /R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/include > -isystem /R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/mingw/include > -B/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/bin/ > -B/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/lib/ > -isystem > /R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/include > -isystem > /R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/sys- > include --sysroot=/R/winlibs64_stage/gcc-10-20210320/build_mingw/mingw-w64 > -DDLL_EXPORT -Wall -frelease -O2 -g -nostdinc -I > ../../../../libphobos/libdruntime -I . -c > ../../../../libphobos/libdruntime/core/demangle.d -fversion=Shared -o > core/.libs/demangle.o > r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d: > 134:5: error: undefined identifier 'FILE' > 134 | int fwprintf(FILE* stream, in wchar_t* format, ...); > | ^ What predefined versions are added by the compiler? ./gcc/d21 -v 2>&1 | grep predefs
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 --- Comment #8 from Brecht Sanders --- predefs GNU D_Version2 LittleEndian GNU_SEH_Exceptions GNU_EMUTLS GNU_StackGrowsDown GNU_InlineAsm D_LP64 D_PIC assert D_ModuleInfo D_Exceptions D_TypeInfo all X86_64 D_HardFloat Windows MinGW Win64 CppRuntime_Gcc
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 --- Comment #9 from Iain Buclaw --- (In reply to Brecht Sanders from comment #8) > predefs GNU D_Version2 LittleEndian GNU_SEH_Exceptions GNU_EMUTLS > GNU_StackGrowsDown GNU_InlineAsm D_LP64 D_PIC assert D_ModuleInfo > D_Exceptions D_TypeInfo all X86_64 D_HardFloat Windows MinGW Win64 > CppRuntime_Gcc So there's no predefined CRuntime_* version condition, which is where all the missing definitions are hidden behind. Would MinGW be a CRuntime_Glibc target, a CRuntime_Microsoft target, or using it's own C library that has little commonality with neither glibc nor msvc?
[Bug c/99694] New: gcc: fatal error: Killed signal terminated program cc1 under -O2 to -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
Bug ID: 99694
Summary: gcc: fatal error: Killed signal terminated program cc1
under -O2 to -Os
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi all.
GCC takes too much compiling time and then crashes on the valid small.c under
-O2 to -Os. Also, all GCC-9 upward versions behave the same.
$cat small.c
#include
int a, b, c;
void d() {
uint16_t e;
int32_t *f;
int32_t *g;
if (a) {
int32_t *k;
for (;; *k += 1) {
int32_t **i = &f;
int32_t **l = &g;
for (e = 6; e; e++) {
g = k = f;
j:
**l = 0;
}
*i = c;
}
}
uint16_t i = &e;
b = i / 0;
goto j;
}
$time gcc -w -c -O1 small.c
real0m0.057s
user0m0.023s
sys 0m0.006s
$time gcc -w -c -Os small.c (same as -O2 and -O3)
gcc: fatal error: Killed signal terminated program cc1
compilation terminated.
real79m53.073s
user78m10.888s
sys 0m28.194s
$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/tuhaoxin/compilers/gcc/build-20210320/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
--prefix=/home/tuhaoxin/compilers/gcc/build-20210320/ --enable-bootstrap
--enable-checking=release --enable-languages=c,c++ -disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210320 (experimental) (GCC)
Thanks,
Haoxin
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 --- Comment #10 from Brecht Sanders --- I thought MinGW-w64 is it's own C library. It is found by GCC build process because the folder mingw exists in the location specified with --with-build-sysroot CppRuntime_Gcc is mentioned in the predefs, why would CRuntime_Gcc not be defined then?
[Bug libstdc++/99692] Lookup for operator<< skips global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692 --- Comment #6 from Sergey Kaniskin --- > Which seems correct to me. Users should not be overloading operator<< for > types defined by the standard library anyway. You don't own vector so > you don't get to say how it should be output to std::ostream. I am sorry, do you mean it is a valid rejection or that it's just a bad taste?
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 --- Comment #11 from Iain Buclaw --- (In reply to Brecht Sanders from comment #10) > I thought MinGW-w64 is it's own C library. > It is found by GCC build process because the folder mingw exists in the > location specified with --with-build-sysroot > Right, so there will need to be some porting done to add `version (MinGW)` blocks to druntime in order to define all bindings that are tied to a specific C library - such as core/stdc/stdio.d. > CppRuntime_Gcc is mentioned in the predefs, why would CRuntime_Gcc not be > defined then? CppRuntime_Gcc is for libstdc++, the other C++ runtime library is MSVC++, which GCC is not compatible with. There is no C runtime library included with GCC.
string.h bug Benjamin-Elias Probst
Hello, my computer tried to build gcc in gcc-10.2.0 This happend after ./configure ... sudo make on ubuntu mint 20.1: TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="" \ /bin/bash ./mkconfig.sh config.h TARGET_CPU_DEFAULT="" \ HEADERS="options.h insn-constants.h config/vxworks-dummy.h config/i386/biarch64.h config/i386/i386.h config/i386/unix.h config/i386/att.h config/dbxelf.h config/elfos.h config/gnu-user.h config/glibc-stdint.h config/i386/x86-64.h config/i386/gnu-user-common.h config/i386/gnu-user64.h config/linux.h config/linux-android.h config/i386/linux-common.h config/i386/linux64.h config/initfini-array.h defaults.h" DEFINES="LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3 LIBC_MUSL=4 DEFAULT_LIBC=LIBC_GLIBC ANDROID_DEFAULT=0" \ /bin/bash ./mkconfig.sh tm.h TARGET_CPU_DEFAULT="" \ HEADERS="config/i386/i386-protos.h config/linux-protos.h tm-preds.h" DEFINES="" \ /bin/bash ./mkconfig.sh tm_p.h TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="" \ /bin/bash ./mkconfig.sh bconfig.h g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I. -I./build -I./../include -I./../libcpp/include \ -o build/genmodes.o genmodes.c In file included from bconfig.h:3, from genmodes.c:20: auto-host.h:2539:16: error: declaration does not declare anything [-fpermissive] 2539 | #define rlim_t long |^~~~ In file included from genmodes.c:21: system.h:495:14: error: conflicting declaration of C function 'void* sbrk(int)' 495 | extern void *sbrk (int); | ^~~~ In file included from system.h:301, from genmodes.c:21: /usr/include/unistd.h:1041:14: note: previous declaration 'void* sbrk(intptr_t)' 1041 | extern void *sbrk (intptr_t __delta) __THROW; | ^~~~ In file included from genmodes.c:21: system.h:503:14: error: ambiguating new declaration of 'char* strstr(const char*, const char*)' 503 | extern char *strstr (const char *, const char *); | ^~ In file included from /usr/include/c++/9/cstring:42, from system.h:241, from genmodes.c:21: /usr/include/string.h:312:20: note: old declaration 'const char* strstr(const char*, const char*)' 312 | extern const char *strstr (const char *__haystack, const char *__needle) |^~ In file included from genmodes.c:21: system.h:551:20: error: conflicting declaration of C function 'const char* strsignal(int)' 551 | extern const char *strsignal (int); |^ In file included from /usr/include/c++/9/cstring:42, from system.h:241, from genmodes.c:21: /usr/include/string.h:447:14: note: previous declaration 'char* strsignal(int)' 447 | extern char *strsignal (int __sig) __THROW; | ^ In file included from system.h:702, from genmodes.c:21: ./../include/libiberty.h:112:14: error: ambiguating new declaration of 'char* basename(const char*)' 112 | extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL ATTRIBUTE_NONNULL(1); | ^~~~ In file included from /usr/include/c++/9/cstring:42, from system.h:241, from genmodes.c:21: /usr/include/string.h:484:26: note: old declaration 'const char* basename(const char*)' 484 | extern "C++" const char *basename (const char *__filename) | ^~~~ make: *** [Makefile:2798: build/genmodes.o] Error 1 Best regards, Benjamin-Elias Probst
[Bug c++/99695] New: Cannot static compile with C++ module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99695
Bug ID: 99695
Summary: Cannot static compile with C++ module
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
Hello.cc
module;
// legacy includes go here – not part of this module
import ;
import ;
export module Hello;
// the module purview starts here
// provide a function to users by exporting it
export inline void SayHello(std::string_view name)
{
std::cout << "Hello " << name << "!\n";
}
main.cc
import Hello;
int main()
{
SayHello("sdgsdg");
}
g++ -o main hello.o main.o -Ofast -std=c++20 -fmodules-ts -static
D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/11.0.1/../../../../x86_64-w64-mingw32/bin/ld.exe:
D:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/11.0.1/../../../../lib\libstdc++.a(cxx11-locale-inst.o):(.rdata$_ZTVNSt7__cxx118numpunctIcEE[_ZTVNSt7__cxx118numpunctIcEE]+0x0):
multiple definition of `vtable for std::__cxx11::numpunct';
main.o:main.cc:(.rdata+0x3a0): first defined here
bunch of errors
[Bug middle-end/99696] New: lto looks past aliases to initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99696
Bug ID: 99696
Summary: lto looks past aliases to initializers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rth at gcc dot gnu.org
Target Milestone: ---
The following is a c-ish version of
const int y = init();
which no longer works with gcc 11.
The intended advantage to the program from which this is
extracted is that references to Y may be cse'd across calls.
IMO this should work fine with LTO, so long as it does not
apply the constant initializer optimization to const variables
that are aliased.
Compile: gcc -O2 -flto y?.c
--- y1.c ---
#include
extern const int y;
int main(void)
{
assert(y == 1);
return 0;
}
--- y2.c ---
static int x;
extern const int y __attribute__((alias("x")));
static void __attribute__((constructor)) init(void)
{
x = 1;
}
[Bug fortran/99688] AddressSanitizer: stack-buffer-overflow on address at gfc_match_name(char*) gcc/fortran/match.c:685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99688 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/567066.html Should fix this issue and three other issues.
[Bug debug/99388] Invalid debug info for __fp16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99388
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fc24ea2374259d401a46ce3526688b7e79d4cc13
commit r11-7753-gfc24ea2374259d401a46ce3526688b7e79d4cc13
Author: Jakub Jelinek
Date: Sun Mar 21 17:27:39 2021 +0100
dwarf2out: Fix debug info for 2 byte floats [PR99388]
Aarch64, ARM and a couple of other architectures have 16-bit floats,
HFmode.
As can be seen e.g. on
void
foo (void)
{
__fp16 a = 1.0;
asm ("nop");
a = 2.0;
asm ("nop");
a = 3.0;
asm ("nop");
}
testcase, GCC mishandles this on the dwarf2out.c side by assuming all
floating point types have sizes in multiples of 4 bytes, so what GCC emits
is it says that e.g. the DW_OP_implicit_value will be 2 bytes but then
doesn't emit anything and so anything emitted after it is treated by
consumers as the value and then they get out of sync.
real_to_target which insert_float uses indeed fills it that way, but
putting
into an array of long 32 bits each time, but for the half floats it puts
everything into the least significant 16 bits of the first long no matter
what endianity host or target has.
The following patch fixes it. With the patch the -g -O2 -dA output changes
(in a cross without .uleb128 support):
.byte 0x9e// DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x3c00 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL1 // Location list begin address (*.LLST0)
.8byte .LVL2 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e// DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4000 // fp or vector constant word 0
.byte 0x7 // DW_LLE_start_end (*.LLST0)
.8byte .LVL2 // Location list begin address (*.LLST0)
.8byte .LFE0 // Location list end address (*.LLST0)
.byte 0x4 // uleb128 0x4; Location expression size
.byte 0x9e// DW_OP_implicit_value
.byte 0x2 // uleb128 0x2
+ .2byte 0x4200 // fp or vector constant word 0
.byte 0 // DW_LLE_end_of_list (*.LLST0)
Bootstrapped/regtested on x86_64-linux, aarch64-linux and
armv7hl-linux-gnueabi, ok for trunk?
I fear the CONST_VECTOR case is still broken, while HFmode elements of
vectors
should be fine (it uses eltsize of the element sizes) and likewise SFmode
could
be fine, DFmode vectors are emitted as two 32-bit ints regardless of
endianity
and I'm afraid it can't be right on big-endian. But I haven't been able to
create a testcase that emits a CONST_VECTOR, for e.g. unused vector vars
with constant operands we emit CONCATN during expansion and thus ...
DW_OP_*piece for each element of the vector and for
DW_TAG_call_site_parameter we give up (because we handle CONST_VECTOR only
in loc_descriptor, not mem_loc_descriptor).
2021-03-21 Jakub Jelinek
PR debug/99388
* dwarf2out.c (insert_float): Change return type from void to
unsigned, handle GET_MODE_SIZE (mode) == 2 and return element size.
(mem_loc_descriptor, loc_descriptor, add_const_value_attribute):
Adjust callers.
[Bug c/99693] -O2 not move 'if' checks on const data outside the loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99693 --- Comment #2 from Andrew Pinski --- Loop unswitching is correctly only turned on at -O3+. So you want to move it to -O2. Note loop unswitching can cause performance problems due to increase of usage of the icache and such.
[Bug c++/99697] New: ICE for class template partial specialization over non-template (structural class template) parameter of deduced class type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99697
Bug ID: 99697
Summary: ICE for class template partial specialization over
non-template (structural class template) parameter of
deduced class type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: davveston at gmail dot com
Target Milestone: ---
The following program:
// ---
// prog.cc
template struct S {};
template struct U {};
template struct V;
template struct V> {}; // #1: ICE
int main() {}
// ---
compiled with gcc HEAD 11.0.1 20210320 (experimental) and the following command
g++ prog.cc -Wall -Wextra -std=gnu++2b
results in the following ICE (segfault) at #1:
// ---
prog.cc:5:28: internal compiler error: Segmentation fault
5 | template struct V> {}; // ICE
|^
0xca91ff crash_signal
../../source/gcc/toplev.c:327
0x63a207 resolve_args(vec*, int)
../../source/gcc/cp/call.c:4548
0x78a764 do_class_deduction
../../source/gcc/cp/pt.c:29332
0x78a764 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../../source/gcc/cp/pt.c:29509
0x798c37 convert_template_argument
../../source/gcc/cp/pt.c:8491
0x79a19b convert_template_argument
../../source/gcc/cp/pt.c:8264
0x79a19b coerce_template_parms
../../source/gcc/cp/pt.c:8995
0x79b411 lookup_template_class_1
../../source/gcc/cp/pt.c:9833
0x79c3ec lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../source/gcc/cp/pt.c:10237
0x7c028d finish_template_type(tree_node*, tree_node*, int)
../../source/gcc/cp/semantics.c:3563
0x75f603 cp_parser_template_id
../../source/gcc/cp/parser.c:17458
0x75f86b cp_parser_class_name
../../source/gcc/cp/parser.c:24685
0x75783a cp_parser_qualifying_entity
../../source/gcc/cp/parser.c:7002
0x75783a cp_parser_nested_name_specifier_opt
../../source/gcc/cp/parser.c:6684
0x76c30f cp_parser_simple_type_specifier
../../source/gcc/cp/parser.c:18851
0x74cd8d cp_parser_type_specifier
../../source/gcc/cp/parser.c:18509
0x75d323 cp_parser_type_specifier_seq
../../source/gcc/cp/parser.c:23360
0x75bba4 cp_parser_type_id_1
../../source/gcc/cp/parser.c:23163
0x75de83 cp_parser_template_type_arg
../../source/gcc/cp/parser.c:23268
0x75dfaf cp_parser_template_argument
../../source/gcc/cp/parser.c:17908
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/99698] New: [aarch64] Impossible to accurately detect extensions using preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99698
Bug ID: 99698
Summary: [aarch64] Impossible to accurately detect extensions
using preprocessor
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: e...@coeus-group.com
Target Milestone: ---
Using SHA3 as an example, but this problem exists for other extensions as well.
If you pass something like -march=armv8-a+sha3, GCC will define
__ARM_FEATURE_SHA3. According to the ACLE documentation:
__ARM_FEATURE_SHA3 is defined to 1 if the SHA1 & SHA2 Crypto instructions
from Armv8-A and the SHA2 and SHA3 instructions from Armv8.2-A and newer
are supported and intrinsics targeting them are available. These
instructions include AES{E, D}, SHA1{C, P, M}, RAX, and others.
So, I should be able to use the preprocessor to call a function like vbcaxq_u32
if __ARM_FEATURE_SHA3 is defined to 1.
However, if I call vbcaxq_u32 I get an error about a target specific option
mismatch. It turns out that you need -march=armv8.2-a+sha3 to convince GCC to
accept the function call.
AFAICT there is no way to reliably detect armv8.2-a. The only difference in
the preprocessor macros defined for armv8-a and armv8.2-a are a few extra
__ARM_FEATURE_* macros. There is *no* difference in pre-defined macros between
armv8.1-a and armv8.2-a.
FWIW, clang accepts -march=armv8-a+sha3, defines __ARM_FEATURE_SHA3 to 1, and
allows you to call the SHA3 functions, which seems pretty reasonable to me.
[Bug target/99698] [aarch64] Impossible to accurately detect extensions using preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99698 --- Comment #1 from Andrew Pinski --- >AFAICT there is no way to reliably detect armv8.2-a. There is supposed to be See PR 99312 .
[Bug middle-end/99696] lto looks past aliases to initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99696 --- Comment #1 from Richard Henderson --- Actually, I can reproduce this with gcc 9.3 as well. My upstream bug report simply uses gcc 11, so I assumed.
[Bug target/99698] [aarch64] Impossible to accurately detect extensions using preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99698 --- Comment #2 from Evan Nemerson --- Nice, thanks! That would at least make testing possible, though I still think that just checking __ARM_FEATURE_SHA3 should be sufficient, and ktkachov's comment reinforces that.
[Bug c++/99699] New: Type deduction failure for deducing a non-type template parameter via another deducible structural type (class template specialization) non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99699
Bug ID: 99699
Summary: Type deduction failure for deducing a non-type
template parameter via another deducible structural
type (class template specialization) non-type template
parameter
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: davveston at gmail dot com
Target Milestone: ---
The following program:
//
templatestruct S {};
template struct U {};
template struct V { V() = delete; };
template s>
struct V> {};
V{}>> v{}; // #1
// Expected: use partial specialization #1
// GCC actual: error (rejects-valid): use of deleted function
int main() {}
//
is rejected by gcc HEAD 11.0.1 20210320 (experimental) when compiling with 'g++
prog.cc -Wall -Wextra -std=c++2b', as #1 matches to the primary template
instead of the partial specialization.
It seems to find the non-type template parameter N non-deducible; however all
arguments of the partial specialization are arguably deducible from the
'U{}>' argument to the primary template:
- 'A' / 'P' matching 'U{}>' / 'U' deduces 's' to 'S<0>{}' and its type
to 'S<0>',
- 'A' / 'P' matching 'S<0>' to 'S' deduces 'N' to '0'; 'N' is particularly
not in a non-deduced context above, as it's not used in sub-expression in the
non-type template parameter 's' of the partial specialization.
Demo: https://wandbox.org/permlink/QQQxa3BhBTMM476E
[Bug c++/99700] New: gcc takes an uninitialized variable as a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99700
Bug ID: 99700
Summary: gcc takes an uninitialized variable as a constant
expression
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/93qM1b
struct A {
constexpr A() { c[0] = 0; }
char c[2];
};
constexpr A a;
[Bug d/99691] OpenBSD support for GDC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99691 --- Comment #2 from Brian Callahan --- (In reply to Iain Buclaw from comment #1) > Thanks, I have an OpenBSD VM with a WIP port as well, so I'll compare the > two - I don't recall any problems with shared libraries, though the host > system demands that PIC/PIE is forced for all built compilers/generator > programs. Yes, I do the same with PIC/PIE. Thanks.
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #30 from Paul Thomas ---
Created attachment 50442
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50442&action=edit
Patch that "fixes" all versions of the problem.. so far :-)
Hi Juergen,
I think that this one does the job... it is even correct and regtests OK;-)
I found that the gdb session was a miserable afair that didn't help at all
because of the change in dwarf versions. I would up reducing the testcase to
what you will find below. Please excuse my mutilation of Whizard!
The chunk of whizard that you provided throws up all sorts of memories. In the
1970's I used to go up to Caltech every Wednesday for Feynman and Gell-mann
seminars. I was around for the earliest days of partons and the realisation
that quarks might even be real.
Paul
module model_data
type :: model_data_t
type(modelpar_real_t), dimension(:), pointer :: par_real => null ()
contains
procedure :: get_par_data_ptr => model_data_get_par_data_ptr_name
procedure :: set => field_data_set
end type model_data_t
type :: modelpar_real_t
character (4) :: name
real(4) :: value
end type modelpar_real_t
type(modelpar_real_t), target :: names(2) = [modelpar_real_t("foo ", 1), &
modelpar_real_t("bar ", 2)]
contains
function model_data_get_par_data_ptr_name (model, name) result (ptr)
class(model_data_t), intent(in) :: model
character (*), intent(in) :: name
class(modelpar_real_t), pointer :: ptr
integer :: i
ptr => null ()
do i = 1, size (model%par_real)
if (model%par_real(i)%name == name) ptr => model%par_real(i)
end do
end function model_data_get_par_data_ptr_name
subroutine field_data_set (this, ptr)
class(model_data_t), intent(inout) :: this
class(modelpar_real_t), intent(in), pointer :: ptr
if (associated (ptr)) then
print *, "'ptr%value' = ", ptr%value
else
print *, "'ptr' not associated in 'field_data_set'"
end if
end subroutine
end module model_data
use model_data
class(model_data_t), allocatable :: model
class(modelpar_real_t), pointer :: name_ptr
allocate (model_data_t :: model)
model%par_real => names
! name_ptr => model%get_par_data_ptr ("bar ")
! call field_data_set (model, name_ptr)
! call field_data_set (model, model%get_par_data_ptr ("bar "))
call model%set (model%get_par_data_ptr ("bar "))
call model%set (model%get_par_data_ptr ("tea "))
end
[Bug sanitizer/99673] [11 Regression] bogus -Wstringop-overread warning with address sanitizer due to member address substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673 --- Comment #3 from Martin Sebor --- None of the -Wstringop-xxx warnings (either true or false positives) affects code generation. Thanks for the true vs false positive breakdown. If you remember and could let me know the details of the real bugs that'd be great. (In addition to reporting any false positives we don't yet know about as you have been.)
Re: string.h bug Benjamin-Elias Probst
On 3/21/21 9:01 AM, Benjamin-Elias Probst wrote: Hello, my computer tried to build gcc in gcc-10.2.0 This happend after ./configure ... sudo make on ubuntu mint 20.1: If you are reporting a bug then please enter it in GCC Bugzilla (https://gcc.gnu.org/bugzilla/). This list simply collects Bugzilla updates and isn't meant for directly posting bugs or for discussion. If you are asking a usage question then please use the gcc-help mailing list. Martin TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="" \ /bin/bash ./mkconfig.sh config.h TARGET_CPU_DEFAULT="" \ HEADERS="options.h insn-constants.h config/vxworks-dummy.h config/i386/biarch64.h config/i386/i386.h config/i386/unix.h config/i386/att.h config/dbxelf.h config/elfos.h config/gnu-user.h config/glibc-stdint.h config/i386/x86-64.h config/i386/gnu-user-common.h config/i386/gnu-user64.h config/linux.h config/linux-android.h config/i386/linux-common.h config/i386/linux64.h config/initfini-array.h defaults.h" DEFINES="LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3 LIBC_MUSL=4 DEFAULT_LIBC=LIBC_GLIBC ANDROID_DEFAULT=0" \ /bin/bash ./mkconfig.sh tm.h TARGET_CPU_DEFAULT="" \ HEADERS="config/i386/i386-protos.h config/linux-protos.h tm-preds.h" DEFINES="" \ /bin/bash ./mkconfig.sh tm_p.h TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="" \ /bin/bash ./mkconfig.sh bconfig.h g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I. -I./build -I./../include -I./../libcpp/include \ -o build/genmodes.o genmodes.c In file included from bconfig.h:3, from genmodes.c:20: auto-host.h:2539:16: error: declaration does not declare anything [-fpermissive] 2539 | #define rlim_t long |^~~~ In file included from genmodes.c:21: system.h:495:14: error: conflicting declaration of C function 'void* sbrk(int)' 495 | extern void *sbrk (int); | ^~~~ In file included from system.h:301, from genmodes.c:21: /usr/include/unistd.h:1041:14: note: previous declaration 'void* sbrk(intptr_t)' 1041 | extern void *sbrk (intptr_t __delta) __THROW; | ^~~~ In file included from genmodes.c:21: system.h:503:14: error: ambiguating new declaration of 'char* strstr(const char*, const char*)' 503 | extern char *strstr (const char *, const char *); | ^~ In file included from /usr/include/c++/9/cstring:42, from system.h:241, from genmodes.c:21: /usr/include/string.h:312:20: note: old declaration 'const char* strstr(const char*, const char*)' 312 | extern const char *strstr (const char *__haystack, const char *__needle) |^~ In file included from genmodes.c:21: system.h:551:20: error: conflicting declaration of C function 'const char* strsignal(int)' 551 | extern const char *strsignal (int); |^ In file included from /usr/include/c++/9/cstring:42, from system.h:241, from genmodes.c:21: /usr/include/string.h:447:14: note: previous declaration 'char* strsignal(int)' 447 | extern char *strsignal (int __sig) __THROW; | ^ In file included from system.h:702, from genmodes.c:21: ./../include/libiberty.h:112:14: error: ambiguating new declaration of 'char* basename(const char*)' 112 | extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL ATTRIBUTE_NONNULL(1); | ^~~~ In file included from /usr/include/c++/9/cstring:42, from system.h:241, from genmodes.c:21: /usr/include/string.h:484:26: note: old declaration 'const char* basename(const char*)' 484 | extern "C++" const char *basename (const char *__filename) | ^~~~ make: *** [Makefile:2798: build/genmodes.o] Error 1 Best regards, Benjamin-Elias Probst
[Bug c++/99701] New: std::nullptr_t can be compared with relational ops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99701 Bug ID: 99701 Summary: std::nullptr_t can be compared with relational ops Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: cjdb.ns at gmail dot com Target Milestone: --- Created attachment 50443 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50443&action=edit Temp file for provided source The following program is valid in all versions of GCC from 4.7.1 through trunk[1]. Relational operations on std::nullptr_t don't really make sense since there's only one value. ``` auto lt = nullptr < nullptr; auto gt = nullptr > nullptr; auto le = nullptr <= nullptr; auto ge = nullptr >= nullptr; ``` This was apparently addressed by DR583/N3478 (thanks to Richard Smith for providing these). [1]: https://godbolt.org/z/h11183 # Versions * All GCC releases at least as far back as 4.7.1 (where I stopped looking). # System type * Debian (checked GCC 10.2.1) * Compiler Explorer (checked all other reported versions). # Options given to GCC `g++ -save-temps nullptr-relop.cpp -c -std=c++20`
[Bug target/99702] New: [11 Regression] ICE: RTL check: expected code 'const_int', have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262 with memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99702
Bug ID: 99702
Summary: [11 Regression] ICE: RTL check: expected code
'const_int', have 'subreg' in riscv_expand_block_move,
at config/riscv/riscv.c:3262 with memcpy()
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu
Created attachment 50444
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50444&action=edit
reduced testcase (from libgcc/unwind-dw2.c)
Compiler output:
$ cc1 -mabi=lp64d -march=rv64imafdc -O testcase.c
foo
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> {heap 860k} {heap 860k}
{heap 860k} {heap 992k} {heap 1720k}
{heap 1720k} {heap 1720k}Streaming LTO
{heap 1720k} {heap 1720k} {heap
1720k} {heap 1720k} {heap 1720k} {heap 1720k}
{heap 1720k} {heap 1720k} {heap
1720k} {heap 1720k}Assembling functions:
fooduring RTL pass: expand
testcase.c: In function 'foo':
testcase.c:4:3: internal compiler error: RTL check: expected code 'const_int',
have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262
4 | __builtin_memcpy(i, j, n);
| ^
0x6c4289 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.c:879
0x776ff0 riscv_expand_block_move(rtx_def*, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/riscv/riscv.c:3262
0x14c4ba0 gen_cpymemsi(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/repo/gcc-trunk/gcc/config/riscv/riscv.md:1528
0xd4b8d8 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.c:7820
0xae7f5e emit_block_move_via_pattern
/repo/gcc-trunk/gcc/expr.c:1873
0xae7f5e emit_block_move_hints(rtx_def*, rtx_def*, rtx_def*, block_op_methods,
unsigned int, long, unsigned long, unsigned long, unsigned long, bool, bool*,
bool)
/repo/gcc-trunk/gcc/expr.c:1665
0x977aa3 expand_builtin_memory_copy_args
/repo/gcc-trunk/gcc/builtins.c:6053
0x989470 expand_builtin_memcpy
/repo/gcc-trunk/gcc/builtins.c:5906
0x98c3a2 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/repo/gcc-trunk/gcc/builtins.c:9955
0xade284 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.c:11282
0x9b9d5c expand_expr
/repo/gcc-trunk/gcc/expr.h:282
0x9b9d5c expand_call_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:2840
0x9b9d5c expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.c:3844
0x9b9d5c expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.c:4008
0x9ba7a9 expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.c:6045
0x9bc4a6 execute
/repo/gcc-trunk/gcc/cfgexpand.c:6729
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ xgcc -v
Using built-in specs.
COLLECT_GCC=/repo/build-gcc-trunk-riscv64/./gcc/xgcc
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-7753-20210321172739-gfc24ea23742-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.1 20210321 (experimental) (GCC)
This breaks compiler build with --enable-checking=yes,rtl,df,extra
[Bug target/99702] [11 Regression] ICE: RTL check: expected code 'const_int', have 'subreg' in riscv_expand_block_move, at config/riscv/riscv.c:3262 with memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99702 Zdenek Sojka changed: What|Removed |Added Known to fail||11.0 --- Comment #1 from Zdenek Sojka --- This might be a recent regression, r11-7696 works fine.
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602 --- Comment #31 from Jürgen Reuter --- (In reply to Paul Thomas from comment #30) > Created attachment 50442 [details] > Patch that "fixes" all versions of the problem.. so far :-) > > Hi Juergen, > > I think that this one does the job... it is even correct and regtests OK;-) > > I found that the gdb session was a miserable afair that didn't help at all > because of the change in dwarf versions. I would up reducing the testcase to > what you will find below. Please excuse my mutilation of Whizard! > > The chunk of whizard that you provided throws up all sorts of memories. In > the 1970's I used to go up to Caltech every Wednesday for Feynman and > Gell-mann seminars. I was around for the earliest days of partons and the > realisation that quarks might even be real. > > Paul > Hi Paul, that's a much nicer reproducer, congrats! And thanks for fixing this regression so timely. I confirm that all our tests work again with this fix. I guess the compilation and running with default flags (-g -O2) is not affected by this fix? But I will test once the fix is committed. Nice to hear that you had such a fun time at Calteach. I was never there unfortunately, but visited Stanford U. and SLAC a lot. And I was lucky to meet Gell-Mann as well, 2008 in Aspen at the physics center. To me the fix looks good to go, when it is pushed I will recompile gcc and run our code with all different combinations again. All the best, JRR
[Bug libstdc++/99692] Lookup for operator<< skips global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692 --- Comment #7 from Jonathan Wakely --- I mean that the test used in the library code is doing the right thing. I haven't investigated whether the compiler is not handling the lookup correctly, but I don't think there's a libstdc++ bug here.
[Bug c++/87699] Implement CWG 1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99701 --- Comment #9 from Jonathan Wakely --- (In reply to CVS Commits from comment #7) > 3) The overload descriptions for built-in operators were adjusted, >because objects of type std::nullptr_t cannot be used with relational >operators any more. This apparently wasn't completely done, see PR 99701.
[Bug c++/99701] std::nullptr_t can be compared with relational ops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99701 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed||2021-03-21
[Bug target/48097] gcc sometimes generates code that uses the buggy libgcc_s unwinder on darwin (originally exposed by Throw_2 failures in libjava testsuite under Xcode 4.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #19 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:c3d51b2d2382d44b0463b7ebaf12f3b788c9027e commit r10-9502-gc3d51b2d2382d44b0463b7ebaf12f3b788c9027e Author: Iain Sandoe Date: Mon Jan 18 20:09:10 2021 + dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097]. This address one of the more long-standing and serious regressions for Darwin. GCC emits unwind code by default on the assumption that the unwinder will be (of have the same capability) as the one in the current libgcc_s. For Darwin platforms, this is not the case - some of them are based on the libgcc_s from GCC-4.2.1 and some are using the unwinder provided by libunwind (part of the LLVM project). The latter implementation has gradually adopted a section that deals with GNU unwind. The most serious problem for some of the platform versions is in handling DW_CFA_remember/restore_state pairs. The DWARF description talks about these in terms of saving/restoring register rows; this is what GCC originally did (and is what the unwinders do for the Darwin versions based on libgcc_s). However, in r118068, this was changed so that not only the registers but also the current frame address expression were saved. The unwind code assumes that the unwinder will do this; some of Darwin's unwinders do not, leading to lockups etc. To date, the only solution has been to replace the system libgcc_s with a newer one which is not a viable solution for many end-users (since that means overwritting the one provided with the system installation). The fix here provides a target hook that allows the target to specify that the CFA should be reinstated after a DW_CFA_restore. This fixes the issue (and also the closed WONTFIX of 44107). (As a matter of record, it also fixes reported Java issues if backported to GCC-5). gcc/ChangeLog: PR target/44107 PR target/48097 * config/darwin-protos.h (darwin_should_restore_cfa_state): New. * config/darwin.c (darwin_should_restore_cfa_state): New. * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New. * doc/tm.texi: Regenerated. * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE. * dwarf2cfi.c (connect_traces): If the target requests, restore the CFA expression after a DW_CFA_restore. * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook. (cherry picked from commit 491d5b3cf8216f9285a67aa213b9a66b0035137b)
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #35 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:c3d51b2d2382d44b0463b7ebaf12f3b788c9027e commit r10-9502-gc3d51b2d2382d44b0463b7ebaf12f3b788c9027e Author: Iain Sandoe Date: Mon Jan 18 20:09:10 2021 + dwarf2unwind : Force the CFA after remember/restore pairs [44107/48097]. This address one of the more long-standing and serious regressions for Darwin. GCC emits unwind code by default on the assumption that the unwinder will be (of have the same capability) as the one in the current libgcc_s. For Darwin platforms, this is not the case - some of them are based on the libgcc_s from GCC-4.2.1 and some are using the unwinder provided by libunwind (part of the LLVM project). The latter implementation has gradually adopted a section that deals with GNU unwind. The most serious problem for some of the platform versions is in handling DW_CFA_remember/restore_state pairs. The DWARF description talks about these in terms of saving/restoring register rows; this is what GCC originally did (and is what the unwinders do for the Darwin versions based on libgcc_s). However, in r118068, this was changed so that not only the registers but also the current frame address expression were saved. The unwind code assumes that the unwinder will do this; some of Darwin's unwinders do not, leading to lockups etc. To date, the only solution has been to replace the system libgcc_s with a newer one which is not a viable solution for many end-users (since that means overwritting the one provided with the system installation). The fix here provides a target hook that allows the target to specify that the CFA should be reinstated after a DW_CFA_restore. This fixes the issue (and also the closed WONTFIX of 44107). (As a matter of record, it also fixes reported Java issues if backported to GCC-5). gcc/ChangeLog: PR target/44107 PR target/48097 * config/darwin-protos.h (darwin_should_restore_cfa_state): New. * config/darwin.c (darwin_should_restore_cfa_state): New. * config/darwin.h (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New. * doc/tm.texi: Regenerated. * doc/tm.texi.in: Document TARGET_ASM_SHOULD_RESTORE_CFA_STATE. * dwarf2cfi.c (connect_traces): If the target requests, restore the CFA expression after a DW_CFA_restore. * target.def (TARGET_ASM_SHOULD_RESTORE_CFA_STATE): New hook. (cherry picked from commit 491d5b3cf8216f9285a67aa213b9a66b0035137b)
[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96251 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:0b0a579191828727c232d26b513e3f4d9eeb9b3d commit r10-9504-g0b0a579191828727c232d26b513e3f4d9eeb9b3d Author: Iain Sandoe Date: Tue Feb 23 12:54:26 2021 + coroutines : Adjust error handling for type-dependent coroutines [PR96251]. Although coroutines are not permitted to be constexpr, generic lambdas are implicitly from C++17 and, because of this, a generic coroutine lambda can be marked as potentially constexpr. As per the PR, this then fails when type substitution is attempted because the check disallowing constexpr in the coroutines code was overly restrictive. This changes the error handing to mark the function as 'invalid_constexpr' but suppresses the error in the case that we are instantiating a constexpr. gcc/cp/ChangeLog: PR c++/96251 * coroutines.cc (coro_common_keyword_context_valid_p): Suppress error reporting when instantiating for a constexpr. gcc/testsuite/ChangeLog: PR c++/96251 * g++.dg/coroutines/pr96251.C: New test. (cherry picked from commit f13d9e48eeca7ed8f8df55c9a62fc9980d5606ad)
[Bug libgcc/99703] New: gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99703 Bug ID: 99703 Summary: gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: worx at pouf dot org Target Milestone: --- Hi, I'm using Gentoo, and I have an issue to build GCC 10.2.0 with a Via C3 Eden CPU. hecking for CET support... configure: error: Intel CET must be enabled on Intel CET enabled host make[2]: *** [Makefile:14350 : configure-stage1-lto-plugin] Erreur 1 I have met the same issue with binutils : https://sourceware.org/PR27397
[Bug libgcc/99703] gcc-10.2.0 with Via C3 Eden: configure: error: Intel CET must be enabled on Intel CET enabled host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99703 --- Comment #1 from Worx --- Created attachment 50445 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50445&action=edit host details emerge --info = More details about the host
[Bug c++/96251] [constexpr, coroutines] co_yield incorrectly rejected in non-explicitly-constexpr generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96251 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Iain Sandoe --- fixed for 10.3 and GCC 11.1
[Bug c++/99456] [11 regression] ABI breakage with some static initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99456 cqwrteur changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #16 from cqwrteur --- (In reply to Jakub Jelinek from comment #15) > Fixed. Hi Jakub. Is this a related issue? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99677
[Bug target/98914] [11 Regression] ICE in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98914 --- Comment #5 from CVS Commits --- The master branch has been updated by Xiong Hu Luo : https://gcc.gnu.org/g:d0a5e8e1a84bdd6ce915c3be65da8af2552cd49e commit r11-7755-gd0a5e8e1a84bdd6ce915c3be65da8af2552cd49e Author: Xionghu Luo Date: Sun Mar 21 21:14:02 2021 -0500 rs6000: Convert the vector set variable idx to DImode [PR98914] vec_insert defines the element argument type to be signed int by ELFv2 ABI. When expanding a vector with a variable rtx, convert the rtx type to DImode to support both intrinsic usage and other callers from rs6000_expand_vector_init produced by v[k] = val when k is long type. gcc/ChangeLog: 2021-03-21 Xionghu Luo PR target/98914 * config/rs6000/rs6000.c (rs6000_expand_vector_set_var_p9): Convert idx to DImode. (rs6000_expand_vector_set_var_p8): Likewise. gcc/testsuite/ChangeLog: 2021-03-21 Xionghu Luo PR target/98914 * gcc.target/powerpc/pr98914.c: New test.
[Bug target/98914] [11 Regression] ICE in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98914 luoxhu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from luoxhu at gcc dot gnu.org --- Fixed on master.
[Bug target/99704] New: volatile is needed on asm statements in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99704 Bug ID: 99704 Summary: volatile is needed on asm statements in Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com, ubizjak at gmail dot com Target Milestone: --- Target: i386,x86-64 Since CPUID instruction may return different values on hybrid core. volatile is needed on asm statements in .
[Bug target/99704] volatile is needed on asm statements in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99704 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com Last reconfirmed||2021-03-22 Status|UNCONFIRMED |NEW --- Comment #1 from H.J. Lu --- Created attachment 50446 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50446&action=edit A patch
[Bug target/99704] volatile is needed on asm statements in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99704 --- Comment #2 from Hongtao.liu --- How should we handle -march=native on hybrid core?
