[Bug c/98460] New: _builtin_cpu_supports("sha") missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98460
Bug ID: 98460
Summary: _builtin_cpu_supports("sha") missing
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
gcc offers a useful builtin around the cpuid instruction on x86 and x86_64,
which can be used to check for specific instruction set extensions, e.g.
if (_builtin_cpu_supports("avx2"))
I need to check for the SHA-NI extension, which does not appear to be
supported.
However, checking for AES-NI is supported with the string "aes".
[Bug analyzer/100294] New: need attribute takes_ownership
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100294 Bug ID: 100294 Summary: need attribute takes_ownership Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: felix-gcc at fefe dot de Target Milestone: --- Now that -fanalyzer is here to track leaking memory, I need a way to tell gcc that a function takes ownership of a pointer. You could call it takes_ownership or maybe free. Here's my setup: I have a function that does I/O batching for you. You have a batch as a context variable, then you add buffers to it, then you write the whole batch to a descriptor (or callback). The idea is that the descriptor can point to a non-blocking socket and the abstraction takes care of repeatedly writing the next bit in the vector after a partial write. Anyway, I have a function that adds a buffer to the batch, and I have a function that adds a buffer to the batch plus the batch takes ownership of the pointer, i.e. when you are done with the batch and close it, all those pointers will be freed. -fanalyze now (rightly) complains that I'm leaking the memory of the pointer I gave to the function that takes ownership. I need a way to either say "takes ownership" or maybe, even better, a way to say how the free will happen, so malloc+free matching in gcc 11 can apply.
[Bug other/107614] New: build goes through but make install fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107614 Bug ID: 107614 Summary: build goes through but make install fails Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: felix-gcc at fefe dot de Target Milestone: --- I'm trying to build the current gcc git and install it to /opt/gcc so it doesn't clash with the system gcc. This is on x86_64 Linux. The build goes through but make install fails in x86_64-pc-linux-gnu/libsanitizer/lsan: /usr/bin/mkdir -p '/tmp/fefix/usr/lib64/../lib64' /opt/diet/bin/install -c -m 644 liblsan_preinit.o '/tmp/fefix/usr/lib64/../lib64' /usr/bin/mkdir -p '/tmp/fefix/usr/lib64/../lib64' /bin/sh ../libtool --mode=install /opt/diet/bin/install -c liblsan.la '/tmp/fefix/usr/lib64/../lib64' libtool: install: error: cannot install `liblsan.la' to a directory not ending in /opt/gcc/lib64/../lib64 /tmp/fefix is my $DESTDIR for this make install. gcc make install is trying to install liblsal to /usr/lib64 but libtool refuses because that's not under /opt/gcc/lib64 where the rest of gcc goes.
[Bug other/107614] build goes through but make install fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107614 felix-gcc at fefe dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from felix-gcc at fefe dot de --- oops sorry my build script was at fault.
[Bug c/105728] New: dead store to static var not optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105728
Bug ID: 105728
Summary: dead store to static var not optimized out
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
Consider this piece of test code:
int dummy1()
{
static int removeme = 0;
if (removeme)
{
return 0;
}
removeme = 1;
return 0;
}
int dummy2()
{
static int removeme = 0;
if (!removeme)
removeme = 1;
return 0;
}
int dummy3()
{
static int removeme = 0;
removeme = 1;
return 0;
}
To me, all of these do the same thing and should generate the same code.
As nobody else can see removeme, and we aren't leaking its address, shouldn't
the compiler be able to deduce that all accesses to removeme are
inconsequential and can be removed?
My gcc 11.3 generates a condidion and a store and a return 0 for dummy1, the
same thing for dummy2, but for dummy3 it understands that it only needs to emit
a return 0.
[Bug ipa/105728] dead store to static var not optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105728 --- Comment #4 from felix-gcc at fefe dot de --- If you do have a printf that references debug_cnt, it wouldn't be removed, right? If you expect unreferenced variables to not be optimized out, you can always compile without optimizer. For local variables even that doesn't help with clang already. OTOH we do have attributes "used" and "unused". They could be extended to variables.
[Bug driver/114658] New: branch "releases/gcc-13" builds "gcc version 14.0.1 (experimental)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114658 Bug ID: 114658 Summary: branch "releases/gcc-13" builds "gcc version 14.0.1 (experimental)" Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: felix-gcc at fefe dot de Target Milestone: --- Not sure how and where to file this bug, sorry. I'm trying to build the current stable release branch, i.e. 13.2 with bug fixes from git. So I do git checkout releases/gcc-13 and build gcc, but the result doesn't say it is gcc 13.2.1, it says it's gcc 14.0.1 (experimental). Shouldn't this branch contain the non-experimental version?
[Bug driver/114658] branch "releases/gcc-13" builds "gcc version 14.0.1 (experimental)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114658 --- Comment #2 from felix-gcc at fefe dot de --- I'm probably doing something really stupid wrong, sorry for the noise. Here's what I'm doing: $ git checkout releases/gcc-13 Switched to branch 'releases/gcc-13' $ git branch master * releases/gcc-13 $ cat gcc/BASE-VER 14.0.1
[Bug driver/114658] branch "releases/gcc-13" builds "gcc version 14.0.1 (experimental)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114658 felix-gcc at fefe dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from felix-gcc at fefe dot de --- ok it looks like it was my fault (surprise) and I fixed it. Here's what I did: $ git checkout master Switched to branch 'master' Your branch is up to date with 'origin/master'. $ git branch -D releases/gcc-13 Deleted branch releases/gcc-13 (was 32fb04adae9). $ git checkout releases/gcc-13 Updating files: 100% (40334/40334), done. branch 'releases/gcc-13' set up to track 'origin/releases/gcc-13'. Switched to a new branch 'releases/gcc-13' $ cat gcc/BASE-VER 13.2.1 Sorry again for the noise. Hope this helps the next git noob :)
[Bug c/117810] New: Feature request: attribute access but for (start, end) type interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117810 Bug ID: 117810 Summary: Feature request: attribute access but for (start, end) type interfaces Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: felix-gcc at fefe dot de Target Milestone: --- I love attribute access, I use it all the time in my projects. You can tell the compiler that the function reads n elements from a pointer, and n is given as a function argument. But not all functions work like that. In fact, C++ iterators don't. My LDAP code also doesn't. It looks like this: size_t scan_asn1BOOLEAN(const char* src,const char* max,int* l); Instread of src and len I pass src and max. The reasoning is that you will use these functions to iterate over multiple serialized elements. The common pattern for that will be to move the pointer forward until you hit the end. If I pass a length, then the caller would have to decrement the length, too. That is a burden the caller does not need to carry, so I'm trying to relieve them of it. Unfortunately attribute access does not work because since I can't point it to a length, I can only express that I will read one byte from src, which is not true. It might in fact be wrong because if src == max then I won't be reading anything. Please extend attribute access to also work if the second argument given is not an int but another pointer of the same type. Or you could give me a new attribute doing the same thing under another name for backwards compatibility. I don't care. I just want to be able to annotate my code properly.
[Bug c/117809] New: feature request: attribute malloc but for non-function-return-value return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117809 Bug ID: 117809 Summary: feature request: attribute malloc but for non-function-return-value return values Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: felix-gcc at fefe dot de Target Milestone: --- I love attribute malloc! I would like to annotate all my functions with it where applicable! But you can only do it for functions that return the malloced memory as return value from the function. What about this type of function: errno_t my_malloc(void** ptr, size_t len); I'd love to add something like this: __attribute__((malloc2(1,my_free,2))) errno_t my_malloc(void** ptr, size_t len); Here is a more real-world example, from the GNUNET interface to jansson (json lib): struct GNUNET_JSON_Specification GNUNET_JSON_spec_json (const char *name, json_t **jsonp); I'd like to be able to annotate the second argument.
[Bug c/117810] Feature request: attribute access but for (start, end) type interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117810 --- Comment #2 from felix-gcc at fefe dot de --- Hmm, now that you mention it explicitly... Just like C++ iterators, max does not actually point at the last element in the array but at the first element behind the array. That appears to be more natural in C to me. Like you do in a for loop iterating over an array: for (i=0; i
[Bug analyzer/117807] New: analyzer gets confused by integer promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117807
Bug ID: 117807
Summary: analyzer gets confused by integer promotion
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: felix-gcc at fefe dot de
Target Milestone: ---
Here is my example code:
#include
#include
int open_for_reading(int* retfd,const char* filename) {
int fd=open(filename,O_RDONLY);
if (fd!=-1) {
*retfd=fd;
return 1;
}
return 0;
}
int open_for_reading_long(signed long long int* d,const char* filename) {
long fd=open(filename,O_RDONLY);
if (fd != -1) {>--// gcc -fanalyze false positive
*d=fd;>-// no leak, we return in *d
return 1;
}
return 0;
}
Run with -fanalyzer gcc will complain that open_for_reading_long contains a
file descriptor leak. The warning goes away if I turn d into an int*, and it
also goes away if I turn fd into an int.
[Bug rust/119353] New: build failure: error[E0554]: `#![feature]` may not be used on the stable release channel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119353 Bug ID: 119353 Summary: build failure: error[E0554]: `#![feature]` may not be used on the stable release channel Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: felix-gcc at fefe dot de CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org, pierre-emmanuel.patry at embecosm dot com Target Milestone: --- cargo build --manifest-path ../../gcc/rust/checks/errors/borrowck/ffi-polonius/Cargo.toml --release --target-dir rust/ffi-polonius Compiling ffi-polonius v0.1.0 (/src/cvs/gcc/gcc/rust/checks/errors/borrowck/ffi-polonius) error[E0554]: `#![feature]` may not be used on the stable release channel --> src/lib.rs:19:1 | 19 | #![feature(extern_types)] | ^ For more information about this error, try `rustc --explain E0554`. error: could not compile `ffi-polonius` (lib) due to 1 previous error
[Bug rust/119353] [15 regression] Rust fails to build (build failure: error[E0554]: `#![feature]` may not be used on the stable release channel)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119353 --- Comment #2 from felix-gcc at fefe dot de --- I ran rustup update stable. $ rustc --version rustc 1.85.0 (4d91de4e4 2025-02-17)
[Bug c/117809] feature request: attribute malloc but for non-function-return-value return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117809 --- Comment #2 from felix-gcc at fefe dot de --- Another real-world example is asprintf from GNU libc: int asprintf(char **restrict strp, const char *restrict fmt, ...);
