[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #5 from Marc Glisse --- We could indeed relax a bit the "same type" condition. We could also make sure that __restrict appears somewhere in the call chain when using copy or uninitialized_*, which lets the compiler merge the 2 loads/stores. (In reply to fdlbxtqi from comment #2) > The last 2nd line return __dst is wrong. It should not exist. Write a patch, test it, and send it to the mailing list? (In reply to fdlbxtqi from comment #3) > For vector, the performance lost is even worse. It generates 96 lines of > assembly for different types since it does not call memmove. What operation are you doing on vector? None of your testcases seem to use it. > clearly incorrect Please distinguish between what is wrong (generated code crashes, or returns 3 instead of 2), and what is suboptimal.
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #6 from fdlbxtqi ---
> What operation are you doing on vector? None of your testcases seem to use
> it.
void copy_char_vector_with_iter(std::vector::iterator
out,std::vector const& bits)
{
std::copy_n(bits.begin(),bits.size(),out);
}
https://godbolt.org/z/_yA_Ls
See the assembly
> > clearly incorrect
>
> Please distinguish between what is wrong (generated code crashes, or returns
> 3 instead of 2), and what is suboptimal.
Suppose #ifdef __cpp_lib_is_constant_evaluated is not defined (for C++17)
It becomes:
return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
return __dst;
?
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #7 from Marc Glisse --- (In reply to fdlbxtqi from comment #6) > > > clearly incorrect > > > > Please distinguish between what is wrong (generated code crashes, or returns > > 3 instead of 2), and what is suboptimal. > > Suppose #ifdef __cpp_lib_is_constant_evaluated is not defined (for C++17) > > It becomes: > return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num); > return __dst; > > ? I should have kept the whole quote: > 1. libstdc++ does not use memmove for different trivially copyable objects. > It only uses it for the same type which is clearly incorrect.
[Bug tree-optimization/93063] New: Loop distribution and NOP conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93063
Bug ID: 93063
Summary: Loop distribution and NOP conversions
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
This comes from PR 93059.
void f(signed short*__restrict p,unsigned short*__restrict q,int n){
for(int i=0;i
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #8 from Marc Glisse ---
(In reply to fdlbxtqi from comment #6)
> void copy_char_vector_with_iter(std::vector::iterator
> out,std::vector const& bits)
> {
> std::copy_n(bits.begin(),bits.size(),out);
> }
>
> https://godbolt.org/z/_yA_Ls
> See the assembly
Thanks, I just filed PR 93063 about a subpart that the compiler should be able
to do without help from the library.
[Bug c++/93064] New: ICE on C++20 operator<=> use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93064
Bug ID: 93064
Summary: ICE on C++20 operator<=> use
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Target Milestone: ---
» cat x.cpp
#include
#include
struct D {
D() { printf("*D\n"); }
~D() { printf("~D\n"); }
auto operator<=>(const D &) = default;
};
int main()
{
D d;
d <=> d;
}
» g++-10 -v x.cpp -std=c++2a
Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/10/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--disable-werror --with-gxx-include-dir=/usr/include/c++/10 --enable-ssp
--disable-libssp --disable-libvtv --disable-cet --disable-libcc1
--enable-plugin --with-bugurl=https://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-10 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191210 (experimental) (SUSE Linux)
COLLECT_GCC_OPTIONS='-v' '-std=c++2a' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/lib64/gcc/x86_64-suse-linux/10/cc1plus -quiet -v -D_GNU_SOURCE x.cpp
-quiet -dumpbase x.cpp -mtune=generic -march=x86-64 -auxbase x -std=c++2a
-version -o /tmp/ccBzGUTo.s
GNU C++17 (SUSE Linux) version 10.0.0 20191210 (experimental)
(x86_64-suse-linux)
compiled by GNU C version 10.0.0 20191210 (experimental), GMP version
6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/10
/usr/include/c++/10/x86_64-suse-linux
/usr/include/c++/10/backward
/usr/lib64/gcc/x86_64-suse-linux/10/include
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/10/include-fixed
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/include
/usr/include
End of search list.
GNU C++17 (SUSE Linux) version 10.0.0 20191210 (experimental)
(x86_64-suse-linux)
compiled by GNU C version 10.0.0 20191210 (experimental), GMP version
6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 17fc461878f813b85b050d0380f89fc7
x.cpp:6:7: error: defaulted ‘auto D::operator<=>(const D&)’ must be ‘const’
6 | auto operator<=>(const D &) = default;
| ^~~~
x.cpp: In member function ‘constexpr auto D::operator<=>(const D&)’:
x.cpp:6:7: internal compiler error: Segmentation fault
0x7fa3e9f2a14f ???
/usr/src/debug/glibc-2.30-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7fa3e9f14e0a __libc_start_main
../csu/libc-start.c:308
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/93064] ICE on C++20 operator<=> use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93064 --- Comment #1 from Jan Engelhardt --- Possibly a duplicate of #92496 (the automatic "Possible duplicates" in the New Bug form was slow to load), but my preconditions are different: I don't have a public data member, nor is a template used like 92496.
[Bug middle-end/68360] GCC bitfield processing code is very inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360 --- Comment #5 from Andrew Pinski --- (In reply to Eric Botcazou from comment #4) > > it returns QImode. If it returned SImode as on SPARC, the code would be: SLOW_BYTE_ACCESS set to 0 is the cause there ...
[Bug libgcc/93053] libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 --- Comment #4 from Roman Zhuykov --- Maybe this should be catched earlier in configure scripts? Are there any simple workaround without patching the gcc source? I'm not familiar with different armvN -march option values. Probably it can help choosing some cpu family which doesn't support lse? PS. Cfarm gcc117 and 118 are not available at the moment, and 113-116 have same hardware and old binutils 2.24.
[Bug libgcc/93053] libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 --- Comment #5 from Andrew Pinski --- (In reply to Roman Zhuykov from comment #4) > PS. Cfarm gcc117 and 118 are not available at the moment, and 113-116 have > same hardware and old binutils 2.24. Just compile your own new binutils first. GCC does pick up the binutils from the PATH first when doing a bootstrap.
[Bug target/93061] Optimising for size -Os causes segfault with AES-NI reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93061 Mutex changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Mutex --- Doesn't crash if aligned_alloc is used to allocate the buffers. Suppose this should be used with the AES-NI functions really.
[Bug tree-optimization/93055] accumulation loops in stepanov_vector benchmark use more instruction level parpallelism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- GCC is missing a smarter unrolling that would factor dependency chains is such tiny loops. Also, how on Earth do we get this invariant computation inside the loop? > lea0x2100(%rsp),%rdi That's probably a regression that could be investigated and fixed separately.
[Bug libgomp/93065] New: libgomp: destructor missing to delete goacc_cleanup_key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93065
Bug ID: 93065
Summary: libgomp: destructor missing to delete
goacc_cleanup_key
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: v.narang at samsung dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
libgomp constructor creates goacc_cleanup_key on dlopen but doesn't delete key
on dlclose. dlopen and dlclose of libgomp.so exhausts pthread keys, which
results in pthread_key_create failure.
pthread_key_delete needs to be called by libgomp destructor.
Test Code:
#include
#include
#include
int main(int argc, char **argv)
{
void *handle;
double (*cosine)(double);
char *error;
while(1) {
handle = dlopen("/usr/lib/libgomp.so", RTLD_LAZY);
if (!handle) {
fprintf(stderr, "%s\n", dlerror());
exit(EXIT_FAILURE);
}
dlclose(handle);
}
exit(EXIT_SUCCESS);
}
Test Logs:
$./a.out
libgomp: could not create thread pool destructor
[Bug middle-end/93041] GCC 10 removes an infinite loop and causes a null pointer to dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041 --- Comment #4 from WHR --- OK, I'm now fully understood what's happens. If the loop breaks, 'p' must be 0, so the later '**p' will dereference a null pointer. Looks like this is actually a feature...
[Bug libgomp/93066] New: libgomp/target.c:525:46: error: expected expression before ')' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93066 Bug ID: 93066 Summary: libgomp/target.c:525:46: error: expected expression before ')' token Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 The following build error occurs: /bin/sh ./libtool --tag=CC --mode=compile /test/gnu/gcc/objdir/./gcc/xgcc -B/ test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/bin/ -B/o pt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-10/hppa 64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/sys-i nclude -fno-checking -DHAVE_CONFIG_H -I. -I../../../gcc/libgomp -I../../../gc c/libgomp/config/hpux -I../../../gcc/libgomp/config/posix -I../../../gcc/libgomp -I../../../gcc/libgomp/../include -Wall -Werror -Wc,-pthread -g -O2 -MT targe t.lo -MD -MP -MF .deps/target.Tpo -c -o target.lo ../../../gcc/libgomp/target.c libtool: compile: /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-10/hppa64 -hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/include -i system /opt/gnu64/gcc/gcc-10/hppa64-hp-hpux11.11/sys-include -fno-checking -DHAV E_CONFIG_H -I. -I../../../gcc/libgomp -I../../../gcc/libgomp/config/hpux -I../.. /../gcc/libgomp/config/posix -I../../../gcc/libgomp -I../../../gcc/libgomp/../in clude -Wall -pthread -Werror -g -O2 -MT target.lo -MD -MP -MF .deps/target.Tpo - c ../../../gcc/libgomp/target.c -DPIC -o .libs/target.o ../../../gcc/libgomp/target.c: In function 'gomp_attach_pointer': ../../../gcc/libgomp/target.c:525:46: error: expected expression before ')' toke n 525 | if (n->aux->attach_count[idx] < UINTPTR_MAX) | ^ On HP-UX, we have in inttypes.h, /* The following 2 macros are provided for testing whether the types ** intptr_t and uintptr_t (integers large enough to hold a void *) are ** defined in this header. They are needed in case the architecture can't ** represent a pointer in any standard integral type. */ #define INTPTR_MAX #define UINTPTR_MAX UINTPTR_MAX is defined in stdint.h which doesn't seem to be included.
[Bug tree-optimization/93055] accumulation loops in stepanov_vector benchmark use more instruction level parpallelism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055 --- Comment #2 from Alexander Monakov --- Can you attach preprocessed source and double-check command-line flags? I can't reproduce the problem with lea, and the code does not have explicit prefetch instructions that I get with -O3 -march=bdver1
[Bug tree-optimization/93055] accumulation loops in stepanov_vector benchmark use more instruction level parpallelism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055 --- Comment #3 from Jan Hubicka --- Created attachment 47546 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47546&action=edit preprocessed benchmark I am attaching preprocessed source. I used -O3 -march=native -fno-prefetch-loops-arrays (since I was more interested in the dependency chain breaking). It expands to: /aux/hubicka/trunk-install/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/cc1plus -quiet -v -I . -imultiarch x86_64-linux-gnu -D_GNU_SOURCE stepanov_vector.cpp -march=bdver1 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mlwp -mno-fma -mfma4 -mxop -mno-bmi -mno-sgx -mno-bmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mxsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-cldemote -mno-ptwrite -mno-avx512bf16 -mno-enqcmd -mno-avx512vp2intersect --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver1 -quiet -dumpbase stepanov_vector.cpp -auxbase stepanov_vector -g -O3 -std=c++14 -version -fno-prefetch-loop-arrays -o /tmp/ccN2TJcU.s
[Bug tree-optimization/93056] Poor codegen for heapsort in stephanov_vector benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93056 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- The benchmark sorts a 2000-entry random array, so GCC's version runs with high branch misprediction rate. Clang's version is if-converted, it issues one extra load compared to gcc. PRE makes it very difficult to if-convert this on RTL, with -fno-tree-pre we even get nicer code but still not if-converted, so slower than Clang.
[Bug tree-optimization/93055] accumulation loops in stepanov_vector benchmark use more instruction level parpallelism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055 --- Comment #4 from Alexander Monakov --- The attachment is edited to test insertion_sort, and doesn't call accumulate_vector at all - looks like you attached a wrong file?
[Bug tree-optimization/93051] Wrong optimizations for pointers: `if (p == q) use p` -> `if (p == q) use q`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93051
--- Comment #3 from Alexander Cherepanov ---
For completeness, an example with a guessed pointer, based on the testcase from
bug 65752, comment 0, gcc-only (dom2):
--
#include
#include
__attribute__((noipa)) // imagine it in a separate TU
static uintptr_t opaque_to_int(void *p) { return (uintptr_t)p; }
int main()
{
int x;
int *p = &x;
uintptr_t ip = (uintptr_t)p;
uintptr_t iq = 0;
while (iq < ip)
iq++;
uintptr_t ir = opaque_to_int(p); // hide provenance of p
if (ir == iq) {
*p = 1;
*(int *)ir = 2;
printf("result: %d\n", *p);
}
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191224 (experimental)
--
[Bug tree-optimization/93052] Wrong optimizations for pointers: `p == q ? p : q` -> `q`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052 --- Comment #5 from Alexander Cherepanov --- 1. It should be noted that the idea of problems arising from `p == q ? p : q` is from Chung-Kil Hur via bug 65752, comment 15. 2. clang bug -- https://bugs.llvm.org/show_bug.cgi?id=44374.
[Bug c/55791] gcc fails to detect wrong type in sizeof in malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55791 --- Comment #4 from Eric Gallager --- For reference, clang catches this with its static analyzer: $ clang --analyze 55791.c 55791.c:10:15: warning: Result of 'malloc' is converted to a pointer of type 'char', which is incompatible with sizeof operand type 'char *' p = (char *) malloc( 10 * sizeof( char *)); ~~ ^~ ~~~ 1 warning generated. $ Since gcc will be getting a static analyzer, too, once David Malcolm's analyzer branch is merged, we could do this warning there, but I think it would make more sense to do this warning in the compiler proper, though.
[Bug other/93067] New: diagnostics are not aware of -finput-charset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067 Bug ID: 93067 Summary: diagnostics are not aware of -finput-charset Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: lhyatt at gmail dot com Target Milestone: --- Created attachment 47547 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47547&action=edit Candidate patch Hello- When source lines are needed for diagnostics output, they are retrieved from the source file by the fcache infrastructure in input.c, since libcpp has generally already forgotten them already (plus not all front ends are using libcpp). This infrastructure does not read the files in the same way as libcpp does; in particular, it does not translate the encoding as requested by -finput-charset, and it does not strip a UTF-8 BOM if present. The attached patch adds this ability. My thinking in deciding how to do it was the following: - Use of -finput-charset is rare, and use of UTF-8 BOMs must be rarer still, so this patch should try hard not to introduce any worse performance unless these features are being used. - It is desirable to reuse libcpp's encoding infrastructure from charset.c rather than repeat it in input.c. (Notably, libcpp uses iconv but it also has hand-coded routines for certain charsets to make sure they are available.) - There is a performance degradation required in order to make use of libcpp directly, because the input.c infrastructure only reads as much of the source file as necessary, whereas libcpp interfaces require to read the entire file into memory. - It can't be quite as simple as just "only delegate to libcpp if -finput-charset was specified", because the stripping of the UTF-8 BOM has to happen with or without this option. - So it seemed a reasonable compromise to me, if -finput-charset is specified, then use libcpp to convert the file, otherwise, strip the BOM in input.c and then process the file the same way it is done now. There's a little bit of leakage of charset logic from libcpp this way, but it seems worthwhile, since otherwise, diagnostics would always be reading the entire file into memory, which is not a cost paid currently. Hope that makes some sense. One thing I wasn't sure of, is what's the right way to communicate to input.c that libcpp is being used to process the source files. I added a global variable for this because I didn't see any other way to do it without making drastic changes. This requires C-family and Fortran front-ends, and any future libcpp users, to set the variable; basically it makes explicit the fact that there's a single global cpp_reader object in use. If there's a less-bad way to do it, please let me know... If the global cpp_reader variable doesn't get set, then the behavior is the same as current. Separate from the attached patch are two testcases that both fail before this patch and pass after. I attached them gzipped because they use non-standard encodings. If this overall approach seems OK, please let me know and I can prepare it for gcc-patches. bootstrap + reg test look good on x86-64 linux. Thanks! -Lewis
[Bug other/93067] diagnostics are not aware of -finput-charset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067 --- Comment #1 from Lewis Hyatt --- Created attachment 47548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47548&action=edit testcases
[Bug ada/93068] New: Professional Dissertation Writing Services
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93068 Bug ID: 93068 Summary: Professional Dissertation Writing Services Product: gcc Version: new-ra Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: alicethomas056 at gmail dot com Target Milestone: --- Professional writing services Professional https://thedigitalwebs.com/";>dissertation writing service for exposition writing are of incredible assistance to postgraduate students. It is an enormous endeavor to compose a Ph.D. paper. As needs are, there are various individuals who feel that completing such scholarly writing, which is essential so as to finish the program, is one of the most intricate assignments they have needed to do in their life. While taking a shot at one's degree, most of the students are ordered to complete a Ph.D. thesis. This is a record with various sections that subtleties one's finding and individual research on explicit examination zones. On the off chance that you have nearly finished your exposition, you might feel restless about whether you have had the option to precisely speak to your exploration in the writing. This is the reason various Ph.D. students have taken to utilizing a thesis writing administration and utilizing paper editors for the contract. When picking a proofreader, employ one with experience and a built-up record of achievement. The entire time you will compose such scholarly research records as dissertations, all things considered, your essential center will utilize new ends and discoveries that you have had the option to reveal in your own examinations to integrate past research. When you arrive at the part of the arrangement, it can appear to be practically strange. Except if you have an educator or counsel with heaps of extra time, getting a person that would will and ready to peruse your record for attachment and congruity can be fairly hard. Objectivity is one quality that must completely be controlled by an editorial manager. Contract a scholastic editorial manager who is unprejudiced and has composed a Ph.D. thesis previously. It is consequently that various people suggest that you utilize thesis editing services and contract an editorial manager before you at long last turn in the last draft of your paper. Various students are of the conclusion that to so as to satisfy degree prerequisites one must be absolutely in control for all the exposition angles. Regardless, this is the perfect method for permitting sentence structure and wording blunders discover their way to your last draft. You ought to do all that you can to guarantee that the last record is impeccable. All things considered, you will probably have dealt with it from anyplace between one to five years. Exposition writing services and an editorial manager for the contract can give you the preferred position you have to prevail in the scholarly world without an unreasonable measure of time and stress. On the off chance that you need a professional manager, procure one who, notwithstanding editing, can enable you to spot blunders in your references, commentaries, creator's names, dates, references, and the quality and rationale of your contentions. In like manner, you will have the option to turn in the last thesis with certainty. In the back of your psyche, you will realize that it is in all ways a predominant quality scholastic paper. You will discover comfort in the way that a proofreader for the contract of a person who is very much educated about scholarly writing has examined through your report and consoled you that it has been composed with both expert and clearness.
[Bug tree-optimization/81396] [7/8 Regression] Optimization of reading Little-Endian 64-bit number with portable code has a regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81396 --- Comment #10 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #4) > Either we can do something in the bswap pass with it as done in this > untested patch, or we could consider match.pd optimization for: > _3 = BIT_FIELD_REF <_7, 8, 16>; > _32 = (typeof(_7)) _3; > _4 = _32 << 16; > into: > _4 = _7 & (((1ULL << 8) - 1) << 16); I am implementing the above because when I was adding detecting bit_insert more, bswap goes not understand bit_insert, plus we can optimize this earlier.
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #10 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #9)
> (In reply to Marc Glisse from comment #8)
> > (In reply to fdlbxtqi from comment #6)
> > > void copy_char_vector_with_iter(std::vector::iterator
> > > out,std::vector const& bits)
> > > {
> > > std::copy_n(bits.begin(),bits.size(),out);
> > > }
> > >
> > > https://godbolt.org/z/_yA_Ls
> > > See the assembly
> >
> > Thanks, I just filed PR 93063 about a subpart that the compiler should be
> > able to do without help from the library.
>
> I have tried the same benchmark on clang. It has the same issue. However,
> GCC's optimization of this would inspire Clang I believe.
and libc++
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #9 from fdlbxtqi ---
(In reply to Marc Glisse from comment #8)
> (In reply to fdlbxtqi from comment #6)
> > void copy_char_vector_with_iter(std::vector::iterator
> > out,std::vector const& bits)
> > {
> > std::copy_n(bits.begin(),bits.size(),out);
> > }
> >
> > https://godbolt.org/z/_yA_Ls
> > See the assembly
>
> Thanks, I just filed PR 93063 about a subpart that the compiler should be
> able to do without help from the library.
I have tried the same benchmark on clang. It has the same issue. However, GCC's
optimization of this would inspire Clang I believe.
[Bug tree-optimization/93063] Loop distribution and NOP conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93063 --- Comment #1 from Marc Glisse --- Created attachment 47549 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47549&action=edit Untested patch Not ready, at the very least it misses a comment and a test, but it shows where the test needs relaxing.
[Bug tree-optimization/83784] Missed optimization with bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83784 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/83784] Missed optimization with bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83784 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Andrew Pinski --- Mine, for GCC 11. I have patches which improve things but not fully yet.
[Bug target/93062] Failed to generate indirect branch for long branches on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #1 from Jim Wilson --- We need to check length attributes in the branch patterns, and emit different sequences depending on the length. There are multiple examples to compare with, for instance the condjump pattern in the aarch64.md file.
[Bug testsuite/93045] gc bug with test "start_unit-test-1.c"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93045 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #1 from Jim Wilson --- This worked for me running natively on a fedora rawhide system with a 4.15 linux kernel.
[Bug target/93062] Failed to generate indirect branch for long branches on riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-25 Ever confirmed|0 |1
[Bug target/93069] New: Assembler messages: Error: unsupported masking for `vextracti32x8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
Bug ID: 93069
Summary: Assembler messages: Error: unsupported masking for
`vextracti32x8'
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: assemble-failure
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
gas 2.33.1 rejects the code generated by gcc-10.0.0-alpha20191222 snapshot
(r279712) w/ -march=skylake-avx512 -O2 -fopenmp-simd for the following
testcase:
#pragma omp declare simd
int
hm (int vk, int r8)
{
return vk == 0 ? vk : r8;
}
% x86_64-pc-linux-gnu-gcc-10.0.0-alpha20191222 -march=skylake-avx512 -O2
-fopenmp-simd -c knlviqq0.c
/tmp/ccT8evyF.s: Assembler messages:
/tmp/ccT8evyF.s:198: Error: unsupported masking for `vextracti32x8'
182 _ZGVeN16vv_hm:
183 .LFB7:
184 .cfi_startproc
185 pushq %rbp
186 .cfi_def_cfa_offset 16
187 .cfi_offset 6, -16
188 vpxor %xmm2, %xmm2, %xmm2
189 vpcmpd $4, %ymm2, %ymm0, %k1
190 movq%rsp, %rbp
191 .cfi_def_cfa_register 6
192 andq$-64, %rsp
193 addq$-128, %rsp
194 movq%fs:40, %rax
195 movq%rax, 120(%rsp)
196 xorl%eax, %eax
197 vextracti32x8 $0x1, %zmm0, %ymm0
198 vextracti32x8 $0x0, %zmm1, 32(%rsp){%k1}{z}
199 vpcmpd $4, %ymm2, %ymm0, %k1
200 vextracti32x8 $0x1, %zmm1, %ymm0{%k1}{z}
201 vmovdqa64 %ymm0, 64(%rsp)
202 vmovdqu32 32(%rsp), %zmm0
203 movq120(%rsp), %rax
204 subq%fs:40, %rax
205 jne .L37
206 leave
207 .cfi_remember_state
208 .cfi_def_cfa 7, 8
209 ret
[Bug c++/93070] New: std::__lg (and all functions that use it) generates suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93070
Bug ID: 93070
Summary: std::__lg (and all functions that use it) generates
suboptimal code
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at mailinator dot com
Target Milestone: ---
On Godbolt, the following code:
```
#include
int f(int x){
return std::__lg(x);
}
int g(int x){
return 31-__builtin_clz(x);
}
int h(int x){
return 31^__builtin_clz(x);
}
```
compiles to:
```
f(int):
bsr edi, edi
mov eax, 31
xor edi, 31
sub eax, edi
ret
g(int):
bsr edi, edi
mov eax, 31
xor edi, 31
sub eax, edi
ret
h(int):
bsr eax, edi
ret
```
Only `h` are optimal. `f` and `g` has a tiny slowdown with redundant `31-` and
`31^`.
Suggestion: The better option would be to recognize `(power of 2 - 1) ^ x` and
`(power of 2 - 1) - x` as equal, but otherwise it's possible to just change the
`__lg` implementation to use `^` instead of `-` when the size is a power of 2.
[Bug c++/93071] New: std::__lg (and all functions that use it) generates suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93071
Bug ID: 93071
Summary: std::__lg (and all functions that use it) generates
suboptimal code
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at mailinator dot com
Target Milestone: ---
On Godbolt, the following code:
```
#include
int f(int x){
return std::__lg(x);
}
int g(int x){
return 31-__builtin_clz(x);
}
int h(int x){
return 31^__builtin_clz(x);
}
```
compiles to:
```
f(int):
bsr edi, edi
mov eax, 31
xor edi, 31
sub eax, edi
ret
g(int):
bsr edi, edi
mov eax, 31
xor edi, 31
sub eax, edi
ret
h(int):
bsr eax, edi
ret
```
Only `h` are optimal. `f` and `g` has a tiny slowdown with redundant `31-` and
`31^`.
Suggestion: The better option would be to recognize `(power of 2 - 1) ^ x` and
`(power of 2 - 1) - x` as equal, but otherwise it's possible to just change the
`__lg` implementation to use `^` instead of `-` when the size is a power of 2.
[Bug c++/93070] std::__lg (and all functions that use it) generates suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93070 John Simon changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from John Simon --- Duplicate of 93071. *** This bug has been marked as a duplicate of bug 93071 ***
[Bug c++/93071] std::__lg (and all functions that use it) generates suboptimal code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93071 --- Comment #1 from John Simon --- *** Bug 93070 has been marked as a duplicate of this bug. ***
