Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: fabian-gcc at kloetzl dot info
Target Milestone: ---
Hi all,
Hereby I am forwarding a bug I filed against Debian [1]. One of my packages
there failed to build on hurd-i386 and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419
--- Comment #3 from kloetzl ---
Hm, I feared that this would be the answer I would get. This makes GCCs
__has_attribute much less useful than Clangs version where the docs state:
“This function-like macro takes a single identifier argument that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419
--- Comment #5 from kloetzl ---
Sorry for missing out the details, here goes:
I work in a Debian Hurd 20290705 image using qemu. The example file is given
above. Compiling with `gcc -Wall -Wextra ifunc.c` produces the following error.
error: i
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fabian-gcc at kloetzl dot info
Target Milestone: ---
Hi all,
There is a little quirks with `remove_if` and lambdas that mutably capture by
value. As a contrived example let's print all the odd numbers from a list and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81482
--- Comment #2 from kloetzl ---
I don't think that the runtime cost of the copies is measurable. My bigger
issue is that this quirks exposes the internal behaviour of the algorithm
implementation; In this case the fact that remove_if calls find_i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81482
--- Comment #4 from kloetzl ---
> And changing the algorithm to make no copies would not make it opaque, because
> the lack of copies would be observable. As the standard says, whether copies
> are made or not is unspecified. So if you want to tr
