[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 #12 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 think the implementation is still problematic since C++ 20 adds the
contiguous_iterator concept. The current implementation looks not to allow
custom
contiguous iterators types to be optimized as memmove.
It needs certain kinds of revamping IMO.
[Bug c/12245] [8/9/10 regression] Uses lots of memory when compiling large initialized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245 JeanHeyd Meneide changed: What|Removed |Added CC||phdofthehouse at gmail dot com --- Comment #75 from JeanHeyd Meneide --- I would like to add to this post. I experience severe memory usage and compilation time consumption that ramps up heavily when dealing with binary data. I documented much of my struggles here: https://thephd.github.io/embed-the-details I am being told that the functionality I am developing is more suited for a bug report and that this should be compiler QoI. Upon attempting to file this bug, I decided to throw my own data and woes into the ring here. Is there a place I should start looking to help out with this? I would like to start getting closer to the theoretical near-perfect overhead of dealing with what essentially ends up being a large binary payload, without resorting to #embed or any special builtins.
[Bug c++/93093] New: __builtin_source_location reports values for default arguments not aligned with the Standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093
Bug ID: 93093
Summary: __builtin_source_location reports values for default
arguments not aligned with the Standard
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: phdofthehouse at gmail dot com
Target Milestone: ---
Consider the following example from the C++ Standard N4842 (nice website
version: eel.is/c++draft/support.srcloc#cons-4):
===
struct s {
source_location member = source_location::current();
int other_member;
s(source_location loc = source_location::current())
: member(loc) // values of member refer to the location of the
calling function ([dcl.fct.default])
{}
s(int blather) :// values of member refer to this location
other_member(blather)
{}
s(double) // values of member refer to this location
{}
};
void f(source_location a = source_location::current()) {
source_location b = source_location::current(); // values in b refer to
this line
}
void g() {
f(); // f's first argument corresponds to this line of code
source_location c = source_location::current();
f(c); // f's first argument gets the same values as c, above
}
===
When source_location is implemented with __builtin_source_location, code like
the above does not report those locations. s{}.member does not refer to the
calling location, s(2.0).member does not refer to the constructor declaration
s, and s(1).member does not refer to that location, and so forth.
Some talking on IRC revealed that this might be because of constant evaluation
/ constant folding, changing how the source location attribute behaves in
instances like these. This also affects the patch at
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01579.html whose tests fail in
both static_assert and regular runtime VERIFYs.
[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 #11 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.
TBH. I would rather see the library does the optimization instead of the
compiler. I do not trust the compiler can always optimize this stuff.
Re: The gcc compiler detects functions in the C binary search program by default
Oh my god, this is a low-level mistake, not funny 8-0..
caipenghui
在 2019/12/29 10:50, Andrew Pinski 写道:
On Sat, Dec 28, 2019 at 6:31 PM caipenghui wrote:
hello everyone,
I found that gcc version 9.2.1 20191008,
i to compiles a binary search algorithm program that I write that only
checks the function prototype,
but does not check the name after the definition?
bsearch is a standard C function.
https://pubs.opengroup.org/onlinepubs/009695399/functions/bsearch.html
http://www.cplusplus.com/reference/cstdlib/bsearch/
Thanks,
Andrew Pinski
/ * binary bearch * /
#include
int bsearch(int x, int a[], int n);
int main(void)
{
int a[] = {
0, 555,
3, 4, 5,
6,
};
printf("%d\n", bsearch(0, a, sizeof a / sizeof a[0]));
return 0;
}
int abasjkjkerch(int x, int
a[], int n)
{
int low;
int hig;
int mid;
low = 0;
hig = n - 1;
while (low <= hig) {
mid = (low + hig) / 2;
if (x < *(a + mid))
hig = mid - 1;
else if (x > *(a + mid))
low = mid + 1;
else
return mid;
}
return -1;
}
Re: The gcc compiler detects functions in the C binary search program by default
On Sat, Dec 28, 2019 at 6:31 PM caipenghui wrote:
>
> hello everyone,
>
> I found that gcc version 9.2.1 20191008,
>
> i to compiles a binary search algorithm program that I write that only
> checks the function prototype,
>
> but does not check the name after the definition?
>
bsearch is a standard C function.
https://pubs.opengroup.org/onlinepubs/009695399/functions/bsearch.html
http://www.cplusplus.com/reference/cstdlib/bsearch/
Thanks,
Andrew Pinski
> / * binary bearch * /
> #include
> int bsearch(int x, int a[], int n);
> int main(void)
> {
> int a[] = {
> 0, 555,
> 3, 4, 5,
> 6,
> };
> printf("%d\n", bsearch(0, a, sizeof a / sizeof a[0]));
> return 0;
> }
>
>
> int abasjkjkerch(int x, int
> a[], int n)
> {
> int low;
> int hig;
> int mid;
>
> low = 0;
> hig = n - 1;
> while (low <= hig) {
> mid = (low + hig) / 2;
> if (x < *(a + mid))
> hig = mid - 1;
> else if (x > *(a + mid))
> low = mid + 1;
> else
> return mid;
> }
> return -1;
> }
>
>
The gcc compiler detects functions in the C binary search program by default
hello everyone,
I found that gcc version 9.2.1 20191008,
i to compiles a binary search algorithm program that I write that only
checks the function prototype,
but does not check the name after the definition?
/ * binary bearch * /
#include
int bsearch(int x, int a[], int n);
int main(void)
{
int a[] = {
0, 555,
3, 4, 5,
6,
};
printf("%d\n", bsearch(0, a, sizeof a / sizeof a[0]));
return 0;
}
int abasjkjkerch(int x, int
a[], int n)
{
int low;
int hig;
int mid;
low = 0;
hig = n - 1;
while (low <= hig) {
mid = (low + hig) / 2;
if (x < *(a + mid))
hig = mid - 1;
else if (x > *(a + mid))
low = mid + 1;
else
return mid;
}
return -1;
}
[Bug c++/93092] New: g++ takes tremendous compilation times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93092 Bug ID: 93092 Summary: g++ takes tremendous compilation times Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ad...@tho-otto.de Target Milestone: --- Created attachment 47558 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47558&action=edit preprocessed version of nfosmesa_init.cpp When compiling the attached, preprocessed file with -O2 (or above), and generating debug information, cc1plus takes incredible compilation times (>5min on a 4GHz Intel i7), and also uses incredible amounts of memory (> 16GB). The attached file is a preprocessed version of a source file from the ARAnyM project, and the original file contains just a single function. Tried on openSUSE Tumbleweed: $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/9/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++/9 --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=-9 --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 gcc version 9.2.1 20190903 [gcc-9-branch revision 275330] (SUSE Linux)
[Bug other/93090] RFE: Add a frontend for the Rust programming language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090 --- Comment #2 from John Paul Adrian Glaubitz --- (In reply to Jakub Jelinek from comment #1) > The Go FE actually isn't that independent, the same gofrontend is used by > both GCC and LLVM, the same FE written in C++ in that case has then a > compiler dependent layer for GCC and another one for LLVM. Right. I think this argument was partially true though for earlier implementations of the Go frontend in GCC, wasn't it? > So, is for the bountysource another interface for the rustc FE ok, or are > you looking for completely independent FE implementation? I'm fine with either way actually. My main motivation is to have a Rust compiler that supports more architectures than the one currently developed by the Rust develeopers. > And even if yes, can e.g. the runtime library be shared with rustc, > or does it need to be independent? If I understand the approach by "sapir" correctly, this is actually what's being worked on in his gcc-rust frontend: > https://github.com/sapir/gcc-rust/tree/rust > Again, talking about Go, I think the go runtime is shared by all of goland, > gcc-go and gollvm. Which would be perfectly fine with me. I didn't want to leave the impression that a completely independent implementation would be necessary. I just mentioned it because it was brought up as one of the arguments for having a Rust frondend in GCC within the community. I think the approach by "sapir" is actually very promising as it should be able to keep up with Rust upstream which is currently a rather fast moving target.
[Bug other/93090] RFE: Add a frontend for the Rust programming language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The Go FE actually isn't that independent, the same gofrontend is used by both GCC and LLVM, the same FE written in C++ in that case has then a compiler dependent layer for GCC and another one for LLVM. So, is for the bountysource another interface for the rustc FE ok, or are you looking for completely independent FE implementation? And even if yes, can e.g. the runtime library be shared with rustc, or does it need to be independent? Again, talking about Go, I think the go runtime is shared by all of goland, gcc-go and gollvm.
[Bug libfortran/93091] New: Apparent bugs in "sizeof" and "transfer" intrinsic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93091 Bug ID: 93091 Summary: Apparent bugs in "sizeof" and "transfer" intrinsic functions Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: thfanning at gmail dot com Target Milestone: --- Created attachment 47557 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47557&action=edit Code to demonstrate incorrect results. When actual arguments are passed to a subroutine that accepts polymorphic dummy arguments, the "sizeof" and "transfer" intrinsic functions can return strange results. For example: character(80) :: msg print *, sizeof(msg) ! prints "80" print *, size(transfer(msg,[0_c_int8_t]),kind=c_size_t) ! prints "80" call poly(msg) ! prints "1" and "1" where subroutine poly(obj) class(*) :: obj print *, sizeof(obj) print *, size(transfer(obj,[0_c_int8_t]),kind=c_size_t) end Also, integer :: iary(10) print *, sizeof(iary) ! prints "40" print *, size(transfer(iary,[0_c_int8_t]),kind=c_size_t) ! prints "40" call poly1(iary) ! prints "40" and "80" where subroutine poly1(obj) class(*) :: obj(:) print *, sizeof(obj) print *, size(transfer(obj,[0_c_int8_t]),kind=c_size_t) end See attached file for complete code that demonstrates these problems. The documentation for "sizeof" states that "The argument shall be of any type, rank or shape" and further, that "If the argument is polymorphic, the size according to the dynamic type is returned." Similar statements apply to the "transfer" intrinsic. The size for assumed-shape dummy arguments should be known, but inconsistent results occur as described above. Admittedly, the size for assumed-size dummy arguments may not be known.
[Bug other/93090] New: RFE: Add a frontend for the Rust programming language
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93090 Bug ID: 93090 Summary: RFE: Add a frontend for the Rust programming language Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de Target Milestone: --- This is a request for enhancement to add a frontend for the Rust programming language to GCC. Currently, there is only one official implementation of the Rust language which is the rustc compiler developed by the Rust developers. The goal of this enhancement request is to add a Rust frontend to GCC as an independent implementation, analogue to the already existing Go frontend. The benefits of having an independent implementation of the Rust language in GCC is that it helps writing a formal specification for the Rust language which doesn't exist yet as well as making the language available to a wider range of architectures which are supported by GCC but not LLVM which is what Rust uses as its backend. There are currently two ongoing development projects working on such a Rust frontend for GCC and either of them may be a potential candidate for this request for enhancement: > https://github.com/redbrain/gccrs > https://github.com/sapir/gcc-rust/tree/rust This bug report was created after a short discussion on the gcc-patches mailing list with the intention to create a campaign on BountySource.com to help stimulate the development with a financial incentive to anyone working on a Rust frontend for GCC: > https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01568.html I will be using this bug report to create a bounty on BountySource.com.
[Bug c++/93033] [10 Regression] error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033 Khem Raj changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #8 from Khem Raj --- with this patch I dont see the ICE I was seeing in quite a few qt apps as reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93077
[Bug c++/93036] [9/10 Regression] g++.dg/cpp2a/nontype-class27.C testcase accepted in -std=c++17 mode since r276248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93036 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-28 Ever confirmed|0 |1
[Bug target/93089] New: Force mprefer-vector-width=512 in 'e' simd clones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93089 Bug ID: 93089 Summary: Force mprefer-vector-width=512 in 'e' simd clones Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- The 'e' mangled simd clones that use 512-bit arguments/return value won't be really called if the caller isn't preferring 512-bit vectors, so it seems much better not to emit terrible code in those functions by trying to use only 256-bit vectors in there, which isn't fully possible anyway, as it needs to extract the arguments from 512-bit vectors and store the result there too. Unfortunately, we don't even allow prefer-vector-width= in target attribute.
[Bug target/93069] Assembler messages: Error: unsupported masking for `vextracti32x8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
--- Comment #3 from Jakub Jelinek ---
Note, the above isn't the smallest possible fix, so perhaps for backporting
instead of the gcc/config/i386/ changes
--- gcc/config/i386/sse.md.jj 2019-12-27 18:16:48.146431083 +0100
+++ gcc/config/i386/sse.md 2019-12-28 16:54:09.536217497 +0100
@@ -8782,7 +8782,8 @@ (define_expand "avx_vextractf128"
})
(define_insn "vec_extract_lo_"
- [(set (match_operand: 0 "nonimmediate_operand" "=v,v,m")
+ [(set (match_operand: 0 ""
+ "=v,v,")
(vec_select:
(match_operand:V16FI 1 ""
"v,,v")
@@ -8834,7 +8835,8 @@ (define_split
})
(define_insn "vec_extract_lo_"
- [(set (match_operand: 0 "" "=v,v,m")
+ [(set (match_operand: 0 ""
+ "=v,v,")
(vec_select:
(match_operand:VI8F_256 1 ""
"v,,v")
@@ -8844,7 +8846,7 @@ (define_insn "vec_extract_lo_ || !(MEM_P (operands[0]) && MEM_P (operands[1])))"
{
if ()
-return "vextract64x2\t{$0x0, %1, %0%{%3%}|%0%{%3%}, %1,
0x0}";
+return "vextract64x2\t{$0x0, %1,
%0|%0, %1, 0x0}";
else
return "#";
}
might be better, i.e. insist on _maskm patterns for masked operations into
memory and force non-memory destination for the rest of vector extractions,
plus the %{%3%} instead of I think can't work properly if zero
masking is needed into register destination.
[Bug target/93069] Assembler messages: Error: unsupported masking for `vextracti32x8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069 --- Comment #2 from Jakub Jelinek --- Created attachment 47556 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47556&action=edit gcc10-pr93069.patch Untested fix.
[Bug tree-optimization/93084] [10 regression] Infinite loop in ipa-cp when building clang with LTO+PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93084 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #4 from Martin Jambor --- I can't look into this now but couple of lines above there's an exit intended to prevent this kind of situation (AFAIU from a quick look now), just below the comment saying: /* If the lattice has already been propagated for the call site, no need to do that again. */ Can you have a look why it does not trigger? Thanks.
[Bug c++/93077] internal compiler error: in hash_operand during GIMPLE pass: fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93077
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2 from Arseny Solokha ---
(In reply to Jakub Jelinek from comment #1)
> I'm seeing a different ICE:
> pr93077.ii: In function ‘QVector itemVector()’:
> pr93077.ii:50312:36: error: incorrect sharing of tree nodes
> 50312 | static inline QVector itemVector()
> |^~
> *D.122849
> D.122849->description = QCoreApplication::translate ("QtModulesInfo", "Core
> non-GUI classes used by other modules", 0B, -1); [return slot optimization]
Which probably makes it a duplicate of PR93033.
[Bug rtl-optimization/93088] New: [10 Regression] Compile time hog on gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3 -funroll-loops -fno-tree-dominator-opts -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93088 Bug ID: 93088 Summary: [10 Regression] Compile time hog on gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3 -funroll-loops -fno-tree-dominator-opts -fno-tree-vrp Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: x86_64-unknown-linux-gnu gcc-10.0.0-alpha20191222 snapshot (r279712) takes inordinate time to compile gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3 -funroll-loops -fno-tree-dominator-opts -fno-tree-vrp: % timeout 30 x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20191222 -O3 -funroll-loops -fno-tree-dominator-opts -fno-tree-vrp -c pr56348.c zsh: exit 124 timeout 30 x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20191222 -O3-c perf top shows only these two entries during the compilation: Overhead Sha Symbol 83.70% cc1 [.] replace_single_def_regs 16.30% cc1 [.] find_reg_equal_equiv_note
[Bug c/93087] New: Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93087 Bug ID: 93087 Summary: Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))` Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sagebar at web dot de Target Milestone: --- Created attachment 47555 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47555&action=edit Issue demonstration Like the title implies, `-Wsuggest-attribute=cold` is emit for functions that were already given the `__attribute__((cold))` annotation The attached file demonstrates the issue, and should be compiled as: ``` gcc -c -O* attached-file.c ``` Where `*` can be any one of `` (empty), `1-3` (though not `0`), `g`, `s`, `fast` Note that the issue doesn't arise when no `-O*` flag is given at all (or when `-O0` is given)
[Bug target/93069] Assembler messages: Error: unsupported masking for `vextracti32x8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93069
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-12-28
CC||jakub at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Indeed, if the destination is memory, {z} is not allowed.
[Bug c/93072] [8/9/10 Regression] ICE: gimplifier segfault with undefined nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93072 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org Target Milestone|--- |8.4 --- Comment #2 from Jakub Jelinek --- Started with r267665 aka PR88720 and PR88726 fix.
[Bug bootstrap/93074] [10 regression] build FAIL with --enable-offload-targets=nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93074 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #6 from Jakub Jelinek --- Should be fixed now.
[Bug libgomp/93066] libgomp/target.c:525:46: error: expected expression before ')' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93066 --- Comment #3 from Andreas Schwab --- Or use (uintptr_t)-1 instead.
[Bug bootstrap/93074] [10 regression] build FAIL with --enable-offload-targets=nvptx-none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93074 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Sat Dec 28 09:26:03 2019 New Revision: 279747 URL: https://gcc.gnu.org/viewcvs?rev=279747&root=gcc&view=rev Log: PR bootstrap/93074 * plugin/cuda/cuda.h (cuDeviceGetName, cuDriverGetVersion): Declare. (cuDeviceTotalMem, cuMemGetInfo): Likewise. Define to *_v2. Modified: trunk/libgomp/ChangeLog trunk/libgomp/plugin/cuda/cuda.h
[Bug libgomp/93066] libgomp/target.c:525:46: error: expected expression before ')' token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93066 --- Comment #2 from Jakub Jelinek --- (In reply to dave.anglin from comment #1) > Including stdint.h after inttypes.h would avoid the problem That would be quite difficult, as stdint.h is included by libgomp.h that needs to be included first. An easier workaround might be not to use the UINTPTR_MAX macro at all, I think we can rely on uintptr_t being unsigned integral type and so instead of if (n->aux->attach_count[idx] < UINTPTR_MAX) we could use if (n->aux->attach_count[idx] + 1 != 0)
